Fluxtail
Sign in Start free
Log aggregation

Log Aggregation for Apps, Hosts, Containers, and Collectors

Log aggregation collects logs from many sources, preserves useful context, and makes the result searchable from one place. Fluxtail receives logs over HTTP, Syslog, OTLP, GELF, Kubernetes collectors, and Fluent Bit, then keeps them readable in centralized streams.

HTTP Syslog OTLP GELF Kubernetes collectors Fluent Bit
Start free View pricing
Collect from several paths

Apps, hosts, containers, syslog senders, OTLP pipelines, GELF senders, and collectors can all feed a central log destination.

Preserve useful fields

Good aggregation keeps timestamp, service, host, pod, severity, request ID, trace ID, and custom fields available for filtering.

Read centralized logs live

Fluxtail streams support live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat over the same event set.

Keep sources organized

Streams can separate production apps, infrastructure syslog, Kubernetes workloads, OTLP services, and legacy GELF logs.

Definition

What Is Log Aggregation?

Log aggregation is collecting logs from many systems into one searchable place. The goal is not only to store every event, but to keep enough context to understand failures, deployments, noisy hosts, and repeated errors.

01

Aggregation collects the event stream

API servers, workers, Kubernetes pods, nginx, syslog devices, container runtimes, OpenTelemetry collectors, Fluent Bit agents, and GELF senders can all push events into a shared destination.

02

Management starts after the logs arrive

Once logs are centralized, the next work is reading, filtering, searching, alerting, summarizing, and keeping the raw events available for verification.

03

Fluxtail combines the receiver and reader

Fluxtail accepts common log inputs, routes them into streams, and provides live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.

Collection paths

Common source paths into Fluxtail

A useful aggregation setup keeps the source, receiver, stream, and resulting event shape easy to inspect.

Fluxtail live tail showing active log rows in the product.

Source paths
text
1Node.js API -> HTTP JSON -> Fluxtail -> stream:production-api
2nginx host -> rsyslog -> Fluxtail Syslog -> stream:web-syslog
3Kubernetes pods -> Fluent Bit DaemonSet -> Fluxtail -> stream:kubernetes-prod
4Java services -> OpenTelemetry Collector -> OTLP -> Fluxtail -> stream:otel-prod
5Docker GELF driver -> GELF -> Fluxtail -> stream:legacy-containers

The source path should stay easy to explain after the second or third log source is added.

Source paths

Common Log Source Paths

Most environments have several logging paths. Fluxtail can sit at the receiving end while each source keeps the collection method that already fits it.

01

Application logs over HTTP

Direct HTTP log collection works when the application controls the payload and can send structured fields such as service, environment, request_id, customer_id, and status_code.

Application event
json
1{
2  "timestamp": "2026-04-24T14:22:31.118Z",
3  "level": "error",
4  "service": "checkout-api",
5  "env": "production",
6  "message": "payment authorization failed",
7  "request_id": "req_82HkT4",
8  "customer_id": "cus_1942",
9  "provider": "stripe",
10  "status_code": 402
11}
02

Linux hosts and network devices over syslog

Syslog still fits servers, firewalls, routers, appliances, and older applications that already emit host-oriented events.

Syslog line
output
<14>Apr 24 14:27:10 web-03 nginx: 203.0.113.42 GET /api/orders 502 request_id=req_A91f upstream=checkout-api
03

Kubernetes logs through Fluent Bit or collectors

Kubernetes log aggregation usually starts at the node. Pods write to stdout or stderr, the runtime writes log files, and a DaemonSet such as Fluent Bit forwards enriched events.

Kubernetes-enriched event
json
1{
2  "timestamp": "2026-04-24T14:31:44.904Z",
3  "level": "warn",
4  "message": "queue depth above threshold",
5  "kubernetes": {
6    "namespace": "prod",
7    "pod_name": "ingest-worker-7f8c9d6b9c-l2qnx",
8    "container_name": "worker",
9    "node_name": "worker-node-04"
10  },
11  "queue": "logs.ingest",
12  "depth": 18422
13}
04

OpenTelemetry logs over OTLP

OTLP works when services already use OpenTelemetry SDKs or collectors and logs should carry resource attributes such as service name, deployment environment, and version.

OTLP-style log payload
json
1{
2  "resourceLogs": [{
3    "resource": { "attributes": { "service.name": "accounts-api", "deployment.environment": "production" } },
4    "scopeLogs": [{
5      "logRecords": [{
6        "severityText": "ERROR",
7        "body": { "stringValue": "failed to refresh account quota" },
8        "attributes": { "account_id": "acc_7q2", "job": "quota-refresh", "attempt": 3 }
9      }]
10    }]
11  }]
12}
05

GELF from existing logging stacks

GELF is useful when an existing Graylog-compatible app, Docker log driver, or legacy sender already emits GELF-shaped JSON.

GELF event
json
1{
2  "version": "1.1",
3  "host": "worker-02",
4  "short_message": "invoice export failed",
5  "timestamp": 1777041488.231,
6  "level": 3,
7  "_service": "billing-worker",
8  "_env": "production",
9  "_job_id": "job_5518"
10}
Collection paths

