La Versión Corta

Si eres la única persona de guardia, monitorización y alertas no son el mismo trabajo, y tratarlas como una sola cosa es exactamente la razón por la que terminas ignorando ambas.

Monitorización es todo lo que tu sistema registra en silencio para que puedas entenderlo después: latencia, tráfico, errores, saturación de recursos, logs, trazas. Las alertas son el pequeño recorte de la monitorización que tiene permiso para interrumpirte. El encuadre de las cuatro señales doradas del libro de SRE de Google (latencia, tráfico, errores, saturación) resulta útil precisamente porque obliga a un equipo pequeño a elegir qué importa en lugar de observarlo todo.

La regla práctica para un fundador en solitario: monitoriza en un panel diario amplio, alerta con precisión sólo en las pocas condiciones que significan que un usuario está siendo dañado ahora mismo. Todo lo demás pasa a una revisión semanal o a una línea discreta en el log.

Por Qué Mezclarlas te Agota

La mayoría de equipos en etapas tempranas instala una herramienta de monitorización, activa cada alerta por defecto y silencia las notificaciones en una semana. Eso no es una falla personal; es lo que la herramienta está diseñada para producir. Las reglas por defecto de muchas plataformas están escritas para una rotación 24/7 con una biblioteca de runbooks, no para una persona que también responde correos de clientes.

Varias fuentes describen el mismo patrón: una deriva lenta en la que los paneles se vuelven más densos mientras la capacidad real del operador para actuar sobre ellos se reduce. La solución no es “mejores paneles”. Es decidir de antemano qué señales merecen una página y cuáles merecen un resumen.

Las Cuatro Señales Doradas, Traducidas a un Equipo Pequeño

El libro de SRE de Google define cuatro señales que vale la pena seguir en cualquier sistema de cara al usuario. No necesitas todas a precisión p99, pero sí necesitas saber qué te está contando cada una.

Latencia es cuánto tardan las peticiones en responder. La trampa en la que caen muchos equipos pequeños es promediar. Los promedios ocultan la cola larga, y la cola larga es de lo que se quejan los usuarios. Mira p95 o p99, y separa peticiones exitosas de fallidas. Una petición fallida que vuelve en 3 ms bajará tu promedio y te hará sentir bien mientras los usuarios ven páginas de error.

Tráfico es cuánta demanda estás absorbiendo. Por sí solas, las cifras de tráfico no dicen mucho. En contexto con latencia y errores, te dicen si un pico es carga normal, un bot o el inicio de una caída. Un salto de latencia a 3x el tráfico normal significa algo distinto que el mismo salto a las 3 AM sin tráfico.

Errores son peticiones fallidas, medidas como tasa y no como conteo bruto. Distingue, como mínimo, 4xx de 5xx. Un pico de 4xx suele ser un bug del cliente o un despliegue defectuoso; un pico de 5xx suele ser problema tuyo. Los presupuestos de error, que son cuánta falla te permites antes de romper tus propias promesas, son la forma en que los equipos grandes mantienen esto honesto. Para una persona, sirve una versión más simple: decide qué tasa de error estás dispuesto a tolerar durante una semana, y alerta cuando la realidad la cruce.

Saturación es cuán cerca estás del techo en CPU, memoria, disco, conexiones a base de datos, profundidad de cola o cualquier cosa con un límite duro. Es la única señal que genuinamente predice problemas antes de que los usuarios los sientan. La mayoría de equipos la ignora hasta que algo más rompe primero.

Estas cuatro señales funcionan porque cubren el sistema sin obligarte a instrumentar cada línea de código. Puedes montar una configuración de monitorización creíble con ellas en un fin de semana.

Qué Va al Panel y Qué Va a la Alerta

Esta es la decisión que define si duermes o no.

Un panel diario debería mostrar:

  • Latencia a p95 y p99, separada por éxito y fallo.
  • Tasa de peticiones, idealmente comparada con la misma hora de la semana pasada.
  • Tasa de errores, separada por clase.
  • Saturación sobre tu recurso más ajustado (a menudo conexiones a base de datos o memoria de una instancia).
  • Una muestra pequeña de logs de error recientes con el ruido filtrado.

Una alerta debería dispararse sólo cuando:

  • Un SLO visible para el usuario está en riesgo ahora mismo. No “podría estar”. Ahora mismo.
  • Un recurso está en camino de agotarse en horas, no en días.
  • Una dependencia sin la que no puedes operar (proveedor de auth, procesador de pagos, base de datos principal) está degradada.
  • Un despliegue reciente parece haber roto algo que no puedes revertir con facilidad.

Todo lo demás va al panel, a la revisión semanal, o a una búsqueda silenciosa en logs. El modelo mental: las alertas se pagan con tu atención, así que gástalas como un fundador con horas limitadas.

Umbrales que Aguantan una Guardia de una Sola Persona

Los umbrales estáticos (“alertar al 80% de CPU”) son fáciles de configurar y casi siempre equivocados. O se disparan con carga normal y te enseñan a ignorarlos, o se disparan demasiado tarde para servir.

