Buyer’s Guide - August 2026

The 10 best ZooKeeper monitoring tools, ranked

ZooKeeper fails quietly. Rising request latency, stale requests, fsync stalls, and leader elections matter long before a node goes down, and most generic JVM monitoring misses all of it. We ranked ten tools on how deeply they read ZooKeeper’s real health interfaces (mntr, the 3.6+ metrics system, the AdminServer), how fast they collect, and how predictably they are priced.

Start with Netdata (free) Jump to rankings

Why this list exists

ZooKeeper is a coordination service, not a database, and its failure modes are subtle. An ensemble can be “up” on every health check while request latency climbs past 100ms, outstanding requests queue up, and fsync stalls ripple into every system that depends on it: Kafka, Solr, Hadoop, HBase. The tools that catch these problems early are the ones that read ZooKeeper’s actual health interfaces, not the ones that treat it as a generic JVM process.

The most common buying mistake in this category is assuming JMX is enough. JMX gives you heap and GC, but the metrics that diagnose ensemble trouble live in the mntr 4-letter-word command, the ZooKeeper 3.6+ Prometheus MetricsProvider, and the AdminServer HTTP API. Before shortlisting anything, check which interface the tool actually parses.

Three dimensions decide the outcome for most teams:

Metric depth and interface. Does the tool cover latency min/avg/max, outstanding requests, znode and ephemeral counts, watches, connections, server state, fsync time, and quorum or leader metrics, and does it get them from mntr, the 3.6+ metrics system, or the AdminServer rather than JMX alone?
Collection resolution. ZooKeeper latency and queue spikes can appear and clear in seconds. Per-second collection catches them; 10 to 30 second scrape intervals often do not. Apache’s own reference Prometheus config scrapes every 10 seconds, and New Relic’s example config collects every 30.
Cost shape. ZooKeeper’s znode count, watch count, and request volume grow with your cluster. Per-node pricing stays flat as those grow; per-GB-ingested and per-custom-metric pricing does not.

One note on pricing: we do not quote list prices for any vendor except Netdata. List prices for observability tools change frequently and rarely survive contact with a real fleet, so we describe each tool’s pricing shape and link the official pricing page instead. For operator-level guidance on the metrics themselves, see our ZooKeeper monitoring guides, which cover thresholds and ensemble runbooks in detail.

We assembled the shortlist from tools with a documented, working ZooKeeper integration: a collector, exporter, template, extension, sensor, or plugin that an engineer can actually deploy today. Tools that only monitor ZooKeeper as a generic Java process were excluded. Every claim in the cards below comes from vendor documentation, Apache’s own ZooKeeper monitoring guide, or the projects’ public repositories.

The two heaviest-weighted criteria are metric depth and collection resolution, because they determine whether you see a problem at all. ZooKeeper latency spikes and leader elections are short-lived events, and a tool that polls every 30 seconds or only reads JMX heap stats will show you a healthy ensemble while clients time out. Alerting quality, deployment fit, ecosystem breadth, and cost shape carry the remaining weight, with setup ease as a tiebreaker.

Tester credit

Compiled by the Netdata team - Updated August 12, 2026

Sources verified

Scoring criteria

ZooKeeper metric depth and coverage 25%
mntr, 3.6+ metrics system, or AdminServer coverage of latency, queues, znodes, watches, state, fsync, and quorum
Collection resolution and real-time visibility 20%
Per-second versus 10-30s intervals; short spikes decide outages
Alerting and anomaly detection 15%
Packaged ZooKeeper alert rules and ML on top of static thresholds
Deployment and operational fit 15%
SaaS or self-hosted, agent footprint, auto-discovery, JMX or AdminServer prerequisites
Ecosystem and integration breadth 10%
Correlation with Kafka, Solr, Hadoop, logs, and Kubernetes
Total cost shape and predictability 10%
Per-node versus per-host versus per-GB; does the bill grow with data volume
Ease of setup and maintenance 5%
Time from install to a working ZooKeeper dashboard

