A practical comparison of ClickHouse monitoring tools - built-in system tables and the embedded Prometheus endpoint, Grafana, Altinity, Datadog, chmonitor, and NeverBlink - with the metrics and failure modes that matter in production.

ClickHouse Monitoring Tools: What Actually Works in Production

ClickHouse is famously fast out of the box, and famously quiet about the ways it degrades. Inserts start getting rejected with TOO_MANY_PARTS, a replica silently goes read-only after losing its Keeper session, or a merge backlog builds for days after a bulk load - and none of it shows up on a generic CPU/memory dashboard.

ClickHouse monitoring means tracking the database's own operational signals - query load, part counts per partition, merge and mutation queues, replication delay, memory tracking, and Keeper health - rather than just host metrics. The good news: ClickHouse exposes all of this itself, through system tables queryable with plain SQL and an embedded Prometheus endpoint. The tools below differ in how much of that raw signal they turn into history, alerts, and answers.

This comparison covers what we use and see across production deployments, from ClickHouse consulting engagements to our own clusters, as of ClickHouse 26.x (25.8 being the current LTS line).

Quick Comparison

Tool Type Cost ClickHouse-specific History & alerting Best for
System tables + /dashboard Built-in Free Yes Limited (metric_log, no alerting) Ad-hoc diagnosis, always available
ClickHouse Cloud console Managed Included Yes Yes ClickHouse Cloud users
Grafana + Prometheus Open-source Free (self-hosted) Via plugin/exporter Yes Standard OSS observability stack
Altinity operator + dashboards Open-source Free Yes Yes (via Prometheus) Kubernetes deployments
Datadog SaaS $15/host/mo + DBM Yes (integration) Yes Existing Datadog shops
chmonitor Open-source Free Yes Yes Lightweight dedicated UI + advisor
NeverBlink SaaS (private beta) Beta signup; paid plans from $29/cluster/mo Yes (purpose-built) Yes AI root-cause analysis, beyond monitoring

ClickHouse Monitoring Tools

1. Built-in: system tables, the Prometheus endpoint, and /dashboard

ClickHouse is its own best monitoring tool. system.metrics holds current-state gauges, system.events cumulative counters, and system.asynchronous_metrics background measurements like CPU and memory. system.query_log records every query with duration, rows and bytes read, and peak memory - in our experience it answers about 80% of production questions on its own. Add system.parts, system.merges, system.mutations, and system.replicas and you can diagnose most incidents with SQL alone. For history, system.metric_log snapshots metric values over time.

Two features many teams miss. First, ClickHouse ships an embedded Prometheus endpoint - add a <prometheus> block with a port to the server config and every metric, event, and async metric is scrapeable with zero exporters. Second, every server hosts a built-in HTML dashboard at $HOST:$HTTP_PORT/dashboard, charting QPS, CPU, memory, merges, and part counts from system.metric_log. There are also health endpoints: /ping for liveness and /replicas_status, which returns 503 when a replica lags.

What the built-ins lack is alerting and long-term, cross-cluster history. Nobody gets paged by a system table.

2. ClickHouse Cloud monitoring

ClickHouse Cloud bundles an advanced dashboard, a Query Insights UI, and resource-utilization views into the console. A practical detail worth knowing: console metrics are served from materialized views refreshed every minute, so checking dashboards does not wake an idled service.

For integration with your own stack, Cloud exposes a Prometheus-compatible API endpoint per service - or one org-level endpoint federating all services - authenticated with a Cloud API key. A filtered_metrics option trims the full 1000+ metric set down to roughly 125 critical ones, and it plugs into Prometheus, Grafana Cloud, or Datadog's OpenMetrics check directly. If you run on Cloud, this endpoint plus the console covers monitoring basics without any agents.

3. Grafana and Prometheus

The default open-source stack. The official grafana-clickhouse-datasource plugin, maintained by Grafana Labs and actively released (v4.20 as of July 2026), queries system tables directly with a SQL editor or visual builder, and ships six pre-built dashboards covering query analysis, cluster monitoring, and system metrics - plus logs and traces support for teams storing observability data in ClickHouse.

The complementary pattern is scraping the embedded Prometheus endpoint and alerting through Prometheus/Alertmanager. Altinity's knowledge base documents both approaches and maintains its own Grafana datasource plugin, the older but still actively maintained alternative. The trade-off is the usual one: you assemble and operate the stack, and you decide which of the hundreds of metrics deserve alert rules - which requires knowing ClickHouse failure modes in advance.

