Fluxtail
Sign in Start free
Use case / Kubernetes

Kubernetes Log Aggregation With Fluxtail

Kubernetes log aggregation means getting pod, container, namespace, service, and node logs into one place without losing the fields needed to read them. Fluxtail receives collector output into receivers and streams, then supports live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.

Kubernetes logs Collectors Streams Live tail
Start free View pricing
Collect from the cluster path already in place

Use Fluent Bit, OpenTelemetry Collector, a Kubernetes agent, or another collector that already runs close to the workloads.

Keep Kubernetes context visible

Preserve namespace, pod, container, node, service, severity, request ID, and trace ID fields so logs stay filterable.

Use streams to separate cluster traffic

Route logs by namespace, service, environment, cluster, or source type instead of mixing all pod output into one stream.

Read rows before summaries

Use live tail, filters, facets, histograms, and alerts first. MCP diagnostics and AI chat should point back to raw rows.

Fields

What Kubernetes log aggregation should preserve

The stream is only useful if each row keeps the fields needed to filter from cluster-wide noise down to one service or pod.

01

Kubernetes identity fields

Keep cluster, namespace, pod, container, node, workload, and service fields on every row where the collector can attach them.

02

Application fields

Preserve severity, logger, request ID, trace ID, span ID, route, job ID, and tenant or environment fields when the app emits them.

03

Original message fields

Keep the original message readable. Structured fields help filtering, but the message is still what a person scans first.

Path

A simple Kubernetes log aggregation path

The collector stays close to Kubernetes. Fluxtail receives the forwarded records and keeps the stream readable.

Cluster aggregation path
text
1pods and nodes
2  -> Fluent Bit, OpenTelemetry Collector, or another collector
3  -> Fluxtail receiver
4  -> stream by namespace, service, or environment
5  -> live tail, filters, facets, histograms, alerts

The useful boundary is explicit: collector output enters a receiver, then lands in a stream that is named for how you read it.

Aggregated Kubernetes record
json
1{
2  "timestamp": "2026-04-24T14:21:09Z",
3  "level": "ERROR",
4  "message": "checkout timeout after 3 retries",
5  "service.name": "checkout-api",
6  "k8s.namespace.name": "storefront",
7  "k8s.pod.name": "checkout-api-7b8f6d8bd5-7nmzl",
8  "k8s.container.name": "app",
9  "k8s.node.name": "pool-a-03",
10  "request_id": "req-9f2c"
11}

Use the field names your collector emits. The key requirement is that Kubernetes context survives forwarding.

Readable rows after aggregation
output
2026-04-24T14:21:09Z ERROR checkout-api storefront pod=checkout-api-7b8f6d8bd5-7nmzl timeout after 3 retries request_id=req-9f2c
2026-04-24T14:21:12Z WARN  api-gateway storefront pod=api-gateway-6d9cbf56b8-tk42s upstream timeout route=/checkout request_id=req-9f2c
2026-04-24T14:21:17Z WARN  queue-worker storefront pod=queue-worker-6fd9fd8bb8-kk2js retry limit reached job_id=job-7789

A good aggregated stream lets you scan related rows without jumping between pods one by one.

Setup

A simple cluster logging path

Start with one namespace or service, then expand only after the stream shape is readable.

01

Collect at the node or collector layer

Run the collector where it can read container output and attach Kubernetes metadata before the record leaves the cluster.

02

Forward to a Fluxtail receiver

Use the receiver endpoint, port, protocol, and key assigned to that source. Keep one receiver per meaningful source boundary when possible.

03

Read from a named stream

Name streams after the way you search: cluster, namespace, service, environment, or source type.

Path

A simple Kubernetes log aggregation path

The collector stays close to Kubernetes. Fluxtail receives the forwarded records and keeps the stream readable.

Cluster aggregation path
text
1pods and nodes
2  -> Fluent Bit, OpenTelemetry Collector, or another collector
3  -> Fluxtail receiver
4  -> stream by namespace, service, or environment
5  -> live tail, filters, facets, histograms, alerts

The useful boundary is explicit: collector output enters a receiver, then lands in a stream that is named for how you read it.

Aggregated Kubernetes record
json
1{
2  "timestamp": "2026-04-24T14:21:09Z",
3  "level": "ERROR",
4  "message": "checkout timeout after 3 retries",
5  "service.name": "checkout-api",
6  "k8s.namespace.name": "storefront",
7  "k8s.pod.name": "checkout-api-7b8f6d8bd5-7nmzl",
8  "k8s.container.name": "app",
9  "k8s.node.name": "pool-a-03",
10  "request_id": "req-9f2c"
11}

Use the field names your collector emits. The key requirement is that Kubernetes context survives forwarding.