Vendor 01 / 10 · #netdata

Netdata

Real-time infrastructure monitoring with per-second ZooKeeper metrics, ML anomaly detection on every chart, and flat per-node pricing.

Best for

Teams that want per-second visibility into ZooKeeper latency and request queues without assembling Prometheus and Grafana themselves
SREs who want ML anomaly detection on every ZooKeeper metric out of the box
Fleets that want predictable per-node pricing with unlimited metrics and retention

Pricing

Per-node pricing: Cloud Business starts at $4.5/node/month on annual plans, and the per-node price decreases as node count grows
Unlimited metrics, logs, users, and retention per node; the bill does not grow with znode count, watch count, or request volume
Free Cloud tier for small fleets; agents are open source (AGPL) and free
Homelab plan at $90/year for unlimited nodes under fair use

Pros

Per-second collection by default (update_every: 1), the sharpest resolution in this category for catching short latency and queue spikes
Auto-detects ZooKeeper on its standard sockets (127.0.0.1:2181 and 127.0.0.1:2182) with zero configuration
Collects 18 ZooKeeper charts via mntr: outstanding requests, latency min/avg/max, stale requests, connections, server state, packets, file descriptors, znode and ephemeral counts, watches, and approximate data size
Supports multiple local and remote instances plus TLS/mTLS in one collector config
ML-based anomaly detection and AI-assisted root cause analysis on every collected metric
Open-source agent; deploys as a DaemonSet to monitor ZooKeeper pods in Kubernetes

Where teams pair it

No alert rules ship configured for the ZooKeeper collector, so you define your own thresholds for latency, outstanding requests, and state changes; Apache’s reference rules are a good starting point
Metric depth is narrower than Datadog’s for ZooKeeper 3.6+: no request-processor, commit-processor, session-queue, or JVM heap/GC internals in the ZooKeeper collector
No per-client connection breakdown the way Zabbix’s template discovers individual clients

Verdict

Netdata leads this list because it pairs the sharpest collection resolution available with the metrics that actually diagnose ensemble trouble: latency, outstanding requests, stale requests, server state, znodes, and watches, all from mntr at one-second intervals. Auto-detection means a working dashboard in minutes, and ML anomaly detection flags deviations without hand-tuned thresholds. The honest caveat is depth: if you need ZooKeeper 3.6+ request-processor internals or per-client latency breakdowns, Datadog or Zabbix go further, and you will write your own alert rules. For most teams, per-second visibility plus flat per-node pricing is the better trade.

Start free ->

Vendor 02 / 10 · #prometheus-grafana

Prometheus + Grafana

The open-source metrics stack that Apache’s own documentation recommends for ZooKeeper monitoring.

Best for

Teams already standardized on Prometheus and Grafana who want ZooKeeper alongside the rest of the stack
Organizations that prefer to own and operate their monitoring stack rather than send data to a SaaS
Teams on ZooKeeper 3.6+ who want Apache’s officially documented PrometheusMetricsProvider path

Pricing

Open source and self-hosted (Prometheus is Apache 2.0, Grafana is AGPLv3); you run and operate it yourself
Grafana Cloud is a separate SaaS with usage-based pricing driven by series, logs, and traces ingested
Operating cost grows with your own storage, retention, and the time to maintain exporters, scrape configs, and alert rules

Pros

Apache’s official ZooKeeper documentation names Prometheus as the easiest ingestion path via the built-in PrometheusMetricsProvider on port 7000
Mature community Grafana dashboards: 9969, 10465, and 11442
dabealu/zookeeper-exporter covers pre-3.6 ZooKeeper, including leader-only metrics like zk_followers and zk_pending_syncs
Apache publishes reference Alertmanager rules for znode count, connections, watches, leader elections, fsync time, latency, and heap
No vendor lock-in; the same Prometheus monitors Kafka, Solr, and Hadoop

