Prometheus & Grafana: Monitoreo de Kubernetes

Prometheus es un sistema de monitoreo basado en pull: el servidor scrapea periódicamente endpoints HTTP /metrics expuestos por tus aplicaciones y por exporters, en vez de que agentes le empujen datos. Cada scrape retorna métricas en el formato de exposición de texto de Prometheus (u OpenMetrics) — una línea por serie temporal, con un nombre de métrica, un conjunto de labels clave/valor y un valor flotante. Este modelo pull hace que los targets se autodescriban y permite que Prometheus detecte un target caído simplemente porque el scrape falla, dándote una métrica up integrada gratis.

Una serie temporal se identifica de forma única por su nombre de métrica más el conjunto completo de pares clave/valor de labels. Ese conjunto de labels es el modelo de datos central: http_requests_total{method="GET",status="200",pod="api-7f9"} es una serie distinta a la misma métrica con status="500". Prometheus 3.x es la línea mayor actual (3.0 salió en noviembre de 2024; la serie 3.x se publica en una cadencia de aproximadamente seis semanas, con una línea 3.x LTS designada para despliegues conservadores). Prometheus 3 trajo una UI de consultas reconstruida, nombres de métricas y labels con UTF-8 nativo, un receptor OTLP nativo y Remote Write 2.0.

Las muestras aterrizan en el TSDB local, un almacén de series temporales de propósito específico. Los datos entrantes se bufferean en un bloque head en memoria y en un write-ahead log (WAL) para seguridad ante caídas, luego se compactan en bloques inmutables de 2 horas en disco, que se fusionan progresivamente en bloques más grandes. La retención está limitada por --storage.tsdb.retention.time (por defecto 15 días) o por tamaño. Como el TSDB local no está clusterizado, el patrón estándar para escala y durabilidad es un par de servidores Prometheus idénticos para HA más remote_write a un backend de largo plazo como Thanos o Grafana Mimir (que cubrimos más abajo).

PromQL es el lenguaje de consulta funcional que usas para rebanar métricas, construir alertas y alimentar los paneles de Grafana. Un selector de vector instantáneo como http_requests_total{job="api"} retorna una muestra por serie que coincide en un instante único; un vector de rango como http_requests_total{job="api"}[5m] retorna todas las muestras en una ventana de tiempo y es sobre lo que operan la mayoría de las funciones. Los matchers de labels soportan igualdad (=), negación (!=) y regex (=~, !~).

La función más importante es rate(). Los counters solo aumentan (hasta un reset a cero en un reinicio), así que casi nunca los graficas en crudo — calculas una tasa promedio por segundo sobre una ventana: rate(http_requests_total[5m]). Usa rate() para alertas y gráficas de movimiento lento, e irate() solo para dashboards rápidos y volátiles. Elige siempre un rango de al menos cuatro veces tu intervalo de scrape para que cada evaluación vea suficientes muestras. Para convertir tasas por serie en un número a nivel de servicio, envuélvelas en una agregación: sum(rate(...)) by (status).

Para latencia, las aplicaciones exponen histogramas como series _bucket, _sum y _count. Calcula un cuantil con histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)). Prometheus 3 también trae native histograms, una representación de buckets exponenciales mucho más eficiente que se consulta con la misma familia de funciones. El ejemplo de abajo es una expresión clásica de ratio de error RED (Rate, Errors, Duration) — la columna vertebral de la mayoría de las alertas de SLO.

Prometheus solo sabe cómo scrapear un endpoint /metrics, así que cualquier cosa que no exponga métricas de Prometheus de forma nativa necesita un exporter — un pequeño proceso que traduce el estado de algún sistema al formato de exposición. En Kubernetes, dos exporters hacen la mayor parte del trabajo pesado: node_exporter para métricas a nivel de máquina y kube-state-metrics (KSM) para el estado de los objetos de Kubernetes. Instrumenta tus propias apps directamente con una librería cliente oficial (Go, Java, Python, Node.js, Rust) en vez de con un exporter.

