Logging records timestamped events with textual or structured payloads. Events may describe expected behavior, debugging details, warnings, or errors, and humans usually consume them by searching or correlating them with other signals. section 2.3
Useful events provide actionable context. Structured formats such as JSON and labels improve correlation; common alternatives include syslog, Apache common log format, and binary journal formats. In containerized systems, writing to stdout lets log agents collect and route events. section 2.3 section 3.2.3
Logging supports several practical workflows:
- Debug existing code and identify the service or code responsible for a bug or outage. section 2.3.4
- Support soak tests, performance tests, and chaos engineering by showing where microservices break. section 2.3.4
- Provide operational, change-related, regulatory, and security context during incident response. section 2.3.4
- Correlate with metrics and traces: move from an alert to a trace and then into service logs for detailed verification. section 1.5.2
Structured logs from an echo service
A small Go HTTP service logs an input event at INFO and an error event when a request fails. Logrus adds a service label and emits JSON, while the service continues serving requests on port 4242. section 2.3.1
Instrumentation is usually inexpensive and widely supported, but distributed systems still pay for collection, routing, runtime footprint, ingestion, reliability, security, and long-term storage. Select agents and retention according to workload utility and cost. section 2.3.3
Kubernetes exposes system logs from control-plane components and container runtimes, alongside application logs. kubectl logs is useful for development and testing, but transient retention is generally unsuitable for production; routing to a central service requires an explicit strategy. section 3.2.3
