Practice structured logging vocabulary: JSON log format, log fields, logs lacking context, querying logs with JQL, and trace IDs linking requests.
0 / 5 completed
1 / 5
The observability guide requires all services to emit logs in ___ format instead of plain text.
JSON log format means each log entry is a JSON object with named fields. This lets log aggregation tools like Elasticsearch, Loki, or Splunk automatically parse and index the fields without needing custom regex parsers.
2 / 5
A standard JSON log entry includes ___ fields: timestamp, level, message, and trace_id.
Log fields are the key-value pairs in a structured log entry. Standard fields include timestamp (when), level (severity), message (human description), service (which component), and trace_id (which request). Consistent field names enable cross-service querying.
3 / 5
During debugging an engineer says: 'The log ___ context — I can't tell which user or request this error belongs to.'
'The log lacks context' means the log entry only contains a generic message without identifying fields like user_id, request_id, or session_id. Without context, debugging requires cross-referencing multiple data sources, slowing incident resolution.
4 / 5
The SRE queries log data using ___, writing filters like level:ERROR AND service:payments.
JQL, KQL (Kibana Query Language), or Lucene query syntax are domain-specific languages for searching structured log fields in platforms like Elasticsearch/Kibana, Grafana, or Splunk. They enable filtering by field value, range, and boolean logic.
5 / 5
The trace_id field ___ all logs for a single request across multiple services.
A trace_id is a unique identifier (UUID or similar) assigned at the entry point of a request and propagated through all downstream services via headers. Including it in every log entry lets you retrieve the complete story of a single request across a distributed system.