El Módulo 6 terminó con una pregunta incómoda: la plataforma es segura, pero ¿sabemos si funciona? En un monolito, "funciona" se comprobaba mirando un proceso y un log. En Kilómetro Cero hay seis servicios, tres bases de datos, un clúster de Kafka, Redis, MinIO, un gateway y un IdP, repartidos por decenas de contenedores: nadie puede mirar todo eso a la vez, y cuando algo va mal casi nunca lo dice a gritos. Un inventario que responde en 900 ms en lugar de 40 sigue "funcionando"; un consumidor de pedidos.eventos que se ha quedado atrás tres horas no lanza ninguna excepción; un certificado de Vault que caduca a las 03:00 de un domingo solo se nota cuando el primer pedido de la mañana falla. Esta lección trata de convertir la plataforma en algo observable a través de su primer pilar, las métricas: qué medir, cómo recogerlo con Prometheus, cómo expresar en números lo que Kilómetro Cero le promete a Ana, y cómo alertar antes de que ella se entere. Los logs y las trazas, los otros dos pilares, son la lección 07-02.

1. Observabilidad y sus tres pilares
2. Qué medir: infraestructura, plataforma, aplicación y negocio
3. Tipos de métrica y el problema de la cardinalidad
4. Prometheus: modelo pull, exporters y descubrimiento
5. PromQL esencial: tasas, percentiles y agregaciones
6. SLI, SLO, SLA y presupuesto de error
7. Alertas: síntomas, burn rate y Alertmanager
8. Dashboards en Grafana y monitoreo activo
9. Errores comunes y consejos
10. Ejercicios y soluciones
11. Conclusión

Monitorizar es comprobar cosas que ya sabemos que pueden fallar: el disco se llena, el proceso muere, la latencia sube. Observabilidad es una propiedad del sistema: la capacidad de responder a preguntas que no habíamos previsto ("¿por qué los pedidos de Lleida con queso-fresco tardan el doble desde ayer?") a partir de lo que el sistema emite hacia fuera. En un sistema distribuido la diferencia importa porque las preguntas imprevistas son la norma: los fallos interesantes son combinaciones de piezas, no piezas aisladas.

Las tres señales que un sistema emite, y que juntas dan observabilidad, son:

Las métricas son el punto de partida porque son las únicas de las tres que escalan con el número de series, no con el tráfico: contar 10 pedidos por minuto o 10 000 cuesta lo mismo. Son la señal que dispara alertas y la que pinta el panel de la Semana de la Vendimia. Los logs y las trazas entran después, cuando la métrica dice "algo va mal" y hay que averiguar qué.

Un error frecuente es empezar por la infraestructura (CPU, memoria) porque es lo que dan los agentes por defecto, y acabar con cien gráficas que no dicen si Ana puede comprar. Conviene pensar en cuatro capas, de abajo arriba, y elegir en cada una pocas métricas con sentido.

Lo que mide node_exporter en cada máquina o cAdvisor en cada contenedor: CPU, memoria, disco (espacio y latencia de E/S), red (bytes, errores, paquetes descartados). Para estos recursos vale el método USE de Brendan Gregg: para cada recurso, Utilización (porcentaje de tiempo ocupado), Saturación (trabajo encolado que no cabe: run queue, swap, cola de disco) y Errores.

Las piezas intermedias tienen métricas propias que anticipan problemas de la aplicación:

• Kafka: el lag de cada grupo de consumidores (mensajes producidos menos consumidos, por partición). Un lag creciente en analitica es tolerable; en reparto significa que el panel de furgoneta-3 muestra posiciones viejas. También particiones sin réplica sincronizada (se verá en 07-03).
• PostgreSQL: conexiones activas frente al máximo (max_connections), transacciones por segundo, retraso de la réplica pedidos-db-replica respecto al primario, tamaño de tablas y bloqueos en espera.
• Redis: hit ratio de la caché de catálogo (aciertos / (aciertos + fallos)), memoria usada frente al límite, claves expulsadas, latencia de comandos.
• Cassandra: latencia de lectura y escritura por tabla, compactaciones pendientes, nodos caídos vistos por gossip.

