What is the difference between centralized and distributed logging in microservices?
Learn the difference between centralized and distributed logging in microservices, why correlation IDs matter, and how tools like ELK aggregate logs.
Expected Interview Answer
Distributed logging means each microservice writes its own logs locally in isolation, while centralized logging ships every service's logs into one aggregated store (like ELK, Loki, or a cloud log service) so they can be searched, correlated, and analyzed together.
In a distributed setup, logs live scattered across dozens of containers and hosts, making it painful to trace a single user request that crossed several services. Centralized logging solves this by forwarding logs through an agent or sidecar to a common pipeline, where they are indexed, tagged with a correlation or trace ID, and queried from a single dashboard. The centralized approach is the industry standard for production microservices because it turns fragmented, ephemeral output into a searchable, durable, unified view.
- Single searchable view across all services
- Correlate a request across service boundaries with trace IDs
- Logs survive after ephemeral containers die
- Faster incident debugging and root-cause analysis
- Enables alerting, dashboards, and long-term retention
AI Mentor Explanation
Distributed logging is like every fielder keeping his own private notebook of what happened near him during the match. When the captain wants to review a controversial dismissal, he must run to eleven scattered players and stitch their notes together. Centralized logging is the official scorer's single scorebook where every delivery, run, and wicket is recorded in one place, so the whole innings can be reconstructed instantly from one source.
Step-by-Step Explanation
Step 1
Emit structured logs
Each service logs in JSON with fields like service name, level, timestamp, and a correlation/trace ID.
Step 2
Collect with an agent
A log shipper or sidecar (Fluent Bit, Filebeat, Promtail) reads each container's stdout and forwards it.
Step 3
Aggregate in a pipeline
Logs flow into a central store such as Elasticsearch, Loki, or a cloud logging service.
Step 4
Index and correlate
The store indexes fields and links entries by trace ID so one request can be followed across services.
Step 5
Query and alert
Engineers search, build dashboards (Kibana/Grafana), and set alerts on error patterns from one place.
What Interviewer Expects
- Clear contrast between scattered local logs and one aggregated store
- Mention of correlation/trace IDs for cross-service tracing
- Awareness that containers are ephemeral so logs must be shipped out
- Naming a real stack (ELK, Loki/Grafana, Fluentd)
- Understanding that centralized logging is standard for production
Common Mistakes
- Confusing logging with metrics or distributed tracing entirely
- Forgetting correlation IDs, making cross-service tracing impossible
- Assuming logs persist inside containers that get destroyed
- Logging unstructured text that cannot be indexed or queried
- Ignoring log volume, cost, and retention in centralized systems
Best Answer (HR Friendly)
“Distributed logging keeps each service's notes on its own machine, so investigating a problem means checking many places separately. Centralized logging gathers everything into one searchable system, so teams can trace a request across all services and fix issues much faster.”
Code Example
# fluent-bit.conf
[INPUT]
Name tail
Path /var/log/app/*.log
Parser json
[FILTER]
Name record_modifier
Match *
Record service order-service
[OUTPUT]
Name es
Match *
Host elasticsearch.logging.svc
Port 9200
Index microservices-logsFollow-up Questions
- How do correlation IDs get propagated across service calls?
- What is the difference between logging, metrics, and tracing?
- How would you control log volume and storage costs at scale?
- What role does a sidecar play in log collection?
- How do you handle sensitive data (PII) in centralized logs?
MCQ Practice
1. What is the main problem centralized logging solves in microservices?
Centralized logging aggregates scattered logs so a single request crossing many services can be traced from one place.
2. Why can't you rely on logs stored only inside containers?
Containers are short-lived, so logs must be shipped to durable central storage before the container is destroyed.
3. Which field is most critical for correlating logs across services?
A shared correlation or trace ID lets you stitch together all log entries belonging to one request across services.
Flash Cards
Distributed logging — Each service keeps its own logs locally, in isolation, with no shared view.
Centralized logging — All services' logs are shipped to one aggregated, indexed, searchable store.
Correlation ID — A shared identifier passed through services to link all logs for one request.
Why ship logs out? — Containers are ephemeral; logs must persist in durable central storage.
Continue Learning
Related Interview Questions
How do you handle distributed tracing and observability in microservices?
medium
What is metric cardinality, and how do you keep microservice observability affordable without losing the ability to debug?
medium
What is the sidecar pattern and how is it used in microservices?
medium
What is Distributed Tracing and Why Is It Needed?
medium