node_exporter corre como un DaemonSet (un Pod por nodo) y expone métricas de hardware y del SO: CPU por modo (node_cpu_seconds_total), memoria (node_memory_MemAvailable_bytes), disco, llenado del filesystem (node_filesystem_avail_bytes) y red. Lee del /proc y /sys del host, así que su Pod los monta como solo lectura. Estas son las métricas detrás de los dashboards de CPU/memoria/disco de nodos y de las alertas de capacidad.

kube-state-metrics es diferente: no reporta uso de recursos, reporta el estado deseado vs actual de los objetos de la API. Observa el API server y emite series como kube_deployment_status_replicas_available, kube_pod_status_phase, kube_pod_container_status_restarts_total y kube_node_status_condition. Une las métricas de estado de KSM con las métricas de uso de cAdvisor (expuestas por el kubelet) para responder preguntas como “¿cuáles Deployments están corriendo menos réplicas de las solicitadas?” Ambos exporters vienen pre-cableados en el kube-prometheus-stack, así que rara vez los despliegas a mano — pero debes entender qué métrica viene de dónde.

En un cluster donde los Pods aparecen y desaparecen cada minuto, hardcodear targets de scrape es inútil. Prometheus resuelve esto con service discovery: consulta la API de Kubernetes y mantiene automáticamente la lista de targets. El kubernetes_sd_config soporta varios roles — node, endpoints, service, pod y endpointslice — cada uno retornando un flujo de targets decorados con metadata de discovery como labels __meta_*.

Esos labels crudos de discovery se moldean en tu conjunto final de targets con relabeling. Los relabel_configs corren antes del scrape y deciden qué targets conservar, qué puerto y ruta atacar y qué labels adjuntar; los metric_relabel_configs corren después del scrape y pueden descartar o reescribir series ruidosas individuales antes de que lleguen al TSDB. La convención común es scrapear solo los Pods que llevan una anotación como prometheus.io/scrape: "true", leyendo el puerto y la ruta de anotaciones hermanas.

Cuando corres el Prometheus Operator (el motor dentro del kube-prometheus-stack) rara vez escribes scrape_configs crudos. En su lugar creas recursos personalizados ServiceMonitor y PodMonitor que seleccionan targets por label, y el Operator genera la configuración de Prometheus subyacente por ti. Esto mantiene la configuración de scrape declarativa, versionada en Git y en manos de cada equipo junto a los manifiestos de su app. Los tres roles de abajo cubren la gran mayoría del monitoreo de Kubernetes.

Las reglas son expresiones PromQL que Prometheus evalúa según un horario (evaluation_interval). Hay dos tipos. Las reglas de recording precalculan una consulta costosa o de uso frecuente y guardan el resultado como una nueva serie temporal, de modo que los dashboards y las alertas leen una métrica pre-agregada barata en vez de recalcular una expresión pesada en cada refresco. Por convención sus nombres usan dos puntos, p. ej. job:http_requests:rate5m, lo que las distingue de las métricas crudas de exporters.

Las reglas de alerting disparan cuando una expresión retorna resultados. El expr define la condición, for exige que se mantenga verdadera durante una duración antes de disparar (esto suprime el flapping ante picos transitorios), labels adjuntan severidad y claves de ruteo, y annotations llevan texto legible por humanos con templating. Una buena alerta es basada en síntomas y accionable: alerta sobre la quema de SLO de cara al usuario (ratio de error, latencia) en vez de sobre cada pico de CPU. Prometheus solo decide cuándo una alerta está disparando; luego la reenvía a Alertmanager, que decide quién recibe el page.

