DevOps · Observability

Log Aggregation Strategies — A Field Guide

Once you run more than one service, logs scattered across machines are useless in an incident. Aggregation centralises them — and the strategy is as much about cost as about collection.

John Kihiu12 min read

A single application's logs are easy; a distributed system's are a nightmare without aggregation. When a request touches five services across many machines, debugging by SSH-ing into each to grep local files is hopeless. Log aggregation centralises logs from everywhere into one searchable place. The strategy that makes it useful — and affordable — comes down to structure, correlation, retention, and cost, because at volume, logging bills become real.

Centralise everything

The foundation is shipping logs from every service and host to a central system where they can be searched together. This is what lets you follow a request across services and see the whole picture in an incident instead of a fragment. Whatever the backend — an ELK/OpenSearch stack, Loki, or a managed service — the principle is the same: logs must leave the individual machines and land somewhere unified, or they cannot help you when it matters.

Structured logs and correlation ids

Centralised plain-text logs are searchable but hard to query precisely. Structured logging — emitting logs as structured data (JSON) with consistent fields — lets you filter and aggregate on fields like service, level, user, or status, turning logs into queryable data. Pair this with a correlation id: generate an id per request and attach it to every log line across every service that request touches. Now you can pull up the complete story of one request across the whole system with a single query, which is the single most valuable thing aggregation gives you.

Retention and cost

Log volume — and the bill — grows relentlessly, so retention strategy is central, not an afterthought:

Log volume is a cost you must actively manage

Logging feels free until the aggregation bill arrives, and it scales with volume that only ever grows. Treat retention tiers, log levels, and sampling as ongoing cost controls, not one-time settings. The team that logs everything at debug level forever discovers that observability has quietly become one of its largest infrastructure costs — manageable, but only if managed deliberately.

Log aggregation centralises logs from every service into one searchable place, made genuinely useful by structured logging and a correlation id that ties a request's story together across services. Layer on tiered retention and active cost control, because log volume and its bill grow without end. Get the structure and the cost strategy right and aggregated logs become the tool that turns a distributed-system incident from guesswork into a query.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.