Buyer’s Guide - August 2026

The 6 best tools for monitoring Logstash itself

Q: How do I monitor Logstash persistent queues?

Query the monitoring API directly: curl http://localhost:9600/_node/stats/pipelines and inspect the queue section. The key metrics are queue_size_in_bytes, max_size_in_bytes, queue events count, and page capacity. A full persistent queue blocks ingestion and can crash the Logstash pod, so alert on queue growth well before it hits queue.max_bytes. Tools that expose these queue metrics include Netdata, Datadog, the kuskoman/logstash-exporter, and Elastic Stack Monitoring.

Logstash exposes a rich monitoring API on port 9600: JVM heap, event throughput, queue depth, per-pipeline and per-plugin stats. The tools that matter are the ones that consume that API, not the ones that merely accept the logs Logstash ships. This ranking grades six tools on metric depth, collection granularity, alerting, and what the bill looks like as your pipelines grow.

Start with Netdata (free) Jump to rankings

The 6 best tools for monitoring Logstash itself product interface

Why this list exists

Most “Logstash monitoring” searches surface log management platforms that ingest the logs Logstash ships. That is log shipping, not Logstash monitoring. Monitoring Logstash means watching the process and its pipelines: JVM heap and garbage collection, events in/filtered/out, event duration, persistent queue fill, plugin performance, and reload failures. The only honest source for that data is the Logstash monitoring API on port 9600, and the tools on this list are the ones that actually consume it.

The mistake buyers make is assuming their existing log platform covers the shipper itself. It usually does not. Vendors like Sematext, New Relic, and Instana integrate with Logstash as a log source and expose nothing about pipeline health. When a persistent queue fills and ingestion stalls, those platforms go quiet precisely because Logstash has stopped sending them data.

Three dimensions decide which tool fits:

Metric depth. Does the tool pull node stats, JVM stats, pipeline stats, and queue stats from the monitoring API, or does it only check process up/down?
Collection granularity. Queue backpressure and event-duration spikes can appear and resolve in seconds. Per-second collection catches them; 30 to 60 second polling often misses them entirely.
Cost shape. Does the bill grow with hosts, with log volume, with metric cardinality, or with a second monitoring cluster you have to run yourself?

One note on pricing: we do not quote competitor list prices here. Vendor pricing pages change, tiers shift, and a stale dollar figure is worse than none. Each card links the vendor’s official pricing page so you can check current numbers. For operator-level detail on the metrics themselves, the Logstash monitoring guides cover the API endpoints, queue tuning, and heap sizing in depth.

We assembled the shortlist from tools with a documented Logstash integration that consumes the monitoring API on port 9600: vendor documentation, maintained open-source exporters and plugins, and community templates listed on official integration pages. Tools that only accept Logstash output as a log source were excluded.

The two heaviest criteria are metric depth and collection granularity, because they determine whether you can actually troubleshoot a pipeline stall or only confirm that the process is running. Alerting and deployment cost follow, since an integration you cannot afford to operate or that never pages you is not monitoring.

Tester credit

Compiled by the Netdata team - Updated August 12, 2026

Sources verified

Scoring criteria

Logstash metric depth and coverage 25%
JVM, events, queues, per-pipeline and per-plugin stats from the monitoring API
Collection granularity 20%
Per-second vs 30-60s polling for short-lived bottlenecks
Alerting and anomaly detection 15%
Queue backpressure, heap pressure, reload failures, ML vs hand-built thresholds
Deployment and operational cost 15%
What you run, what you pay, and how the bill grows
Ease of setup 10%
Auto-discovery and zero config vs manual exporter and template assembly
Ecosystem and integrations 10%
Kubernetes, Elasticsearch, Kafka, Prometheus, notification channels
Maintenance and community health 5%
Is the integration tested against current Logstash versions

Vendor 01 / 06 · #netdata

Netdata

Open-source, per-second infrastructure and application monitoring with built-in ML anomaly detection and a dedicated Logstash collector.

Best for

Teams that want Logstash JVM, event, and pipeline metrics at per-second granularity without building a Prometheus exporter stack
Buyers who want anomaly detection and alerting on Logstash health without writing thresholds for every metric
Organizations that want to avoid per-GB log-ingest pricing for infrastructure metrics

Pricing

