En la lección anterior instalamos metrics-server y por fin supimos cuánto consume cada componente de Rutas Norte ahora mismo. También descubrimos su límite infranqueable: no recuerda nada. La pregunta "¿qué pasó anoche a las tres de la madrugada?" sigue sin respuesta, y con ella todas las que de verdad importan: ¿cuántas reservas por minuto estamos confirmando?, ¿ha subido la latencia desde el último despliegue?, ¿cuánto falta para que se llene el disco de postgres-reservas?

Esta lección despliega Prometheus, el estándar de facto para monitorizar Kubernetes y el segundo proyecto graduado de la CNCF después del propio Kubernetes. Vamos a entender su modelo de datos, de dónde salen realmente las métricas de un clúster (una de las mayores fuentes de confusión para quien empieza), cómo instrumentar api-reservas con métricas de negocio, cómo desplegar el stack con el operador que anunciamos en 06-07, y cómo escribir PromQL que responda a preguntas reales de Rutas Norte. Al terminar, la plataforma tendrá memoria.

1. Qué aporta Prometheus frente a metrics-server
2. El modelo de extracción (pull) y los endpoints /metrics
3. El modelo de datos: series, etiquetas y los cuatro tipos de métrica
4. De dónde salen las métricas de un clúster: la tabla que aclara la confusión
5. Instrumentar api-reservas con métricas de negocio
6. Desplegar el kube-prometheus-stack con Helm
7. El Prometheus Operator y sus recursos personalizados
8. ServiceMonitor de Rutas Norte y diagnóstico de objetivos
9. PromQL desde cero y con sentido
10. Los cuatro indicadores dorados aplicados a Rutas Norte
11. Almacenamiento, retención y los límites de Prometheus
12. Errores comunes y consejos
13. Ejercicios

Tres cosas, y las tres son las que nos faltaban.

Histórico. Prometheus guarda cada muestra en una base de datos de series temporales en disco. Con la retención por defecto del stack tendremos varios días; configurando el almacenamiento, semanas o meses. La pregunta de las tres de la madrugada tiene respuesta.

Consultas. PromQL es un lenguaje completo para agregar, filtrar, derivar y comparar series. No es "ver un número": es "dame la tasa de errores 5xx de api-reservas en el entorno de producción, agrupada por ruta, durante la última hora".

Alertas. Prometheus evalúa expresiones periódicamente y, cuando se cumplen durante un tiempo sostenido, dispara alertas que Alertmanager enruta a quien corresponda. Eso es lo que hace que alguien se entere a las tres de la madrugada sin estar mirando una pantalla.

Y una cuarta, menos obvia pero decisiva: cualquier cosa puede exponer métricas. metrics-server solo sabe de CPU y memoria. Prometheus recoge lo que sea que un endpoint HTTP le ofrezca: peticiones por ruta, reservas confirmadas, tamaño de la cola de correos, conexiones activas de PostgreSQL, certificados a punto de caducar.

Los dos conviven. No sustituimos metrics-server: lo complementamos.

Aquí está la decisión de diseño que define todo lo demás.

La mayoría de sistemas de monitorización tradicionales funcionan por empuje (push): la aplicación envía sus métricas a un servidor central. Prometheus hace lo contrario: extracción (pull). Prometheus tiene una lista de objetivos (targets) y, cada cierto intervalo (típicamente 30 segundos), hace un GET a cada uno.

¿Por qué es mejor extraer que recibir?

• Prometheus sabe si un objetivo está caído. Si el GET falla, la métrica sintética up vale 0. Con push, la ausencia de datos es ambigua: ¿la aplicación está caída o simplemente no ha enviado nada?
• El control del ritmo lo tiene el sistema de monitorización, no las aplicaciones. Cien aplicaciones mal programadas no pueden inundarlo.
• Descubrimiento automático. Prometheus consulta la API de Kubernetes para saber qué pods existen. Un pod nuevo aparece como objetivo automáticamente, sin configurar nada en la aplicación.
• Depuración trivial. Puedes hacer curl al endpoint /metrics desde tu portátil y ver exactamente lo mismo que ve Prometheus.

La excepción son los procesos de vida muy corta, como nuestro CronJob informes-ocupacion: puede terminar antes de que Prometheus lo escanee. Para esos casos existe el Pushgateway, un intermediario al que el job empuja sus métricas y que Prometheus escanea después. Es la única excepción legítima y conviene usarla con moderación.

