Key metrics and recommended alert rules for ClickHouse Private components. This is not exhaustive — your environment may expose additional metrics depending on configuration.
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.
Alert Rule Definitions
Operator Alerts
ClickhouseOperatorNotReconciling
Purpose: Alerts when the operator has not reconciled within 2 hours.
Recommended action:
- 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-reconcile annotation on the CR.
ClickhouseOperatorReconcileErrors
Purpose: Alerts when reconciliation errors exceed 5% of total reconciliation attempts.
Recommended action: Check operator logs for error messages to find the underlying cause.
ClickHouse Server Alerts
ClickHouseBrokenDetachedParts
Purpose: Triggered when broken detached parts exceed 100 for at least 60 minutes.
Recommended action:
- Wait to see if
ClickHouseDataLoss also triggers.
- For SMT/RMT tables: if data loss alert also fires, investigate and mitigate data loss first.
- For local metadata tables (
s3disk or s3diskWithCache): 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
Purpose: Indicates potential data loss. Fires immediately when lost parts are detected.
Recommended action: Contact ClickHouse support. Initial investigation steps:
-
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_log for TRUNCATE or DROP PARTITION queries.
ClickHouseCannotWriteToFileDescriptor
Note: The alert expression checks 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 exec into the pod and run df -h to check cache disk size.
- Run
SELECT path, max_size FROM system.filesystem_cache_settings to check required cache size.
- If actual disk is smaller than configured, the issue is misconfiguration.
- Contact ClickHouse support.
ClickHouseChecksumsMismatch
Purpose: Checksums of data parts don’t match. May indicate a bug after upgrade.
Recommended action: Contact ClickHouse support.
ClickHouseCorruptedData
Purpose: Data parts are corrupted. May indicate a bug after upgrade.
Recommended action: Contact ClickHouse support.
ClickHouseLogicalErrors
Purpose: Logical errors occurred. Often a bug in the codebase.
Recommended action: Contact ClickHouse support.
ClickHouseNotEnoughSpaceErrors
Purpose: NOT_ENOUGH_SPACE errors emitted. Could indicate full PVC, misconfiguration, or large temporary data reservation.
Recommended action: Contact ClickHouse support.
ClickHouseBrokenPartDetectedOnSelect
Purpose: SELECT failed due to POTENTIALLY_BROKEN_DATA_PART error, indicating data loss.
Recommended action: See ClickHouseDataLoss action. Examine logs for POTENTIALLY_BROKEN_DATA_PART exception. Check system.errors if not found in logs. Contact ClickHouse support.
ClickHouseReplicaAlreadyExists
Purpose: Replica creation failed because a replica already exists at the path. Usually a bug in the Replicated database engine or Shared Catalog.
Recommended action: Unlikely to be user error. Contact ClickHouse support.
ClickHouseServerShutdownStuck
Purpose: ClickHouse server has been shutting down for over an hour.
Recommended action: Check threads via system.stack_trace or GDB.
ClickHouseTableReplicasReadOnly
Purpose: A table has been in READONLY mode for more than an hour.
Recommended action:
- Check server logs filtered by affected table name(s).
- Check keeper logs for potential issues.
- Query current read-only tables:
- Try running
SYSTEM RESTART REPLICA for 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.
Alternative:
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
These are environment-specific and not covered by the ClickHouse-specific alerts above.
The Grafana ClickHouse mixin provides a prebuilt dashboard for many ClickHouse metrics. Last modified on August 7, 2026