In the structured log entry, the traceId field is "abc-126-mno". What is the primary purpose of the traceId field in a distributed system?
traceId links all log entries for one logical request across services.
In a microservices or distributed system, a single user action (e.g., "log in") triggers calls to multiple services: the API gateway, the auth service, perhaps a database service. Each service writes its own logs. Without a shared identifier, finding all log lines belonging to one request is nearly impossible.
How trace IDs work:
The first service (often the API gateway) generates a traceId for each inbound request
It is passed in HTTP headers (e.g., X-Trace-Id, traceparent in W3C Trace Context) to every downstream service
Each service writes the traceId into its log entries
You can then run: grep "abc-126-mno" /logs/*.json and see the full picture
Notice in the log stream: Entry 4 and Entry 5 share traceId: "abc-126-mno" — they belong to the same request. Entry 5 (api-gateway) received the 423 from Entry 4 (auth-service).
Related standards: OpenTelemetry, W3C Trace Context, Jaeger, Zipkin, Datadog APM Key terms: distributed tracing, span, trace, correlation ID, request ID
The second and third log entries are both at level WARN. What action should an on-call engineer take upon seeing WARN entries — based on how severity levels are used?
WARN = monitor and investigate; do not ignore, do not panic.
Log severity levels form a hierarchy of urgency:
DEBUG — verbose detail for development; disabled in production
INFO — normal operations; useful for audit trails
WARN — something unusual occurred but the system is still functional; a potential problem signal
ERROR — an operation failed; a user or process was impacted; requires attention
FATAL — the process cannot continue and will (or should) exit
WARN in this context: A single WARN (attempt 1) might be a user mistyping their password once — not noteworthy. But two consecutive WARNs from the same userId (u-8821) in under 3 seconds is a pattern worth noting. Good monitoring tools set up alerts like: "3 WARN entries for the same userId within 10 seconds" — which preempts the ERROR.
Good on-call practice: look at WARNs in context. A burst of WARNs across many userIds suggests a credential-stuffing attack. A single WARN is noise.
An engineer wants to find all log entries related to the lockout event from a system with hundreds of microservices. Which field should they filter on?
traceId: "abc-126-mno" is the most precise filter for one specific lockout event.
Here is why the other options are less precise:
userId: "u-8821" — returns all activity by this user: their successful login (entry 1), historical requests, etc. Too broad if you only care about the lockout incident.
level: "ERROR" — returns every ERROR from every service across the entire system. Thousands of entries, not useful for a specific event.
service: "auth-service" — returns all auth-service logs for the day. Also too broad.
traceId: "abc-126-mno" — returns exactly the entries for that one request: the lockout error (entry 4) and the API gateway downstream error (entry 5). Precise and complete.
When to combine filters: Sometimes you use userId + time range to investigate a user's session, then drill into a specific traceId from the results.
Tools that use traceId filtering: Kibana, Grafana Loki, Datadog, Splunk, AWS CloudWatch Logs Insights Typical log query:traceId="abc-126-mno" | json
The lockDurationSeconds field in the log entry is 900. What does this field represent, and what does its presence in the log suggest about the logging practice?
lockDurationSeconds: 900 = 15-minute lockout; structured fields carry business context.
900 seconds = 15 minutes. This tells the reader (and any monitoring system) exactly how long the user will be unable to log in without contacting support.
Why this is good structured logging practice:
Plain text log:"Account locked" — tells you something happened, nothing actionable
Structured log:"message": "Account locked after 3 failed attempts", "lockDurationSeconds": 900, "userId": "u-8821" — tells you what happened, for whom, and how long
Benefits of structured/JSON logs:
Machine-readable: log aggregation tools can filter, group, and alert on field values
Queryable: lockDurationSeconds > 3600 finds accounts locked for more than an hour
No regex needed: parse-free extraction of fields
Good structured log fields to include: timestamp (ISO 8601), level, service, message, traceId, userId, duration, error codes, relevant business counts Key terms: structured logging, log schema, log aggregation, Elastic Common Schema (ECS)