Es texto plano. Cada línea es nombre{etiquetas} valor. Las líneas # HELP y # TYPE son metadatos: descripción y tipo. Ese formato, deliberadamente simple, es todo el contrato entre una aplicación y Prometheus.

Una serie temporal en Prometheus se identifica de forma única por su nombre de métrica más el conjunto exacto de sus etiquetas. Esto es fundamental:

Cambiar el valor de una sola etiqueta crea una serie completamente nueva. Cada serie ocupa memoria y disco, y de ahí nace el peligro más citado de Prometheus: la cardinalidad.

Regla de oro de la cardinalidad: nunca uses como etiqueta un valor con muchos valores posibles. Nada de identificadores de usuario, de reserva, de sesión, direcciones IP de cliente, marcas de tiempo o mensajes de error completos.

Un ejemplo real del peligro. Si api-reservas etiquetara cada petición con el dni del cliente:

Con 200 000 clientes y 15 rutas, tendrías 3 millones de series solo de esa métrica. Prometheus se quedaría sin memoria en minutos. Y, además, estarías metiendo datos personales en el sistema de monitorización, con las implicaciones que veremos en 07-05.

Etiquetas que Prometheus añade por sí mismo a todo lo que recoge en Kubernetes (y que usaremos constantemente):

counter (contador). Un valor que solo crece: peticiones atendidas, errores, bytes enviados, reservas confirmadas. Nunca se consulta directamente. El valor absoluto 184203 no dice nada: ¿son muchas? ¿desde cuándo? Se consulta siempre con rate() o increase(), que calculan cuánto ha crecido por unidad de tiempo. Por convención, su nombre acaba en _total.

Prometheus detecta automáticamente los reinicios del contador (cuando un pod se recrea, el contador vuelve a 0) y rate() los compensa. No tienes que preocuparte por ello.

gauge (medidor). Un valor que sube y baja: conexiones activas, temperatura, memoria en uso, tamaño de una cola. Se consulta directamente. Es el tipo de casi todo lo que expone cAdvisor sobre memoria.

histogram (histograma). El tipo más potente y el peor entendido. En lugar de guardar cada valor individual, la aplicación clasifica cada observación en cubetas acumulativas predefinidas. Una métrica de histograma expone en realidad tres cosas:

Lectura: 8140 peticiones tardaron menos de 50 ms; 9210 tardaron menos de 100 ms (incluidas las 8140 anteriores: son acumulativas); 9821 en total, luego 9 peticiones tardaron más de 1 segundo.

Con esos datos, la función histogram_quantile() puede estimar cualquier percentil. La ventaja enorme frente al summary: como las cubetas son contadores normales, se pueden sumar entre pods. Puedes calcular el percentil 95 de latencia de todo api-reservas agregando sus seis réplicas. Con un summary eso es matemáticamente imposible.

El coste: cada cubeta es una serie. Un histograma con 10 cubetas y 15 rutas son 150 series por pod. Elige las cubetas con criterio, ajustadas a la latencia real de tu servicio.

summary (resumen). La aplicación calcula los percentiles ella misma y los expone. Barato de consultar, pero no agregable entre instancias: el percentil 95 del pod A y el del pod B no se pueden combinar para obtener el del servicio. En Kubernetes, donde todo tiene varias réplicas, esto lo descarta casi siempre. Úsalo solo si necesitas un percentil exacto de una única instancia.

Prometheus tiene convenciones que conviene respetar porque las herramientas y los cuadros de mando las asumen:

• Prefijo con el nombre del sistema: rutasnorte_.
• Unidad base en el nombre y siempre en unidades base del SI: _segundos no _ms, _bytes no _mb.
• Los contadores acaban en _total.
• Nombres en snake_case, sin mayúsculas.

Esta es la sección que resuelve la duda que tiene todo el mundo la primera semana: "¿por qué necesito cuatro cosas distintas para monitorizar Kubernetes?".

La respuesta corta: porque son cuatro capas de realidad diferentes y ninguna de ellas puede ver las otras.

Vamos una a una, porque la distinción importa muchísimo a la hora de escribir consultas.

Es la misma fuente que alimenta a metrics-server (07-02), pero Prometheus la lee directamente y con mucho más detalle. Métricas clave:

Fíjate en la tercera: el contador de periodos estrangulados que en 07-02 dijimos que kubectl top no puede darnos. Aquí está, y es la que confirmará el diagnóstico de throttling de api-reservas.