En producción, una estrategia de burn-rate sobre la regla de recording del ratio de error hace page al ingeniero de guardia solo cuando el SLO está genuinamente en riesgo: una alerta de quema rápida (2% del presupuesto en 1 hora) dispara un page, mientras una alerta de quema lenta (10% del presupuesto en 6 horas) abre un ticket. Este enfoque multi-ventana, multi-burn-rate — sacado directo del workbook de SRE de Google — redujo drásticamente la fatiga de alertas comparado con un umbral ingenuo de tasa de error.

Alertmanager es un binario separado que recibe las alertas que disparan desde uno o más servidores Prometheus y las convierte en notificaciones. Maneja el lado humano desordenado de las alertas que Prometheus deja fuera a propósito: agrupación de alertas relacionadas en una sola notificación, deduplicación entre pares Prometheus en HA, inhibición (suprimir un warning cuando un critical relacionado ya está disparando), silenciamiento (silenciar alertas durante una ventana de mantenimiento) y entrega a receivers como PagerDuty, Opsgenie, Slack, email o un webhook genérico.

La configuración gira en torno a un árbol de ruteo. El bloque route tiene un receiver por defecto de nivel superior y rutas hijas anidadas que coinciden por labels de la alerta — así las alertas severity: page van a PagerDuty mientras las severity: ticket abren un issue en Jira. Las claves de agrupación (group_by) colapsan muchas alertas que comparten el mismo cluster/servicio en un solo mensaje; group_wait, group_interval y repeat_interval controlan el timing de los mensajes primero, de seguimiento y de re-notificación.

Corre Alertmanager como un pequeño cluster HA (dos o tres réplicas que se comunican por gossip sobre una malla) para que la falla de un solo nodo nunca deje caer un page. En el kube-prometheus-stack, Alertmanager es un recurso personalizado de primera clase y su configuración vive en un CRD AlertmanagerConfig, dejando que cada namespace sea dueño de su propio ruteo y receivers. Rutea por el mismo label severity que setean tus reglas de alerting, y conserva inhibit_rules para que un critical de “cluster completo caído” no te entierre bajo cien warnings por servicio.

Grafana es la capa de visualización. Consulta a Prometheus (y a docenas de otros backends) y renderiza paneles — time series, stat, gauge, tabla, heatmap y los más nuevos paneles trend y canvas. Grafana 13 (la línea 13.x actual, GA en abril de 2026) hizo que los dashboards dinámicos sean el default y llevó Git Sync a disponibilidad general, sobre el trabajo de Grafana 12 que trajo el schema de dashboard v2 y una experiencia de edición rediseñada. Agregas Prometheus como data source por URL; dentro del cluster eso típicamente es http://prometheus-server.monitoring.svc:80.

No construyas dashboards haciendo clic para siempre. Usa variables de plantilla — una variable $namespace o $pod poblada por una consulta label_values() — para que un solo dashboard funcione en cada namespace y pod. Referencia la variable directamente en PromQL (rate(http_requests_total{namespace="$namespace"}[5m])). Provisiona dashboards y data sources de forma declarativa desde ConfigMaps o archivos para que sean reproducibles; en el kube-prometheus-stack un dashboard es simplemente un ConfigMap con un label grafana_dashboard: "1" que el sidecar de Grafana carga automáticamente.

Para los paneles en sí, apóyate en dashboards de la comunidad como punto de partida — el dashboard Node Exporter Full, el conjunto Kubernetes / Compute Resources y el overview de Alertmanager están probados en batalla — y luego recórtalos al puñado de paneles RED y USE (Utilization, Saturation, Errors) que tu equipo realmente lee durante un incidente. Grafana también tiene su propio motor de alerting unificado que puede evaluar reglas contra cualquier data source, pero muchos equipos mantienen la evaluación de alertas en Prometheus (para una única fuente de verdad) y usan Grafana puramente para visualización.