Google popularizó en Site Reliability Engineering las cuatro señales doradas, las que hay que mirar en cualquier servicio que atiende peticiones:

1. Latencia: cuánto tarda en responder, distinguiendo peticiones correctas de fallidas (un error rápido no es "buena latencia").
2. Tráfico: cuánta demanda recibe (peticiones por segundo, mensajes consumidos por segundo).
3. Errores: qué fracción de peticiones falla, explícita (5xx, UNAVAILABLE de gRPC) o implícitamente (respondió 200 pero tardó más del acuerdo).
4. Saturación: cómo de "lleno" está el servicio: hilos ocupados, conexiones del pool en uso, cola de trabajo.

El método RED (Tom Wilkie) es la versión para servicios: Rate, Errors, Duration. Coincide con las tres primeras señales doradas y es lo que instrumentamos de forma uniforme en todos los servicios de km0/.

Tabla de señales doradas por servicio:

Las métricas de negocio son las que explican a Jordi Sala y Marta Puig si la plataforma cumple su propósito, y a menudo detectan fallos que las técnicas no ven: si pedidos responde 200 en 80 ms pero los pedidos por minuto caen a cero un sábado a las 11:00, algo se ha roto antes (el front, Kong, Keycloak). Para Kilómetro Cero: pedidos creados por minuto (por mercado y por productor), tasa de pago rechazado, valor medio del pedido, reservas de stock fallidas por producto, entregas a tiempo. Se instrumentan igual que las técnicas, en el mismo Prometheus.

Prometheus (y OpenTelemetry Metrics, que usa el mismo modelo conceptual) distingue cuatro tipos:

Dos aclaraciones que evitan muchos errores:

• Un counter nunca se lee en crudo. km0_pedidos_total vale 1 284 522 y no dice nada; lo que interesa es su derivada: rate(km0_pedidos_total[5m]) = pedidos por segundo en los últimos 5 minutos. Prometheus gestiona los reinicios (cuando el contador baja, asume reinicio y no produce una tasa negativa).
• Histogram frente a summary: el histogram guarda cuántas observaciones cayeron por debajo de cada límite (le="0.1", le="0.25", le="0.5", ...). Los percentiles se calculan en el servidor y, sobre todo, se pueden agregar entre instancias: el p99 de pedidos con 3 réplicas se obtiene sumando buckets. Un summary calcula el p99 en cada proceso y no hay forma correcta de combinar tres p99 (la media de percentiles no es un percentil). En un sistema distribuido, salvo casos muy concretos, se usa histogram.

Cada combinación distinta de nombre + etiquetas es una serie temporal que Prometheus guarda en memoria y en disco. km0_peticion_duracion_segundos{servicio, metodo, codigo} con 6 servicios × 10 métodos × 5 códigos × 12 buckets = 3 600 series: bien. Si a alguien se le ocurre añadir pedido_id como etiqueta, cada pedido crea una serie nueva por bucket: un millón de pedidos son doce millones de series, y Prometheus muere. La regla: una etiqueta solo puede tomar un conjunto pequeño y acotado de valores (servicio, método, código de estado, mercado, estado del pedido). Nunca identificadores de entidad (pedido_id, usuario, request_id), ni direcciones IP de clientes, ni rutas con parámetros sin normalizar (/pedidos/P-2026-000123 debe registrarse como /pedidos/{id}). Lo que necesite el identificador va a los logs o a las trazas (07-02).

Un caso límite interesante es km0_stock_unidades{producto}: con unos cientos de productos es aceptable; con cien mil no. En Kilómetro Cero se limita a los productos de las campañas activas y, para el resto, se publica un gauge agregado por productor.

Prometheus funciona en modo pull: no espera a que los servicios le envíen datos, sino que cada 15 segundos (configurable) hace GET /metrics a cada objetivo y guarda lo que encuentra. El formato es texto plano:

El pull tiene consecuencias importantes en un sistema distribuido:

• Prometheus sabe cuándo un objetivo no responde: la métrica up{job="pedidos", instance="pedidos-2:8000"} vale 0. Con un modelo push, un servicio muerto simplemente deja de enviar y hay que inferir la ausencia.
• Los servicios no necesitan conocer la dirección de Prometheus ni gestionar colas de envío.
• Necesita descubrir los objetivos: en docker-compose basta con listarlos; en Kubernetes (07-05) los descubre preguntando a la API; en la nube, a la API del proveedor. Para trabajos efímeros (un Job que dura 3 segundos) existe el Pushgateway, que es la excepción, no la norma.

Los componentes que no exponen /metrics por sí mismos se cubren con exporters: procesos pequeños que traducen el estado de PostgreSQL, Kafka, Redis, etc. al formato de Prometheus. En Kilómetro Cero:

Todos los servicios comparten un módulo con las métricas comunes, para que el nombre y las etiquetas sean idénticos y los paneles valgan para cualquiera de ellos.

Puntos que conviene entender:

• Counter, Gauge e Histogram son registros globales del proceso: se declaran una vez, a nivel de módulo, y cualquier parte del servicio los usa. prometheus_client los expone todos juntos en /metrics.
• .labels(...) selecciona la serie concreta; la primera vez que se usa una combinación, se crea. Por eso hay que controlar qué valores se pasan (cardinalidad).
• medir registra el código también cuando hay excepción: sin ese except, las peticiones que fallan con error interno no aparecerían en el histograma, y la latencia parecería mejor de lo que es.
• PETICIONES_EN_VUELO es la señal de saturación más barata de obtener: cuántas peticiones hay a la vez. Si en pedidos supera el número de hilos del servidor, las siguientes esperan en cola.

inventario ya tiene AuthInterceptor y ServicioInterceptor (06-04). Se añade uno más, que envuelve cada llamada y traduce el código de estado gRPC a etiqueta:

Y en el arranque del servidor, el orden de los interceptores importa: métricas primero, para medir también las llamadas rechazadas por autenticación.

pedidos es una aplicación FastAPI; un middleware mide cada petición y /metrics se monta en la misma app:

El uso de la plantilla de la ruta (/pedidos/{id}) en lugar de la URL real es la aplicación práctica de la regla de cardinalidad.

En docker-compose.yml la pila de observabilidad se añade junto a los servicios:

El usuario exporter de PostgreSQL es de solo lectura sobre las vistas pg_stat_*; en un despliegue real se obtendría de Vault (06-04).

PromQL es el lenguaje de consulta. Cuatro construcciones cubren el 90 % de los usos:

rate(counter[ventana]): tasa por segundo en la ventana. Peticiones por segundo a pedidos, sumando las tres réplicas y desglosando por método:

Se usa el sufijo _count del histograma (número de observaciones) como contador de peticiones: cada petición medida es una observación.

Tasa de error: fracción de peticiones con código 5xx:

histogram_quantile(q, buckets): percentil a partir de los buckets. El p99 de pedidos, agregando todas las instancias:

El sum by (le) es obligatorio: hay que sumar los buckets de todas las instancias conservando la etiqueta le (límite del bucket), que es la que histogram_quantile necesita para interpolar.

increase(counter[ventana]): cuánto ha subido en la ventana (útil para "pedidos en la última hora"):

Otras que aparecen a diario: avg_over_time(gauge[10m]) para suavizar un gauge, absent(up{job="pedidos"}) para detectar que no hay ningún objetivo, topk(5, ...) para los cinco productos con menos stock, y operadores entre vectores (/, and, unless) que emparejan series por etiquetas.

Con 1 000 peticiones de 50 ms y 10 de 5 s, la media es 99 ms: "todo bien". El p99 es 5 s: uno de cada cien clientes espera cinco segundos. En un sistema distribuido, donde una página del catálogo hace varias llamadas internas, la latencia de cola se amplifica: si cada llamada tiene un 1 % de probabilidad de ser lenta y una petición hace 10, un 10 % de las peticiones ven al menos una llamada lenta. Por eso los objetivos se fijan sobre percentiles (p50 para "lo normal", p99 para "lo que sufre alguien cada minuto") y nunca sobre medias.

