Las «cuatro señales doradas» de Google SRE — latency, traffic, errors, saturation — son la baseline obligatoria en cualquier entrevista de arquitectura. En la práctica se recitan de memoria y se marca la casilla; un año más tarde el postmortem del incidente demuestra que ninguna de las cuatro atrapó en producción lo que debía atrapar.
Qué captura realmente cada señal
Latency. No la media — la media oculta el tail. Solo p95 / p99. Un request que tarda cinco segundos uno de cada diez es invisible en la media; el usuario al que le tocó se marcha. Separar latency de éxitos y latency de errores: un 500 en 50 ms y un 200 en 5 segundos son dos incendios distintos.
Traffic. No «cuántos RPS», sino a dónde van. Per-target imbalance en el load balancer por encima del 40 % significa degradación oculta: una nodo se convierte en agujero negro digital, el 99 % del tráfico se sirve, el 1 % queda colgado sin alerta. Slowness es peor que una caída — la retención cae en silencio.
Errors. Los 5xx explícitos son la mitad del cuadro. Los errores implícitos — timeouts, upstreams caídos, retries que «tuvieron éxito» al sexto intento — nunca llegan al contador estándar de 5xx. El error budget se construye sobre la success rate, no sobre los 5xx.
Saturation. La métrica más engañosa. Un servicio I/O-bound (esperando a la base de datos o a una API externa) con p99 latency de 8 segundos muestra CPU al 12 %. Los pods no están cargados — están esperando. El HPA autoscaling/v2 sobre CPU/memory es totalmente ciego a esto; para el autoscaler la foto parece «un sistema sin tráfico», así que escala hacia abajo. Saturation se mide con request rate, queue depth, SLO burn rate — es decir, con KEDA, no con el HPA nativo.
Cadena causa-efecto de un fallo: traffic↑ → saturation↑ → latency↑ → errors↑. Quien la sigue atrapa el problema antes del impacto en el usuario. Recitar las señales de memoria no.
Por qué el stack es VictoriaMetrics + Loki
Prometheus como implementación de referencia de las cuatro señales doradas sigue siendo el estándar. En producción en 2026 la elección habitual es VictoriaMetrics: 10× la densidad de almacenamiento, 10× más active series, MetricsQL como superconjunto de PromQL, long-term storage integrado sin Thanos/Cortex aparte. vmagent es más liviano que Prometheus como scraper, vmauth resuelve el multi-tenancy.
Logs — Loki. No porque «supere a OpenSearch», sino porque el full-text indexing es caro y rara vez necesario. Loki indexa solo labels y guarda el cuerpo del log barato. La correlación entre métrica y log va por un trace_id o request_id compartido, no por un full-text join. Promtail entró en modo mantenimiento: en clusters nuevos se instala Grafana Alloy — un único pipeline collector en River language que sustituye a Promtail + node-exporter + OTel Collector con un solo DaemonSet.
Explicar «tenemos monitoring» con nombres de herramientas es una señal débil. Una señal fuerte es el data flow:
Application → OTel SDK / OBI
→ Collection (vmagent / Alloy)
→ Storage (VictoriaMetrics / Loki)
→ Visualization (Grafana)
→ Alerting (Alertmanager)El esquema aguanta cambios de nodos: Loki por OpenSearch, VictoriaMetrics por Datadog — la estructura es la misma. Un arquitecto explica el flow y los trade-offs en cada nodo; un ingeniero recita nombres de herramientas.
Tres trampas detrás de «tenemos monitoring»
Se monitorea el producer, no el output. El ALB target group está verde cuatro días mientras sitemap.xml está stale, porque el servicio que lo genera perdió su alias. El health check del producer nunca lo detecta. Cada artefacto consumido externamente recibe un freshness probe propio — comprobación de edad por Last-Modified. Monitorear el output, no solo el producer.
Cardinality explosion en labels. user_id, session_id, request_id, pod_uid, path sin normalizar — muerte instantánea de la TSDB en cuestión de semanas. Esos labels se bloquean en code review de métricas con la misma disciplina que el código de producción. Los datos de alta cardinalidad viven en trace attributes (sampleados) y log fields, no en labels de métricas.
Local alerting sobre el mismo cluster. Si el cluster cae, caen también las alertas que iban a avisar de la caída. La observability del control plane vive en un cluster separado, en un managed service o en un receiver externo. Push, no pull. Si el cluster observado cae, el observador ve el silencio como señal, no como datos ausentes.
El mínimo que «tenemos monitoring» realmente significa
No 50 alertas, sino 5–8 accionables. Cada alerta lleva un runbook_url en las annotations. Cada alerta critical es un SLO burn rate con multi-window, no un threshold flap. Cada servicio entrega logs JSON estructurados con trace_id, service, team, env. Y una vez por trimestre, un disaster-visibility test: simulación de caída del cluster observado. Si las alertas no llegan y los dashboards quedan a oscuras, la observability va una o dos etapas por detrás de la realidad, y un incidente real lo demostrará más caro que un simulacro.