Nadie arma un stack de monitoreo de Kubernetes componente por componente en 2026. El Helm chart kube-prometheus-stack, mantenido por la organización prometheus-community, empaqueta todo en una sola instalación: el Prometheus Operator, el propio Prometheus, Alertmanager, Grafana, node_exporter, kube-state-metrics y un gran conjunto de dashboards por defecto curados y reglas de alerting para la salud del cluster. El chart está en la versión mayor 87.x y se distribuye tanto desde el repo tradicional de Helm como como artefacto OCI en oci://ghcr.io/prometheus-community/charts/kube-prometheus-stack.

La idea clave es el Prometheus Operator. En vez de editar prometheus.yml a mano, gestionas todo mediante recursos personalizados: un CR Prometheus define el servidor, ServiceMonitor/PodMonitor seleccionan targets de scrape, PrometheusRule contiene reglas de recording y alerting, y Alertmanager/AlertmanagerConfig gestionan las notificaciones. El Operator observa estos objetos y reconcilia el despliegue en ejecución — un modelo declarativo, nativo de GitOps, que encaja perfecto con Argo CD o Flux.

Instala con un override de values en vez de los defaults: fija los tamaños de volúmenes persistentes y la retención, define requests/limits de recursos para Prometheus (la memoria escala con las series activas — presupuesta unos pocos KB por serie), habilita persistencia para Grafana y activa remoteWrite cuando agregues almacenamiento a largo plazo. Una trampa crucial: este chart instala CRDs, y Helm no actualiza los CRDs automáticamente en un helm upgrade — aplica los nuevos CRDs del release antes de subir el chart a través de una versión mayor.

El TSDB local de un solo servidor Prometheus no está replicado y está limitado a unas pocas semanas de retención. Para métricas durables, multi-cluster y de larga retención usas remote_write: Prometheus sigue scrapeando y evaluando reglas localmente, pero además transmite cada muestra a un backend remoto. Prometheus 3 habla Remote Write 2.0, un formato protobuf más compacto que lleva metadata, native histograms y exemplars junto a las muestras. Los dos backends open-source dominantes son Thanos y Grafana Mimir.

Thanos toma el camino de menor fricción: un sidecar junto a cada Prometheus sube sus bloques del TSDB a almacenamiento de objetos (S3/GCS), y un Thanos Querier abanica sobre todas las instancias de Prometheus más el Store Gateway del almacén de objetos para darte una vista de consulta única, global y deduplicada con downsampling para gráficas de rango largo baratas. Está en la serie 0.4x con una cadencia de seis semanas. Grafana Mimir toma el enfoque opuesto: un backend de microservicios escalable horizontalmente y multi-tenant (su línea estable es 3.x) al que Prometheus empuja vía remote-write. Elige Thanos cuando ya corres Prometheus y quieres el bolt-on más simple; elige Mimir cuando necesitas aislamiento multi-tenant fuerte y estás sirviendo a cientos de equipos con un equipo de plataforma dedicado.

OpenTelemetry amarra el ecosistema. Prometheus 3 trae un receptor OTLP nativo — habilita --web.enable-otlp-receiver y las aplicaciones pueden empujar métricas OTLP a /api/v1/otlp/v1/metrics en vez de exponer un endpoint de scrape. En sentido contrario, el exporter prometheusremotewrite del OpenTelemetry Collector reenvía métricas OTLP directo a cualquier backend Remote-Write (Prometheus, Thanos, Mimir), y su receiver prometheus puede scrapear targets Prometheus existentes. Un patrón común en 2026 es un Collector como puerta de entrada de ingesta para trazas, logs y métricas, haciendo remote-write de las métricas a Mimir mientras tus servidores Prometheus siguen haciendo evaluación de reglas y alerting.

La plataforma monitorea un cluster GKE que corre 26 microservicios con el kube-prometheus-stack: un par de servidores Prometheus en HA scrapeando vía ServiceMonitors, node_exporter y kube-state-metrics para el estado de la infraestructura, Alertmanager ruteando a PagerDuty y Slack, y Grafana para los dashboards. Las métricas hacen remote-write a un backend de largo plazo para 13 meses de retención, y las alertas de burn-rate de SLO hacen page a la guardia solo cuando el presupuesto de error está genuinamente en riesgo.

