Skip to main content
El operador expone métricas compatibles con Prometheus y sondas de estado de Kubernetes para que pueda observar su actividad de reconciliación, detectar controladores atascados y generar alertas ante fallos. Esta guía explica qué expone el operador, cómo recopilarlo y qué consultas resultan útiles en el día a día.
Esta guía trata sobre el propio proceso del operador (el controller manager). Para las métricas del ClickHouse server (consultas, partes, retraso de replicación), use el endpoint de Prometheus en ClickHouse para recopilarlo por separado.

Endpoints

El proceso del operador expone dos endpoints HTTP dentro del pod de Kubernetes del manager: El endpoint de métricas está desactivado de forma predeterminada cuando se ejecuta directamente el binario del operador (--metrics-bind-address=0). El gráfico de Helm lo habilita con metrics.enable: true y metrics.port: 8080. El endpoint de la sonda de estado siempre está habilitado; la plantilla de implementación conecta /healthz y /readyz a las sondas de liveness y readiness del pod de Kubernetes en el puerto 8081.

Indicadores del binario del operador

Los indicadores relevantes de manager (definidos en cmd/main.go):
La convención 8443 (HTTPS) / 8080 (HTTP) en el texto de ayuda del indicador es solo una referencia. El gráfico de Helm sirve HTTPS en 8080 porque establece tanto metrics.port: 8080 como metrics.secure: true. No hay detección de modo basada en el puerto: --metrics-secure es lo que selecciona HTTPS o HTTP.

Habilitar métricas con Helm

El chart ya crea un Service para el puerto de métricas y, opcionalmente, un ServiceMonitor para prometheus-operator. El endpoint de métricas está habilitado de forma predeterminada (metrics.enable: true, puerto 8080, servido por HTTPS mediante metrics.secure: true). La única configuración que normalmente tendrás que cambiar es prometheus.enable para que el chart cree un ServiceMonitor por ti:
Si no usa cert-manager, establezca además certManager.enable: false y el ServiceMonitor recopilará las métricas con insecureSkipVerify: true, basándose únicamente en la autenticación mediante bearer token. El conjunto completo de valores predeterminados relacionados con las métricas es:
Aplicar:
Después de la instalación, el chart crea:
  • Service/<resource-prefix>-metrics-service — expone el puerto 8080 (HTTPS cuando metrics.secure: true).
  • ServiceMonitor/<resource-prefix>-controller-manager-metrics-monitor — cuando prometheus.enable: true.
  • ClusterRole/<resource-prefix>-metrics-reader — URL sin recurso /metrics con el verbo get.

Protección del endpoint de métricas

Cuando metrics.secure: true, el servidor de métricas exige TLS y autenticación/autorización de Kubernetes en cada recopilación. Los scrapers deben:
  1. Presentar un token Bearer de Kubernetes válido.
  2. Pertenecer a una ServiceAccount vinculada a un Rol de clúster que conceda get sobre la URL sin recursos /metrics.
El chart incluye ese Rol de clúster:
Vincúlalo a la ServiceAccount que utiliza tu scraper (normalmente, Prometheus):
Si ves 401 Unauthorized o 403 Forbidden en el endpoint de métricas, el scraper está usando HTTPS, pero no tiene un token Bearer de Kubernetes o no está autorizado para usarlo, o bien su ServiceAccount no tiene la asociación indicada arriba. Deshabilitar la seguridad estableciendo metrics.secure: false no se recomienda en clústeres compartidos, porque cualquiera con conectividad de red al pod de Kubernetes podría recopilar métricas del endpoint.

Referencia de ServiceMonitor

El chart genera un ServiceMonitor con esta estructura cuando prometheus.enable: true:
Si tu instancia de Prometheus no usa cert-manager, establece tlsConfig.insecureSkipVerify: true y confía únicamente en la autenticación mediante bearer token; el chart ya lo hace cuando certManager.enable: false.

Ejemplo independiente de Prometheus

Si no utiliza kube-prometheus-stack, el repositorio incluye un ejemplo autocontenido en examples/prometheus_secure_metrics_scraper.yaml. Crea una ServiceAccount, el RBAC necesario y un CR de Prometheus que selecciona el ServiceMonitor del operador.

Endpoints de las sondas de estado

Ambos endpoints se registran con la misma comprobación trivial de ping (healthz.Ping de sigs.k8s.io/controller-runtime). Por lo tanto, una sonda fallida significa “el proceso del manager no está sirviendo HTTP en :8081”, no “los controladores no están en mal estado”. Para detectar problemas a nivel de controlador, use en su lugar las métricas de reconciliación. Ambos endpoints se exponen en el puerto 8081 de forma predeterminada. Están conectados a la Implementación de la siguiente manera:
Una sonda que falla repetidamente suele significar que el propio servidor de la sonda nunca llegó a iniciarse; por ejemplo, que el manager se cerró prematuramente durante el arranque. Revise los logs del manager en busca de unable to start manager, errores de RBAC o errores de cache did not sync.

Catálogo de métricas

El operador no registra recolectores personalizados de Prometheus. Todo lo que aparece a continuación lo exponen las bibliotecas subyacentes controller-runtime y client-go. Las series más útiles, agrupadas según su finalidad:

Actividad de reconciliación

La etiqueta controller se deriva en controller-runtime del tipo de recurso registrado con For(...). Con el código actual en internal/controller/clickhouse e internal/controller/keeper, esto corresponde a clickhousecluster y keepercluster, respectivamente. Si ha personalizado el operador, verifíquelo con una recopilación puntual de /metrics.

Cola de trabajo

Las etiquetas name y controller tienen el mismo valor (el nombre del controlador).

Tráfico del servidor de API

Elección de líder

El gráfico de Helm habilita --leader-elect de forma predeterminada, por lo que esta métrica está presente en las instalaciones estándar de Helm. Cuando se ejecuta el binario directamente sin ese indicador, la métrica no aparece.

Entorno de ejecución

Colectores estándar del proceso y del entorno de ejecución de Go: go_goroutines, go_memstats_*, process_cpu_seconds_total, process_resident_memory_bytes, etc.

Consultas útiles de PromQL

Resumen del estado de salud

Detección de acumulación

Limitación de tasa y carga sobre la API

Estado del líder (implementación de alta disponibilidad)

Alertas sugeridas

Punto de partida para una PrometheusRule (ajuste los umbrales según su entorno):
La última regla solo tiene sentido cuando está habilitada la elección de líder.

Verificación de la configuración

Una comprobación rápida de extremo a extremo, suponiendo que el chart se ha instalado en clickhouse-operator-system:
Si la recopilación devuelve métricas en el formato de exposición de Prometheus, el endpoint y RBAC están correctamente conectados.
  • Instalación — Valores de Helm relevantes para la supervisión.
  • Configuración — Configuración de TLS compartida con el servidor de métricas.
Última modificación el 3 de julio de 2026