Per-node pricing: Netdata Cloud Business starts at $4.50/node/month on annual plans, with the per-node price decreasing as node count grows
Free Cloud tier for small fleets (up to 5 active connected nodes), with unlimited metrics and logs
Agents are open source (AGPL) and self-hosted; you run and operate them yourself
No per-GB, per-metric, or per-series charges; containers on a monitored host are included

Pros

Dedicated Logstash collector (go.d.plugin) polls the Logstash monitoring API with a default update_every of 1 second
Covers JVM threads, heap memory, garbage collection, open file descriptors, events in/filtered/out, event duration, uptime, and per-pipeline metrics
800+ integrations with auto-discovery and zero configuration; dashboards and alerts come out of the box
Unsupervised ML runs on every metric for anomaly detection and root-cause correlation, so a queue fill or GC storm gets flagged without a hand-tuned threshold
Distributed architecture keeps metric data on your infrastructure; only views stream to the cloud
Per-node pricing means the bill does not grow with log volume or metric cardinality

Where teams pair it

The Logstash collector ships with no default alert rules; you configure Logstash-specific thresholds (queue growth, reload failures, heap pressure) yourself
No pipeline topology viewer equivalent to Elastic’s Pipeline Viewer; Netdata visualizes metrics, not the pipeline graph
No prebuilt Logstash-specific dashboard template; you assemble custom dashboards from the collected JVM, event, and pipeline metrics

Verdict

Netdata is the only tool on this list that combines per-second collection of the full Logstash monitoring API with built-in ML anomaly detection and zero-configuration setup, without requiring a second monitoring cluster, a separately installed community agent check, or a DIY exporter stack. When a persistent queue starts filling at 3 AM, per-second granularity is the difference between seeing the ramp and seeing a flat line followed by an outage. The honest caveats: Logstash alerting is not prebuilt, so you write those rules yourself, and there is no pipeline topology view. For teams that need the pipeline graph, pairing Netdata’s metrics with Elastic’s Pipeline Viewer is a reasonable split.

Start free -> Netdata pricing ->

Vendor 02 / 06 · #elastic

Elastic Observability

The native monitoring stack for Logstash, with Stack Monitoring, a Pipeline Viewer UI, and monitoring APIs built into every Logstash node.

Best for

Teams already running the Elastic Stack who want Logstash monitoring in the same Kibana UI as their logs
Operators who need the Pipeline Viewer to see pipeline topology and plugin-level throughput
Organizations that want first-party support for Logstash monitoring rather than a third-party integration

Pricing

Elastic Cloud Hosted uses resource-based pricing, pay-as-you-go or prepaid
Elastic Cloud Serverless is usage-based on ingested and processed data
Self-managed licensing is based on node count and RAM allocated
The bill grows with the monitoring cluster: monitoring Logstash requires running Elasticsearch and Kibana to store and view the data, which adds footprint on top of the production stack

Pros

Native Stack Monitoring: Elastic Agent collects Logstash node and pipeline stats into a monitoring cluster, with the deepest Logstash-specific coverage of any vendor
Logstash exposes monitoring APIs by default (node info, node stats, hot threads, health report, plugins info) with no extra configuration
Pipeline Viewer UI shows pipeline topology, plugin events in/out, and worker utilization, which no other tool on this list matches
Covers JVM stats, process stats, event stats, pipeline runtime stats, and hot threads
Monitoring APIs can be secured with TLS and HTTP basic auth via logstash.yml

Cons

Requires a separate monitoring cluster (Elasticsearch plus Kibana) to store and view Logstash monitoring data, roughly doubling the Elastic footprint you operate
Monitoring collection adds overhead to the Logstash nodes being monitored
Self-managed licensing scales with node count and RAM, so the monitoring cluster itself grows the bill
Collection is polling-based at typical stack-monitoring intervals of tens of seconds, not per-second

Verdict

If you already run the Elastic Stack, this is the deepest Logstash monitoring available: Elastic owns Logstash, so the APIs, the Pipeline Viewer, and Stack Monitoring are first-party and current. The Pipeline Viewer alone earns it the second spot, because no third-party tool shows pipeline topology and plugin-level flow. The cost is architectural. You run a second Elastic cluster just to watch the first one, and collection granularity is polling-based, so short-lived queue spikes can slip between intervals. Elastic-centric shops should start here; everyone else pays a heavy tax for the privilege.

