Skip to main content

nginx access log parsing

Log Lens reads your nginx access logs and turns each request into a structured event, so HTTP traffic lands in the same dashboard as your application errors. This is how a spike in 500s or a flood of 404s becomes a searchable, groupable issue instead of a wall of raw text.

What it recognizes

A file is treated as an nginx access log when its name contains access or nginx and its first line matches the standard combined log format:

127.0.0.1 - alice [25/Jul/2026:10:15:42 +1000] "GET /api/orders?page=2 HTTP/1.1" 200 1024 "https://example.com/" "Mozilla/5.0"

The HTTP version and the trailing "referer" "user-agent" pair are optional, so plainer formats still parse. Any line that does not match the pattern is skipped rather than mis-parsed.

Status to severity

Each request's HTTP status code drives the event severity:

StatusSeverity
5xxERROR
4xxWARNING
everything elseINFO

That mapping is what lets you filter access traffic by severity alongside your other logs - surface only 5xx errors, or include 4xx warnings when you need them.

The event

Events are tagged with source nginx and type nginx_access. The message is built as HTTP <status> <method> <path>, for example HTTP 200 GET /api/orders. The path is the URL path with the query string stripped, which keeps requests to the same route grouped together as one issue even when query parameters differ.

Context fields

Every event carries the full request detail in its context, visible when you open the event:

FieldMeaning
ipClient IP address
methodHTTP method
targetRaw request target, query string included
pathPath only, query stripped
statusNumeric status code
bytesResponse size
refererReferer header (empty if absent)
user_agentUser-agent header (empty if absent)

The request timestamp is normalized to Y-m-d H:i:s; if a line's time can't be parsed, the current time is used instead.

Getting nginx logs in

Point a connector at the directory holding your access logs and Log Lens detects and ingests them automatically.