Cons

You assemble and operate everything yourself: exporter or MetricsProvider, Prometheus, Alertmanager, and Grafana are separate components
Apache’s reference scrape config uses a 10-second interval, so short latency spikes can be missed
No built-in anomaly detection; alerting is static thresholds you write and tune
The dabealu exporter has not had a release since November 2022, so pre-3.6 users depend on a lightly maintained project

Verdict

This is the path Apache itself documents, and the dashboard and alerting ecosystem around it is the richest available. For ZooKeeper 3.6+ the MetricsProvider makes ingestion clean, and the reference alert rules save real work. The trade is operational: you own four components, the default 10-second resolution misses short spikes, and there is no vendor to call when the stack breaks. If your team already runs Prometheus well, this is a strong choice; if not, budget for the assembly time.

Read full Netdata vs Prometheus -> Grafana pricing ->

Vendor 03 / 10 · #datadog

Datadog

A SaaS observability platform with the deepest ZooKeeper integration of any commercial tool.

Best for

Enterprises standardized on Datadog who want ZooKeeper correlated with Kafka, Solr, and traces in one UI
Teams that need ZooKeeper 3.6+ internals including request-processor and JVM metrics
Organizations that want managed SaaS with nothing to self-host

Pricing

Per-host pricing for infrastructure monitoring plus per-GB charges for ingested logs
Custom metrics and high-cardinality usage are billed separately and can dominate the bill
SaaS-only; cost grows with host count, log volume, and custom metric cardinality

Pros

100+ ZooKeeper metrics including 3.6+ request-processor, commit-processor, session, and JVM internals
Parses mntr and stat 4-letter-word commands directly; no JMX or external exporter required
Service checks for ensemble health: zookeeper.ruok and zookeeper.mode (leader/follower match)
Log collection for ZooKeeper log4j logs alongside metrics
Correlates ZooKeeper with Kafka, Solr, Hadoop, and application traces

Cons

SaaS-only; ZooKeeper metrics leave your network
Per-host plus per-GB-log plus custom-metric pricing grows quickly at fleet scale
Collection interval is not published in the integration docs; it is not per-second
Requires stat and mntr in the 4lw.commands.whitelist

Verdict

Datadog’s ZooKeeper integration is the most comprehensive of the SaaS tools, and the 3.6+ internal metric coverage is genuinely ahead of everything else on this list. If your troubleshooting regularly goes past mntr into request-processor queues and JVM behavior, that depth earns its place. The costs are structural: SaaS-only deployment, unpublished collection resolution, and a bill that grows with hosts, log volume, and cardinality rather than a flat per-node fee.

Read full Netdata vs Datadog -> Datadog pricing ->

Vendor 04 / 10 · #zabbix

Zabbix

Open-source enterprise monitoring with an official HTTP-based ZooKeeper template and per-client discovery.

Best for

Organizations that want a self-hosted, open-source platform with an official ZooKeeper template
Teams on ZooKeeper 3.6+ with the AdminServer enabled who want per-client connection discovery
Enterprises already running Zabbix for the rest of their infrastructure

Pricing

Open source and self-hosted (AGPLv3 since version 7.0); you operate it yourself
Commercial support, training, and professional services sold separately
Operating cost is your own infrastructure plus template and proxy maintenance time

Pros

Official Zookeeper by HTTP template collects via the AdminServer API with no external scripts or JMX
Leader metrics discovery: pending syncs, quorum size, synced followers, synced observers, and learners
Per-client connection discovery with per-client latency, packets, and outstanding requests, unique in this list
Built-in triggers for file descriptors, queued requests, pending syncs, follower count, and server-state changes
Template versions for Zabbix 5.0 through 7.4, tested against ZooKeeper 3.6+ and 3.8+

Cons

