Hosting Operations
Read-only, can be slowCount Request IDs in Error Lines
An app log includes request IDs, and you need to see which failing request appears more than once.
Command
grep -Ei 'error|timeout|fatal|exception' fixtures/incidents/app.log | awk '{for (i=1;i<=NF;i++) if ($i ~ /^request_id=/) print $i}' | sort | uniq -c | sort -nrBefore you run this
System impact: Read-only. Can create load on large logs, directories, filesystems, or process tables.
When not to use it: Do not use it when logs lack stable IDs; group by source, path, user, or job name instead.
Expected output
Counts followed by request_id values.
System impact
Read-only, can be slow. Nothing changes. The command extracts request IDs from severe lines and counts repeats.
Scope this to the smallest useful path or service on busy systems.
Recovery / rollback: no state is changed.
When to use it
Use when multiple log lines may belong to the same failed request or job.
When not to use it
Do not use it when logs lack stable IDs; group by source, path, user, or job name instead.
Watch this command run
Command transcript
This sanitized transcript shows the commands and output shape without exposing host details.
$ grep -Ei 'error|timeout|fatal|exception' sample-files/incidents/app.log
2026-06-25T14:03:08Z level=ERROR service=api request_id=req-103 msg=database_timeout timeout_ms=30000
2026-06-25T14:03:12Z level=ERROR service=api request_id=req-103 msg=retry_failed upstream=db
2026-06-25T14:05:10Z level=FATAL service=worker request_id=req-105 msg=job_runner_exit code=137
2026-06-25T14:06:33Z level=ERROR service=api request_id=req-107 msg=payment_provider_500 provider=demo-pay$ grep -Ei 'error|timeout|fatal|exception' sample-files/incidents/app.log | awk '{for (i=1;i<=NF;i++) if ($i ~ /^request_id=/) print $i}' | sort | uniq -c | sort -nr
2 request_id=req-103
1 request_id=req-107
1 request_id=req-105View commands shown
These are the commands shown in the sanitized transcript.
Commands shown
grep -Ei 'error|timeout|fatal|exception' fixtures/incidents/app.loggrep -Ei 'error|timeout|fatal|exception' fixtures/incidents/app.log | awk '{for (i=1;i<=NF;i++) if ($i ~ /^request_id=/) print $i}' | sort | uniq -c | sort -nr
next steps
Related commands
Count App Errors by Minute
A minute-by-minute count shows whether an incident is a spike or a drip.
awk 'tolower($0) ~ /(error|fatal|timeout|exception)/ {minute=substr($1,1,16); count[minute]++} END {for (m in count) print count[m], m}' fixtures/incidents/app.log | sort -nr
Show Context Around the First App Error
The first error often explains more than the last one.
awk '{buf[NR%5]=$0} tolower($0) ~ /(error|exception|fatal)/ {for (i=NR-4;i<=NR;i++) if (i>0) print buf[i%5]; exit}' fixtures/incidents/app.log
Group Server Errors by URL Path
A 500 spike is easier to triage when the broken path is obvious.
awk '$9 ~ /^5/ {count[$7]++} END {for (path in count) print count[path], path}' ./fixtures/nginx/access.log | sort -nr | head
Find Unusually Large Web Responses
A few huge responses can explain bandwidth, latency, and suspicious download patterns.
awk '$10 ~ /^[0-9]+$/ && $10 > 1000000 {print $10, $1, $7, $9}' ./fixtures/nginx/access.log | sort -nr | head
Summarize HTTP Status Codes
Before chasing individual lines, get the shape of the whole log.
awk '{count[$9]++} END {for (code in count) print count[code], code}' ./fixtures/nginx/access.log | sort -nr
Study mapping
Use this as independent command practice: read the notes, predict the output, then compare it with the example before using a real shell.
Useful for
- LPIC-1 style command-line practice
- LFCS style performance tasks
- Linux+ style troubleshooting review
Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.