Monitoriza primero tus endpoints orientados al cliente
Cada producto SaaS tiene endpoints con los que los usuarios interactúan directamente. Estos son tu máxima prioridad de monitorización.
Comienza con el panel de tu aplicación. Si los usuarios inician sesión en app.tuempresa.com, monitoriza esa URL. Luego añade tu endpoint de autenticación. Si los usuarios no pueden iniciar sesión, el resto de tu monitorización no importa.
Añade tus endpoints API principales. Si tu producto tiene una API REST que los clientes integran, monitoriza los endpoints que más llaman. Un endpoint /v1/health está bien, pero puede devolver 200 mientras tus endpoints de datos reales lanzan errores 500. Monitoriza los endpoints que tus usuarios realmente golpean.
Añade tu flujo de facturación y pagos. Si los webhooks de Stripe o Paddle dejan de llegar, o tu endpoint de gestión de suscripciones se cae, estás perdiendo dinero. Monitoriza los endpoints que tocan los ingresos.
Verifica tus trabajos en segundo plano
Tu servidor está activo. Tu API devuelve 200. Tu panel carga. Todo parece ir bien. Pero tu copia de seguridad nocturna de la base de datos lleva dos semanas fallando silenciosamente. Tu cola de correo tiene 8.000 mensajes sin entregar. Tu pipeline de exportación de datos se detuvo hace tres días.
Esta es la brecha de monitorización que atrapa a la mayoría de los equipos. La monitorización de disponibilidad cubre la ruta solicitud-respuesta. No cubre tareas programadas, workers en segundo plano ni pipelines asíncronos.
La monitorización heartbeat llena este vacío. Cada tarea programada obtiene una URL única. Cuando la tarea se ejecuta con éxito, hace ping a esa URL. Si el ping no llega dentro de la ventana esperada, recibes una alerta. La configuración es un solo comando curl al final de tu script cron.
Monitoriza estos trabajos como mínimo:
- Copias de seguridad de bases de datos
- Colas de entrega de correo electrónico
- Facturación y generación de facturas
- Sincronizaciones y exportaciones de datos
- Rotación y limpieza de logs
- Automatización de renovación de certificados
Más información sobre la monitorización heartbeat y cómo detecta lo que las verificaciones de disponibilidad pasan por alto.
Elige el intervalo de verificación adecuado
No todos los endpoints necesitan la misma frecuencia de verificación. Alinea tus intervalos con el impacto empresarial del tiempo de inactividad.
Verificaciones de 30 segundos para endpoints críticos para los ingresos: tu flujo de pago, tu API principal, tu servicio de autenticación. Si estos se caen, estás perdiendo dinero o bloqueando usuarios. Necesitas saberlo lo antes posible.
Verificaciones de 1 minuto funcionan para la mayoría de los servicios de producción. Tu panel de aplicación, APIs secundarias, endpoints de estado. Suficientemente rápido para detectar problemas reales, suficientemente lento para evitar falsas alarmas.
Verificaciones de 5 minutos están bien para endpoints de menor prioridad: páginas de marketing, sitios de documentación, herramientas internas. Si el sitio de marketing está caído durante 4 minutos, el impacto empresarial es bajo.
Cuanto más rápidas sean tus verificaciones, antes lo sabrás. Pero verificaciones más rápidas también significan más datos, más ruido y costes potencialmente más altos. Haz coincidir el intervalo con el impacto.
Configura alertas que no agoten a tu equipo
La fatiga de alertas es el asesino silencioso de la monitorización. Cuando cada pequeño parpadeo activa una notificación, tu equipo deja de prestar atención. Silencian el canal. Ignoran los correos. Luego ocurre un incidente real y nadie se da cuenta.
Usa umbrales de escalado de alertas. Requiere 2 o 3 fallos consecutivos antes de que se active una alerta. Esto filtra problemas de red transitorios que se resuelven solos en segundos. Un solo fallo de verificación no es un incidente. Tres seguidos sí lo son.
Enruta las alertas por gravedad. Los monitores críticos van a PagerDuty o teléfonos de guardia. Los monitores de nivel de advertencia van a un canal de Slack. Los monitores informativos van al correo o a un panel. No envíes todo al mismo lugar.
Usa horas de silencio para mantenimiento. Si despliegas cada martes a las 2 AM, suprime las alertas en los monitores afectados durante esa ventana. Tu equipo sabe del despliegue. No necesita ser notificado porque la aplicación se reinició.
Separa los canales de alerta de los canales de discusión. Tu canal #alertas solo debe contener mensajes de alerta automatizados. La discusión humana ocurre en #ops o #ingenieria. Esto mantiene limpio y escaneable el feed de alertas.
Construye una página de estado que tus usuarios realmente consulten
Tu página de estado no es solo una casilla para marcar. Es una herramienta de comunicación que reduce la carga de soporte durante incidentes.
Ponla en tu propio dominio (estado.tuempresa.com). Personalízala con tu marca. Enlázala desde el pie de página de tu aplicación, tu documentación de soporte y tus páginas de error.
Cuando ocurra un incidente, publica actualizaciones. “Estamos investigando informes de errores elevados en la API” es mejor que el silencio. “El problema se ha identificado como agotamiento del pool de conexiones de base de datos. Estamos escalando.” dice a los usuarios que sabes qué está mal. “Monitorizando la recuperación. La latencia de la API ha vuelto a la normalidad.” cierra el ciclo.
Una página de estado que se actualiza automáticamente desde tus datos de monitorización significa que no tienes que accionar interruptores manualmente durante un incidente. La página refleja la realidad. Tú te concentras en solucionar el problema. Más información sobre las páginas de estado de PingWatchdog.
Revisa tus incidentes
Después de cada incidente, dedica 10 minutos a revisar lo que sucedió. Mira la línea de tiempo. ¿Cuánto tiempo se tardó en detectar? ¿Cuánto en responder? ¿Cuánto en resolver?
Estos tres números son tus métricas principales de fiabilidad: tiempo medio de detección (MTTD), tiempo medio de respuesta (MTTR) y tiempo medio de resolución (MTTResolve). Hazles seguimiento en el tiempo. ¿Estás mejorando? ¿Empeorando?
Usa los datos de incidentes para justificar mejoras. Si el 40% de tus incidentes son causados por problemas de conexión a la base de datos, es una señal para invertir en pool de conexiones o réplicas de lectura. Si la expiración de certificados SSL causa incidentes cada 90 días, automatiza la renovación de certificados.
PingWatchdog crea incidentes automáticamente cuando los monitores caen y los resuelve automáticamente cuando los servicios se recuperan. Obtienes una línea de tiempo completa sin trabajo manual. Más información sobre la gestión de incidentes.
Superpón tu monitorización
Una sola herramienta no puede cubrirlo todo. Usa PingWatchdog para monitorización externa: disponibilidad, SSL, heartbeat, páginas de estado. Usa herramientas de monitorización de rendimiento de aplicaciones (APM) como Datadog o Sentry para métricas internas. Usa agregación de logs para depuración.
La vista externa te dice si los usuarios pueden alcanzar tu servicio. La vista interna te dice por qué. Ambas importan.
Comparar herramientas de monitorización para encontrar el stack adecuado para tu equipo.