S

Skill Entry

Structured logging

Defines a consistent set of log fields—request ID, user ID, feature flag, latency bucket, error code—so production debugging does not rely on grep across inconsistent printf-style strings. Structured JSON or key=value logging enables dashboards, alerts, and log aggregation tools to parse and query logs programmatically rather than through manual text searching.

Category Operations
Platform Codex / Claude Code
Published 2026-04-12
loggingobservabilitydebugging

Use cases

  • Building a new microservice where you want debuggability from day one rather than retrofitting logs after an incident
  • Debugging a production issue where you need to correlate logs across multiple services by request ID
  • An AI agent tool that calls external APIs and needs to expose its inputs, outputs, and errors in a queryable format
  • An incident where log volume is high and you need to filter quickly by severity, service, and time window without parsing text

Key features

  • Define the mandatory fields for every log entry: timestamp with timezone, service name, log level, and a unique request or trace ID
  • Define contextual fields appropriate to the operation: user ID for user-facing services, feature flag for conditional behavior, latency bucket for performance logging
  • Emit logs in a structured format (JSON or key=value) rather than human-readable strings so log aggregators can parse them automatically
  • Wire dashboards and alerts to specific field values so you can filter and alert on structured data without regex matching
  • Document the logging schema so new engineers know what fields are expected and how to add new ones consistently

When to Use This Skill

  • When building a new service and wanting observability built in from the start rather than retrofitted
  • When debugging an incident that requires correlating logs across multiple services
  • When log volume is high and you need to filter and alert programmatically

Expected Output

A logging schema with mandatory and contextual fields, implemented log statements in JSON or key=value format, and dashboards wired to structured field queries.

Frequently Asked Questions

How do I avoid logging too much and generating excessive log volume and cost?
Log at DEBUG level only in non-production environments. In production, log at INFO for expected events and ERROR or WARN for unexpected events. Use sampling for high-volume paths (health checks, metrics) while keeping full logging for errors.
What sensitive data should I avoid logging?
Never log passwords, API keys, full credit card numbers, or personal health information. Log user IDs and session IDs for debugging but not the content of user data unless it is explicitly needed and legally permissible.
How does structured logging relate to OpenTelemetry?
OpenTelemetry defines a standard log data model and SDK that supports structured logging. Adopting OTel for logs means your logs are compatible with a wide range of OTel-compatible observability backends without vendor lock-in.

Related

Related

3 Indexed items