chmonitorClickHouse monitoring: Grafana vs Datadog vs a dedicated dashboard
How Grafana, Datadog, and a ClickHouse-native dashboard differ for query, storage, and cluster monitoring — and when to use each (or all three).
"ClickHouse vs Datadog" and "ClickHouse vs Grafana" are slightly the wrong questions. Datadog is a full-stack observability platform. Grafana is a visualization layer. ClickHouse is the database. The useful comparison is how you monitor ClickHouse: agent metrics, DIY SQL panels, or a dashboard that already speaks system.query_log, system.parts, and system.replicas.
Three different jobs
| Datadog | Grafana | chmonitor | |
|---|---|---|---|
| Primary job | APM, infra, logs, incidents | Multi-source dashboards | ClickHouse operational monitoring |
| How it sees CH | Agent (and DBM Preview) | ClickHouse plugin and/or Prometheus | Direct SELECT on system.* |
| Agents on CH nodes | Typical | Optional | No |
| Merges / parts / replicas UI | Integration / DBM metrics | You write the panels | Built-in pages |
| Multi-datasource wall | Strong | Strongest | ClickHouse-only by design |
Does Datadog use ClickHouse?
Two separate facts get mixed in search:
- Datadog monitors ClickHouse — the Agent integration plus Database Monitoring (Preview) for query samples, explain-ish views, parts and merges.
- Datadog can send observability data into ClickHouse — for example routing logs through Observability Pipelines. That is Datadog as a producer into CH, not "Datadog is built on ClickHouse."
Neither replaces a native ops UI if your on-call is "why is this MergeTree exploding."
What each is good at
Datadog — ClickHouse is one service among Kubernetes, Kafka, and app traces. You want correlation, org-wide SLOs, and an incident product. You already pay for Datadog.
Grafana — You already have Prometheus, Loki, and a wall of panels. The official ClickHouse data source (or Altinity's) can chart the same system tables. Great for custom boards; you own the SQL and the refresh load.
chmonitor — Running and slow queries, table size and parts, merge backlog, replication lag, storage, health, plus an AI agent and MCP server over those tables. Five-minute Docker/Helm, no per-node agent.
Performance and storage monitoring, concretely
| Workflow | Grafana | Datadog | chmonitor |
|---|---|---|---|
Slow queries from query_log | SQL panel | DBM / query metrics | Queries pages |
| Too many parts / table size | SQL panel | Integration metrics | Tables |
| Merge backlog | SQL panel | Integration / DBM | Operations / Health |
| Replication lag | SQL panel | Host/replica metrics | Cluster / replicas |
| "What should I change?" | You | You + platform AI | Ranked recommendations, you apply DDL |
Copy-paste Grafana SQL that matches chmonitor's queries: Grafana bridge.
When Grafana still makes sense
You standardized on Grafana. You need one glass for Prom + logs + ClickHouse application data, not only system.*. You like building panels. Run Grafana and chmonitor together — same cluster, separate read-only users (GRANT SELECT ON system.*). Grafana is not "vs ClickHouse"; it visualizes it.
When Datadog still makes sense
ClickHouse is not the only thing that pages you. You need traces, log search, and escalation in one vendor. Keep Datadog for the fleet; put a dedicated dashboard on the cluster if merge/part/query drills are where the CH on-call actually lives.
When a dedicated ClickHouse dashboard wins
CH-heavy, self-hosted or cost-sensitive teams. You want version-aware system-table SQL without maintaining a JSON dashboard pack. You want MCP so another agent can ask "what's the replication lag" without scraping Prometheus.
Suggested stacks
Grafana + chmonitor — wall + CH ops. Datadog + chmonitor — APM + CH ops. chmonitor alone — ClickHouse is the product you run. None of these require ripping the other out.
Marketing-length matrices: chmonitor vs Datadog, vs Grafana. Demo: dash.chmonitor.dev.
Related
Reduce ClickHouse query memory with external GROUP BY
How max_bytes_before_external_group_by spills aggregation to disk to avoid MEMORY_LIMIT_EXCEEDED, cheaper alternatives to try first, and the diagnostic SQL to confirm a spill happened.
ch-ui vs chmonitor: ClickHouse UI vs monitoring
ch-ui is a ClickHouse workspace (SQL editor, pipelines). chmonitor is an operational monitoring dashboard over system tables. How they differ — and why search mixes the names.