Requires ZooKeeper 3.6+ with the AdminServer (embedded Jetty on port 8080) enabled and reachable
Default polling cadence is not per-second; short latency spikes can be missed
Setup requires configuring host macros such as {$ZOOKEEPER.HOST} and {$ZOOKEEPER.PORT}
The Zabbix configuration model has a steeper learning curve than SaaS alternatives

Verdict

Zabbix’s official template is the strongest open-source option short of building a Prometheus stack, and per-client connection discovery is something nothing else here offers. Sensible default triggers mean alerting works out of the box. The limits are the 3.6+ AdminServer prerequisite, no mntr-based template for older ZooKeeper, polling resolution, and the general Zabbix learning curve. For Zabbix shops on modern ZooKeeper, it is an easy yes.

Read full Netdata vs Zabbix -> Zabbix pricing ->

Vendor 05 / 10 · #newrelic

New Relic

An observability platform with an Instant Observability quickstart for Apache ZooKeeper.

Best for

Teams already on New Relic who want ZooKeeper next to APM, logs, and traces
Organizations that want a quickstart install rather than a custom integration
Teams that want prebuilt alerts on rejected connections and watch counts

Pricing

Usage-based: per-seat pricing plus per-GB data ingested across metrics, logs, and traces
A free tier exists; production cost scales with seat count and ingest volume
The bill grows with users and telemetry volume, making it harder to predict than flat per-node pricing

Pros

Instant Observability quickstart ships prebuilt ZooKeeper dashboards and alerts (rejected connections, watch counts)
The nri-zookeeper / nri-flex integration parses mntr output with no JMX or exporter required
Correlates ZooKeeper with Kafka, Solr, and application traces in one platform
Open-source integration code on GitHub

Cons

The example nri-flex config collects every 30 seconds, slow for catching short latency spikes
The ZooKeeper integration is quickstart/community level rather than a deep first-party integration like Datadog’s
Usage-based per-seat plus per-GB pricing is hard to forecast
SaaS-only; telemetry leaves your network

Verdict

For teams already paying for New Relic, the quickstart delivers working ZooKeeper dashboards and alerts in an afternoon, and the mntr-based collector avoids JMX entirely. What you give up is resolution (30 seconds in the example config) and depth relative to Datadog, plus a pricing model tied to seats and ingest. A reasonable choice inside an existing New Relic estate; a hard sell as a ZooKeeper-specific purchase.

Read full Netdata vs New Relic -> New Relic pricing ->

Vendor 06 / 10 · #sematext

Sematext

A full-stack observability SaaS with a dedicated ZooKeeper integration and container auto-discovery.

Best for

Teams that want a dedicated ZooKeeper integration with hourly metering for autoscaling environments
Organizations running ZooKeeper in Docker or Kubernetes that want service auto-discovery
Teams that want ZooKeeper metrics and logs in one SaaS platform

Pricing

Per-host per-month pricing, metered by the hour so dynamic environments only pay for active hosts
Retention is tiered by plan; longer retention costs more
The bill grows with monitored host count and retention tier

Pros

Dedicated integration with 15+ curated metrics including request latency min/avg/max, alive connections, outstanding requests, packets, and quorum
Auto-discovers ZooKeeper services in containers via the Sematext Agent on Linux, Docker, and Kubernetes
Hourly per-host metering suits environments that scale up and down
Correlates ZooKeeper with SolrCloud and other connected apps in the UI

Cons

Smaller metric set than Datadog or Zabbix: no per-client breakdown or deep 3.6+ request-processor internals
Collection interval is not published in the integration docs
SaaS-centric; the on-premise Enterprise option is a heavier commitment
Smaller community and fewer third-party ZooKeeper dashboards than Prometheus + Grafana

Verdict

Sematext is a solid mid-tier option: a purpose-built ZooKeeper integration covering the core mntr metrics, hourly metering that treats autoscaling fleets fairly, and genuine container discovery. It does not match Datadog’s depth, Zabbix’s per-client visibility, or Netdata’s resolution, and the unpublished collection interval leaves a question mark for latency-sensitive work. Worth a look for container-heavy teams that want metrics and logs in one bill.

