Mapa de lecturaDe la señal a una decisión operativa
  1. 01Entender
  2. 02Priorizar
  3. 03Actuar

La mayoría de los equipos no tiene un problema de falta de métricas. Tiene un problema de selección. Golden Signals, RED y USE son tres marcos simples para observar servicios y recursos sin convertir cada gráfico en una alerta.

Los tres métodos en una tabla

Método Señales Mejor uso
Golden Signals Latencia, tráfico, errores, saturación Salud de servicios orientados a usuarios
RED Rate, Errors, Duration APIs, microservicios y transacciones
USE Utilization, Saturation, Errors Infraestructura y recursos limitados

No compiten. RED puede describir una API y USE explicar por qué el recurso que la sostiene está saturado.

Golden Signals

Google SRE propone cuatro señales fundamentales.

Latencia

Tiempo necesario para atender una solicitud. Debe separar respuestas exitosas y fallidas, y analizar percentiles. Un error puede responder rápido y mejorar falsamente el promedio.

Tráfico

Demanda que recibe el sistema: requests por segundo, transacciones, sesiones, mensajes o consultas. Proporciona contexto para interpretar las demás señales.

Errores

Solicitudes fallidas de forma explícita, implícita o por política. Un HTTP 200 con resultado incompleto también puede ser un error de negocio.

Saturación

Qué tan cerca está el sistema de su límite: colas, threads, conexiones, CPU o capacidad. La saturación anticipa degradación antes del agotamiento total.

Método RED

RED simplifica la vista por servicio:

  • Rate: cuántas operaciones procesa.
  • Errors: cuántas fallan.
  • Duration: cuánto tardan.

Es ideal para mapas de microservicios porque permite comparar componentes con un lenguaje común. Un dashboard RED por servicio debe incluir versión y entorno para relacionar cambios.

Método USE

USE se aplica a cada recurso:

  • Utilization: porcentaje de tiempo o capacidad utilizada.
  • Saturation: trabajo en espera que no puede atenderse inmediatamente.
  • Errors: fallas del recurso.

Ejemplos:

Recurso Utilización Saturación Errores
CPU tiempo ocupado run queue errores de máquina
Disco tiempo activo cola de I/O operaciones fallidas
Pool DB conexiones usadas solicitudes esperando timeouts
Cola consumo/capacidad profundidad o edad mensajes fallidos

Una CPU al 90 % no implica necesariamente un problema. Si no existe cola y el SLO se cumple, puede representar uso eficiente.

Del dashboard a la alerta

No toda métrica merece paginar a una persona. Una alerta urgente debería cumplir tres condiciones:

  1. Existe impacto o riesgo inminente.
  2. Una persona puede ejecutar una acción.
  3. La urgencia justifica interrumpirla.

Las alertas basadas en síntomas —errores o latencia respecto de un SLO— suelen ser más útiles que umbrales aislados de recursos. USE aporta contexto para diagnosticar la causa.

SLO y burn rate: agregar urgencia de negocio

Las señales muestran comportamiento; un SLO define cuánto deterioro tolera el servicio. El error budget representa el margen permitido y el burn rate indica a qué velocidad se consume.

Una alerta por burn rate evita dos extremos: paginar por una desviación breve sin impacto o esperar hasta que el objetivo mensual ya sea irrecuperable. Las ventanas rápidas detectan incidentes intensos; las ventanas largas capturan degradaciones sostenidas.

Para diseñarla:

  1. Definí el indicador desde la experiencia del usuario.
  2. Acordá el objetivo y la ventana con el negocio.
  3. Calculá consumo de presupuesto, no sólo valor instantáneo.
  4. Asigná severidad según velocidad y tiempo restante.
  5. Vinculá cada nivel con una acción concreta.

Un SLO no debe convertirse en un número decorativo. Si no cambia prioridades, despliegues o respuesta, todavía no funciona como herramienta operativa.

Ejemplo: checkout lento

  1. Golden Signals detecta aumento de latencia y errores.
  2. RED ubica el cambio en el servicio de pagos.
  3. Una traza muestra espera en la base de datos.
  4. USE confirma saturación del pool de conexiones.
  5. El despliegue reciente explica el nuevo patrón.

Ningún marco aislado cuenta toda la historia. La correlación transforma señales en una explicación.

Percentiles en lugar de promedios

El promedio mezcla experiencias. Si nueve solicitudes tardan 100 ms y una tarda 5 segundos, el promedio no representa a ningún usuario.

Usá p50 para comportamiento típico y p95/p99 para la cola de latencia. Elegí el percentil según volumen y compromiso de servicio; un p99 sobre muy pocas muestras puede ser inestable.

Errores frecuentes

  • Aplicar RED a un disco o USE a una transacción sin adaptación.
  • Alertar por utilización sin observar saturación.
  • Mezclar errores técnicos y de negocio.
  • Usar promedios para latencia.
  • Crear el mismo umbral para todos los servicios.
  • No segmentar por versión, región o dependencia.
  • Medir sin un SLO que defina qué importa.

Plantilla por servicio

Para cada servicio documentá:

  • Propietario y criticidad.
  • SLO y ventana de medición.
  • Rate, errores y duración.
  • Dependencias principales.
  • Recurso limitante y señales USE.
  • Cambios recientes.
  • Acción y canal de cada alerta.

Esta ficha vale más que veinte dashboards sin responsable.

Prueba de calidad

Tomá un incidente reciente y recorré el tablero sin usar conocimiento previo. ¿Las Golden Signals muestran el impacto? ¿RED ubica el servicio? ¿USE confirma o descarta saturación? Si la respuesta requiere abrir consultas improvisadas, documentá el dato faltante. Si una métrica nunca participa de una decisión, sacala de la vista principal. La prueba debe repetirse después de cambios importantes porque una alerta útil hoy puede quedar obsoleta cuando cambia la arquitectura.

Próximo paso

CTL diseña tableros, SLOs y alertas sobre Grafana, Prometheus y plataformas APM. Agendá un workshop para convertir métricas actuales en señales operables.

Preguntas frecuentes

¿RED reemplaza a las Golden Signals?

No. RED cubre tráfico, errores y latencia; la saturación se observa con Golden Signals o USE. Pueden combinarse.

¿Cuántas métricas necesita un servicio?

No existe un número fijo. Empezá por las señales que representan experiencia y capacidad de acción; agregá detalle sólo cuando ayude a diagnosticar.

¿Qué alerta debería configurarse primero?

Una alerta sobre incumplimiento o consumo acelerado del SLO de la experiencia más crítica, con un playbook y owner definidos.

Fuentes verificables