Cómo Configurar un Verificador de Caídas para Servicios Detrás del Firewall
La mayoría de los verificadores de caídas de sitios web prueban tus servicios desde centros de datos en la internet pública. Eso funciona para un sitio corporativo, pero falla en cuanto un servicio está detrás de un firewall, en una VLAN privada o dentro de un clúster de Kubernetes sin IP externa: la sonda nunca llega, y el verificador reporta una caída falsa o simplemente no puede monitorear el destino.
La solución no es cambiar el firewall, sino cambiar de lugar el verificador. Esta guía explica cómo un agente local ligero elimina ese punto ciego y cómo configurar tu primera verificación interna en DownWarning.
Por qué los verificadores en la nube no ven los servicios privados
Un servicio con IP privada, dentro de una VPC sin endpoint público o expuesto solo como ClusterIP en Kubernetes no tiene ruta de regreso hacia una sonda externa. Cada API interna, base de datos y endpoint entre servicios se convierte en un punto ciego, y ese punto ciego crece junto con tu infraestructura.
La solución alternativa habitual —abrir un puerto de entrada, asignar una IP pública o añadir un proxy inverso solo para monitorear— cambia un problema de visibilidad por uno de seguridad. Un servicio interno es interno por una razón. La arquitectura de monitoreo debe adaptarse al diseño de tu red, no al revés.
Cómo un agente solo de salida cambia las reglas
Un verificador basado en agente invierte la conexión. Un binario pequeño se ejecuta dentro de tu red, verifica los destinos internos localmente y envía los resultados a DownWarning mediante una conexión HTTPS saliente estándar. Sin puertos de entrada, sin reglas de firewall que modificar, sin IP pública: para el firewall, es una petición HTTPS saliente más.
El agente de DownWarning se ejecuta en Linux, macOS y Windows (incluso como servicio de Windows), o como un pod dentro de un clúster de Kubernetes. Se autentica con una clave de API del agente generada en el panel, recibe los monitores asignados y se actualiza solo cuando sale una nueva versión. Si el agente deja de reportar, el panel lo marca como desconectado, así que un agente silencioso nunca se confunde con servicios saludables.
Qué puede verificar el agente
Un verificador de caídas tiene una tarea concreta: probar un destino a intervalos, confirmar que responde correctamente y alertar cuando no lo hace. Para destinos internos, el agente admite tres tipos de verificación:
HTTP(S)
Verificaciones completas de petición y respuesta en APIs y aplicaciones internas: método HTTP, encabezados personalizados, autenticación, códigos de estado esperados y una palabra clave que debe (o no debe) aparecer en el cuerpo de la respuesta.
Ping
Alcance ICMP para hosts y dispositivos de red. Útil para la infraestructura, pero un ping exitoso no demuestra que la aplicación funcione: combínalo con una verificación HTTP o de Puerto.
Puerto
Conectividad TCP para servicios que no son HTTP, como bases de datos, Redis, brokers de mensajes y SSH, donde la pregunta correcta es "¿el puerto acepta conexiones?".
Las verificaciones de DNS y el seguimiento de vencimiento de certificados SSL se ejecutan desde las sondas externas de DownWarning, por lo que aplican a endpoints accesibles públicamente y no a monitores asignados a un agente. Si un servicio tiene un endpoint público y uno interno, monitorea el público externamente para DNS y SSL, y el interno a través del agente.
Configura tu primera verificación interna
1. Instala el agente
Crea un agente en el panel de DownWarning para obtener su clave de API y ejecuta el binario en una máquina (o como pod) dentro de la red privada, pasando la clave con --api-key, con la variable de entorno MONITOR_API_KEY o en un archivo config.yaml. Un solo agente suele cubrir un segmento de red completo.
2. Crea un monitor para el agente
Elige HTTP, Ping o Puerto, indica el destino interno —una IP privada, un hostname interno o una dirección del clúster como orders.default.svc.cluster.local— y asigna el monitor a tu agente en lugar de a las sondas externas. Los monitores de agente se ejecutan en intervalos de 60 segundos o más.
3. Conecta las alertas y valida
Vincula uno o más contactos de alerta al monitor y observa los primeros resultados en el panel. Un error en la primera ejecución suele indicar un problema de DNS o de enrutamiento entre el agente y el destino; el motivo del fallo en el resultado de la verificación indica qué capa falló.
En clústeres de Kubernetes que aplican NetworkPolicies, añade una política acotada que permita al namespace del agente alcanzar los namespaces de las aplicaciones en los puertos que monitoreas. Aplica el principio de mínimo privilegio y pruébala primero fuera de producción.
Alertas que las personas realmente atienden
Una alerta que llega al lugar equivocado, en la práctica, no es una alerta. DownWarning notifica por correo electrónico, Slack, Microsoft Teams, Telegram, Discord, Google Chat y webhooks, que puedes enrutar a PagerDuty, Opsgenie o tu propia automatización. Asigna contactos distintos por monitor, para que la alerta de la base de datos llegue al equipo de DBA y la de la API interna llegue a sus responsables.
Cada alerta incluye el nombre del monitor, el motivo del fallo y un enlace al incidente, y se envía una notificación de recuperación por los mismos canales cuando el servicio vuelve. Las alertas se disparan con la primera verificación fallida, así que elige el intervalo según la rapidez con la que necesitas enterarte: un minuto para servicios internos críticos, intervalos más largos para el resto.
Coloca el verificador donde viven tus servicios
Un verificador de caídas solo funciona si puede alcanzar el servicio. Para todo lo que está detrás de un firewall, el modelo de sonda externa falla por diseño, y exponer servicios solo para complacer al verificador es la solución equivocada. Un agente solo de salida te da cobertura HTTP, Ping y Puerto de servicios privados y de Kubernetes sin tocar ninguna regla de entrada.
Preguntas Frecuentes
¿Un verificador de caídas en la nube puede monitorear servicios detrás de un firewall?
No sin exponerlos. Las sondas externas necesitan una ruta hasta el destino, por lo que las IPs privadas, los servicios limitados a la VPC y los servicios ClusterIP de Kubernetes aparecen como caídos de forma permanente. Un agente local dentro de la red lo evita verificando localmente y reportando mediante conexiones salientes.
¿Necesito abrir algún puerto de entrada en el firewall para el agente?
No. El agente solo realiza conexiones HTTPS salientes hacia DownWarning. Tus reglas de entrada del firewall se quedan exactamente como están.
¿Qué tipos de verificación funcionan a través del agente?
Verificaciones HTTP(S), Ping y de Puerto. Las verificaciones de DNS y el seguimiento de vencimiento de certificados SSL se ejecutan desde las sondas externas de DownWarning sobre endpoints accesibles públicamente.
¿El agente local está disponible en el plan gratuito?
Sí. El plan gratuito Starter incluye un agente local, así que puedes monitorear una red privada o un clúster de Kubernetes sin costo. Actualiza a Pro o Scale cuando necesites más agentes para cubrir otras redes.