Log management

Centralized Log Management for Apps, Hosts, and Clusters

Centralized log management should let you collect logs from important sources, find the event you need, and keep enough context to understand what happened.

Centralized logs Streams Live tail AI analysis

Start free View pricing

Collect from common sources

Send logs from apps, syslog devices, collectors, Kubernetes workloads, OpenTelemetry pipelines, and GELF emitters into one account.

Keep intake visible

Receivers show how a source enters Fluxtail, and streams show where the resulting events should be read.

Read live traffic

Use live tail, filters, and facets to confirm that events are arriving and narrow the window you need to inspect.

Summarize with raw logs nearby

MCP diagnostics and built-in AI chat can summarize errors or missing-log checks while the raw stream remains the source of truth.

Basics

What centralized log management should make easier

For teams evaluating centralized log management, Fluxtail focuses on ingestion paths, readable streams, live investigation, and field-based search.

01

Collect logs without hiding the original event

HTTP, Syslog, OTLP, GELF, collectors, and client libraries can all send events to receivers. The goal is to preserve the original message while making the useful fields searchable.

source or receiver that accepted the event
stream where the event should be read
timestamp, host, service, level, and message
structured fields such as request_id, trace_id, namespace, or error_code

02

Keep sources separated enough to read

Streams give centralized logging a practical shape. Use them for environments, services, namespaces, customer groups, or source types so unrelated logs do not all land in one endless list.

prod-apps for application logs
prod-infra for syslog and host logs
prod-kubernetes for cluster and workload logs
security-events for selected GELF or syslog events

03

Read while the source is still active

Live tail logs help verify deployments, collector changes, failing requests, noisy hosts, and new error patterns while events are still arriving.

04

Use AI after the rows are readable

MCP diagnostics and built-in AI chat are most useful after events have consistent fields. Use them to summarize errors, group repeated messages, or check why a source is quiet, then verify against the raw stream.

Product proof

Send one event, watch it land, then narrow the stream

Create a receiver, route the logs into a stream, then read and filter the resulting traffic in one place.

Fluxtail live tail showing active log rows in the product.

Send one structured event to the HTTP receiver

bash

1curl -X POST 'https://<your-fluxtail-ingest-endpoint>/<receiver-path>' \
2  -H 'Content-Type: application/json' \
3  -H 'Authorization: Bearer <FLUXTAIL_ACCESS_TOKEN>' \
4  -d '{
5    "timestamp": "2026-04-24T14:32:18.421Z",
6    "level": "error",
7    "service": "checkout-api",
8    "environment": "production",
9    "host": "checkout-api-7d9f8b8c5f-v2m4q",
10    "message": "payment authorization failed",
11    "request_id": "req_01HX7R9N3P8Q2M6K",
12    "order_id": "ord_4921",
13    "error_code": "card_declined"
14  }'

Use the endpoint and access token from the Fluxtail receiver you created for this source.

What a readable centralized row looks like

output

2026-04-24T14:32:18.421Z error checkout-api production checkout-api-7d9f8b8c5f-v2m4q payment authorization failed request_id=req_01HX7R9N3P8Q2M6K error_code=card_declined

One row should keep the timestamp, level, service, environment, host, message, and important fields visible enough to filter on.

Verification

What to verify after connecting the first source

A centralized logging setup is not useful just because the first event arrived. Check whether the event can be found, filtered, and understood later.

01

Start with one structured event

Before adding alerts or AI, make sure one app can send one event with the fields you actually filter on.

Minimal structured payload

json

1{
2  "message": "payment authorization failed",
3  "level": "error",
4  "service": "checkout-api",
5  "environment": "production",
6  "request_id": "req_01HX7R9N3P8Q2M6K"
7}

Row in the live stream

output

2026-04-24T14:32:18.421Z error checkout-api production payment authorization failed request_id=req_01HX7R9N3P8Q2M6K

If service, environment, or request_id disappear here, the setup is centralized but still hard to use.

02

Then widen to one real log window

Once the first row is clean, look at a short time window from the service or source you would actually inspect during a failure.

Small investigation window

output

stream=checkout-live window=14:30-14:35
2026-04-24T14:32:18Z error checkout-api production payment authorization failed request_id=req_01HX7R9N3P8Q2M6K
2026-04-24T14:32:19Z warn  api-gateway production upstream returned 502 route=/checkout request_id=req_01HX7R9N3P8Q2M6K
2026-04-24T14:32:21Z info  queue-worker production retry queued order_id=ord_4921