Common source paths into Fluxtail

A useful aggregation setup keeps the source, receiver, stream, and resulting event shape easy to inspect.

Fluxtail live tail showing active log rows in the product.

Source paths
text
1Node.js API -> HTTP JSON -> Fluxtail -> stream:production-api
2nginx host -> rsyslog -> Fluxtail Syslog -> stream:web-syslog
3Kubernetes pods -> Fluent Bit DaemonSet -> Fluxtail -> stream:kubernetes-prod
4Java services -> OpenTelemetry Collector -> OTLP -> Fluxtail -> stream:otel-prod
5Docker GELF driver -> GELF -> Fluxtail -> stream:legacy-containers

The source path should stay easy to explain after the second or third log source is added.

Event shape

Examples of Aggregated Log Events

Aggregated logs come from different sources, but the destination should keep them readable and filterable.

01

Several sources can share one account

App events, host syslog, Kubernetes events, OTLP logs, and GELF logs can land in the same Fluxtail account while still keeping source-specific fields.

Centralized stream examples
output
2026-04-24T14:22:31Z error production-api checkout-api payment authorization failed request_id=req_82HkT4
2026-04-24T14:27:10Z warn  web-syslog web-03 nginx GET /api/orders 502 request_id=req_A91f
2026-04-24T14:31:44Z warn  kubernetes-prod ingest-worker queue depth above threshold depth=18422
Collection paths

Common source paths into Fluxtail

A useful aggregation setup keeps the source, receiver, stream, and resulting event shape easy to inspect.

Fluxtail live tail showing active log rows in the product.

Source paths
text
1Node.js API -> HTTP JSON -> Fluxtail -> stream:production-api
2nginx host -> rsyslog -> Fluxtail Syslog -> stream:web-syslog
3Kubernetes pods -> Fluent Bit DaemonSet -> Fluxtail -> stream:kubernetes-prod
4Java services -> OpenTelemetry Collector -> OTLP -> Fluxtail -> stream:otel-prod
5Docker GELF driver -> GELF -> Fluxtail -> stream:legacy-containers

The source path should stay easy to explain after the second or third log source is added.

Fields

What Centralized Logs Should Preserve

Centralized logs are only valuable if aggregation does not flatten away the details needed during production work.

01

Keep the fields that narrow the search

A practical aggregated log stream should preserve the original message, timestamp, receive time, severity, service, host, pod, container, device, environment, request ID, trace ID, receiver, and source protocol.

  • service, host, pod, container, or device
  • environment, namespace, stream, or receiver
  • request_id, trace_id, span_id, account_id, or job_id
  • structured JSON fields, OTLP attributes, Kubernetes metadata, or GELF extras
02

Keep common pivots searchable

Fields should support queries such as level:error service:checkout-api, namespace:prod pod:ingest-worker, request_id:req_82HkT4, or host:web-03 status_code:502.

Collection paths

Common source paths into Fluxtail

A useful aggregation setup keeps the source, receiver, stream, and resulting event shape easy to inspect.

Fluxtail live tail showing active log rows in the product.

Source paths
text
1Node.js API -> HTTP JSON -> Fluxtail -> stream:production-api
2nginx host -> rsyslog -> Fluxtail Syslog -> stream:web-syslog
3Kubernetes pods -> Fluent Bit DaemonSet -> Fluxtail -> stream:kubernetes-prod
4Java services -> OpenTelemetry Collector -> OTLP -> Fluxtail -> stream:otel-prod
5Docker GELF driver -> GELF -> Fluxtail -> stream:legacy-containers

The source path should stay easy to explain after the second or third log source is added.

Tooling

What Good Log Aggregation Tools Need

Log aggregation tools should do more than accept messages. They need reliable ingestion, searchable storage, fast reads, and enough controls to work during high-volume events.

01

Multiple inputs

HTTP, Syslog, OTLP, GELF, collectors, Kubernetes agents, Fluent Bit, rsyslog, syslog-ng, and client libraries should not require separate log readers.

02

Readable streams

Logs should be grouped by source, service, environment, receiver, namespace, or use case so centralized logs do not become one blended firehose.

03

Investigation controls

Live tail, filters, facets, histograms, alerts, access controls, scoped tokens, MCP diagnostics, and AI chat should operate on the same centralized events.

Collection paths

Common source paths into Fluxtail

A useful aggregation setup keeps the source, receiver, stream, and resulting event shape easy to inspect.

Fluxtail live tail showing active log rows in the product.

Source paths
text
1Node.js API -> HTTP JSON -> Fluxtail -> stream:production-api
2nginx host -> rsyslog -> Fluxtail Syslog -> stream:web-syslog
3Kubernetes pods -> Fluent Bit DaemonSet -> Fluxtail -> stream:kubernetes-prod
4Java services -> OpenTelemetry Collector -> OTLP -> Fluxtail -> stream:otel-prod
5Docker GELF driver -> GELF -> Fluxtail -> stream:legacy-containers