Visit Sematext -> Sematext pricing ->

Vendor 07 / 10 · #dynatrace

Dynatrace

An enterprise observability platform with a JMX-based Apache ZooKeeper extension and topology context.

Best for

Large enterprises already on Dynatrace who want ZooKeeper inside Smartscape and AI root-cause analysis
Teams that want automatic discovery and dependency mapping around ZooKeeper
Organizations needing code-level visibility into the ZooKeeper JVM

Pricing

Usage-based enterprise pricing: per-host infrastructure plus consumption units for ingested metrics
The bill grows with host count and metric, log, and trace volume
Enterprise contracts quoted per account; harder to predict than flat per-node pricing

Pros

Official extension covers alive connections, client packets, outstanding requests, election time, leader status, latencies, and auth failures
Automatic detection of ZooKeeper and dependents (Kafka, Solr, Hadoop) with Smartscape topology mapping
Platform-wide AI root-cause analysis and anomaly detection
Actively maintained extension with an included overview dashboard

Cons

JMX must be enabled and reachable on the ZooKeeper server, adding attack surface and configuration
Metric set is narrower than Datadog’s for 3.6+ internals; no request-processor or session-queue breakdown
Requires OneAgent plus the Extension Execution Controller, adding operational overhead

Verdict

Inside a Dynatrace estate the ZooKeeper extension is a natural add: core health metrics, topology context, and AI root-cause in the platform you already run. The JMX dependency is the sticking point for security-conscious teams, since mntr, AdminServer, and MetricsProvider alternatives avoid exposing JMX on coordination servers. Combined with consumption-based enterprise pricing, this is a fit for existing Dynatrace customers rather than a reason to become one.

Read full Netdata vs Dynatrace -> Dynatrace pricing ->

Vendor 08 / 10 · #manageengine

ManageEngine Applications Manager

An agentless application monitoring platform with built-in Apache ZooKeeper monitoring and JVM thread analysis.

Best for

IT teams that want agentless ZooKeeper monitoring from an on-premise console
Organizations already using ManageEngine or Zoho products
Teams that want JVM thread analysis and cluster discovery without agents on ZooKeeper hosts

Pricing

Perpetual or subscription licensing based on the number of monitors and users
Free edition available with limited monitors; Professional and Enterprise tiers add features
The bill grows with monitor and user count, not data volume

Pros

Agentless monitoring using both JMX and ZooKeeper’s native commands
Automatic discovery and mapping of ZooKeeper clusters with a unified dashboard
Covers JVM heap and non-heap, GC, threads, znodes, watchers, followers, leader election stats, and session counts
Alerts via SMS, email, or webhooks with customizable thresholds
30-day free trial plus a free edition with limited monitors

Cons

JMX dependency means the ZooKeeper JVM must expose JMX remotely, a security and configuration consideration
On-premise deployment only; no first-party SaaS option
Per-monitor licensing can get expensive as monitored ZooKeeper instances grow
No per-second resolution or ML anomaly detection on ZooKeeper metrics

Verdict

Applications Manager is a traditional enterprise tool that happens to cover ZooKeeper well: agentless collection, solid JVM and cluster metrics, and automatic cluster mapping. The JMX requirement and on-premise-only deployment narrow its audience, and per-monitor licensing punishes large ensembles. A sensible pick for ManageEngine shops and IT teams that explicitly want agentless on-prem monitoring; others will get more depth per dollar elsewhere.

Read full Netdata vs ManageEngine -> ManageEngine pricing ->

Vendor 09 / 10 · #site24x7

Site24x7

A cloud monitoring SaaS with a Python plugin for ZooKeeper that reads mntr 4-letter-word stats.

Best for

Small-to-mid teams that want a simple SaaS plugin for ZooKeeper health checks
Organizations already using Site24x7 for server and website monitoring
Teams that want the imok ensemble health check without building a custom probe