Aviso práctico: estas métricas también aparecen con container="" (el valor agregado del pod, incluido el contenedor pause de infraestructura). Casi siempre querrás filtrar con container!="" para no contar el doble.

Es un DaemonSet (un pod por nodo, como estudiamos en 06-02) que lee /proc y /sys del sistema anfitrión. Ve cosas que ningún contenedor puede ver:

Es el que te avisa de que el disco del nodo se está llenando, de que la carga media está por las nubes o de que la tarjeta de red está saturada. Ningún contenedor puede decirte eso de sí mismo.

Esta es la que más cuesta entender y la que más falta hace. No mide consumo de nada. Se conecta a la API de Kubernetes y convierte el estado de los objetos en métricas:

Con estas métricas puedes alertar de cosas que ninguna de las otras fuentes conoce: un Deployment con menos réplicas disponibles de las deseadas, un pod reiniciándose en bucle, un Job que ha fallado, un PVC que lleva veinte minutos en Pending.

Y algo muy útil: kube_pod_container_resource_requests expone las requests declaradas. Cruzando esa con container_memory_working_set_bytes de cAdvisor obtienes, en una sola consulta PromQL, exactamente el análisis de recalibración que en 07-02 tuvimos que hacer con un script de bash.

PostgreSQL no habla el formato de Prometheus. Un exportador es un proceso que se conecta al software, consulta sus estadísticas internas y las traduce a /metrics.

Y aquí conectamos con 06-04: ya lo tenemos desplegado. Cuando añadimos el sidecar exportador de métricas al pod de postgres-reservas, dijimos explícitamente que Prometheus lo consumiría en esta lección. Ha llegado el momento.

Lo que expone, y que nos hará falta:

Existen exportadores para prácticamente todo: redis_exporter para redis-cache, nginx-prometheus-exporter para tienda-web, blackbox_exporter para comprobar desde fuera que https://www.rutasnorte.example responde.

Ninguna de las cuatro fuentes anteriores puede decirte cuántos billetes has vendido. Eso solo lo sabe tu código. Es la siguiente sección.

La instrumentación propia es lo que separa un cuadro de mando de infraestructura de uno que le importa al negocio. "El pod usa 300 Mi de RAM" no interesa al director de Rutas Norte. "Estamos confirmando 12 reservas por minuto, un 40 % menos que ayer a esta hora" sí.

api-reservas está en Node.js, así que usamos la librería cliente oficial prom-client. Existen librerías equivalentes para Java, Go, Python, .NET y prácticamente cualquier lenguaje.

Y el middleware que lo conecta con Express:

Dos decisiones a subrayar:

1. Ruta normalizada, no URL real. req.route.path da /api/reservas/:id, con lo que todas las reservas comparten serie. Usar req.originalUrl daría /api/reservas/48213, /api/reservas/48214... una serie por reserva. Es el error de cardinalidad más frecuente del mundo.
2. /metrics en el mismo puerto que la aplicación, o en uno aparte. Aquí lo dejamos en el 8080 por simplicidad. En producción es preferible exponerlo en un puerto distinto (por ejemplo 9090) que no esté publicado en el Ingress, para que las métricas no sean accesibles desde internet. Las NetworkPolicies de rutas-norte-pro (04-06) deberán permitir el tráfico desde el namespace de monitorización a ese puerto: recuerda que toda conversación nueva necesita su política.

Instalar Prometheus a mano en Kubernetes significa gestionar unos veinte objetos entre Deployments, ConfigMaps, Services, RBAC y almacenamiento. La comunidad ha empaquetado todo eso en un chart de Helm llamado kube-prometheus-stack.

Nota: Helm es el gestor de paquetes de Kubernetes y lo estudiaremos a fondo en 10-03. Aquí lo usamos como herramienta de instalación; por ahora basta con entender que un chart es una plantilla parametrizable de manifiestos y que helm install los genera y los aplica.

Fichero de valores adaptado a Rutas Norte:

Qué acabamos de instalar:

Acceso a la interfaz de Prometheus:

Aquí se materializa lo que anunciamos en 06-07. El Prometheus Operator es el ejemplo canónico del patrón operador: un controlador que observa recursos personalizados y reconcilia el estado real hasta que coincida.

Sin operador, añadir un objetivo nuevo a Prometheus significa editar un fichero prometheus.yml, meterlo en un ConfigMap, recargar la configuración y esperar. Un proceso manual, centralizado y propenso a errores.