En 01-03 se calcularon los "nueves": un servicio con 99,9 % de disponibilidad puede estar caído 43 minutos al mes. Aquella cuenta hablaba de "estar caído"; ahora hay instrumentos para definirlo con precisión.

• SLI (Service Level Indicator): una medida concreta del servicio, expresada como fracción de eventos buenos sobre el total. "Fracción de peticiones a POST /pedidos que responden sin 5xx en menos de 500 ms."
• SLO (Service Level Objective): el objetivo interno para ese SLI en una ventana. "El 99,9 % de las peticiones, medido en ventanas de 30 días."
• SLA (Service Level Agreement): el compromiso contractual con consecuencias (penalizaciones). Siempre más laxo que el SLO: Kilómetro Cero promete a los productores un 99,5 % y se exige un 99,9 %.

Los SLO del servicio pedidos:

Nótese cómo el histograma permite expresar el SLO de latencia como una fracción: "cuántas observaciones cayeron en el bucket le="0.5"" dividido por el total es exactamente "fracción de peticiones por debajo de 500 ms". Esto solo funciona si 0,5 es un límite de bucket, razón por la que BUCKETS_LATENCIA incluye 0.5 y no, por ejemplo, 0.4 y 0.6.

Un SLO del 99,9 % significa que se permite un 0,1 % de peticiones malas: ese es el presupuesto de error. Con 2 millones de peticiones al mes, son 2 000 errores. El presupuesto convierte la fiabilidad en una moneda que se puede gastar:

• Si queda presupuesto, el equipo despliega rápido, prueba cosas, hace experimentos de caos (07-06).
• Si el presupuesto se agota (un incidente de 40 minutos se lo lleva casi entero), se congelan los despliegues no urgentes y se invierte en fiabilidad.

Es también lo que da sentido a las alertas: no importa un pico de errores en sí, importa a qué velocidad se consume el presupuesto.

Una alerta debe despertar a alguien solo cuando un usuario está sufriendo o va a sufrir, y ese alguien debe poder hacer algo. "CPU al 85 % en inventario-2" no cumple ni lo uno ni lo otro: puede ser normal en la Semana de la Vendimia, y no dice qué hacer. "El 2 % de los pedidos falla desde hace 5 minutos" sí. Las causas (CPU, memoria, lag) van a los dashboards, para diagnosticar cuando la alerta de síntoma salta, o se convierten en alertas de baja prioridad (ticket, no llamada).

Las excepciones razonables son las alertas predictivas sobre causas con plazo cierto: un certificado que caduca en 12 h o un disco que se llenará en 4 h al ritmo actual (predict_linear) son avisos que evitan el síntoma.

El burn rate es la velocidad a la que se consume el presupuesto de error, relativa a la velocidad "justa". Burn rate 1 significa que, al ritmo actual, el presupuesto de 30 días se agota exactamente en 30 días. Burn rate 14,4 significa que se agota en 2 días. La técnica recomendada por el libro SRE Workbook es alertar con dos ventanas a la vez, larga y corta:

La ventana larga evita que un pico de 30 segundos despierte a nadie; la ventana corta hace que la alerta se resuelva en cuanto el problema para (sin ella, la alerta de 1 h seguiría activa una hora después de arreglarlo).

Sobre estas reglas:

• Las reglas de grabación (record:) calculan una vez la expresión cara y la guardan como métrica nueva; las alertas y los dashboards la reutilizan. Con ventanas de 6 h sobre histogramas, hacerlo así ahorra mucho a Prometheus.
• for: exige que la condición se mantenga ese tiempo antes de disparar. Es el primer filtro contra alertas por parpadeos.
• Los certificados de 24 h de Vault (06-04) hacen que la alerta a 12 h sea el umbral natural: si a mitad de vida no se ha renovado, la renovación automática está rota.
• km0_vault_lease_segundos_restantes y km0_auditoria_verificaciones_fallidas_total son métricas que los propios servicios publican: la instrumentación de negocio y de seguridad usa el mismo mecanismo que la de latencia.