Readable rows after aggregation
output
2026-04-24T14:21:09Z ERROR checkout-api storefront pod=checkout-api-7b8f6d8bd5-7nmzl timeout after 3 retries request_id=req-9f2c
2026-04-24T14:21:12Z WARN  api-gateway storefront pod=api-gateway-6d9cbf56b8-tk42s upstream timeout route=/checkout request_id=req-9f2c
2026-04-24T14:21:17Z WARN  queue-worker storefront pod=queue-worker-6fd9fd8bb8-kk2js retry limit reached job_id=job-7789

A good aggregated stream lets you scan related rows without jumping between pods one by one.

Organization

How to organize Kubernetes streams

A single cluster-wide stream is easy to create and hard to read. Split streams before noise becomes the default view.

01

Start by environment and cluster

Separate production, staging, and development traffic. If there are multiple clusters, include the cluster name in stream routing or fields.

02

Split noisy namespaces

High-volume namespaces such as ingress, batch workers, or data jobs often deserve their own streams.

03

Keep filters predictable

Use the same service, namespace, pod, and severity field names across collectors so saved filters and alerts keep working.

Path

A simple Kubernetes log aggregation path

The collector stays close to Kubernetes. Fluxtail receives the forwarded records and keeps the stream readable.

Cluster aggregation path
text
1pods and nodes
2  -> Fluent Bit, OpenTelemetry Collector, or another collector
3  -> Fluxtail receiver
4  -> stream by namespace, service, or environment
5  -> live tail, filters, facets, histograms, alerts

The useful boundary is explicit: collector output enters a receiver, then lands in a stream that is named for how you read it.

Aggregated Kubernetes record
json
1{
2  "timestamp": "2026-04-24T14:21:09Z",
3  "level": "ERROR",
4  "message": "checkout timeout after 3 retries",
5  "service.name": "checkout-api",
6  "k8s.namespace.name": "storefront",
7  "k8s.pod.name": "checkout-api-7b8f6d8bd5-7nmzl",
8  "k8s.container.name": "app",
9  "k8s.node.name": "pool-a-03",
10  "request_id": "req-9f2c"
11}

Use the field names your collector emits. The key requirement is that Kubernetes context survives forwarding.

Readable rows after aggregation
output
2026-04-24T14:21:09Z ERROR checkout-api storefront pod=checkout-api-7b8f6d8bd5-7nmzl timeout after 3 retries request_id=req-9f2c
2026-04-24T14:21:12Z WARN  api-gateway storefront pod=api-gateway-6d9cbf56b8-tk42s upstream timeout route=/checkout request_id=req-9f2c
2026-04-24T14:21:17Z WARN  queue-worker storefront pod=queue-worker-6fd9fd8bb8-kk2js retry limit reached job_id=job-7789

A good aggregated stream lets you scan related rows without jumping between pods one by one.

Verification

How to verify the setup

Before adding more sources, confirm one service produces readable rows from source to Fluxtail stream.

01

Compare collector output with the Fluxtail row

Check that the message, severity, service, namespace, pod, container, node, and request fields are still present after forwarding.

02

Filter by service and namespace

A useful stream should let you isolate one service in one namespace without parsing message text manually.

03

Check live tail before alerts

Use live tail to confirm rows arrive with stable fields, then add histograms, facets, saved filters, and alerts.

Path

A simple Kubernetes log aggregation path

The collector stays close to Kubernetes. Fluxtail receives the forwarded records and keeps the stream readable.

Cluster aggregation path
text
1pods and nodes
2  -> Fluent Bit, OpenTelemetry Collector, or another collector
3  -> Fluxtail receiver
4  -> stream by namespace, service, or environment
5  -> live tail, filters, facets, histograms, alerts

The useful boundary is explicit: collector output enters a receiver, then lands in a stream that is named for how you read it.

Aggregated Kubernetes record
json
1{
2  "timestamp": "2026-04-24T14:21:09Z",
3  "level": "ERROR",
4  "message": "checkout timeout after 3 retries",
5  "service.name": "checkout-api",
6  "k8s.namespace.name": "storefront",
7  "k8s.pod.name": "checkout-api-7b8f6d8bd5-7nmzl",
8  "k8s.container.name": "app",
9  "k8s.node.name": "pool-a-03",
10  "request_id": "req-9f2c"
11}

Use the field names your collector emits. The key requirement is that Kubernetes context survives forwarding.

Readable rows after aggregation
output
2026-04-24T14:21:09Z ERROR checkout-api storefront pod=checkout-api-7b8f6d8bd5-7nmzl timeout after 3 retries request_id=req-9f2c
2026-04-24T14:21:12Z WARN  api-gateway storefront pod=api-gateway-6d9cbf56b8-tk42s upstream timeout route=/checkout request_id=req-9f2c
2026-04-24T14:21:17Z WARN  queue-worker storefront pod=queue-worker-6fd9fd8bb8-kk2js retry limit reached job_id=job-7789