Read full Netdata vs Elastic -> Elastic pricing ->

Vendor 03 / 06 · #datadog

Datadog

SaaS observability platform with an agent-based Logstash integration that collects JVM, process, pipeline, plugin, and queue metrics from the monitoring API.

Best for

Teams already standardized on Datadog for infrastructure and APM who want Logstash metrics alongside everything else
Organizations that want a fully managed SaaS with no monitoring cluster to operate
Buyers who need Logstash log shipping (via logstash-output-datadog_logs) and Logstash metrics in one platform

Pricing

Modular per-product usage-based pricing across Free, Pro, and Enterprise tiers
Infrastructure is billed per host; Log Management is billed per GB ingested and per million events indexed
Custom metrics are billed beyond per-host allotments
The bill grows with host count, log volume, and metric cardinality across products, which compounds quickly in log-heavy environments

Pros

Logstash check collects process, JVM, reload, pipeline/event, plugin, and queue metrics as gauges from the monitoring API
Includes a logstash.can_connect service check for availability alerting
Log collection via the logstash-output-datadog_logs plugin with gzip compression and regional endpoints
Supports the multi-pipeline metrics introduced in Logstash 6.0
Agent-based collection works in containers via Autodiscovery templates

Cons

The Logstash check is a community integration, not bundled in the Datadog Agent; it must be installed separately with datadog-agent integration install
Documented compatibility is Logstash 5.x-7.x; there is no verification against Logstash 8.x, including the 8.5+ flow metrics
Per-host plus per-GB log pricing makes the bill grow with both infrastructure size and log volume
The check collects no events, only metrics and one service check

Verdict

Datadog covers the right metric surface: JVM, pipelines, plugins, queues, and reloads, plus a connectivity service check, and the default 15-second check interval is respectable. Two things hold it back. The integration is community-maintained and documented only through Logstash 7.x, so current 8.x flow metrics are unverified territory. And the pricing shape, per host plus per GB plus custom metrics, is exactly the model that punishes log-pipeline-heavy infrastructure. If Datadog is already your standard, add the check. If you are choosing fresh, weigh the bill trajectory carefully.

Read full Netdata vs Datadog -> Datadog pricing ->

Vendor 04 / 06 · #prometheus-grafana

Prometheus + Grafana

Open-source metrics stack that monitors Logstash through the actively maintained kuskoman/logstash-exporter, visualized in Grafana dashboards.

Best for

Teams already running Prometheus and Grafana who want Logstash metrics in the same dashboards as the rest of the stack
Kubernetes shops: the exporter ships a Helm chart, a controller mode for auto-discovery, and a dedicated Grafana dashboard
Buyers who want open-source tooling with no per-host or per-GB vendor lock-in

Pricing

Prometheus and Grafana are open source and self-hosted; you run and operate them, and the cost is infrastructure, storage, and engineering time
Grafana Cloud SaaS is usage-based: per thousand active series for metrics, per GB for logs and traces
The kuskoman/logstash-exporter is open source (MIT-licensed lineage) and self-hosted; you run and operate it
The bill grows with active series and log volume on Grafana Cloud, or with your own operational effort when self-hosted

Pros

kuskoman/logstash-exporter is actively maintained (v1 in production, v2 in beta) and exposes node, JVM, pipeline, plugin, queue, flow, and reload metrics
Grafana dashboard 18628 (Logstash on Kubernetes) provides prebuilt system, JVM, pipeline, and plugin visualizations
Exporter supports TLS, bearer token, and basic auth against the Logstash monitoring API
Kubernetes controller mode auto-discovers Logstash instances via annotations
The Prometheus ecosystem provides flexible alerting through Alertmanager

Cons

The exporter is tested against a single Logstash version; other versions may expose metrics that do not map cleanly, so verify before rollout
You assemble and operate Prometheus, Grafana, the exporter, and Alertmanager yourself; there is no integrated product
The original BonnierNews logstash_exporter is archived (read-only since November 2025), so the ecosystem depends on one maintainer’s fork
No built-in anomaly detection; alerting requires hand-written PromQL thresholds

Verdict

