Learn what centralized logging is, why it matters, how to implement it, and which tools to use. Covers architecture, protocols, and practical setup.
When your application runs on one server, you SSH in and read the log file. When it runs on 20 containers across 3 services, that approach falls apart. Centralized logging solves this by collecting all logs into a single, searchable system.
Centralized logging is the practice of shipping logs from every source — application servers, containers, databases, load balancers, cloud functions — to a single platform where they can be searched, filtered, and analyzed together.
Instead of this:
ssh server-1 → tail -f /var/log/app.log
ssh server-2 → grep "error" /var/log/app.log
ssh server-3 → cat /var/log/app.log | grep "user-123"
You get this:
level:error service:api user_id:123 → 14 results in 8ms
Every log, from every source, in one search. That's the core value.
Containers restart. Kubernetes pods get rescheduled. Lambda functions spin up and down. When the container dies, its logs die with it — unless you shipped them somewhere first.
A user reports a 500 error. The request touched your API gateway, auth service, payment service, and notification service. Without centralized logging, you'd need to SSH into four machines and manually correlate timestamps. With it, you search by trace ID and see the full request path in one view.
You can't set up "alert me when error rate exceeds 5%" if your logs are scattered across servers. Centralized logging enables threshold-based alerts, anomaly detection, and dashboards — all from the same data.
Many industries require log retention for 30, 90, or 365 days. A centralized system with configurable retention policies handles this automatically.
A centralized logging system has three components:
Logs need to get from the source to the central system. There are three approaches:
Direct SDK integration — Your application sends logs directly via HTTP:
import { LogFlow } from '@getlogflow/js'
const logger = new LogFlow({
apiKey: process.env.LOGFLOW_API_KEY,
service: 'api',
})
logger.info('request.handled', { path: '/api/users', status: 200 })
This is the simplest approach and works well for applications you control. See the quick start guide for setup.
Log shippers — Agents like Fluentd, Fluent Bit, Vector, or Filebeat read log files and forward them:
# Fluent Bit config — read Docker logs, forward to LogFlow
[INPUT]
Name tail
Path /var/log/containers/*.log
[OUTPUT]
Name http
Match *
Host api.getlogflow.com
Port 443
URI /v1/logs
Header Authorization Bearer lf_your_api_key
Format json
tls On
Log shippers are ideal for infrastructure you don't control (databases, load balancers, third-party services).
OpenTelemetry — The vendor-neutral standard for telemetry. The OTel Collector receives logs, metrics, and traces and forwards them to any backend. See our OpenTelemetry guide.
The central system needs to store logs efficiently and make them searchable. The two dominant storage engines:
| Engine | Strengths | Weaknesses |
|---|---|---|
| Elasticsearch | Mature ecosystem, full-text search | JVM memory hungry, complex to operate, expensive at scale |
| ClickHouse | Column-oriented, fast aggregations, 10x compression | Newer ecosystem, fewer integrations |
LogFlow uses ClickHouse, which delivers sub-12ms search times at a fraction of the storage cost. For a deeper comparison, see ClickHouse vs Elasticsearch for logs.
Once logs are centralized, you need tools to make sense of them:
Centralized logging works best with structured (JSON) logs:
{"timestamp": "2026-08-28T14:23:11Z", "level": "error", "service": "api", "message": "payment.failed", "user_id": 42, "error": "card_declined", "amount": 99.00}
Unstructured logs require parsing rules (regex, grok patterns) to extract fields. This is fragile and slow. If you control the application, always log structured JSON.
The fastest path to centralized logging:
From zero to centralized logging in under 5 minutes.
Free plan available. No credit card required. Up and running in 2 minutes.
Get started freePython Logging Best Practices in 2026
Stop using print() for debugging. Here's how to set up production-ready logging in Python with the standard library and beyond.
7 ELK Stack Alternatives for Log Management in 2026
Elasticsearch, Logstash, and Kibana are powerful but expensive to operate. Here are 7 alternatives that don't need a platform team.
Docker Compose Logging: Collect Logs from Multi-Container Apps
Docker Compose makes it easy to run multi-container apps. Here's how to make their logs actually useful.