Prometheus evalúa y dispara; Alertmanager decide a quién avisar, cómo agrupar y cuándo callar:

Silencios: cuando Jordi va a reiniciar inventario-2 para una migración, crea un silencio de 30 minutos con un matcher (instance="inventario-2:9464") desde la interfaz o con amtool silence add instance=inventario-2:9464 --duration=30m --comment="migración". Sin silencios, la alternativa es ignorar alertas, que es el principio de la fatiga de alertas: cuando la mitad de las notificaciones son ruido, nadie lee la que importa. Reglas prácticas: cada alerta de página debe tener un runbook (07-03) y una acción posible; una alerta que salta y "se arregla sola" tres veces seguidas se degrada a ticket o se elimina; el número de páginas por semana se revisa como una métrica más.

Un dashboard no es una colección de todo lo que se puede graficar; es una narración de arriba abajo: primero si el negocio va bien, luego si los servicios cumplen, luego por qué. Para la campaña de Bodega Roble Alto:

Grafana se provisiona desde ficheros para que el dashboard viva en el repositorio, no en clics:

Y un dashboard JSON reducido a dos paneles, para ver la estructura:

Todo lo anterior es pasivo: mide el tráfico que hay. Si a las 04:00 no hay tráfico, la tasa de error es 0/0 y no dice nada; si Kong tiene mal una ruta que nadie ha usado todavía, tampoco. El monitoreo activo (sondas sintéticas) genera tráfico artificial para comprobar el camino completo: el blackbox_exporter pide GET /api/v1/catalogo/mercados a través de Kong cada 15 s y publica probe_success, probe_duration_seconds y probe_ssl_earliest_cert_expiry. Una sonda más ambiciosa (un pequeño script que crea y cancela un pedido de prueba con el usuario [email protected], marcado para no contar en analítica) verifica la saga entera. Estas sondas son las que detectan el certificado caducado del domingo antes que Ana.

Todo lo visto usa prometheus_client directamente. OpenTelemetry es el estándar abierto que unifica métricas, logs y trazas en un SDK y un protocolo (OTLP): con él, km0_peticion_duracion_segundos sería un Histogram del MeterProvider de OTel, exportado a un Collector que lo entrega a Prometheus (o a cualquier otro backend). La semántica (tipos, etiquetas, cardinalidad, PromQL) es la misma. En Kilómetro Cero se mantiene prometheus_client para métricas porque es más simple, y se adopta OpenTelemetry para las trazas y la correlación con logs en 07-02, que es donde su valor es mayor.

• Medir solo infraestructura. CPU y memoria no dicen si Ana puede comprar. Empieza por RED en cada servicio y por dos métricas de negocio; añade USE de recursos como apoyo al diagnóstico.
• Etiquetas de alta cardinalidad. pedido_id, usuario, IPs o rutas sin normalizar multiplican las series hasta tumbar Prometheus. Si lo necesitas para investigar, va a logs o trazas.
• Summaries en servicios replicados. Los cuantiles calculados en el cliente no se pueden agregar entre instancias. Usa histogramas con buckets que incluyan los umbrales de tus SLO.
• Alertar sobre medias o sobre causas. La media oculta la cola; la CPU al 80 % no es un problema en sí. Alerta sobre SLI de usuario y burn rate; el resto, a dashboards o tickets.
• Alertas sin for: ni runbook. Cada parpadeo despierta a alguien y nadie sabe qué hacer. Toda alerta de página tiene un for, un dueño y un runbook enlazado en la anotación.
• Olvidar las excepciones en el middleware. Si la métrica solo se registra cuando la petición termina bien, la latencia y los errores de las que fallan desaparecen. Registra en finally.
• Confiar solo en el monitoreo pasivo. Sin tráfico no hay señal. Una sonda sintética por camino crítico (catálogo, crear pedido, login) cubre las horas valle y los cambios de configuración no probados.
• Dashboards hechos a mano en Grafana. Se pierden, se duplican, nadie sabe cuál es el bueno. Provisiónalos desde el repositorio, junto al código que instrumentan.

