2:02 PM: payments fail. The API reports Redis timeout, the worker mentions MySQL deadlock, nginx shows 499 client disconnect. Three engineers open three SSH sessions. Nobody shares the same timeline — nginx logs use local time, PHP uses misconfigured UTC. An hour passes before someone spots a canary deploy visible on one of four nodes.
Centralizing logs is not about "a pretty dashboard." It is rebuilding one timeline when the outage crosses load balancer, application, cache, queue, and database. Without correlation, you stack monologues; with correlation, you read a story.
Pipeline: collect, transport, store, query
A typical architecture uses a light agent — Vector, Fluent Bit, or Filebeat — on each VPS or Kubernetes node. Transport goes through HTTPS bulk or, at scale, Kafka. Storage picks Loki, OpenSearch, or a cloud logging service. The UI — Grafana or Kibana — enables search and alerts.
| Stack | Strength | Cost / complexity |
|---|---|---|
| Loki + Grafana | Labels, metrics integration | Moderate |
| ELK/OpenSearch | Rich text search | High |
| SaaS | Fast time-to-value | Volume €€, jurisdiction |
On a small VPS, sending Vector to Loki Cloud or Grafana Cloud avoids self-hosting Elasticsearch. Compare offers via the directory and comparator.
Structure, personal data, and GDPR
One JSON line per event is enough: timestamp, level, service, request_id, message. Mask or pseudonymize IPs and emails per retention policy — logs may hold personal data. Document duration and access, especially with SaaS outside the EU.
Keep local rotation too: a full VPS disk kills the app before the central store receives anything. Central complements local; it does not replace immediate resilience.
Multi-service correlation
Inject and propagate a common id. nginx can generate $request_id and pass it upstream. Laravel or Symfony add context in middleware. The worker receives the same id in the job payload. A Grafana dashboard filtering {req_id="abc"} crosses api, nginx, and worker in one search.
Under Kubernetes, combine pod, namespace, container labels with application request_id. Without that discipline, Kibana becomes infinite scroll.
Retention, cost, and sampling
Index everything at ERROR and WARN; sample DEBUG in production. Archive to cold object storage for long compliance. Alert on error rate, not every line — otherwise alert fatigue kills vigilance.
The climax: centralized logs without context culture
Distributed outages are understood through a correlated timeline, not infinite scroll in a search UI.
Decide and move forward without blind spots
First standardize structured JSON and enforce request_id on every service before buying more storage. Deploy a light agent on each node and define tiered retention — short hot, long archive per audit needs. Write an incident runbook: time window, service and level filter, group by request_id, link to deploy and metrics. Test with a simulated drill: one end-to-end request must be found in one search — otherwise fix id propagation before investing further.
Frequently asked questions
ELK, Loki, or SaaS — which to choose?
ELK or OpenSearch excel at full-text search with high RAM and disk cost. Loki indexes labels rather than content — cheaper, effective with Prometheus. SaaS speeds time-to-value, but watch billed volume and EU data residency.
What log format should you target?
Structured JSON with UTC timestamp, level, service, request_id, and user id if GDPR allows. Avoid unparsed multiline stack traces that break search.
How long should logs be kept?
Keep 7–30 days hot for incident debugging, then archive 90 days to a year depending on business rules. Infinite retention raises cost and GDPR risk.
How do you correlate app, nginx, and worker?
Propagate the same request_id — e.g. via X-Request-ID — from load balancer to PHP to queue job. Without a common id, centralizing only centralizes noise.
Centralizing is about rebuilding the story — not archiving noise without a thread.