The source path should stay easy to explain after the second or third log source is added.

Fluxtail setup

Using Fluxtail as the Aggregation Destination

Fluxtail receives logs from application code, syslog senders, OTLP pipelines, GELF senders, Kubernetes collectors, and Fluent Bit. Streams keep each source path readable after logs arrive.

01

Route sources into streams

Use streams such as production-api, production-workers, kubernetes-prod, edge-syslog, billing, or security-events to keep sources separated enough to investigate.

Fluxtail stream layout
text
1stream:production-api -> HTTP app logs
2stream:kubernetes-prod -> Fluent Bit and Kubernetes collector logs
3stream:edge-syslog -> rsyslog, syslog-ng, routers, firewalls, hosts
4stream:otel-prod -> OpenTelemetry application logs
5stream:legacy -> GELF senders
Collection paths

Common source paths into Fluxtail

A useful aggregation setup keeps the source, receiver, stream, and resulting event shape easy to inspect.

Fluxtail live tail showing active log rows in the product.

Source paths
text
1Node.js API -> HTTP JSON -> Fluxtail -> stream:production-api
2nginx host -> rsyslog -> Fluxtail Syslog -> stream:web-syslog
3Kubernetes pods -> Fluent Bit DaemonSet -> Fluxtail -> stream:kubernetes-prod
4Java services -> OpenTelemetry Collector -> OTLP -> Fluxtail -> stream:otel-prod
5Docker GELF driver -> GELF -> Fluxtail -> stream:legacy-containers

The source path should stay easy to explain after the second or third log source is added.

Reading

Reading Aggregated Logs in Fluxtail

Aggregation is the first half. The value shows up when recent logs can be read, filtered, summarized, and verified quickly.

01

Use live tail and filters first

Open the relevant stream, filter by fields such as level, service, host, namespace, pod, receiver, or request_id, then use facets and histograms to see repeated sources and spikes.

Debugging path
text
1Open stream:kubernetes-prod
2Filter level:error namespace:prod
3Facet by service and pod
4Open live tail during rollout
5Search request_id from a failed API response
02

Use diagnostics after the stream is narrowed

MCP diagnostics and built-in AI chat can summarize repeated exceptions, inspect why a receiver has no recent logs, or explain error clusters from the selected stream.

Collection paths

Common source paths into Fluxtail

A useful aggregation setup keeps the source, receiver, stream, and resulting event shape easy to inspect.

Fluxtail live tail showing active log rows in the product.

Source paths
text
1Node.js API -> HTTP JSON -> Fluxtail -> stream:production-api
2nginx host -> rsyslog -> Fluxtail Syslog -> stream:web-syslog
3Kubernetes pods -> Fluent Bit DaemonSet -> Fluxtail -> stream:kubernetes-prod
4Java services -> OpenTelemetry Collector -> OTLP -> Fluxtail -> stream:otel-prod
5Docker GELF driver -> GELF -> Fluxtail -> stream:legacy-containers

The source path should stay easy to explain after the second or third log source is added.

Collection paths

Common source paths into Fluxtail

A useful aggregation setup keeps the source, receiver, stream, and resulting event shape easy to inspect.

Fluxtail live tail showing active log rows in the product.

Source paths
text
1Node.js API -> HTTP JSON -> Fluxtail -> stream:production-api
2nginx host -> rsyslog -> Fluxtail Syslog -> stream:web-syslog
3Kubernetes pods -> Fluent Bit DaemonSet -> Fluxtail -> stream:kubernetes-prod
4Java services -> OpenTelemetry Collector -> OTLP -> Fluxtail -> stream:otel-prod
5Docker GELF driver -> GELF -> Fluxtail -> stream:legacy-containers

The source path should stay easy to explain after the second or third log source is added.

Related

Related pages

Related page
Log management

Centralized log management with readable live tail, clear streams, and straightforward ingest.
Related page
Syslog server

Use Fluxtail as a syslog server for centralized syslog collection, live tail, filters, and syslog analysis.
Related page
OpenTelemetry logging

Learn how OpenTelemetry logging preserves service, resource, trace, and severity context with readable Fluxtail log views.
Related page
Kubernetes logging

Practical guide to Kubernetes logging: what metadata to keep, how collection paths work, and how Fluxtail keeps cluster logs searchable.
Related page
Live log viewer

Watch production logs in real time with a live log viewer for readable streams, live tail, filters, and diagnostics.
Related page
Kubernetes log aggregation

Aggregate Kubernetes logs from pods, nodes, and collectors into Fluxtail streams with live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.
Related page
Fluent Bit for Kubernetes

Use Fluent Bit for Kubernetes log collection, forward records to a Fluxtail receiver, and keep namespace, pod, container, service, and severity fields readable.
Related page
Pricing

Pricing is coming soon while Fluxtail plan names, limits, retention, and usage tiers are finalized.
Next step

Send one real source and read the logs

The fastest check is to point one real source at Fluxtail and see whether the resulting stream is easier to read.

Point one real source at Fluxtail.

Create a receiver, send one source, and inspect the first stream.

Start free View pricing