Operator Metrics
ClickHouse Server Metrics
Server metrics are exposed via the:8123/metrics Prometheus endpoint on each server pod. This endpoint requires authentication and should use a dedicated user with read-only privileges.
Note: The prometheus.io/* annotations on server pods expose some metrics, but do not include the ClickHouse_CustomMetrics_* metrics listed below. Set up a PodMonitor or equivalent scrape target for :8123/metrics.
ClickHouse Keeper Metrics
Keeper metrics are exposed via:8001/metrics. A PodMonitor should be created for keeper pods to capture these metrics.
Note: Specific keeper metric definitions are pending documentation (TODO in source). The metrics endpoint is available but individual metric descriptions have not yet been cataloged.
The following metric is referenced by the sizing guidance:
Keeper Sizing Alerts
Keeper holds its dataset in memory and a fixed allocation can be outgrown silently (see Keeper sizing: node vs pod), so alert on memory headroom and watch metadata growth. Example rule (adjust the threshold and label filters to your environment; thecontainer_* and kube_* series are standard cAdvisor / kube-state-metrics metrics):
Alert Rule Definitions
Operator Alerts
ClickhouseOperatorNotReconciling
- Check that the operator pod is running and healthy.
- Check operator logs to see what is preventing reconciliation.
- Verify there is no
clickhouse.com/skip-reconcileannotation on the CR.
ClickhouseOperatorReconcileErrors
ClickHouse Server Alerts
ClickHouseBrokenDetachedParts
- Wait to see if
ClickHouseDataLossalso triggers. - For SMT/RMT tables: if data loss alert also fires, investigate and mitigate data loss first.
- For local metadata tables (
s3diskors3diskWithCache): some small number of broken detached parts may not indicate an incident (files may be created but not written during hard restarts). - Contact ClickHouse support if the issue persists.
ClickHouseDataLoss
-
Query lost parts:
-
Search logs for lost parts:
-
Investigate history of a specific lost part:
-
Check for false positives:
- Check if the table has TTL and the lost part should have been dropped by TTL.
- Check
system.query_logfor TRUNCATE or DROP PARTITION queries.
ClickHouseCannotWriteToFileDescriptor
CANNOT_READ_FROM_FILE_DESCRIPTOR, not CANNOT_WRITE. This is intentional in the upstream alert definition — the read metric fires in the same failure scenario (full cache disk).
Purpose: Mostly indicates a full cache disk (“no space left on device”).
Recommended action:
- If node size or type recently changed, may be related to misconfiguration.
- Known issue: cache disk usage tracking can be incorrect when
join_algorithm = 'partial_merge'is used. - Diagnostic steps:
kubectl execinto the pod and rundf -hto check cache disk size.- Run
SELECT path, max_size FROM system.filesystem_cache_settingsto check required cache size. - If actual disk is smaller than configured, the issue is misconfiguration.
- Contact ClickHouse support.
ClickHouseChecksumsMismatch
ClickHouseCorruptedData
ClickHouseLogicalErrors
ClickHouseNotEnoughSpaceErrors
ClickHouseBrokenPartDetectedOnSelect
POTENTIALLY_BROKEN_DATA_PART exception. Check system.errors if not found in logs. Contact ClickHouse support.
ClickHouseReplicaAlreadyExists
ClickHouseServerShutdownStuck
system.stack_trace or GDB.
ClickHouseTableReplicasReadOnly
- Check server logs filtered by affected table name(s).
- Check keeper logs for potential issues.
- Query current read-only tables:
- Try running
SYSTEM RESTART REPLICAfor affected tables. - A simple replica restart may resolve the issue.
Diagnostic SQL Queries
Replication Queue Size per Table
Trigger: Alert if count exceeds 100 for any table.Replication Queue Oldest Entry per Table
Trigger: Alert if oldest entry is older than 1 day.Read-Only Tables
Lost Parts by Table
Lost Parts Log Search
Part History Investigation
Cache Disk Configuration Check
General Alerting Recommendations
Standard infrastructure alerts should be configured for:- Crashlooping pods
- Unschedulable pods
- Pod OOM kills
- PVC capacity
- Node health