Collect logs from the source you already run
Start from Kubernetes, Fluent Bit, syslog, OpenTelemetry, OTLP, GELF, or direct application logging instead of reshaping every service first.
Use Fluxtail when logs already exist but need a readable place to land. Collect Kubernetes, Docker, syslog, OpenTelemetry, OTLP, GELF, and application logs, then inspect live streams with filters, histograms, facets, alerts, MCP tools, and AI diagnostics.
Start from Kubernetes, Fluent Bit, syslog, OpenTelemetry, OTLP, GELF, or direct application logging instead of reshaping every service first.
Use live tail, stream scope, host and service filters, Kubernetes metadata, histograms, facets, and historical windows while the issue is still happening.
Use scoped access tokens, usage and quota alerts, MCP tools, receiver health checks, exception search, error summaries, no-log diagnostics, and built-in AI chat.
Start with the source you need to collect or the log-reading task you need to complete. Some entries open feature pages because the dedicated use-case page is not split out yet.
Use this page for DaemonSet collection, Kubernetes metadata, live stream reading, filters, histograms, and cluster-level troubleshooting.
Use this page when Fluent Bit tails container logs, adds host or container context, and forwards the result into Fluxtail for reading.
Use this path when rsyslog, syslog-ng, appliances, VMs, or network devices already emit syslog and need one readable destination.
Use this path when syslog-ng is already your routing layer and you want the destination side to handle reading, filtering, alerts, and AI diagnostics.
Use this path when container stdout, JSON logs, or collector-forwarded Docker logs need one central place for live reading.
Use this path when application logs already carry service names, trace IDs, span IDs, deployment context, or other telemetry fields.
Use this path when the main job is reading recent logs, narrowing the time window, and keeping noisy streams understandable while traffic is still arriving.
Use this path when MCP tools or built-in AI chat should inspect recent errors, exception clusters, receiver health, or no-log cases from the same Fluxtail account.
Use this path when several sources need to land in named streams with shared search, filters, retention, and team access.
These are the dedicated use-case pages already split out from the broader use-case map above.
Rsyslog centralized logging sends Linux syslog from servers to a central syslog receiver so host logs stay searchable after local files rotate, hosts restart, or machines disappear. Fluxtail receives those syslog messages into streams and keeps them readable with live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.
syslog-ng centralized logging sends Linux syslog from servers to a central syslog receiver with explicit source, filter, parser, destination, and log routing. Fluxtail receives those syslog messages into streams and keeps them readable with live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.
Docker container logs are useful locally, but production reading usually needs more than `docker logs`. Forward container stdout and stderr with service, container, host, environment, level, and request fields so Fluxtail can keep the stream searchable and readable.
OpenTelemetry application logs are most useful when service name, environment, severity, trace ID, span ID, and resource attributes survive collection. Fluxtail receives OTLP logs into streams so application events stay readable with live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.
Live tail helps when an incident is still active and recent logs need to stay readable. Fluxtail receives logs into streams, then helps narrow the active window with filters, facets, histograms, alerts, MCP diagnostics, and AI chat while the raw rows remain visible.
AI log diagnostics are most useful when they work from scoped log streams, receiver context, and raw rows. Fluxtail combines MCP diagnostics and AI chat with streams, live tail, filters, facets, histograms, and alerts so summaries stay tied to real logs.
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.
Use Fluent Bit as the Kubernetes collector, then forward the records to a Fluxtail receiver and stream. Keep namespace, pod, container, service, severity, request ID, and trace fields available for live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.
Point one syslog, OTLP, Kubernetes, or application source at Fluxtail and inspect the resulting logs.
A real stream will tell you more than another round of comparison shopping.