A good aggregated stream lets you scan related rows without jumping between pods one by one.

Fluxtail

Read Kubernetes logs in Fluxtail

Once records land in a stream, Fluxtail is the place to read, filter, summarize, and alert on Kubernetes logs.

01

Follow active rows

Use live tail when a deploy, job, or service is producing new rows and you need to see them as they arrive.

02

Use facets and histograms

Use facets and histograms to find which service, namespace, host, level, or time window is producing most of the traffic.

03

Use diagnostics after the row shape is stable

MCP diagnostics and built-in AI chat are more useful when the stream already has stable fields and raw rows to verify.

Path

A simple Kubernetes log aggregation path

The collector stays close to Kubernetes. Fluxtail receives the forwarded records and keeps the stream readable.

Cluster aggregation path
text
1pods and nodes
2  -> Fluent Bit, OpenTelemetry Collector, or another collector
3  -> Fluxtail receiver
4  -> stream by namespace, service, or environment
5  -> live tail, filters, facets, histograms, alerts

The useful boundary is explicit: collector output enters a receiver, then lands in a stream that is named for how you read it.

Aggregated Kubernetes record
json
1{
2  "timestamp": "2026-04-24T14:21:09Z",
3  "level": "ERROR",
4  "message": "checkout timeout after 3 retries",
5  "service.name": "checkout-api",
6  "k8s.namespace.name": "storefront",
7  "k8s.pod.name": "checkout-api-7b8f6d8bd5-7nmzl",
8  "k8s.container.name": "app",
9  "k8s.node.name": "pool-a-03",
10  "request_id": "req-9f2c"
11}

Use the field names your collector emits. The key requirement is that Kubernetes context survives forwarding.

Readable rows after aggregation
output
2026-04-24T14:21:09Z ERROR checkout-api storefront pod=checkout-api-7b8f6d8bd5-7nmzl timeout after 3 retries request_id=req-9f2c
2026-04-24T14:21:12Z WARN  api-gateway storefront pod=api-gateway-6d9cbf56b8-tk42s upstream timeout route=/checkout request_id=req-9f2c
2026-04-24T14:21:17Z WARN  queue-worker storefront pod=queue-worker-6fd9fd8bb8-kk2js retry limit reached job_id=job-7789

A good aggregated stream lets you scan related rows without jumping between pods one by one.

Path

A simple Kubernetes log aggregation path

The collector stays close to Kubernetes. Fluxtail receives the forwarded records and keeps the stream readable.

Cluster aggregation path
text
1pods and nodes
2  -> Fluent Bit, OpenTelemetry Collector, or another collector
3  -> Fluxtail receiver
4  -> stream by namespace, service, or environment
5  -> live tail, filters, facets, histograms, alerts

The useful boundary is explicit: collector output enters a receiver, then lands in a stream that is named for how you read it.

Aggregated Kubernetes record
json
1{
2  "timestamp": "2026-04-24T14:21:09Z",
3  "level": "ERROR",
4  "message": "checkout timeout after 3 retries",
5  "service.name": "checkout-api",
6  "k8s.namespace.name": "storefront",
7  "k8s.pod.name": "checkout-api-7b8f6d8bd5-7nmzl",
8  "k8s.container.name": "app",
9  "k8s.node.name": "pool-a-03",
10  "request_id": "req-9f2c"
11}

Use the field names your collector emits. The key requirement is that Kubernetes context survives forwarding.

Readable rows after aggregation
output
2026-04-24T14:21:09Z ERROR checkout-api storefront pod=checkout-api-7b8f6d8bd5-7nmzl timeout after 3 retries request_id=req-9f2c
2026-04-24T14:21:12Z WARN  api-gateway storefront pod=api-gateway-6d9cbf56b8-tk42s upstream timeout route=/checkout request_id=req-9f2c
2026-04-24T14:21:17Z WARN  queue-worker storefront pod=queue-worker-6fd9fd8bb8-kk2js retry limit reached job_id=job-7789

A good aggregated stream lets you scan related rows without jumping between pods one by one.

Related

Related pages

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
Kubernetes logging tools

Compare Kubernetes logging tools by layer: collectors, storage and query stacks, cloud logging, and log management destinations for Kubernetes logs.
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
Log aggregation

Learn how log aggregation works across apps, hosts, syslog, containers, Kubernetes, OTLP, GELF, and collectors.
Related page
Live log viewer

Watch production logs in real time with a live log viewer for readable streams, live tail, filters, and diagnostics.
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