Ejercicio 1. Durante la Semana del Queso Artesano, Quesería Montblanc pregunta cuántos pedidos con queso-curado se han confirmado en la última hora, y Marta quiere saber si inventario está respondiendo peor que ayer. (a) ¿Puede responderse la primera pregunta con km0_pedidos_total{estado="confirmado"} tal como está definida? Si no, ¿qué cambiarías y qué riesgo de cardinalidad tendría? (b) Escribe la consulta PromQL que da el p95 de ReservarStock en los últimos 5 minutos agregando las dos instancias de inventario, y explica por qué no vale avg(histogram_quantile(...)) por instancia. (c) ¿Qué gauge te diría si el problema está en las réplicas inv-bcn/inv-vlc en lugar de en el servicio?

Ejercicio 2. El SLO de pedidos es 99,9 % de éxito en 30 días y el servicio recibe de media 3 millones de peticiones al mes. (a) ¿Cuántos errores caben en el presupuesto? (b) A las 10:00 del sábado empieza un incidente en el que el 8 % de las peticiones falla. Con un tráfico de 100 peticiones/s, ¿en cuánto tiempo se agota el presupuesto entero? (c) ¿Cuál de las dos alertas de burn rate (14,4 en 1 h/5 min; 6 en 6 h/30 min) saltará primero, y aproximadamente cuándo, teniendo en cuenta los for:? (d) A las 10:20 el incidente se resuelve; ¿por qué se resuelve la alerta poco después aunque la ventana de 1 h siga contaminada?

Ejercicio 3. Un lunes Jordi encuentra 47 notificaciones del fin de semana en #km0-operaciones: 30 de PostgresConexionesAltas en la réplica de pedidos (que sube al 90 % cada noche durante el DAG km0_ventas_diarias y baja sola), 12 de ObjetivoCaido para reparto durante un despliegue programado de 10 minutos, y 5 de KafkaLagAnalitica. Ninguna correspondía a un problema real. Propón, para cada grupo, el cambio concreto (en alertas.yml, en alertmanager.yml o en el procedimiento) que evita el ruido sin perder la detección de un problema real, y explica qué señal de síntoma cubriría el caso en que sí lo fuera.

Ejercicio 1.

(a) No: km0_pedidos_total solo tiene la etiqueta estado, no sabe qué productos llevaba cada pedido. Dos opciones: un counter aparte km0_lineas_pedido_total{producto} incrementado por cada línea confirmada (cardinalidad = número de productos, aceptable si se limita a los productos en campaña o si el catálogo es de unos cientos; con decenas de miles de productos habría que agregar por productor o responder esa pregunta desde analitica, no desde Prometheus), o añadir producto a km0_pedidos_total, que es peor porque un pedido con tres productos se contaría tres veces y rompería la métrica de pedidos. Nunca pedido_id. (b) histogram_quantile(0.95, sum by (le) (rate(km0_peticion_duracion_segundos_bucket{servicio="inventario", metodo="ReservarStock"}[5m]))). Sumar primero los buckets de las dos instancias por le reconstruye la distribución conjunta y el percentil se calcula sobre ella; promediar dos p95 calculados por separado no da el p95 del conjunto (si una instancia atiende el 90 % del tráfico con p95 = 40 ms y la otra el 10 % con p95 = 800 ms, la media, 420 ms, no describe a nadie). (c) El retraso de replicación que publica postgres_exporter (pg_replication_lag_seconds o el equivalente sobre pg_stat_replication) para inv-bcn e inv-vlc; si ese gauge sube, las lecturas en réplica devuelven stock viejo y inventario puede estar reintentando o esperando; si está a cero, el problema está en el servicio o en el primario.

Ejercicio 2.

