Test your knowledge: Nginx Observability

Question 1 of 6

Treating `log_format` as a schema means what, concretely?

Think about who consumes the log a year later.

Answer options A Validating the format string with a linter B Choosing stable, documented fields and variable slots up front — the access log becomes a typed dataset downstream systems can rely on C Using only NGINX's predefined combined format D Logging every variable NGINX knows

A format like 'request_id, timing, upstream, cache status' is an API for your observability stack: field order and meaning stay stable, so dashboards and alerts survive config evolution.

Review this lesson

Question 2 of 6

What makes an access log valid JSON per line?

One argument defuses hostile values.

Answer options A log_format json escape=plain with hand-written quoting B escape=json on the log_format — values with quotes, newlines, or control characters are encoded safely C Wrapping the whole log_format in to_json D Writing fields in alphabetical order

escape=json encodes the characters that would break the line as a JSON document — URLs with quotes, user agents with newlines. Without it, one malicious Referer corrupts every downstream parser.

Review this lesson

Question 3 of 6

Which variable answers 'was this response served from cache?' in the access log?

Its values are the cache state machine's own labels.

Answer options A $cached B $upstream_cache_status — HIT, MISS, EXPIRED, UPDATING, STALE, BYPASS C $proxy_hit D $sent_http_cache

$upstream_cache_status logs the exact cache path each response took — the field your hit-rate dashboards slice on. Alongside $upstream_response_time and $request_time it completes the golden-signal view.

Review this lesson

Question 4 of 6

`stub_status;` on a localhost-only location exposes what?

Seven counters, no dependencies.

Answer options A The full request log in real time B A tiny plaintext page of counters: active connections, accepts/handled/requests, reading, writing, waiting C Prometheus metrics natively D Per-upstream latency percentiles

stub_status is the built-in health page: active connections, totals, and the read/write/wait split of the event loop. Prometheus needs an exporter in front of it; percentiles need log math — stub_status is deliberately minimal.

Review this lesson

Question 5 of 6

Raising `error_log` to `debug` in production is dangerous mainly because of what?

The debug build requirement is real, but the production risk is volume.

Answer options A Debug logs contain credentials B Per-connection event traces generate enormous volume — disk and CPU — so it belongs on a canary instance, not the fleet C It disables access logging D It requires a --with-debug build AND changes routing

A --with-debug build unlocks [debug] lines tracing every event — invaluable on one canary, catastrophic on a busy fleet: I/O saturation and log noise that hides real errors. Scope it to a server block, sample it, remove it.

Review this lesson

Question 6 of 6

Mapped to NGINX, the four golden signals are answered by which log variables?

Traffic, errors, latency, saturation — pick the closest variable for each.

Answer options A $status, $upstream_response_time, $upstream_addr, $request_time — errors, latency, saturation's inputs, and duration B $bytes_sent, $gzip_ratio, $scheme, $host C $remote_addr, $http_user_agent, $request_method, $server_name D $connections_active, $pid, $msec, $request_id

$status counts errors by class, $upstream_response_time isolates backend latency, $request_time the whole request, and $upstream_addr/$upstream_cache_status expose where work happened. Four lines of log_format, and the golden signals are queryable.

Review this lesson

Test your knowledge: Nginx Observability