Con operador, el equipo que despliega api-reservas crea un objeto ServiceMonitor junto a su propia aplicación, en su propio namespace, y el operador lo detecta y regenera la configuración de Prometheus automáticamente. La monitorización pasa a ser responsabilidad descentralizada, versionada en Git junto al resto de manifiestos.

Y AlertmanagerConfig, para configurar el enrutado de alertas por namespace. También en 07-04.

Como vimos en 06-06, todos estos son CRDs. Y como Certificate de cert-manager o VolumeSnapshot, se manejan con kubectl exactamente igual que un Deployment.

Requisito imprescindible: el ServiceMonitor referencia el puerto por su nombre, así que el Service debe tenerlo nombrado.

Como postgres-reservas es un StatefulSet con Service headless (06-01), necesitamos un Service adicional específico para métricas. Un Service headless (clusterIP: None) funciona igual de bien como origen de un ServiceMonitor, porque el operador usa los Endpoints, no la ClusterIP.

Con esto, el sidecar que añadimos en 06-04 empieza a alimentar Prometheus. La promesa se cumple.

Nuestra convención es clara: en rutas-norte-pro hay una deny-all y cada conversación se autoriza una a una. Prometheus vive en monitorizacion y quiere hablar con los puertos de métricas de rutas-norte-pro. Sin política, todos los objetivos aparecerán caídos.

En la interfaz de Prometheus, Status → Targets. O por línea de comandos:

Es la pregunta de esta lección. Checklist en orden de frecuencia:

El punto 3 merece detalle porque es traicionero. El recurso Prometheus tiene un serviceMonitorSelector. Si el chart lo dejó con release: monitorizacion, solo recogerá ServiceMonitor con esa etiqueta, y el tuyo será ignorado en silencio: no hay evento, no hay error, simplemente no aparece.

Dos soluciones: poner serviceMonitorSelectorNilUsesHelmValues: false en los valores (lo que hicimos), o añadir la etiqueta release: monitorizacion a todos tus ServiceMonitor.

Comprobar directamente si el objetivo está siendo escaneado:

Un array vacío significa que el objetivo no está configurado (problemas 1-4). Un resultado con value: ["...", "0"] significa que está configurado pero no responde (problemas 5-7).

PromQL asusta al principio y es más sencillo de lo que parece si se aprende por capas.

La consulta más simple es el nombre de una métrica:

Devuelve todas las series con ese nombre: una por cada combinación de etiquetas de cada pod. Para filtrar, se usan las llaves:

Los cuatro operadores de comparación de etiquetas:

Combinables, con AND implícito:

Lectura: peticiones a /api/reservas en producción que devolvieron un código 5xx.

Añadiendo [5m] obtienes, en lugar de un valor por serie, todos los valores de los últimos 5 minutos:

Esto se llama vector de rango y no se puede dibujar directamente: es materia prima para las funciones del siguiente nivel.

rate() — la función más importante de PromQL.

Calcula el incremento por segundo de un contador dentro de una ventana. Es lo que convierte un contador inútil (184203) en un dato con sentido (12,4 peticiones por segundo).

Tres cosas que hay que saber sobre rate():

• Solo funciona con contadores. Aplicarla a un gauge da resultados sin sentido.
• Compensa automáticamente los reinicios del contador cuando un pod se recrea.
• La ventana debe contener al menos 4 muestras. Con interval: 30s, la ventana mínima razonable es [2m]; lo habitual es [5m]. Con [1m] y escaneos de 30 s tendrías dos muestras y resultados erráticos.

increase() — igual que rate() pero da el incremento total de la ventana en vez de por segundo. Es literalmente rate() * segundos_de_la_ventana. Más legible para preguntas humanas:

sum by y sum without — agregación.

rate() devuelve una serie por pod y por combinación de etiquetas. Casi nunca quieres eso: quieres el total del servicio.

sum by (a, b) conserva solo las etiquetas a y b. sum without (pod, instance) conserva todas menos esas. La segunda forma suele ser más robusta ante cambios.

Otras agregaciones: avg, min, max, count, stddev, topk, bottomk.

topk() — los N mayores. Perfecto para "¿quién se está comiendo el clúster?":

histogram_quantile() — percentiles a partir de histogramas.

Descomponiendo, de dentro afuera:

1. rate(..._bucket[5m]) → tasa de incremento de cada cubeta.
2. sum by (le, ruta) → suma las cubetas de todos los pods, conservando le (el límite de la cubeta) y ruta. La etiqueta le es obligatoria: sin ella, histogram_quantile no puede funcionar. Es el error más común con esta función.
3. histogram_quantile(0.95, ...) → estima el percentil 95.