Pricing

Tiered SaaS plans priced per server and per monitor, billed monthly or annually
Infrastructure and APM plans are separate; the bill grows with server and monitor count
Log management is an add-on with its own volume-based tier

Pros

Official plugin reads mntr stats including the imok status check
Covers outstanding requests, average latency, session timeouts, max client connections, connections, and packets
The Python plugin is extensible; custom metrics can be added by editing the script
Part of a broader platform covering servers, websites, and applications

Cons

Manual plugin installation: download zookeeper.py into the agent plugin directory and configure host and port in the script
Limited metric set: no quorum or leader metrics, no per-client breakdown, no JVM metrics
No built-in ZooKeeper alert templates beyond what you configure yourself
SaaS-only; metrics leave your network

Verdict

Site24x7’s plugin is enough to keep a small ensemble honest: imok for health, mntr for the core request and connection metrics, and a script you can extend yourself. It is not a troubleshooting tool. Without quorum, leader, or JVM visibility you will be blind during the failures that matter most, and manual plugin installation adds friction per host. Fine as an add-on for existing Site24x7 users with small clusters; insufficient as a primary ZooKeeper monitor.

Read full Netdata vs Site24x7 -> Site24x7 pricing ->

Vendor 10 / 10 · #instana

IBM Instana

An APM platform with an automatically installed ZooKeeper sensor and dependency mapping.

Best for

Enterprises running Instana who want automatic ZooKeeper discovery with zero manual configuration
Teams that want ZooKeeper metrics inside a dependency map with AI root-cause analysis
Organizations monitoring Kafka and ZooKeeper together with both auto-instrumented

Pricing

Per-host per-month pricing with a minimum host commitment
SaaS and self-hosted options; the bill grows with monitored host count
Enterprise pricing quoted per account; expensive for small fleets

Pros

The ZooKeeper sensor installs and configures automatically when the host agent is deployed
Captures ZooKeeper version, client, mode, and state data plus ensemble-level views
Automatic service mapping and tracing around ZooKeeper and dependents like Kafka and Solr
AI-based Smart Alerts and root-cause analysis across the platform

Cons

Enterprise pricing with a minimum host commitment rules out small fleets
ZooKeeper metric depth is not documented at the level of Datadog or Zabbix templates
Less community content for ZooKeeper specifically than the open-source options
Both deployment modes require the Instana agent infrastructure

Verdict

Instana’s zero-configuration ZooKeeper sensor is the easiest setup in this list: deploy the agent and ensemble metrics appear, mapped against dependent services. That convenience comes with enterprise pricing, a minimum host commitment, and a ZooKeeper metric catalog that is documented less thoroughly than the leaders. The right call for Instana customers; an expensive way to monitor ZooKeeper on its own.

Read full Netdata vs Instana -> IBM Instana pricing ->

Frequently asked questions

What are the most important ZooKeeper metrics to monitor?

Start with request latency (min/avg/max); Apache’s reference alert fires when avg_latency exceeds 100ms for one minute. Watch outstanding requests, since queued requests mean the server is receiving more than it can process. Track znode count and approximate data size, because Apache warns above 1,000,000 znodes and 1GB of znode memory. Monitor alive connections against maxClientCnxns, server state (leader/follower/observer/standalone) and leader election events, fsync time and snapshot time (both alert at 100ms in Apache’s rules), open file descriptors (reference threshold 300), and JVM heap usage above 80% of max.

How do I monitor ZooKeeper with Prometheus?

On ZooKeeper 3.6+, enable the built-in Prometheus MetricsProvider by setting metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider in zoo.cfg; the endpoint defaults to port 7000 and is configurable via metricsProvider.httpPort. Apache’s reference scrape config uses a 10-second scrape_interval. For pre-3.6 ZooKeeper, the dabealu/zookeeper-exporter exports mntr stats in Prometheus format. Import a community Grafana dashboard such as 9969, 10465, or 11442, and pair with Alertmanager using Apache’s reference alerting rules.

