Centralized logging: how to get all your logs in one place

Centralized logging is the practice of collecting the logs from every service, container, and host into one place, so you can search and analyze them together instead of logging into machines one by one. It is the foundation that makes monitoring, alerting, and investigation possible once your system is more than a single process. Here is what it is, why you need it, and how to set it up.

What centralized logging is

A log is a timestamped record of something that happened: a request came in, a query ran, a payment failed. The format most logging still descends from, syslog, defines a log entry as a message with a timestamp, a source, and a severity.¹ Every service you run produces a steady stream of these, and by default each stream stays where it was written: a file on that box, or the stdout of that container.

Centralized logging is the practice of pulling all of those streams into one place. Instead of a dozen separate log files scattered across machines, you ship every log to a single backend that stores, indexes, and lets you search them together. It is not exotic: in Grafana's 2025 observability survey, 87% of teams already collect logs.² The interesting question is not whether to keep logs, it is whether they are somewhere you can actually use them.

Why you need it once you have more than one service

A single process on one box can get away with a local log file. The problem is that almost nothing stays that simple. A normal backend is several services, a database, some background workers, and a few outbound calls, spread across containers and hosts. That breaks local logging in three ways.

• Logs are scattered. To answer one question you would have to log into several machines and grep each one, in whatever format that service happens to use.
• Containers are ephemeral. When a container restarts or is rescheduled, its local logs are gone. The logs you most want, from the thing that just crashed, are exactly the ones that disappear.
• You cannot follow a request. One user action crosses several services. Without a shared place and a shared request id, you cannot line those log lines up into a single story.

Centralized logging fixes all three at once: the logs outlive the container that wrote them, they sit in one queryable store, and once they carry a shared id you can trace one request end to end. That is why it is the groundwork for everything else, monitoring, alerting, and the investigation you do when something breaks.

How centralized logging works

Whatever tool you use, the pipeline is the same shape: get the logs off each machine and into one searchable place.

1. Emit. Your apps write logs, ideally structured as JSON with fields, to stdout or a file. Structure here is what makes everything downstream searchable rather than a wall of text.
2. Collect. An agent on each host or container gathers those logs. The vendor-neutral standard for this is the OpenTelemetry Collector, which receives, processes, and exports telemetry in one place; Fluent Bit is another common collector.³
3. Ship. The collector forwards the logs to a central backend, batching and retrying so nothing is lost if the network hiccups.
4. Enrich and structure. Along the way, logs get tagged with metadata, the service, host, environment, and a trace id, so lines from different services can be joined together.⁴
5. Store, index, and retain. The backend stores and indexes the logs so they are searchable, and you decide how long to keep them. Retention is where a lot of the cost lives.
6. Search and analyze. Now you can query across everything at once, which is the whole point, and build monitoring and alerts on top.

Centralized logging tools and approaches

The tools mostly differ on one axis: how much of the stack you run yourself versus how much you pay someone else to run, and what that costs as your log volume grows.

The tradeoff is real. Self-hosted options give you control and cost you the time to run, scale, and tune them, which for a small team is time you do not have. Hosted platforms remove the ops work but bill by volume, and log volume grows faster than you expect, which is why cost is a top-three observability concern in the 2025 survey, with spend averaging around 17% of compute infrastructure.² And nearly all of them still hand you a query language and leave the analysis to you.

Centralized logging without running the stack

Fixter centralizes your logs without making you stand up ELK or manage a Datadog bill. You drop in the SDK, built on OpenTelemetry, and your logs, traces, and metrics are collected and stored for you. There is no collector to configure and no cluster to operate. The difference comes after they are centralized: instead of a dashboard and a query language, you ask about your logs in plain language, from your editor, over MCP, and Fixter runs the search and the investigation for you.

The point of centralizing logs was never the storage, it was being able to ask one place what happened. For a small team that is the part worth having without the stack underneath it. From here, the natural next steps are turning those centralized logs into log monitoring and alerts, wiring them into Claude Code over MCP, and if you are comparing hosted options, Datadog alternatives for small teams.

Frequently asked questions

What is centralized logging?

Centralized logging is the practice of collecting the logs from every service, container, and host into one place, so you can search and analyze them together. Instead of logging into each machine to read local files, all your logs are shipped to a single backend where they are stored, indexed, and searchable across the whole system.

Why is centralized logging important?

Because a modern app is not one process. It is several services across containers and hosts, and containers are ephemeral, so a crashed one takes its local logs with it. Without a central place you cannot follow a request across services or search everything at once, which makes monitoring and investigation nearly impossible.

What is the difference between centralized logging and log aggregation?

Log aggregation is the collection step: gathering log lines from many sources and forwarding them onward. Centralized logging is the whole practice built on top of that, including storing, indexing, retaining, and searching those aggregated logs in one backend. Aggregation gets them together; centralized logging is what you do with them once they are.

What tools are used for centralized logging?

For collecting and shipping, the OpenTelemetry Collector and Fluent Bit are common. For storing and searching, options range from self-hosted ELK/OpenSearch and Grafana Loki to hosted platforms like Datadog and Better Stack. Fixter takes a different route: your logs are centralized through its SDK and you query them in plain language over MCP.

Do I need centralized logging for a small app?

As soon as you run more than one service or container, yes. A single process on one box can get by with a local file. The moment you have a couple of services, background workers, or anything that restarts and loses its logs, you need them in one searchable place, and it is far easier to set up early than to retrofit later.