El resultado es en segundos: 0.412 significa que el 95 % de las peticiones se resuelven en menos de 412 ms.

Precisión: el resultado es una estimación por interpolación lineal dentro de la cubeta. Si tus cubetas son [0.1, 0.5, 1] y el p95 real está en 0,42 s, la estimación puede desviarse bastante. Por eso elegimos cubetas ajustadas a nuestra latencia real en el apartado 5.

Operadores aritméticos y comparación entre métricas.

Prometheus empareja series de ambos lados por sus etiquetas comunes. Si las etiquetas no coinciden, el resultado es vacío: es la causa de la mitad de las consultas que "no devuelven nada". on() e ignoring() permiten controlar el emparejamiento.

Peticiones por segundo por ruta:

Tasa de error (proporción de 5xx sobre el total):

Devuelve un número entre 0 y 1. Multiplicado por 100 es el porcentaje. Advertencia: si el denominador es 0 (sin tráfico), el resultado es NaN y desaparece del gráfico. Es un comportamiento correcto: sin tráfico no hay tasa de error que medir.

Percentil 95 de latencia por ruta:

Reservas confirmadas por minuto (la métrica del negocio):

Saturación de CPU respecto al límite configurado:

Un valor de 0.95 significa que el pod está usando el 95 % de su límite: candidato inmediato a throttling.

Confirmar el throttling que en 07-02 no podíamos ver:

Es la fracción de periodos de planificación en los que el contenedor fue estrangulado. Por encima de 0.25 (25 %) hay un problema real de rendimiento. Esta es exactamente la consulta que habría diagnosticado el problema de api-reservas en 07-02 en diez segundos.

Comparar consumo real con las requests: la recalibración de 07-02, ahora automatizada:

Con Prometheus, esta consulta sobre 30 días de histórico sustituye por completo al script de bash de 07-02, y además permite pedir el percentil real usando quantile_over_time.

Réplicas no disponibles (usa kube-state-metrics):

Objetivo caído:

Pods reiniciándose en bucle:

Conexiones de PostgreSQL respecto al máximo (del sidecar de 06-04):

Fallos de la pasarela de pagos externa:

Esta consulta permite distinguir "nuestra plataforma falla" de "el proveedor externo falla", que es una distinción muy valiosa a las tres de la madrugada.

Los cuatro indicadores dorados (golden signals), popularizados por el libro de SRE de Google, son el marco que evita el error de monitorizar todo y no entender nada.

Un matiz esencial sobre la latencia: hay que medir por separado la de las peticiones que fallan. Un error 500 devuelto en 3 ms baja artificialmente la latencia media y puede hacer que un servicio que falla masivamente parezca rapidísimo.

Las consultas concretas para api-reservas, que serán la base del cuadro de mando de 07-04:

Esa última consulta cierra un círculo del módulo: es exactamente el fenómeno que en 07-01 dejaba a api-reservas viva pero inservible. Entonces solo teníamos una readiness que apartaba el pod; ahora tenemos además el dato registrado y consultable a posteriori.

Consultas como el p95 son caras: recorren muchas series. Si un cuadro de mando la ejecuta cada 15 segundos con 8 paneles abiertos, Prometheus sufre.

Las reglas de grabación (recording rules) precalculan una consulta periódicamente y guardan el resultado como una métrica nueva:

Ahora los cuadros de mando y las alertas consultan apireservas:latencia_p95:5m, que es una única serie ya calculada. En 07-04 las usaremos intensivamente.

Prometheus escribe en su propia base de datos de series temporales (TSDB):

1. Las muestras nuevas van a un bloque en memoria y a un registro de escritura anticipada (WAL) en disco, que protege ante caídas.
2. Cada 2 horas, ese bloque se persiste como un directorio inmutable en disco.
3. Un proceso de compactación va fusionando bloques pequeños en bloques mayores.
4. Los bloques que superan la retención se borran enteros.

Consecuencia importante: la retención no borra muestras sueltas, borra bloques completos. Con retention: 30d puedes tener puntualmente algo más de 30 días.

La regla práctica aceptada: entre 1 y 2 bytes por muestra tras la compresión.

Con 50 GiB de PVC vamos sobrados, incluso con margen para la compactación (que necesita espacio temporal). Por eso pusimos también retentionSize: 45GiB: es el freno de emergencia si la cardinalidad crece más de lo previsto.

