Skip to main content
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:
  1. Check that the operator pod is running and healthy.
  2. Check operator logs to see what is preventing reconciliation.
  3. 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:
  1. Query lost parts:
  2. Search logs for lost parts:
  3. Investigate history of a specific lost part:
  4. 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:
    1. kubectl exec into the pod and run df -h to check cache disk size.
    2. Run SELECT path, max_size FROM system.filesystem_cache_settings to check required cache size.
    3. 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:
  1. Check server logs filtered by affected table name(s).
  2. Check keeper logs for potential issues.
  3. Query current read-only tables:
  4. Try running SYSTEM RESTART REPLICA for affected tables.
  5. 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

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