For teams that already live in the Prometheus ecosystem, this is the natural answer: the exporter covers the full monitoring API surface including Logstash 8.5+ flow metrics, the Kubernetes story is genuinely good, and nothing is locked to a vendor. The trade-off is that everything is DIY. You run four components, write your own PromQL alerts, and depend on a single maintainer’s fork now that the original exporter is archived. Scrape intervals of 15 to 30 seconds are also coarse enough to blur fast queue spikes. Strong choice for Prometheus shops; a lot of assembly for everyone else.

Read full Netdata vs Grafana -> Grafana pricing ->

Vendor 05 / 06 · #zabbix

Zabbix

Open-source enterprise monitoring platform with a community Logstash template that collects pipeline and JVM metrics via the monitoring API.

Best for

Organizations already running Zabbix for infrastructure monitoring who want Logstash checks in the same platform
Teams that prefer a self-hosted platform with no license fees and a large community
Buyers who need Logstash monitoring alongside network, server, and application monitoring in one tool

Pricing

Zabbix software is open source and self-hosted; no license fees and no device limits, but you run and operate it
Optional support subscriptions (Silver through Global) are priced by response SLA and server count
Zabbix Cloud SaaS is offered in tiered plans sized by monitored environment
The bill grows with support coverage and cloud tier, not with hosts or metrics

Pros

The official Zabbix integrations page lists a Logstash solution (fredprod/logstash-zabbix) built on the Python protobix library
Template covers Logstash status, pipeline low-level discovery, JVM memory, and pipeline event metrics
Zabbix itself is actively maintained (7.4 current) with a large community and broad infrastructure coverage
No license fees and no host limits on the self-hosted platform

Cons

The Logstash template is community-maintained and targets Logstash 5.x-6.x era metrics, not current 8.x flow metrics
Polling at Zabbix’s typical 30-60 second intervals misses short-lived pipeline bottlenecks
Requires Python protobix setup and manual template import; there is no zero-config Logstash discovery
No Logstash-specific anomaly detection; alerting is threshold-based

Verdict

Zabbix is a capable general monitoring platform, and if your organization already runs it, adding the Logstash template costs little. But be clear-eyed about what the template is: a community artifact aimed at Logstash 5.x and 6.x, polling at intervals too coarse to catch fast queue events, with manual setup and no discovery. It answers “is Logstash up and roughly how busy” rather than “why did the pipeline stall for forty seconds.” Fine as an add-on for Zabbix shops; not a reason to adopt Zabbix.

Read full Netdata vs Zabbix -> Zabbix subscriptions ->

Vendor 06 / 06 · #icinga

Icinga

Open-source monitoring platform with the NETWAYS check_logstash plugin for Logstash health, pipeline, flow, and reload checks.

Best for

Teams already running Icinga 2 who want Logstash health and pipeline checks added to their existing monitoring
Organizations that prefer Nagios-style check-based monitoring with open-source licensing
Operators who need threshold alerts on heap usage, CPU, file descriptors, and inflight events

Pricing

Icinga core is open source and self-hosted, with the open-source community edition covering unlimited hosts and services; you run and operate it
Optional paid subscriptions cover repository access for enterprise Linux, enterprise modules, and support (8x5 or 24/7)
Support subscriptions are priced by number of Icinga servers, not by monitored hosts
The bill grows with support level and enterprise OS coverage, not with Logstash nodes

Pros

NETWAYS check_logstash plugin provides health checks (heap, CPU, file descriptors), pipeline checks (inflight events), flow checks (queue backpressure, requires Logstash 8.5+), and reload checks
Supports HTTPS, bearer token, and basic auth against the Logstash monitoring API
Icinga 2 is actively maintained with current 2.16.x releases and a strong open-source community
GPLv3-licensed plugin that integrates with the broader Nagios-compatible plugin ecosystem

Cons

Check-based monitoring produces point-in-time status, not continuous metric streams; there is no per-second history for troubleshooting
No Logstash-specific visualization; you need Grafana or Icinga Web 2 add-ons for graphs
No anomaly detection; alerting is threshold-based on check results
Requires installing and configuring the plugin plus the Icinga 2 and Icinga Web 2 infrastructure

Verdict

check_logstash is a well-built plugin, and its flow check against the Logstash 8.5+ queue backpressure metrics shows the maintainer keeps it current. For an Icinga shop that wants to get paged when heap pressure climbs or a reload fails, it does the job cleanly. What it cannot do is help you troubleshoot after the page: check intervals of one to five minutes leave no fine-grained history, and there are no Logstash dashboards. Treat it as an alerting layer for Icinga users, not a Logstash metrics platform.

