What this prompt does
This prompt writes a Bash script that analyzes [log_type] logs at [log_path] in [log_format] over the past [time_range]. It parses timestamp, severity, component, and message with awk and sed, summarizes entries by severity with trend comparison, groups the top [top_n] error messages after normalizing variable parts like IDs and IPs, detects anomalies where a [anomaly_window]-minute window exceeds [error_threshold]x baseline, lists unique IPs cross-referenced against [blocklist_source], computes p50/p95/p99 latency over [slow_threshold] ms, and outputs both a terminal table and JSON.
The variables define what the analyzer looks at and how sensitive it is. [log_format] tells the parser how to split fields, [top_n] and [error_threshold] control how much rises to your attention, and [slow_threshold] flags slow endpoints. The error-grouping step normalizes IDs and timestamps before counting so genuinely distinct errors are not scattered across thousands of near-identical lines.
When to use it
- A production incident starts in the logs and you need patterns fast
- You want errors grouped by normalized pattern instead of raw line counts
- Computing p95/p99 latency to find slowness when nothing is throwing
- Detecting anomaly windows where error rate spikes above baseline
- Cross-referencing request IPs against a blocklist like
[blocklist_source] - Producing JSON output to feed a monitoring dashboard
Example output
You get a Bash script that prints a severity summary with trend, a grouped top-[top_n] error table with normalized messages and counts, flagged anomaly windows, a unique-IP list with request counts and blocklist matches, and latency percentiles highlighting endpoints over [slow_threshold] ms. The same results are written to a JSON file for dashboards. Output is dual-format: terminal table plus JSON.
Pro tips
- Set
[log_format]precisely; an awk field split that does not match your real format produces garbage counts - Tune
[error_threshold]and[anomaly_window]to your traffic — too tight and normal bursts alert, too loose and real spikes hide - Trust the normalization step in error grouping; without stripping IDs and IPs, the same error appears as thousands of unique messages
- Use the p95/p99 latency view first when something feels slow but nothing errors; averages hide the tail that users actually feel
- Keep
[blocklist_source]lookups rate-limited or cached if it is an API like AbuseIPDB, or a large unique-IP set will hit limits - Cap
[top_n]to a readable number; you want the signal, not every rare error in one table - Lean on the trend comparison against the previous period; an absolute error count means little until you know whether it is higher or lower than yesterday's baseline
- Limit the analysis to the past
[time_range]so a long-lived log file does not make every run scan months of history; bounding the window keeps the script fast enough to run repeatedly during an active incident