(a) 0,1 % de 3 000 000 = 3 000 errores al mes. (b) 100 peticiones/s × 8 % = 8 errores/s; 3 000 / 8 = 375 s ≈ 6 minutos y cuarto. Todo el presupuesto del mes se va en poco más de seis minutos. (c) Burn rate = 0,08 / 0,001 = 80, muy por encima de ambos umbrales. La ventana de 5 min supera el 1,44 % casi de inmediato; la de 1 h necesita acumular: con la hora previa limpia, la tasa de error en 1 h alcanza 1,44 % cuando llevan unos 11 minutos de incidente (0,08 × t / 60 min = 0,0144 → t ≈ 10,8 min); con for: 2m, PedidosBurnRateRapido avisa hacia las 10:13. La de 6 h necesitaría 0,006 × 360 / 0,08 = 27 minutos más for: 15m, así que no llega a saltar si el incidente dura 20 minutos. (d) Porque la regla exige las dos ventanas a la vez (and): al resolverse, la ventana de 5 min baja por debajo del umbral en unos minutos, y aunque la de 1 h siga por encima hasta las 11:20, la conjunción deja de cumplirse y Alertmanager marca la alerta como resuelta. Esa es precisamente la razón de la ventana corta.

Ejercicio 3.

PostgresConexionesAltas en la réplica durante el DAG: es una causa, no un síntoma, y es un comportamiento esperado; opciones: subir el umbral solo para la réplica con un unless/matcher por instance, añadir for: 30m (el DAG dura menos), o mejor, degradarla a severidad: ticket (ya lo es) y enrutar los tickets a un resumen diario en lugar de a Slack en tiempo real (group_interval/repeat_interval largos en la ruta por defecto); el síntoma real que sí debe avisar es la latencia p99 de pedidos o el retraso de replicación, que están cubiertos por PedidosLatenciaP99. ObjetivoCaido en despliegues: el procedimiento de despliegue debe crear un silencio (amtool silence add job=reparto --duration=15m --comment="despliegue") como paso del pipeline; además, con varias réplicas la alerta debería ser "todas las instancias del job caídas" (absent(up{job="reparto"} == 1) o count(up{job="reparto"} == 1) == 0), no una instancia; el síntoma que cubre un despliegue realmente roto es el lag de reparto.posiciones (KafkaLagReparto) y la sonda sintética del panel. KafkaLagAnalitica: 200 000 con for: 30m es demasiado sensible para un consumidor batch que se pone al día cada noche; subir el umbral, alargar for a varias horas, o cambiarla a una alerta sobre el síntoma de analítica: "el DAG km0_ventas_diarias no ha terminado a las 07:00" (métrica de Airflow) o "la última ejecución falló". En todos los casos, el principio es el mismo: la alerta de página protege una experiencia de usuario concreta; lo demás es información para el diagnóstico.

Un sistema distribuido no avisa cuando falla; hay que construir los instrumentos. La observabilidad se apoya en tres señales y esta lección ha desarrollado la primera: las métricas, la única que escala con el número de series y no con el tráfico. Hemos visto qué medir en cuatro capas (infraestructura con USE, plataforma, aplicación con RED y las señales doradas, negocio), los cuatro tipos de métrica y por qué el histograma es el tipo adecuado para latencias en servicios replicados, la regla de cardinalidad que prohíbe pedido_id como etiqueta, el modelo pull de Prometheus con sus exporters y sondas, y el PromQL imprescindible (rate, histogram_quantile con sum by (le), increase). Sobre esa base, los "nueves" de 01-03 se han convertido en SLI y SLO concretos para pedidos (99,9 % de éxito, p99 < 500 ms), con un presupuesto de error que se gasta y alertas de burn rate multiventana que avisan por síntomas, enrutadas por Alertmanager a quien puede actuar, y un dashboard provisionado que cuenta la Semana de la Vendimia de arriba abajo.

Ahora, cuando PedidosBurnRateRapido salte un sábado a las 10:13, Jordi sabrá que el 8 % de los pedidos falla. Lo que las métricas no le dirán es cuáles, ni por qué: si es inventario que rechaza reservas de vino-crianza, la pasarela de pagos, o un traceparent que se perdió en una cabecera Kafka. Para eso hacen falta los otros dos pilares: los logs estructurados y centralizados, que cuentan qué pasó con el pedido P-2026-000125, y las trazas distribuidas, que muestran en qué servicio se fueron los 480 ms. Esa es la siguiente lección.