Ver la cardinalidad real:

Esta segunda consulta es la primera que hay que ejecutar cuando Prometheus empieza a consumir demasiada memoria.

Tres limitaciones de diseño, deliberadas:

1. Almacenamiento local, no distribuido. Los datos viven en el disco de un pod. Sin replicación entre instancias.
2. No escala horizontalmente por sí mismo. Dos Prometheus no comparten datos: cada uno tiene los suyos.
3. La retención larga es cara. Guardar dos años en local significa cientos de GB en un disco rápido y un consumo de memoria considerable al consultar.

Para retención larga y visión multiclúster existen dos proyectos que extienden Prometheus:

Ambos permiten años de retención barata y consultar varios clústeres a la vez. Para Rutas Norte con un solo clúster, 30 días son suficientes hoy; cuando el módulo 11-05 aborde la gestión multiclúster, Thanos será la evolución natural.

Configurar remote_write desde el operador es sencillo:

1. Explosión de cardinalidad. El error más grave y el más caro. Etiquetar con identificadores de reserva, DNI, IP de cliente o URLs sin normalizar multiplica las series por miles y tumba Prometheus por falta de memoria. Antes de añadir una etiqueta, pregúntate cuántos valores distintos puede tener. Si la respuesta es "no lo sé", no la añadas.

2. Consultar un contador sin rate(). rutasnorte_peticiones_total a secas devuelve un valor acumulado desde que arrancó el pod. Es un gráfico que solo sube y no significa nada. Siempre rate() o increase().

3. Ventana de rate() demasiado corta. Con interval: 30s, un rate(...[1m]) tiene dos muestras y produce ruido o huecos. Regla: la ventana debe ser al menos 4 veces el intervalo de escaneo.

4. Olvidar le en sum by antes de histogram_quantile. Si agregas sin conservar la etiqueta le, la función no puede reconstruir el histograma y devuelve NaN o nada. Es el fallo número uno con percentiles.

5. El ServiceMonitor selecciona etiquetas de pod en vez de Service. El selector de un ServiceMonitor se compara con las etiquetas del objeto Service. Como en Rutas Norte los Service llevan las mismas etiquetas que los pods, es fácil no darse cuenta hasta que un Service tiene etiquetas distintas.

6. La etiqueta release del operador. Si el recurso Prometheus tiene serviceMonitorSelector: {matchLabels: {release: monitorizacion}}, tus ServiceMonitor sin esa etiqueta se ignoran sin ningún mensaje de error. Comprobarlo es lo primero cuando un objetivo no aparece.

7. Prometheus sin almacenamiento persistente. Sin storageSpec, el chart usa un emptyDir y cada reinicio del pod borra todo el histórico. Es exactamente el problema que veníamos a resolver.

8. Sin retentionSize. Solo con retention: 90d, si la cardinalidad crece, el disco se llena, Prometheus entra en CrashLoopBackOff y te quedas sin monitorización justo cuando más falta hace. Pon siempre un límite de tamaño, y que sea un 80-85 % del PVC.

9. Alertar sobre métricas de un summary. No son agregables entre pods. Si tu alerta usa el p99 de un summary con seis réplicas, el número no significa nada útil.

10. Monitorizar el nodo con métricas de contenedor. cAdvisor no ve el sistema de ficheros del nodo ni su carga media. Para eso está node-exporter. Confundirlos lleva a alertas que nunca disparan.

11. Olvidar las NetworkPolicies. En rutas-norte-pro hay una deny-all. Si Prometheus no puede alcanzar los puertos de métricas, todos los objetivos aparecen caídos y el error (context deadline exceeded) no es nada evidente.

12. Instrumentar demasiado tarde. La instrumentación de negocio se añade en el código, así que requiere un ciclo de desarrollo. Cuanto antes se incorpore como parte del "listo para producción", mejor. Improvisarla durante un incidente es imposible.

El equipo ha desplegado redis-cache con un exportador y ha creado estos manifiestos. En la página de targets de Prometheus no aparece nada.

1. Identifica tres errores distintos.
2. Escribe los manifiestos corregidos.
3. Escribe el comando PromQL o curl que confirma que el problema está resuelto.

El sábado del puente, entre las 12:00 y las 13:30, los clientes se quejaron de que la web iba lentísima y algunas compras fallaban. Ya pasó, nadie tomó notas, y el director pide explicaciones el lunes.