That is where centralized log management starts replacing pod tails, host SSH sessions, and copied snippets.

03

Check the setup before relying on it

Confirm that the receiver is enabled, the stream is correct, the original message is preserved, timestamps are normalized, filters return the event, and the plan limits and data window match expected volume.

filter by service, level, host, message text, or request_id
check auth failures, retries, and network errors from the sender
document which stream to open first for the source

Product proof

Send one event, watch it land, then narrow the stream

Create a receiver, route the logs into a stream, then read and filter the resulting traffic in one place.

Fluxtail live tail showing active log rows in the product.

Send one structured event to the HTTP receiver

bash

1curl -X POST 'https://<your-fluxtail-ingest-endpoint>/<receiver-path>' \
2  -H 'Content-Type: application/json' \
3  -H 'Authorization: Bearer <FLUXTAIL_ACCESS_TOKEN>' \
4  -d '{
5    "timestamp": "2026-04-24T14:32:18.421Z",
6    "level": "error",
7    "service": "checkout-api",
8    "environment": "production",
9    "host": "checkout-api-7d9f8b8c5f-v2m4q",
10    "message": "payment authorization failed",
11    "request_id": "req_01HX7R9N3P8Q2M6K",
12    "order_id": "ord_4921",
13    "error_code": "card_declined"
14  }'

Use the endpoint and access token from the Fluxtail receiver you created for this source.

What a readable centralized row looks like

output

2026-04-24T14:32:18.421Z error checkout-api production checkout-api-7d9f8b8c5f-v2m4q payment authorization failed request_id=req_01HX7R9N3P8Q2M6K error_code=card_declined

One row should keep the timestamp, level, service, environment, host, message, and important fields visible enough to filter on.

How it works

How centralized logging works in Fluxtail

The path stays short enough that setup and debugging are both easy to explain.

Step 1

Create a receiver

Choose the ingestion path that matches the source: direct HTTP JSON, Syslog forwarding, OTLP pipelines, GELF emitters, or collector output.

Step 2

Route traffic into streams

Use named streams to keep services, workloads, environments, or source types readable when traffic gets noisy.

Step 3

Read live traffic

Live tail stays focused on the event rows themselves so you can confirm new events, collector changes, and errors as they land.

Step 4

Filter, summarize, and verify

Use filters, facets, MCP diagnostics, or built-in AI chat to narrow the window, then confirm conclusions against the raw stream.

Product proof

Send one event, watch it land, then narrow the stream

Create a receiver, route the logs into a stream, then read and filter the resulting traffic in one place.

Fluxtail live tail showing active log rows in the product.

Send one structured event to the HTTP receiver

bash

1curl -X POST 'https://<your-fluxtail-ingest-endpoint>/<receiver-path>' \
2  -H 'Content-Type: application/json' \
3  -H 'Authorization: Bearer <FLUXTAIL_ACCESS_TOKEN>' \
4  -d '{
5    "timestamp": "2026-04-24T14:32:18.421Z",
6    "level": "error",
7    "service": "checkout-api",
8    "environment": "production",
9    "host": "checkout-api-7d9f8b8c5f-v2m4q",
10    "message": "payment authorization failed",
11    "request_id": "req_01HX7R9N3P8Q2M6K",
12    "order_id": "ord_4921",
13    "error_code": "card_declined"
14  }'

Use the endpoint and access token from the Fluxtail receiver you created for this source.

What a readable centralized row looks like

output

2026-04-24T14:32:18.421Z error checkout-api production checkout-api-7d9f8b8c5f-v2m4q payment authorization failed request_id=req_01HX7R9N3P8Q2M6K error_code=card_declined

One row should keep the timestamp, level, service, environment, host, message, and important fields visible enough to filter on.

Source fit

Choose the ingestion path that matches the source

Start with the log path your source already supports, then keep the resulting fields readable in Fluxtail.

01

HTTP for application JSON

Use HTTP receivers when an app or client library can send structured JSON directly.

02

Syslog for hosts and appliances

Use Syslog for servers, routers, firewalls, appliances, VMs, rsyslog, syslog-ng, and legacy services that already emit syslog.

03

OTLP, GELF, and collectors for existing pipelines

