ClickHouse is not a traditional OLTP database, and monitoring it like one is the most common mistake buyers make. Connection counts and CPU tell you almost nothing. The failure modes that actually take down a ClickHouse cluster are merge backlog, replication lag, runaway part counts per partition, and rejected inserts, and those live in system tables like system.metrics, system.events, system.replicas, and system.parts. Any tool that does not read those tables out of the box is giving you generic host monitoring with a ClickHouse logo on it.
The second mistake is assuming the built-in tooling is enough. ClickHouse ships a /dashboard UI, a Prometheus endpoint on port 9363, and HTTP health endpoints, and ClickHouse Cloud adds Query Insights and an Advanced Observability dashboard. Those visualize; they do not alert, correlate, or retain fleet history. You still need a monitoring layer on top.
Three dimensions decide the outcome of this purchase:
- Resolution. Per-second collection catches merge storms and insert spikes that 30-second scrapes and minute-level polling smooth into invisibility. This is the sharpest differentiator in the category.
- ClickHouse-specific alerting. Replication lag, max part count per partition, delayed inserts, long-running queries: either the tool ships these rules or you write them yourself.
- Query-level analysis. system.query_log is the source of truth for per-query performance. Most tools skip it entirely; a few (Datadog DBM, SigNoz) ingest it.
We do not quote competitor list prices in this guide. Pricing pages change, and a stale dollar figure is worse than none. Instead we describe each vendor’s pricing shape (per-host, per-metric, per-GB, per-monitor) and what makes the bill grow, and we link every official pricing page — including our own — so you can pull current numbers. For hands-on configuration walkthroughs, our ClickHouse operator guides cover the metrics and alert thresholds that matter in production.