What Is Log Aggregation?

Last verified on Nov 8, 2026.

Log aggregation is the practice of collecting logs from many hosts, containers, and services into one central place where you can search them together. Without it, you find a failure by logging in to machines one at a time, and the logs of a container that has already been replaced are gone. With it, one query spans every service.

The Three Tiers

NIST SP 800-92 describes a log management infrastructure in three tiers:

NIST calls servers that receive logs from multiple generators "collectors or aggregators." That second tier is what most people mean by log aggregation.

Agents and Gateways

Two roles show up in every pipeline. An agent sits next to the logs, and a central tier receives from many agents.

• Agent. The OpenTelemetry Collector's agent pattern runs a Collector alongside the application or on the same host, such as a sidecar or DaemonSet. Vector calls its equivalent the daemon role, and recommends it for collecting everything on a single host.
• Aggregator or gateway. OpenTelemetry's gateway pattern sends telemetry to a central Collector that exports to backends. Vector's aggregator role handles cross-host processing from multiple upstream sources.

Here is a minimal agent that tails files and forwards to a central Collector over OTLP:

receivers:
  filelog:
    include: [/var/log/myapp/*.log]
    start_at: beginning

exporters:
  otlp:
    endpoint: collector.internal.example.com:4317

service:
  pipelines:
    logs:
      receivers: [filelog]
      exporters: [otlp]

Moving logs between tiers is log forwarding. Turning raw lines into fields on the way is log parsing.

What Makes Aggregated Logs Usable

• One time standard. OWASP says to synchronize time across all servers and devices, so events from different machines sort correctly. If you see drift, clock skew detection covers it.
• A consistent format. Structured logging means every service lands as the same shape, with a trace ID to join them.
• Protection. OWASP asks that logs be protected from tampering in transit and from unauthorized access, modification, and deletion once stored. Logs often hold personal or sensitive data, so see secrets in logs.
• A plan for volume. NIST describes event filtering as suppressing entries unlikely to contain useful information, and notes that filtering usually does not alter the original logs. See log sampling and log retention.
• A local copy for important events. NIST suggests keeping entries of particular interest both on the source system and in the central infrastructure, so that either side can fail and the other still has the data.

Aggregation Versus Event Aggregation

NIST uses "event aggregation" for something different: consolidating similar entries into one entry with a count, such as a thousand scan entries becoming a single line that says how many hosts were scanned. That reduces volume. Collecting logs centrally does not change what each entry says.

Aggregating Logs in Sazabi

Sazabi, an AI-native observability and security platform, uses one intake URL per project for application logs, metrics, traces, and webhook events. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run. You can point an agent such as Fluent Bit, Vector, or the OpenTelemetry Collector at that URL, and the records are searchable together. See the everything is a log docs.