Prometheus 3.x es la línea mayor actual: Prometheus 3.0 llegó en noviembre de 2024 — el release más grande en años — y la serie 3.x ha continuado en una cadencia de aproximadamente seis semanas a lo largo de 2026 (3.13 salió en julio de 2026). Cambios destacados sobre la era 2.x: una UI de consultas y TSDB completamente reconstruida, soporte UTF-8 nativo en nombres de métricas y labels, un receptor OTLP integrado, Remote Write 2.0 y native histograms estables. Existe una línea LTS designada para equipos que prefieren actualizaciones más lentas, solo de parches — 3.13 es la LTS actual (soportada hasta julio de 2027), sucediendo a la 3.5.

Native histograms: Los histogramas tradicionales de Prometheus te exigen elegir de antemano buckets fijos, lo cual es a la vez con pérdida y costoso en conteo de series. Los native histograms (promovidos a lo largo de la línea 3.x) usan un esquema de bucketing exponencial almacenado como una sola muestra, dando distribuciones de latencia de alta resolución a una fracción de la cardinalidad. Los consultas con la misma familia histogram_quantile(), y remote-write 2.0 los lleva de extremo a extremo hacia Thanos y Mimir.

Ingesta OTLP y convergencia con OpenTelemetry: Prometheus ahora acepta nativamente métricas de OpenTelemetry sobre OTLP (habilita --web.enable-otlp-receiver; endpoint /api/v1/otlp/v1/metrics), y el ecosistema se ha asentado en una clara división del trabajo — el OpenTelemetry Collector como la capa de ingesta y procesamiento neutral al proveedor, Prometheus/Mimir/Thanos como el almacén de métricas y motor de consulta, y Grafana como la UI. Los nombres de métricas UTF-8 en Prometheus 3 eliminan el último punto de fricción al mapear nombres OTLP (con puntos) a Prometheus.

Grafana 12 y 13: Grafana 12 (la 12.x actual) empujó los dashboards hacia ser gestionados como código: schema de dashboard v2, Git Sync para almacenar dashboards en un repositorio y una experiencia de edición reelaborada, junto con inversión continua en el motor de alerting unificado y Grafana Alloy (la distribución de collector basada en OpenTelemetry que sucede al Grafana Agent). Grafana 13 salió a mediados de 2026. Fija tu despliegue a un release soportado y trata los dashboards como artefactos versionados en vez de click-ops.

kube-prometheus-stack en 87.x, OCI-first: La instalación de facto de Kubernetes ahora se publica tanto en el repo clásico de Helm como como artefacto OCI en oci://ghcr.io/prometheus-community/charts/kube-prometheus-stack, siguiendo los releases recientes de Prometheus, Grafana y el Prometheus Operator. Grafana Labs también lanzó la v4 de su Helm chart separado de Kubernetes Monitoring en 2026, haciendo explícito el despliegue de exporters (node_exporter, kube-state-metrics) para que puedas apuntar a instancias existentes en vez de duplicarlas silenciosamente.

Madurez del almacenamiento a largo plazo: Thanos continúa su cadencia de release de seis semanas en la serie 0.4x con mejoras constantes en rendimiento de consulta y almacén de objetos, mientras Grafana Mimir alcanzó su línea estable 3.x (3.0 en noviembre de 2025) con multi-tenancy más fuerte y operación más simple. Ambos consumen Prometheus Remote Write 2.0 y native histograms, así que la elección ahora es mayormente operativa: simplicidad de bolt-on (Thanos) frente a plataforma multi-tenant escalable (Mimir). VictoriaMetrics sigue siendo una alternativa drop-in popular donde la eficiencia cruda de ingesta es la prioridad.