Use OpenTelemetry logs when services already emit through OTLP collectors. Use GELF when an existing shipper emits GELF. Send Kubernetes logs through collectors with namespace, pod, container, service, and environment fields preserved when available.

Product proof

Send one event, watch it land, then narrow the stream

Create a receiver, route the logs into a stream, then read and filter the resulting traffic in one place.

Fluxtail live tail showing active log rows in the product.

Send one structured event to the HTTP receiver

bash

1curl -X POST 'https://<your-fluxtail-ingest-endpoint>/<receiver-path>' \
2  -H 'Content-Type: application/json' \
3  -H 'Authorization: Bearer <FLUXTAIL_ACCESS_TOKEN>' \
4  -d '{
5    "timestamp": "2026-04-24T14:32:18.421Z",
6    "level": "error",
7    "service": "checkout-api",
8    "environment": "production",
9    "host": "checkout-api-7d9f8b8c5f-v2m4q",
10    "message": "payment authorization failed",
11    "request_id": "req_01HX7R9N3P8Q2M6K",
12    "order_id": "ord_4921",
13    "error_code": "card_declined"
14  }'

Use the endpoint and access token from the Fluxtail receiver you created for this source.

What a readable centralized row looks like

output

2026-04-24T14:32:18.421Z error checkout-api production checkout-api-7d9f8b8c5f-v2m4q payment authorization failed request_id=req_01HX7R9N3P8Q2M6K error_code=card_declined

One row should keep the timestamp, level, service, environment, host, message, and important fields visible enough to filter on.

Product proof

Send one event, watch it land, then narrow the stream

Create a receiver, route the logs into a stream, then read and filter the resulting traffic in one place.

Fluxtail live tail showing active log rows in the product.

Send one structured event to the HTTP receiver

bash

1curl -X POST 'https://<your-fluxtail-ingest-endpoint>/<receiver-path>' \
2  -H 'Content-Type: application/json' \
3  -H 'Authorization: Bearer <FLUXTAIL_ACCESS_TOKEN>' \
4  -d '{
5    "timestamp": "2026-04-24T14:32:18.421Z",
6    "level": "error",
7    "service": "checkout-api",
8    "environment": "production",
9    "host": "checkout-api-7d9f8b8c5f-v2m4q",
10    "message": "payment authorization failed",
11    "request_id": "req_01HX7R9N3P8Q2M6K",
12    "order_id": "ord_4921",
13    "error_code": "card_declined"
14  }'

Use the endpoint and access token from the Fluxtail receiver you created for this source.

What a readable centralized row looks like

output

2026-04-24T14:32:18.421Z error checkout-api production checkout-api-7d9f8b8c5f-v2m4q payment authorization failed request_id=req_01HX7R9N3P8Q2M6K error_code=card_declined

One row should keep the timestamp, level, service, environment, host, message, and important fields visible enough to filter on.

FAQ

Questions readers usually ask next

Short answers to the follow-on questions this page tends to raise.

FAQ What does centralized log management mean in Fluxtail?

It means routing logs into one place where you can inspect live traffic, organize events into streams, filter by useful fields, and debug without bouncing between local files and ad hoc viewers.

FAQ Can Fluxtail handle HTTP, Syslog, OTLP, and GELF in one account?

Yes. HTTP, Syslog, OTLP, GELF, collectors, and client libraries can land in the same account, then be grouped into streams for reading and analysis.

FAQ Where does AI fit in Fluxtail?

AI helps with summarization, clustering, and faster navigation through a noisy log window. It does not replace the raw stream, filters, or human verification.

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

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

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

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

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

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

Centralized Log Management for Apps, Hosts, and Clusters

What centralized log management should make easier

Collect logs without hiding the original event

Keep sources separated enough to read

Read while the source is still active

Use AI after the rows are readable

Send one event, watch it land, then narrow the stream

What to verify after connecting the first source

Start with one structured event

Then widen to one real log window

Check the setup before relying on it

Send one event, watch it land, then narrow the stream

How centralized logging works in Fluxtail

Create a receiver

Route traffic into streams

Read live traffic

Filter, summarize, and verify

Send one event, watch it land, then narrow the stream

Choose the ingestion path that matches the source

HTTP for application JSON

Syslog for hosts and appliances

OTLP, GELF, and collectors for existing pipelines

Send one event, watch it land, then narrow the stream

Send one event, watch it land, then narrow the stream

Questions readers usually ask next

Related pages

Send one real source and read the logs