AI SRE Agent Monitors ClickHouse Cluster Health and Posts to Slack
Ingestion stops, and you start reading system tables by hand to find out why. This run checks disk, merges, and replication across every replica first.
Learn more about AURA → https://www.mezmo.com/aura
Get started today → https://github.com/mezmo/aura
Get deployment help → https://www.mezmo.com/contact
Kwabena runs self-hosted ClickHouse clusters. In this walkthrough he points AURA at a multi-replica cluster in orchestration mode: an agent named ClickHouse Report Orchestrator, running on GPT-5.2, dispatches three parallel workers and a Slack reporter. A workload analyst reads query_log and system.processes, a storage analyst reads system.parts, system.part_log, system.merges, and system.mutations, and a replication analyst covers replication state. Because the cluster has multiple replicas, CLICKHOUSE_CLUSTER is injected into the prompt at load so the workers can issue clusterAllReplicas queries.
The full disk that opens the video is Kwabena's own past incident, traced by hand through the query log and system tables to ZooKeeper logs and dedupe hashes from async inserts and materialized view dedupes. AURA did not find it. What AURA returns in this run is no critical findings, warnings across ingestion, parts and merges, replication, and capacity, and a set of recommendations, with a trimmed version posted to Slack and the full context available in the terminal.
The same run is then automated. A Python job in a kind cluster pings AURA's OpenAI-compatible chat completions endpoint on a 10-minute interval, with the ClickHouse and Slack MCP servers deployed separately because the kind cluster cannot start them as dependencies. Kwabena closes by noting the report can go to any destination with an MCP server behind it, and that an alerting system such as PagerDuty could trigger the run instead of a schedule. Neither alternative is demonstrated here.
Every worker holds run_query-only permissions. They cannot drop anything and they cannot mutate data, so AURA reads the cluster, reports what it sees, and recommends. It does not act on the cluster. AURA is built for the engineer who runs their own ClickHouse and wants a recurring read of disk, merges, and replication without hand-querying system tables at 3 a.m.
0:00 A full disk that stopped ingestion
0:39 How the demo is wired up
1:14 Reading the report in Slack
1:49 The AURA orchestration config
2:41 Three read-only analyst workers
3:24 Querying across all replicas
3:47 Running the investigation from the CLI
4:57 Automating the run with a job in kind
6:04 Other destinations and alert-driven runs
#AURA #ClickHouse #AISRE