Imagina que recibes una alerta a las 3 de la mañana. El panel de monitoring muestra cientos de métricas en rojo, amarillo y naranja parpadeando. Después de veinte minutos buscando la causa real, resulta que el problema era simple: un servicio de pagos empezó a responder lento hace una hora. Todo lo demás eran consecuencias en cascada.
Eso es exactamente el problema que los Golden Signals intentan resolver desde 2014, cuando el equipo de SRE de Google los documentó en su libro Site Reliability Engineering: How Google Runs Production Systems. No son una moda. Son la respuesta práctica a una pregunta muy concreta: si solo pudieras medir cuatro cosas de tu sistema, ¿cuáles serían?
La respuesta de Google fue sencilla y directa: latencia, tráfico, errores y saturación. Pero aquí empieza el matiz que este artículo quiere explorar — aplicarlos bien no es tan obvio como parece.
Qué son exactamente y de dónde vienen
Los cuatro Golden Signals son latencia, tráfico, errores y saturación. Si solo puedes medir cuatro métricas de tu sistema de cara al usuario, enfócate en estas cuatro, según el libro SRE de Google.
Cada uno cubre un ángulo distinto de la salud del sistema.
Latencia — el tiempo que tarda el sistema en responder. Aquí hay un matiz importante que el libro original recalca: hay que distinguir entre la latencia de las peticiones exitosas y la de las fallidas. Un error HTTP 500 puede servirse muy rápido, pero factorizar esos 500 en la latencia global puede llevar a cálculos engañosos. Y un error lento es peor que uno rápido.
Tráfico — cuánta demanda soporta el sistema en este momento. En un servicio web, suele medirse en peticiones por segundo.
Errores — la tasa de peticiones fallidas. Más allá de los HTTP 500, hay que definir bien qué es un error para tu caso concreto: fallos implícitos (una respuesta 200 con contenido incorrecto), fallos de política (respuestas que superan tu SLA aunque técnicamente sean correctas).
Saturación — qué tan «lleno» está el sistema. La latencia es frecuentemente un indicador adelantado de saturación: medir el percentil 99 de tiempo de respuesta en una ventana pequeña (por ejemplo, un minuto) puede dar una señal temprana de que el sistema está llegando a su límite.
El contexto técnico y estratégico: por qué no basta con activarlos
Los Golden Signals son importantes porque proporcionan una visión completa de la salud del sistema. Monitorizando estas cuatro métricas, los equipos pueden detectar problemas potenciales temprano y abordarlos antes de que causen interrupciones o degradaciones de rendimiento.
Pero en arquitecturas modernas — microservicios, Kubernetes, pipelines de telemetría complejos — aplicarlos sin criterio puede generar el problema contrario: explosión de cardinalidad, alertas sin contexto y ruido que paraliza a los equipos. El libro SRE original ya avisaba de esto: enviar una alerta a una persona es costoso en términos de tiempo e interrupciones. Cuando las alertas son demasiado frecuentes, los equipos las cuestionan, las ignoran o las desactivan — a veces también una alerta real que queda enmascarada por el ruido.
Los Golden Signals deben entenderse como un patrón de diseño en la monitorización, no como un checklist rígido. Su objetivo es ofrecer un punto de partida para la observabilidad, no el destino final.
Cómo los implementan las herramientas modernas: Dynatrace y Datadog
Aquí es donde la teoría se vuelve práctica. Las dos plataformas líderes en observabilidad tienen enfoques distintos pero complementarios.
Dynatrace: automatización y contexto causal
Dynatrace tiene una ventaja singular: no necesitas configurar manualmente los Golden Signals para la mayoría de servicios. Davis AI detecta automáticamente anomalías de rendimiento en aplicaciones, servicios e infraestructura. La recopilación de datos con contexto y el establecimiento de baselines son los dos pilares fundamentales sobre los que se construye la detección de anomalías.
Esto significa que la latencia, el tráfico, los errores y la saturación se monitorizan desde el primer momento que el OneAgent instrumenta un proceso — sin que tengas que definir umbrales manualmente.
Pero donde Dynatrace destaca de verdad es en lo que hace cuando detecta un problema. Davis AI es un motor de razonamiento que recorre el mapa de topología (Smartscape) para establecer causalidad, determinando la causa raíz basándose en interdependencias y cronología de eventos de forma determinista. Esto evita uno de los antipatrones más comunes: recibir alertas de Golden Signals sin saber qué causó qué.
Un ejemplo práctico: si el percentil 99 de latencia de un servicio de firma electrónica sube de golpe, Davis no solo te alerta — te muestra si el problema viene de un proceso Java específico, de un nodo de base de datos, o de una dependencia externa. Sin esa correlación topológica, la alerta de latencia solo te dice que algo va mal, no dónde.
Davis AI ofrece además un baseline adaptativo automático que ajusta los umbrales de referencia en base a un análisis deslizante de siete días, adaptándose continuamente a los cambios de comportamiento de las métricas. También soporta baseline estacional, ideal para métricas con patrones predecibles como el tráfico de un e-commerce que varía por día de la semana.
Datadog: flexibilidad y SLOs explícitos
Datadog toma un enfoque diferente: te da las herramientas para construir tus Golden Signals de forma explícita y vincularlos a SLOs de manera muy granular.
El Universal Service Monitoring (USM) de Datadog detecta automáticamente todos tus servicios — incluidos servicios de terceros y librerías — y monitoriza sus Golden Signals sin tocar una sola línea de código, analizando el tráfico HTTP desde el kernel de red mediante eBPF.
Para SLOs, Datadog permite definir tres tipos: basados en métricas (count-based, ideal cuando el SLI es la razón de peticiones buenas sobre totales), basados en monitores (time-based, calcula el uptime del servicio), y Time Slice SLOs (definen uptime sin necesitar un monitor subyacente, con posibilidad de explorar downtime durante la creación).
Un ejemplo concreto: para un servicio de autenticación, puedes crear un SLO de latencia definiendo que el 99,5% de las peticiones deben completarse en menos de 200 ms en una ventana de 30 días. Datadog calcula automáticamente el error budget restante y te avisa cuando la tasa de consumo del budget (burn rate) es demasiado alta — incluso antes de que el SLO se rompa.
En Datadog, la práctica recomendada es crear monitores para los Golden Signals de un servicio concreto, usarlos como SLIs, y luego vincularlos a un SLO etiquetando tanto el SLO como los monitores con el mismo tag (por ejemplo, slo:miservicio) para correlacionarlos fácilmente.
Las decisiones clave y sus trade-offs
La principal decisión estratégica es el alcance: ¿Golden Signals por servicio individual, a nivel de plataforma completa, o solo para servicios críticos?
Cada opción tiene su precio. Por servicio, identificas problemas locales rápido, pero el volumen de alertas puede ser alto y la correlación global difícil. Agregados a nivel plataforma, la vista operativa es más simple, pero puedes ocultar problemas específicos. Solo en servicios críticos, optimizas el foco, pero requiere un inventario actualizado y criterios claros de criticidad.
Otro trade-off importante es la cardinalidad. Añadir etiquetas para contexto (zona, versión, cliente) mejora el diagnóstico, pero eleva la complejidad y el coste de almacenamiento. La experiencia muestra que un exceso de etiquetas en Golden Signals reduce su efectividad operativa — más dimensiones no equivale a mejor observabilidad.
Antipatrones comunes: los errores que se repiten
Confundir Golden Signals con métricas exhaustivas. Los Golden Signals son un filtro, no un inventario. Intentar cubrir todo con ellos diluye su propósito.
Alertas estáticas sin ajuste dinámico. Un umbral fijo de latencia que no tiene en cuenta la estacionalidad o el comportamiento histórico genera fatiga. Tanto Dynatrace como Datadog ofrecen baselines dinámicos precisamente para evitar esto.
No contextualizar las señales con dependencias. Sin un mapa de relaciones entre servicios, las alertas de Golden Signals son ambiguas. En Dynatrace, Smartscape hace esto automáticamente. En Datadog, el Service Catalog junto con APM distribuido cumple un rol similar.
Falta de alineación con objetivos de negocio. Golden Signals sin vinculación a SLOs o KPIs relevantes se convierten en ejercicio técnico. Si la latencia del servicio de firma sube pero no hay un SLO que diga cuánto es demasiado, el dato no tiene acción asociada.
Cuándo no aplicarlos de forma rígida
Hay escenarios donde imponer un esquema rígido de Golden Signals es contraproducente.
Plataformas con servicios muy diferenciados en comportamiento y requisitos, donde un conjunto único de señales no refleja adecuadamente la salud de todos ellos. Organizaciones con madurez avanzada en observabilidad que prefieren enfoques basados en SLOs, trazas y logs enriquecidos, relegando las métricas a un rol complementario. Casos donde la instrumentación nativa no soporta la extracción de Golden Signals sin incurrir en sobrecarga técnica significativa.
En esos casos, es preferible diseñar un modelo de observabilidad adaptativo que utilice los Golden Signals como referencia flexible y no como dogma.
Recomendaciones prácticas
Define el scope con criterio. Empieza por los servicios o dominios críticos, no por todo. La cobertura completa puede ser un objetivo a largo plazo, pero intentar llegar ahí desde el día uno es la receta para el ruido y la fatiga.
Activa baseline dinámico desde el principio. Tanto en Dynatrace como en Datadog, los umbrales estáticos son el origen de la mayoría de los falsos positivos. Deja que la herramienta aprenda el comportamiento normal antes de ajustar umbrales manualmente.
Combina métricas con trazas y logs. Los Golden Signals te dicen qué está pasando. Las trazas distribuidas te dicen dónde y los logs te dicen por qué. Las tres capas son necesarias para reducir el tiempo medio de resolución.
Vincula las señales a SLOs y objetivos de negocio. Una alerta de latencia que no está conectada a un SLO es una métrica técnica sin acción asociada. La pregunta que debe poder responderse siempre es: ¿este valor roto impacta al usuario o al negocio?
Mide la calidad de tus alertas. Si recibes muchas alertas que no se traducen en incidentes reales, o si los equipos empiezan a ignorarlas, la implementación de Golden Signals está fallando — independientemente de cuántas señales tengas configuradas.
Conclusión
Los Golden Signals son un patrón poderoso precisamente porque son simples. Cuatro métricas que reflejan la experiencia del usuario mejor que cien dashboards llenos de indicadores técnicos. Pero su efectividad depende de aplicarlos con criterio: scope claro, baseline dinámico, correlación con topología y dependencias, y vinculación a objetivos de negocio reales.
No se trata de implementar un checklist. Se trata de construir un sistema que facilite detectar, diagnosticar y resolver incidentes rápido — sin que el equipo que lo opera acabe quemado por el ruido.
La pregunta que vale la pena hacerse antes de añadir cualquier nueva señal o alerta no es «¿podemos medirlo?» sino «¿qué haremos cuando esta señal se active?». Si no tienes respuesta clara, probablemente no necesitas esa señal.