Escribe las consultas PromQL que responden a cada pregunta. Indica de qué fuente (cAdvisor, kube-state-metrics, node-exporter, exportador o instrumentación propia) sale cada métrica.

1. ¿Cuántas peticiones por segundo atendía api-reservas en ese intervalo, comparado con el sábado anterior?
2. ¿Cuál fue el percentil 99 de latencia de /api/reservas durante el incidente?
3. ¿Estuvo api-reservas sufriendo throttling de CPU?
4. ¿Se quedó postgres-reservas sin conexiones disponibles?
5. ¿Falló la pasarela de pagos externa, o el fallo era nuestro?
6. ¿Cuántas reservas se dejaron de confirmar respecto a lo esperado?

worker-notificaciones consume de una cola de Redis y envía correos de confirmación. Actualmente no expone ninguna métrica. Diseña su instrumentación:

1. Enumera las métricas que debe exponer, con su nombre completo, su tipo (counter, gauge, histogram) y sus etiquetas, justificando la cardinalidad de cada etiqueta.
2. Escribe el ServiceMonitor correspondiente (el worker no tiene Service porque no recibe tráfico: resuelve ese problema).
3. Escribe las consultas PromQL de los cuatro indicadores dorados para este componente.

Solución 1

1. Los tres errores.

Error A — El selector del ServiceMonitor no casa con las etiquetas del Service. El ServiceMonitor busca Services con app: redis-cache y entorno: pro, pero el Service tiene app.kubernetes.io/name: redis-cache y app.kubernetes.io/part-of: rutas-norte. No coincide ninguna. El spec.selector del Service (que sí usa app/entorno) selecciona pods, no es lo que mira el ServiceMonitor.

Error B — El puerto del Service no tiene nombre, y el endpoint referencia metrics. El ServiceMonitor busca un puerto llamado metrics en el Service; el Service define el puerto 9121 sin campo name. El operador no encuentra el puerto y descarta el endpoint.

Error C — El ServiceMonitor está en monitorizacion sin namespaceSelector. Por defecto, un ServiceMonitor busca Services en su propio namespace. Estando en monitorizacion y el Service en rutas-norte-pro, no se encontrarán nunca. Dos soluciones válidas: mover el ServiceMonitor al namespace de la aplicación (preferible, mantiene la monitorización junto al código) o añadir namespaceSelector.

2. Manifiestos corregidos.

Y la NetworkPolicy, porque en rutas-norte-pro hay deny-all:

3. Verificación.

"1" es la confirmación. Si diera "0", el objetivo está configurado pero no responde: revisa la NetworkPolicy y que el exportador escuche en el 9121.

Comprobación adicional de que el operador lo ha recogido:

Solución 2

Nota general: todas las consultas usan el modificador offset o un rango temporal explícito, ya que el incidente pasó. Aquí está la ventaja decisiva sobre kubectl top de 07-02: estos datos existen.

1. Tráfico durante el incidente, comparado con el sábado anterior.

Fuente: instrumentación propia de api-reservas.

Un resultado de 5.8 significa que el sábado del puente hubo casi seis veces más tráfico que el sábado normal: coherente con lo que sabemos de los picos de puentes.

2. Percentil 99 de latencia de /api/reservas.

Fuente: instrumentación propia (histograma).

Se compara con el p95 y con la media (_sum / _count) para ver si el problema afectaba a todas las peticiones o solo a la cola:

Si la media está bien y el p99 disparado, el problema afecta a un subconjunto (por ejemplo, las peticiones que tocan la pasarela de pagos). Si ambos suben, es sistémico.

3. Throttling de CPU.

Fuente: cAdvisor / kubelet.

Un valor sostenido por encima de 0.30 durante el incidente confirma que el límite de CPU estaba frenando la aplicación. Complementaria, para ver si estaba pegada al techo:

(La segunda parte viene de kube-state-metrics: es el ejemplo perfecto de por qué hacen falta las dos fuentes.)

4. Conexiones de PostgreSQL.

Fuente: exportador sidecar de 06-04, más las métricas propias del pool.

Un numbackends / max_connections cercano a 1 confirma que la base de datos estaba saturada de conexiones.

5. ¿Falló la pasarela externa o fallamos nosotros?

Fuente: instrumentación propia.