What is the mntr 4-letter word and why do I need to whitelist it?

mntr is a ZooKeeper 4-letter-word admin command that returns machine-readable key:value metrics. Since ZooKeeper 3.5, the 4lw.commands.whitelist parameter controls which 4-letter words are allowed, and by default only srvr is whitelisted. Most monitoring tools (Netdata, Datadog, New Relic, Site24x7, and the dabealu exporter) parse mntr output, so you must add mntr to the whitelist in zoo.cfg, for example 4lw.commands.whitelist=mntr,stat,srvr,ruok. Datadog additionally needs stat whitelisted because its check parses stat first for the version number.

What is a good ZooKeeper alert threshold?

Apache’s official reference rules are the best starting point: avg_latency above 100ms, znode_count above 1,000,000, num_alive_connections above 50 (adjust to your maxClientCnxns), watch_count above 10,000, open_file_descriptor_count above 300, fsynctime and snapshottime rates above 100ms, and JVM heap above 80%. A leader election event (increase(election_time_count[5m]) > 0) deserves an immediate warning, and outstanding requests should be watched against a low threshold; Zabbix’s template warns at 10. Tune all of these to your ensemble size and workload, since Apache’s values are references, not absolutes.

Can I monitor ZooKeeper without JMX?

Yes. The mntr 4-letter-word command works without JMX and is what Netdata, Datadog, New Relic, Site24x7, and the dabealu exporter use. ZooKeeper 3.6+ also exposes the AdminServer HTTP API on port 8080, which Zabbix’s official template uses, and the built-in Prometheus MetricsProvider on port 7000, which is Apache’s recommended ingestion path. Only tools that chose a JMX-based approach, such as Dynatrace’s extension and ManageEngine, require it. Avoiding JMX reduces attack surface and removes the need to expose JMX ports on coordination servers.

How often should I collect ZooKeeper metrics?

Per-second collection gives you the earliest visibility, since ZooKeeper latency and outstanding-request spikes can appear and clear within seconds. Netdata collects per-second by default, while Apache’s reference Prometheus config scrapes every 10 seconds and New Relic’s example nri-flex config collects every 30 seconds. Datadog, Zabbix, and most other tools do not publish a ZooKeeper-specific interval, so their default polling applies. The right interval depends on the job: 10 seconds is fine for capacity planning, but per-second matters when you are troubleshooting intermittent latency.

What is the difference between monitoring a ZooKeeper leader versus a follower?

The leader carries quorum-specific metrics: pending syncs, quorum size, synced followers, synced observers, and learners. Followers report follower sync time, which measures how long it takes to sync with the leader. Zabbix’s template discovers leader metrics via low-level discovery and only populates them on the leader node, and the dabealu exporter exposes zk_followers, zk_synced_followers, and zk_pending_syncs only on the cluster leader. A change in server state, leader to follower or back, is itself an alert-worthy event in Apache’s reference rules.

How do I monitor ZooKeeper in Kubernetes?

Netdata auto-detects ZooKeeper on its standard TCP sockets and can be deployed as a DaemonSet to monitor ZooKeeper pods. Sematext’s agent auto-discovers ZooKeeper services inside containers. The Prometheus MetricsProvider endpoint can be scraped by the Prometheus Operator with a ServiceMonitor, and Zabbix’s HTTP template can target pods via the {$ZOOKEEPER.HOST} macro. Most SaaS agents (Datadog, New Relic, Site24x7) can monitor ZooKeeper in containers, but check each agent’s container discovery documentation for the specific integration.

The 10 best ZooKeeper monitoring tools, ranked

How we evaluated ZooKeeper monitoring tools

Netdata

Prometheus + Grafana

Datadog

Zabbix

New Relic

Sematext

Dynatrace

ManageEngine Applications Manager

Site24x7

IBM Instana

Frequently asked questions

Book Your Free Demo