Read full Netdata vs Icinga -> Icinga pricing ->

Frequently asked questions

What metrics should I monitor in Logstash?

Start with JVM heap used versus committed plus garbage collection counts, because memory pressure causes pipeline stalls. Track events in, filtered, and out per second for throughput and drops, and event duration in milliseconds for processing latency. Watch queue size and queue events for backpressure and persistent queue fill, along with open file descriptors and CPU usage. Finally, monitor pipeline reload successes and failures so a bad config push never goes unnoticed.

How do I monitor Logstash persistent queues?

Query the monitoring API directly: curl http://localhost:9600/_node/stats/pipelines and inspect the queue section. The key metrics are queue_size_in_bytes, max_size_in_bytes, queue events count, and page capacity. A full persistent queue blocks ingestion and can crash the Logstash pod, so alert on queue growth well before it hits queue.max_bytes. Tools that expose these queue metrics include Netdata, Datadog, the kuskoman/logstash-exporter, and Elastic Stack Monitoring.

What is the Logstash monitoring API and what does it expose?

Logstash automatically captures runtime metrics and exposes them on port 9600 by default. The endpoints cover node info, plugins info, node stats, hot threads, a health report, and a root resource. The API is unsecured by default, so enable TLS and HTTP basic auth via logstash.yml (api.ssl.enabled, api.auth.type) before exposing it beyond localhost. Every serious Logstash monitoring tool consumes this API rather than scraping logs.

How do I monitor Logstash with Prometheus?

Use the kuskoman/logstash-exporter, which queries the Logstash monitoring API and exposes Prometheus metrics on /metrics. The original BonnierNews logstash_exporter is archived; the kuskoman fork is the actively maintained option, with v1 in production and v2 in beta. Grafana dashboard ID 18628 provides prebuilt Logstash-on-Kubernetes visualizations. Note that the exporter is tested against a single Logstash version, so verify metric mapping against your version before relying on it in production.

Does Datadog monitor Logstash?

Yes, via an agent-based Logstash check that collects JVM, process, pipeline, plugin, and queue metrics from the monitoring API. The check is a community integration rather than part of the bundled Datadog Agent, so you install it with datadog-agent integration install. Documented compatibility covers Logstash 5.x through 7.x. Datadog also offers log shipping from Logstash via the logstash-output-datadog_logs plugin, which is separate from monitoring Logstash itself.

How do I monitor Logstash JVM heap and garbage collection?

The key JVM metrics are heap used percent, heap committed, heap max, and GC collection count and time. Sustained high heap with frequent GC pauses indicates the pipeline is memory-bound; correlate that with rising event duration to confirm. Logstash heap is set in jvm.options via -Xms and -Xmx, and monitoring tells you whether the allocation is adequate. Netdata, Elastic Stack Monitoring, Datadog, and the kuskoman/logstash-exporter all expose these JVM metrics.

What is the difference between monitoring Logstash and monitoring the logs Logstash processes?

Monitoring Logstash means watching the process and its pipelines: JVM memory, event throughput, queue depth, plugin performance, and reload status. Monitoring the logs Logstash processes means log management: storing, searching, and alerting on the events flowing through the pipeline. Many vendors, including Sematext, New Relic, and Instana, integrate with Logstash only as a log-shipping source and do not monitor Logstash itself. A complete setup usually needs both: a Logstash monitor for pipeline health and a log platform for the data it produces.

How do I alert on Logstash pipeline failures or reloads?

The monitoring API exposes reload successes and failures per pipeline, so alert on reload failures directly. Watch inflight events (events in minus events out) as a proxy for pipeline blockage. Logstash 8.5 and later expose flow metrics including queue backpressure, which are purpose-built for alerting. On tooling: Netdata requires configuring Logstash alert rules manually, while Elastic Stack Monitoring and Icinga’s check_logstash provide reload and health checks out of the box.

The 6 best tools for monitoring Logstash itself

How we evaluated Logstash monitoring tools

Netdata

Elastic Observability

Datadog

Prometheus + Grafana

Zabbix

Icinga

Frequently asked questions

Book Your Free Demo