Interpretación: si la tasa de fallo de la pasarela sube al 40 % mientras nuestro ratio_errores general también sube, el fallo es del proveedor y hay que reclamarle. Si la pasarela está al 0,1 % de fallos y nosotros devolvemos 5xx, el problema es nuestro. Esta distinción, imposible sin instrumentación, es lo que se lleva a la reunión del lunes.

6. Reservas dejadas de confirmar.

Fuente: instrumentación propia (métrica de negocio).

Y un cruce especialmente revelador: si el tráfico se multiplicó por 5,8 pero las reservas confirmadas solo por 1,3, la diferencia entre ambos factores es una estimación directa del negocio perdido. Ese número, en euros, es el que justifica el presupuesto de infraestructura.

Solución 3

1. Métricas del componente.

Cardinalidad total: unas 43 series por pod. Perfectamente asumible.

Etiquetas descartadas deliberadamente y por qué:

• destinatario (correo del cliente): cardinalidad ilimitada y, sobre todo, dato personal en el sistema de monitorización. Prohibido. Volveremos sobre esto en 07-05.
• id_reserva: cardinalidad ilimitada. Ese dato pertenece a los logs, no a las métricas. Las métricas agregan; los logs detallan.
• mensaje_error completo: cardinalidad impredecible. Se sustituye por motivo, un conjunto cerrado de categorías.

2. ServiceMonitor para un componente sin Service.

worker-notificaciones no recibe tráfico, así que no tiene Service. Dos opciones válidas:

Opción A (recomendada): PodMonitor. Es exactamente el recurso diseñado para este caso.

Con el puerto declarado en el Deployment:

Opción B: crear un Service headless solo para métricas y usar un ServiceMonitor normal. Funciona, pero crea un objeto que no aporta nada más. El PodMonitor es más limpio.

Y la NetworkPolicy correspondiente:

3. Los cuatro indicadores dorados.

Consulta adicional de cobertura, muy valiosa para el negocio: relaciona dos componentes distintos para detectar correos perdidos.

Este tipo de consulta —que cruza métricas de dos componentes para verificar una invariante del negocio— es de las más útiles que se pueden escribir, y en 07-04 la convertiremos en alerta.

Rutas Norte ha pasado de no recordar nada a tener memoria, lenguaje y capacidad de pregunta. En esta lección hemos:

• Entendido el modelo de extracción y por qué es superior al de empuje en un entorno dinámico como Kubernetes.
• Aprendido el modelo de datos: series identificadas por nombre y etiquetas, la amenaza permanente de la cardinalidad, y los cuatro tipos de métrica, con el histogram como el único que permite calcular percentiles agregados entre réplicas.
• Aclarado la confusión clásica sobre de dónde salen las métricas: cAdvisor mide el consumo real de los contenedores, node-exporter el sistema operativo del nodo, kube-state-metrics el estado de los objetos de la API, los exportadores traducen software de terceros —incluido el sidecar de postgres-reservas que añadimos en 06-04, ahora por fin conectado— y la instrumentación propia es lo único que sabe de negocio.
• Instrumentado api-reservas con peticiones por ruta y código, latencia en histograma, reservas confirmadas y el estado del pool de conexiones, cuidando la cardinalidad en cada decisión.
• Desplegado el kube-prometheus-stack y trabajado con el Prometheus Operator que anunciamos en 06-07, creando ServiceMonitor que viven junto a cada aplicación y sabiendo diagnosticar por qué un objetivo no aparece.
• Escrito PromQL de verdad: rate, increase, sum by, topk, histogram_quantile, y las consultas concretas de los cuatro indicadores dorados de cada componente. Entre ellas, la que confirma el throttling que en 07-02 solo podíamos sospechar.
• Dimensionado el almacenamiento y la retención, y entendido por qué Prometheus no es un archivo eterno y cuándo tocará mirar hacia Thanos o Mimir.

Pero seguimos teniendo un problema práctico: todo esto vive en una interfaz web austera donde hay que escribir consultas a mano, y nadie está mirándola a las tres de la madrugada. Tener el dato no sirve de nada si nadie lo ve ni nadie recibe el aviso.

En 07-04 daremos ese salto: construiremos con Grafana el cuadro de mando de Rutas Norte, panel a panel, con variables que sirvan para los tres entornos; escribiremos el catálogo de alertas de la plataforma con PrometheusRule —incluida la que predice cuándo se llenará el disco de postgres-reservas antes de que ocurra—; y configuraremos Alertmanager para que la alerta correcta llegue a la persona correcta, agrupada, sin ruido y con un enlace al procedimiento que hay que seguir.