Access-log analytics
Turn the nginx access logs Log Lens already parses into a traffic, status-code, and top-path view — no separate ingestion, no extra configuration beyond enabling it. Off by default; enable per application in Settings → Plugins → Access-log analytics. Once on, an Access logs view appears in the sidebar.
It reads data you're already collecting
This plugin doesn't ingest anything new. Every nginx access line Log Lens has already parsed (see nginx access parsing) carries structured per-request fields — status code, method, path, user agent — captured as generated columns on the occurrence row. Enabling this plugin just adds a view that aggregates those columns; it does not change what's ingested or reparse anything retroactively (existing occurrences already have the fields, since they're derived at insert time).
What you get
Settings → Access logs (or GET ?api=access-analytics&days={n}, 1–90, default 7) returns:
- Totals and error rate — request count, unique paths, and the 4xx+5xx share of requests over the window.
- Status-code breakdown — 2xx/3xx/4xx/5xx counts.
- Traffic by day — request count and error count per day, for the trend chart.
- Top paths — the busiest endpoints, each with its own error count.
- Error paths — paths ranked purely by error count, separate from the busiest-overall list (a low-traffic endpoint that's completely broken won't show up in "top paths" but will here).
- Methods — request count per HTTP method.
- Top user agents — useful for spotting a misbehaving bot or scraper hammering one endpoint.
What it can't tell you
The default nginx combined log format doesn't record request duration, so latency is not reported — this plugin has no p50/p95/p99 view, and can't, unless your nginx log format is changed to include $request_time and the parser is extended to capture it. If you need latency, this isn't the place to look for it today.
Why it's fast even at volume
Each request field is stored as a generated column with its own index, computed once at insert time from the occurrence's stored context — not recomputed by parsing JSON out of every row on every dashboard load. Every query in this view runs through one shared query building block that resolves those columns once per row, so the status/method/path/agent aggregates share a single underlying scan of the window's access rows rather than each re-deriving them independently.
Related
- Nginx access parsing — where the fields this plugin aggregates actually come from.
- Modules — scope your access logs to a module the same way any other source is organized.