Del libro SRE de Google, las cuatro señales de oro son latency, traffic, errors y saturation. Si solo puedes medir cuatro cosas sobre un sistema orientado al usuario, mide estas — juntas capturan la gran mayoría de los problemas.
Las cuatro señales
LATENCY how long a request takes
→ split SUCCESSFUL vs FAILED latency (a fast 500 isn't "fast")
→ track percentiles (p50/p95/p99), not averages
TRAFFIC how much demand the system is under
→ requests/sec, transactions/sec, concurrent sessions
ERRORS rate of failing requests
→ explicit (HTTP 500) and implicit (wrong content, too slow)
SATURATION how "full" the system is — its most constrained resource
→ CPU, memory, I/O, queue depth; a leading indicator of trouble
Por qué estas cuatro cubren la mayoría de los problemas
Latency y errors son lo que los usuarios sienten directamente. Traffic explica el contexto de carga (un pico de latencia durante un aumento de tráfico 10x significa algo diferente a uno en línea de base). Saturation es el indicador principal — sube antes que latency y errors, dándote una advertencia antes de que los usuarios resulten afectados.
saturation climbs → latency rises → errors appear → users complain
^ warning here, while there's still time to act
Contraste con USE y RED
Las señales de oro son uno de tres marcos relacionados; se superponen mucho y capturan los mismos signos vitales desde diferentes ángulos.
GOLDEN latency, traffic, errors, saturation → user-facing services (general)
RED Rate, Errors, Duration → request-driven services (a subset)
USE Utilization, Saturation, Errors → resources/infra (per device)
RED es esencialmente señales de oro menos saturation, orientadas alrededor de solicitudes; USE es centrada en recursos (aplícalo por disco, NIC, CPU). Usa RED para servicios, USE para hardware, señales de oro como predeterminado general.
Por qué es importante
Monitorear todo produce ruido y puntos ciegos; no monitorear nada te deja volando a ciegas. Las señales de oro son un conjunto mínimo probado que vincula paneles y alertas a la experiencia del usuario mientras sigue exponiendo saturation temprano — así obtienes una advertencia antes de un incidente en lugar de un análisis posterior.
