Monitorización sintética y comprobaciones de disponibilidad: sondear desde fuera lo que ven los usuarios

Objetivo

Detectar que los usuarios no pueden acceder al servicio ni usarlo, con independencia de si las propias métricas, registros o endpoints de estado del servicio funcionan, y registrar la disponibilidad desde el exterior.

Requisitos previos

Una herramienta de sondeo que se ejecuta fuera de la red de producción (el blackbox exporter de Prometheus sondea objetivos HTTP, HTTPS, DNS, TCP, ICMP y gRPC, y expone probe_success junto con métricas de tiempo), al menos dos ubicaciones de sondeo, y una vía de alerta que no dependa del sistema monitorizado. Se aplica la distinción del libro de SRE: la monitorización de caja negra está orientada a síntomas e informa problemas activos («el sistema no funciona correctamente, en este momento»), mientras que la monitorización de caja blanca inspecciona el interior y puede ver problemas inminentes.

Pasos

1. Enumerar en secuencia lo que necesita un usuario: respuesta DNS, negociación TLS, la página de entrada, el punto de inicio de sesión o de la API, una lectura que toca la base de datos, un recurso estático de la CDN.
2. Escribir un sondeo por paso con una condición de corrección, no solo un código de estado: la subcadena o el campo JSON esperados en el cuerpo, el destino de redirección esperado, el valor de registro DNS esperado, la validez del certificado.
3. Fijar el tiempo de espera del sondeo por debajo del intervalo de sondeo; el README del blackbox exporter señala que un tiempo de espera de recolección de Prometheus nunca puede superar el intervalo de recolección.
4. Ejecutar cada sondeo desde al menos dos ubicaciones en redes distintas; tratar un fallo como real solo cuando persiste durante varios intervalos consecutivos en más de una ubicación.
5. Alertar ante probe_success == 0 según esa regla y conservar la serie de duraciones para las tendencias de latencia; una lentitud repentina desde una sola ubicación suele apuntar a una ruta de red, mientras que desde todas las ubicaciones apunta al servicio.
6. Marcar el tráfico de sondeo (un agente de usuario o una cabecera dedicados) para que quede excluido de las analíticas, los límites de tasa y las alertas de seguridad.
7. Ensayar: apuntar un sondeo a un objetivo de staging deliberadamente roto y confirmar que la alerta llega por la vía externa.

Resultado esperado

Un registro de disponibilidad desde el lado del usuario que alerta a los pocos intervalos de una interrupción y que sigue funcionando cuando lo que falló es precisamente la pila de monitorización interna.

Límites y base de verificación

Un sondeo ve una única ruta con un único cliente; no puede ver degradaciones que devuelven una página correcta pero lenta para algunos usuarios, ni recorridos con sesión iniciada, salvo que existan una cuenta de prueba y acciones idempotentes. Sondear endpoints de escritura en producción requiere ese tipo de cuentas y una limpieza posterior. Los intervalos de sondeo y el número de ubicaciones aquí son decisiones de diseño, no óptimos medidos.