Algunos patrones aguantan mejor para equipos pequeños:

  • Alerta sobre el dolor del usuario, no sobre internos. Pagina cuando la tasa de errores cruza un presupuesto definido, no cuando aparece un número concreto de CPU.
  • Usa ventanas de tiempo. Un pico de un minuto es ruido; cinco minutos de tasa de error elevada es señal. La mayoría de herramientas permiten exigir “durante al menos 5 minutos” antes de paginar.
  • Haz la saturación proactiva, no reactiva. Si tu pool de conexiones a base de datos lleva una hora al 85%, quieres enterarte el lunes por la mañana, no cuando llegue al 100% el sábado.
  • Separa alertas de quema lenta de las alertas de buscapersonas. Las lentas van a correo o a un resumen diario. Las de buscapersonas van al móvil, y deberías poder contarlas con los dedos de una mano al mes.

Si no puedes justificar la alerta con la frase “un cliente está siendo dañado ahora mismo y soy la única persona que puede arreglarlo”, no pertenece al buscapersonas.

La Trampa de la Fatiga de Alertas

La fatiga de alertas es lo que pasa cuando el sistema de alertas se convierte en parte del ruido de fondo que has dejado de notar. Es la razón más común por la que un fundador en solitario deja de confiar silenciosamente en su monitorización y se entera de las caídas por los clientes.

La cura no es un algoritmo más inteligente. Es menos alertas. Apunta a un número pequeño de alertas de alta señal, cada una atada a algo sobre lo que realmente harías algo. Cuando se dispara una alerta, el resultado correcto debería ser uno de tres: “arreglarlo ya”, “agendar arreglo esta semana”, o “actualizar el umbral porque la realidad cambió”. Si ninguno aplica, la alerta está mal.

Herramientas: Cuánto es Suficiente

No necesitas una plataforma enterprise de observabilidad para hacer esto bien. Las categorías entre las que tienes que elegir son pocas:

  • Una herramienta de checks de uptime y sintéticos que mire tus endpoints desde fuera de tu infraestructura.
  • Una herramienta de métricas de aplicación y panel para las cuatro señales.
  • Un tracker de errores que agrupe stack traces y te avise cuando aparece uno nuevo.
  • Una capa de alertas, a menudo integrada en las herramientas anteriores, capaz de enrutar a correo, Slack o SMS según severidad.

Para un fundador solo o un equipo pequeño, una única plataforma ligera que cubra uptime externo, métricas de aplicación básicas y alertas simples suele ser el punto de partida correcto. La pregunta no es “qué herramienta tiene más funciones”, sino “qué herramienta me permite montar las cuatro señales y un puñado de alertas en menos de un día”. Cualquier cosa más pesada es pedir complejidad prestada que no tienes tiempo para cargar.

Auto-hospedar monitorización es posible pero rara vez vale el coste de mantenimiento para un equipo pequeño, salvo que tengas una razón firme de residencia de datos. Los servicios gestionados ganan en tiempo-hasta-primera-alerta y en el trabajo aburrido de mantener la propia monitorización en pie mientras tu aplicación está caída.

Una Configuración Práctica que Puedes Hacer Este Fin de Semana

  1. Elige una herramienta que cubra checks de uptime externos más métricas básicas de aplicación.
  2. Conecta las cuatro señales doradas: latencia p95/p99 separada por estado, tasa de peticiones, tasa de errores por clase, y saturación sobre el recurso más ajustado que tengas.
  3. Pon las cuatro en un único panel que realmente abras.
  4. Escribe, en una frase cada uno, las condiciones bajo las que quieres una página. Limítate a tres o cuatro.
  5. Configura sólo esas alertas, con una duración mínima de 5 minutos para no despertar por picos de un minuto.
  6. Enruta las alertas de alta severidad al móvil, el resto a un resumen diario por correo.
  7. Después de dos semanas, borra cada alerta sobre la que no actuaste.

Ese último paso es el que la mayoría de equipos se salta, y es el que hace que el sistema sea sostenible durante meses en lugar de semanas.

FAQ

¿Necesito realmente las cuatro señales doradas desde el primer día?

No. Empieza con latencia y tasa de errores, las dos que se traducen más directamente en dolor para el usuario. Añade tráfico y saturación una vez esas dos estén estables.

¿La monitorización de uptime es lo mismo que la monitorización de aplicación?

No del todo. La de uptime responde “¿algo está respondiendo?”. La de aplicación responde “¿lo que está respondiendo funciona de verdad para los usuarios?”. Normalmente quieres ambas, y a menudo viven en herramientas distintas.

¿Cuántas alertas debería tener un fundador en solitario?

Si no puedes contarlas con los dedos de una mano, tienes demasiadas. Cada alerta debe corresponderse con una acción concreta que tomarías.

**Qué es un presupuesto de error en lenguaje sencillo?

Es la cantidad de fallo que te permites en un periodo, expresada como porcentaje. Si tu presupuesto mensual es 99,9% de disponibilidad, estás允许 unos 43 minutos de caída. Una vez que lo agotas, la regla habitual es “deja de lanzar funciones y arregla fiabilidad”.

¿Cuál es la diferencia entre monitorización y observabilidad?

La monitorización sigue métricas conocidas y alerta sobre umbrales. La observabilidad es una práctica más amplia de收集 suficientes datos (métricas, logs, trazas, eventos) para responder preguntas nuevas que no anticipaste. Para un equipo pequeño, monitorización suele bastar hasta que el sistema se vuelve tan complejo que ya no puedes predecir los modos de fallo de antemano.

Fuentes