ClickHouse monitoring

What to monitor in ClickHouse

ClickHouse monitoring is reading system.query_log, system.parts, system.merges, system.replicas, and related tables — then acting before lag, parts, or runaway queries become an outage. chmonitor ships those views as pages, with a recommend-only advisor that never applies DDL.

chmonitor ClickHouse monitoring: cluster health board over system tables
What you get

Built for this, not bolted on

Queries: running, slow, failed, expensive

system.processes and system.query_log: duration, memory, rows read, the full statement. Kill a runaway from the table. Rank slow and most-expensive queries so tuning starts where it pays off.

Tables, parts, and merges

system.parts and system.merges: table size, part counts, merge backlog, and write amplification. Too many parts or a stuck merge is a storage incident, not a pretty chart.

Replication and cluster topology

system.replicas, replication_queue, and distributed DDL: lag, read-only replicas, in-flight fetches. A live topology map so you see shards, replicas, and Keeper together.

Health checks on one board

Disk, memory, failed queries, stuck mutations, delayed inserts — color-coded from the same system tables, with Slack or Discord when a check turns red and when it recovers.

Recommend-only advisor

EXPLAIN-based query hints and schema/TTL suggestions you copy and apply yourself. chmonitor never rewrites SQL or runs ALTER/DROP. Grafana and Datadog leave that diagnosis to you.

Community

Open source, built in public

FAQ

Questions & answers

What should I monitor in ClickHouse?
Start with running and slow queries (system.processes, system.query_log), part counts and table size (system.parts), merge backlog (system.merges), replication lag and read-only replicas (system.replicas / replication_queue), plus disk and memory. Those are the signals that page on-call. chmonitor maps each to a page instead of a blank Grafana SQL panel.
Is ClickHouse monitoring the same as a ClickHouse dashboard?
Close, but the search intent differs. Monitoring is the checklist: which system tables, which thresholds, what to do next. A dashboard is the UI you look at all day. This page is the monitoring pillar. Home stays the product brand; see ClickHouse dashboard for the live ops UI.
Grafana vs Datadog vs a dedicated ClickHouse monitor?
Grafana is a canvas: you write (and maintain) system-table panels. Datadog is fleet observability with an agent and broader APM. chmonitor is ClickHouse-only: it SELECTs system.* with version-aware SQL and ships complete pages. Many teams keep Grafana or Datadog for the rest of the stack and add chmonitor for merges, parts, and query_log. See /vs-grafana and /vs-datadog.
Does the advisor change my cluster?
No. Query EXPLAIN hints and schema/TTL suggestions are recommend-only. You review and apply DDL yourself. There is no auto-apply path.
Do I need an agent on every ClickHouse node?
No. chmonitor talks to ClickHouse over HTTP with a read-oriented user (typically GRANT SELECT ON system.*). Docker, Helm, or Cloudflare Workers — no per-node exporter.
Comparisons

Grafana, Datadog, or a ClickHouse-native monitor

Grafana wins as a multi-source canvas. Datadog wins as fleet APM. chmonitor wins when on-call is merges, parts, replicas, and query_log. Honest matrices — including rows we lose — live on the comparison pages.

More comparisons: chmonitor vs Grafana · chmonitor vs Datadog · chmonitor vs ClickHouse Cloud · ClickHouse vs TimescaleDB · ClickHouse vs Postgres · ClickHouse vs Druid vs Pinot

Start monitoring — advisor and alerts built in

Open the hosted dashboard and connect a cluster, or self-host with Docker, Kubernetes, or from source. Self-hosting is always free.