Hablar de observabilidad ya no es algo exclusivo de perfiles técnicos muy especializados. Hoy forma parte del día a día de equipos DevOps, SRE y desarrollo que necesitan entender cómo se comportan sus sistemas en producción. En ese contexto aparecen dos conceptos que suelen mencionarse juntos: Golden Signals y RED metrics. Pero ¿son lo mismo? ¿Cuándo conviene usar cada enfoque?
En este artículo vamos a ver qué son las Golden Signals, qué son las RED metrics y, sobre todo, en qué situaciones tiene sentido priorizar unas u otras.
Lo que vas a ver en este post:
Qué son las Golden Signals
Las Golden Signals nacen del enfoque de SRE (Site Reliability Engineering) popularizado por Google. La idea es sencilla: si quieres saber si un servicio está sano, hay cuatro señales que no puedes perder de vista:
- Latencia
- Tráfico
- Errores
- Saturación
Estas cuatro métricas ofrecen una visión de alto nivel sobre la salud de un sistema. No entran en el detalle técnico de cada componente, sino que te ayudan a responder a una pregunta clave: ¿está funcionando correctamente mi servicio desde el punto de vista del usuario?
La latencia mide cuánto tarda el sistema en responder. El tráfico indica cuánta demanda está recibiendo. Los errores muestran la proporción de peticiones fallidas. Y la saturación te dice si estás cerca del límite de capacidad (CPU, memoria, conexiones, etc.).
Si gestionas sistemas distribuidos, microservicios o entornos cloud, las Golden Signals te permiten detectar rápidamente degradaciones antes de que el problema escale. Son especialmente útiles cuando trabajas con SLAs o SLOs y necesitas tener claro si estás cumpliendo los compromisos de disponibilidad y rendimiento.
Qué son las RED metrics
Las RED metrics surgen como una forma más concreta de aplicar la observabilidad a servicios y APIs. RED es el acrónimo de:
- Rate (tasa de peticiones)
- Errors (errores)
- Duration (duración de las peticiones)
Como ves, hay puntos en común con las Golden Signals. Sin embargo, el enfoque es ligeramente distinto. Las RED metrics están pensadas específicamente para monitorizar servicios que procesan peticiones, como APIs HTTP o microservicios.
La tasa (Rate) te dice cuántas solicitudes recibe tu servicio por segundo. Los errores muestran qué porcentaje de esas solicitudes fallan. Y la duración (Duration) mide cuánto tarda cada petición en completarse.
Si estás trabajando con arquitecturas basadas en microservicios, las RED metrics son una forma directa y muy práctica de saber si un servicio concreto está respondiendo como debería.
Golden Signals vs RED metrics: principales diferencias
Aunque comparten conceptos, no son exactamente equivalentes.
Las Golden Signals tienen un enfoque más global. Sirven para evaluar la salud de un sistema completo o de un servicio desde una perspectiva amplia. Incluyen la saturación, que no aparece explícitamente en RED, y ponen el foco en la experiencia del usuario final.
Las RED metrics, en cambio, están más orientadas a servicios individuales. Son ideales para equipos que quieren instrumentar sus APIs y tener métricas claras y accionables sin diseñar un modelo complejo desde cero.
Podríamos decir que las Golden Signals responden a la pregunta “¿está sano mi sistema?”, mientras que las RED metrics responden a “¿está funcionando correctamente este servicio concreto?”.
Cuándo usar Golden Signals
Las Golden Signals son especialmente útiles cuando:
- Necesitas una visión global de la salud de un sistema.
- Gestionas múltiples servicios y quieres un marco común para todos.
- Trabajas con objetivos de nivel de servicio (SLOs).
- Te preocupa el impacto real en el usuario.
Por ejemplo, en una plataforma con decenas de microservicios, empezar por las Golden Signals te ayuda a detectar qué parte del sistema está degradándose sin entrar todavía en el detalle fino. Si la latencia global aumenta o la tasa de errores sube, sabes que algo está fallando y puedes profundizar después.
También son una buena base para cuadros de mando ejecutivos, donde no interesa mostrar cientos de métricas, sino indicadores claros y comprensibles.
Cuándo usar RED metrics
Las RED metrics encajan mejor cuando:
- Quieres monitorizar una API concreta.
- Estás desplegando nuevos microservicios.
- Necesitas métricas simples y fáciles de instrumentar.
- Buscas estandarizar la monitorización entre equipos de desarrollo.
Si cada equipo es responsable de su propio servicio, definir Rate, Errors y Duration como estándar facilita que todos hablen el mismo idioma. Además, es más sencillo integrar estas métricas en herramientas de monitorización y observabilidad sin un diseño previo demasiado complejo.
En entornos donde se despliegan versiones con frecuencia, las RED metrics permiten detectar rápidamente si una nueva release ha incrementado la duración media de las peticiones o ha disparado los errores.
Cómo combinarlas en una estrategia de observabilidad
No se trata de elegir entre Golden Signals o RED metrics como si fueran excluyentes. De hecho, lo más habitual en una estrategia de observabilidad madura es combinarlas.
Puedes usar las Golden Signals como capa superior para entender la salud general del sistema y, al mismo tiempo, aplicar RED metrics a cada servicio individual. Así obtienes una visión de conjunto y, cuando detectas un problema, tienes métricas detalladas para investigar.
Lo importante no es la etiqueta que utilices, sino que las métricas que definas estén alineadas con el impacto en el usuario y con los objetivos del negocio. Medir por medir no aporta valor. Medir lo que realmente afecta a la experiencia y a la fiabilidad, sí.
En definitiva, tanto las Golden Signals como las RED metrics son herramientas prácticas dentro de la observabilidad moderna. Elegir bien cuándo usar cada enfoque —o cómo combinarlos— puede marcar la diferencia entre reaccionar tarde a un incidente o anticiparte antes de que el usuario note el problema.