On Kubernetes, the Altinity clickhouse-operator includes a metrics-exporter that scrapes every managed cluster for Prometheus, with pre-configured dashboards and alert rules - the closest thing to a batteries-included OSS setup for ClickHouse on K8s.

4. Datadog

Datadog's ClickHouse integration is the most complete among the commercial APM platforms: caches, replication delays, background pools, MergeTree parts, and query cache metrics, with an out-of-the-box dashboard and monitors, plus log collection. In 2026 Datadog added a Database Monitoring preview for ClickHouse and a single_endpoint_mode for load-balanced ClickHouse Cloud endpoints.

Pricing follows Datadog's usual model - infrastructure monitoring from $15/host/month, with DBM and logs billed separately - so large clusters add up. New Relic offers only a thin quickstart (one dashboard, two alerts), and IBM Instana has an auto-discovered ClickHouse sensor; neither approaches Datadog's depth here. SigNoz, itself built on ClickHouse, monitors ClickHouse via the OpenTelemetry Collector with a ready dashboard template - a reasonable route for OTel-standardized teams.

5. chmonitor

chmonitor (formerly duyet/clickhouse-monitoring) is the interesting open-source newcomer: a dedicated ClickHouse monitoring UI with 30+ metric charts, merge and replication tracking, and multi-host cluster overviews, deployable via Docker or Helm. Development is very active.

Its recent pivot is what makes it worth watching: beyond dashboards, it now generates recommendations - projections, skip indexes, partition keys, materialized views - in advise-only mode, and exposes an MCP server endpoint. It is GPL-3.0 licensed and still young (v0.3.x), so treat it as a fast-moving companion tool rather than the backbone of production alerting.

NeverBlink, built by our team at BigData Boutique, takes the opposite approach from everything above: instead of handing you more charts, it is an AI-native platform that continuously evaluates cluster health, performs automated root-cause analysis across metrics, logs, and configuration, and produces specific, prioritized fixes. That is the distinction between monitoring and maintenance - knowing a partition crossed 1000 parts is monitoring; being told which insert pattern caused it and what to change is maintenance.

NeverBlink complements existing tools like Grafana and Datadog rather than replacing them, and its API and MCP server let your own AI agents and automation consume findings with humans staying in control. Elasticsearch and OpenSearch are fully supported today; ClickHouse support is in private beta, with signup at neverblink.ai. For teams whose ClickHouse expertise is a bottleneck - most teams, in our experience - this category shortcuts the "which metric matters and what do I do about it" problem entirely.

Key ClickHouse Metrics and Failure Modes

Whatever stack you choose, cover these signals - each maps to a real production failure mode:

  • Parts per partition: watch the MaxPartCountForPartition async metric. By default ClickHouse delays inserts at 1000 parts and rejects them at 3000 (TOO_MANY_PARTS), usually caused by small, frequent inserts. See our deep dive on the too many parts problem.
  • Merge and mutation backlog: merge queue length, system.merges, and stuck entries in system.mutations. A merge backlog after bulk loads degrades reads long before anything "fails."
  • Replication health: ReplicasMaxAbsoluteDelay, replication queue length, and the ReadonlyReplica metric. A replica that loses its Keeper session goes read-only - covered in detail in our post on ClickHouse replication health.
  • Memory: MemoryTracking against limits, queries killed by memory caps, and cache hit rates. See diagnosing memory pressure.
  • Keeper/ZooKeeper: latency and follower sync state via the mntr four-letter command or Keeper's own Prometheus endpoint. Keeper trouble cascades into read-only tables cluster-wide.
  • Query load and failures: QPS by type, running queries against max_concurrent_queries (default 100), failed queries, and long-runners from system.processes.
  • Disk: free space per volume in system.disks and detached parts count. Disk-full cascades into merge failures fast on ClickHouse.

Our Recommendations

Start with what is free and already running: learn the system tables, enable the embedded Prometheus endpoint, and bookmark /dashboard. On ClickHouse Cloud, the console plus the Prometheus API endpoint covers the basics with zero setup. Self-hosted teams with an existing Prometheus/Grafana stack should add the official Grafana plugin and Altinity's alert rules; on Kubernetes, the Altinity operator's exporter is the obvious path.

Datadog makes sense when the rest of your observability already lives there - price it against cluster size first. And when the constraint is ClickHouse expertise rather than metric collection - when the question is "why is this happening and what do we change" - that is what we built NeverBlink for. Its ClickHouse private beta is open for signups now.