Monitores
Un monitor es una cosa que quiere vigilar, y la regla que decide si está sana. Hay treinta tipos. La mayoría hace una petición desde nuestra red y juzga la respuesta; dos esperan a que llegue algo desde la suya, y cuatro recogen lo que sus routers exportan a su propia sonda privada.
Los tipos
Web y red
| Tipo | Qué comprueba |
|---|---|
http | Que una URL responde, con el código de estado, el tiempo de respuesta y, si quiere, una cadena que debe aparecer en el cuerpo. |
ping | Que un host responde a ICMP. |
tcp | Que un puerto acepta una conexión. |
udp | Que un datagrama obtiene respuesta. |
dns | Que un nombre resuelve, opcionalmente a los registros que usted espera. |
Certificados y dominios
| Tipo | Qué comprueba |
|---|---|
ssl_cert | Cuánto le queda a un certificado y que la cadena sea válida. |
tls_audit | Nueve handshakes: cada versión de TLS, las familias de cifrado débiles, los tamaños de clave y las cabeceras de seguridad. Una prueba que no podemos ejecutar informa sin probar en lugar de aprobar — véase más abajo. |
domain_expiry | Cuánto le queda al registro del dominio. |
blacklist | Si una dirección o un dominio aparece en las principales listas de bloqueo. |
Correo
| Tipo | Qué comprueba |
|---|---|
smtp, imap, pop3 | Que el servidor mantiene una conversación real en su propio protocolo y negocia STARTTLS. Nunca se autentica: demostrar un inicio de sesión significaría guardar una contraseña de buzón que funciona por cada monitor. |
mail_posture | Si otros pueden fiarse del correo del dominio. Lee SPF, DKIM y DMARC del DNS; con un buzón, envía cada hora un mensaje real a través de su propio servidor y evalúa lo que llega. |
Protocolos de infraestructura
Existen porque una comprobación tcp del puerto no demuestra casi nada sobre ellos. Un SMSC acepta TCP mucho después de dejar de registrar a nadie; una pila SIP puede quedarse atascada con el socket abierto; un servidor XMPP con el certificado caducado completa perfectamente un handshake TCP.
| Tipo | Qué comprueba |
|---|---|
snmp | Consulta una lista de OID y juzga cada uno contra un umbral, con su propia gravedad por comprobación. |
smpp | Se vincula y se desvincula. Nunca envía un mensaje. |
sip | Envía OPTIONS. Una respuesta final que no sea 2xx es degradado, no caído: un proxy que responde 405 a un desconocido funciona correctamente y nos está rechazando. |
xmpp | Abre un flujo y negocia STARTTLS. |
grpc | Llama a grpc.health.v1.Health/Check. gRPC lleva su estado en los tráileres de HTTP/2, así que una llamada fallida responde igualmente 200 OK; por eso un monitor http no puede sustituir a este. Disponible en el plan Pro y superiores. |
Bases de datos
Pro y superiores. Una comprobación tcp en el 5432 demuestra que algo aceptó un socket, y todos los fallos interesantes de una base de datos mantienen el socket abierto: Postgres en recuperación, un límite de conexiones agotado por una aplicación con fugas, un rol cuya contraseña caducó, una base de datos renombrada, un directorio de datos que no se montó. Así que estas comprobaciones abren una conexión, se autentican y hacen al servidor una pregunta trivial.
| Tipo | Qué comprueba |
|---|---|
postgres | Conecta, se autentica y ejecuta select version(). El nombre de la base de datos es obligatorio, porque en Postgres no existe conectarse sin uno. |
mysql | Lo mismo, y cubre MariaDB: el mismo protocolo de red, no una segunda comprobación. |
redis | Conecta, se autentica y envía PING. Una réplica que todavía carga sus datos responde -LOADING, que se informa como su propio motivo y no como un tiempo de espera agotado. |
mongodb | Conecta, se autentica y ejecuta el comando ping. Se admiten direcciones mongodb+srv, que es la forma habitual de llegar a un MongoDB gestionado. |
mssql | Conecta por TDS, se autentica y ejecuta select @@version. |
Ninguna lee ni escribe nada. Es una comprobación de disponibilidad, no una transacción sintética: dale una cuenta que no pueda hacer nada más que conectarse.
La credencial se guarda sin cifrar, porque la sonda que ejecuta la comprobación recibe la configuración tal cual. Por eso estas cinco solo se ejecutan desde una sonda habilitada para datos personales, que es la misma restricción que tienen snmp ysmpp.
Eso significa uno de dos lugares. Tu propia sonda privada, que es aquello para lo que están diseñadas estas comprobaciones: se ejecuta en tu hardware, dentro de tu red, así que la configuración nunca sale de tu infraestructura, y suele ser lo único capaz de llegar a una base de datos que merezca la pena vigilar — una base de datos detrás de una VPC, un enlace privado o una lista de permitidos no es accesible desde ninguna red ajena, tampoco desde la nuestra. En su defecto, nuestros propios puntos de observación en la UE, para una base de datos que sí sea accesible públicamente.
Contenedores
Pro y superiores. Una comprobación del puerto publicado de un contenedor responde por el proxy que tiene delante. Un contenedor que se reinicia en bucle tras una política de reinicio está activo unos segundos cada vez, un HEALTHCHECK que falla deja el puerto abierto, y una muerte por falta de memoria seguida de un reinicio parece una sola petición lenta. El motor de Docker sabe las tres cosas.
| Tipo | Qué comprueba |
|---|---|
docker | Pide al motor un contenedor por nombre o id. En ejecución es activo; un HEALTHCHECK no sano, o un contenedor en pausa, detenido o muerto por falta de memoria, es caído; una comprobación de salud que aún se inicia, o un reinicio de la política de reinicio en los últimos cinco minutos, es degradado. Nunca inicia, detiene ni ejecuta nada. |
El acceso a la API del motor equivale a root en ese host, así que el endpoint y sus certificados de cliente son credenciales, y este tipo solo se ejecuta desde una sonda autorizada para datos personales. Un socket unix solo lo abre una sonda iniciada con DOCKER_SOCKET_ENABLED=true, algo que configuras en tu propia sonda privada junto a tu propio motor y que nosotros nunca configuramos en las nuestras; en cualquier otro lugar la comprobación se abstiene en vez de dar tu contenedor por caído. Un endpoint tcp:// o https:// con certificados de cliente funciona desde ambos.
Tráfico de red
Business y superiores. Una comprobación de disponibilidad te dice que un enlace responde; no puede decirte que el enlace está saturado, que una copia de seguridad lo inunda a mediodía o que el tráfico hacia tu capa web cayó en silencio a cero. Tus routers y switches ya cuentan todo eso y pueden exportarlo. Estos tipos recogen esa exportación y la convierten en tasas, un desglose por protocolo y los puertos y direcciones con más tráfico.
| Tipo | Qué comprueba |
|---|---|
netflow | NetFlow v5 y v9 de un router, en UDP 2055. Las plantillas se aprenden a medida que llegan; los registros que llegan antes que su plantilla se cuentan y se descartan, nunca se adivinan. |
jflow | J-Flow de un router Juniper, que en la red es NetFlow, en el mismo puerto. |
ipfix | IPFIX, el estándar del IETF que sucede a NetFlow v9, en UDP 4739, incluidos los campos de longitud variable y los específicos de cada fabricante. |
sflow | sFlow v5 de un switch, en UDP 6343: cabeceras de paquetes muestreadas, a través de etiquetas VLAN hasta IPv4 o IPv6, escaladas de nuevo por la tasa de muestreo que informa el switch. |
Todos los umbrales son opcionales: una tasa de bits máxima, una tasa de bits mínima, una tasa de paquetes máxima. Por encima o por debajo de uno es degradado. Sin ninguno, el monitor registra y grafica el tráfico sin alertar por un valor. Un exportador que deja de enviar durante más tiempo del que permites está caído, y uno que envía el protocolo equivocado —sFlow a un monitor NetFlow— está caído con un mensaje que lo dice.
Estos tipos solo se ejecutan en tu propia sonda privada. La exportación de flujos va por UDP, que no lleva autenticación: un colector en nuestra red compartida tendría que fiarse de la dirección del remitente, que cualquiera puede falsificar o reclamar. En una sonda dentro de tu red, los únicos routers que pueden alcanzarla son los tuyos. Además, tus registros de tráfico se quedan en casa: nombran las direcciones de las personas de tu red, así que la sonda los agrega donde llegan y solo nos envía las tasas y las tablas de los diez principales. Inicia la sonda con FLOW_COLLECTOR_ENABLED=true, publica los puertos UDP, apunta tus routers a ella y elige esa sonda al crear el monitor.
Cosas que nos avisan a nosotros
| Tipo | Qué comprueba |
|---|---|
heartbeat | Un cron o un proceso por lotes llama a una URL cuando termina. El silencio pasado el intervalo es el fallo. Úselo para lo que nada más puede ver: una copia de seguridad nocturna, una importación cada hora. |
server_agent | Un pequeño agente en su propia máquina informa de CPU, memoria y disco. Descárguelo con curl desde el enlace del monitor. |
Cada cuánto se ejecuta
Usted elige un intervalo; su plan pone el suelo. Free comprueba cada minuto, Starter cada 45 segundos, Pro cada 30, Business cada 15, Enterprise cada 5.
Cuatro tipos tienen su propio suelo, sea cual sea el plan, porque la respuesta no cambia de un minuto a otro y preguntar más a menudo sería ruido y carga en el servidor de otra persona:
| Tipo | Como mucho |
|---|---|
blacklist | cada hora |
ssl_cert | cada seis horas |
domain_expiry, tls_audit | dos veces al día |
mail_posture | dos veces al día leyendo registros, cada hora cuando envía correo real |
Autenticación del correo, y enviar correo de verdad
Un monitor mail_posture lee SPF, DKIM, DMARC, MTA-STS y TLS-RPT del DNS y le dice qué está roto. Eso detecta un registro que se ha echado a perder, y no detecta aquello sobre lo que esos registros son una predicción: un dominio puede publicar un SPF impecable y enviar desde un servidor que ese registro repudia, publicar una clave DKIM y firmar con otra ya rotada, o tener una pasarela por medio que reescribe una cabecera y rompe una firma que era válida al salir.
Dele al monitor un buzón — una dirección y credenciales SMTP e IMAP — y medirá en lugar de predecir. Cada hora entrega un mensaje a su propio servidor de salida dirigido a nuestro receptor, que comprueba el SPF y el DKIM de lo que realmente llegó, y después responde al buzón para que la siguiente ejecución confirme por IMAP que su dominio también recibe correo. Los dos trayectos tienen que completarse. Un dominio que envía perfectamente y ha dejado de aceptar correo en silencio es una caída real, y una que cualquier comprobación de solo envío da por sana.
Dos cosas que conviene saber antes de rellenarlo. Las credenciales se guardan sin cifrar y se entregan a la sonda que ejecuta la comprobación — eso vale para la configuración de cualquier monitor, porque la sonda es quien hace la petición — así que un monitor con buzón solo se ejecuta dentro de la Unión Europea, nunca en nuestras sondas de otros sitios. Use una contraseña de aplicación si su proveedor las ofrece. Y la respuesta que enviamos se borra del buzón en cuanto se ha leído, para que la carpeta no se llene.
Un intervalo no es lo rápido que se entera de una caída
Esta es la parte que merece leerse dos veces. Una sola comprobación fallida no abre un incidente. Un monitor tiene que fallar tres veces seguidas — ese es el ajuste confirmations, y tres es el valor por defecto — antes de que se avise a nadie.
Pero no son tres veces el intervalo. Cuando una comprobación falla, la siguiente se adelanta en vez de esperar el intervalo entero, así que un monitor de cinco minutos confirma una caída en bastante menos de quince. Un resultado solo puede adelantar la siguiente comprobación, nunca retrasarla.
Baje confirmations si prefiere que le despierten pronto y de vez en cuando para nada. Súbalo para algo que sabe que es inestable.
Las comprobaciones rotan entre ubicaciones
Comprobamos desde varios sitios, uno por intervalo, rotando. Tres puntos de observación en un monitor de cinco minutos significa que cada uno lo ve cada quince minutos mientras el monitor se sigue comprobando cada cinco.
Eso es lo que da sentido a la confirmación: tres fallos seguidos son tres fallos vistos desde tres sitios distintos, así que una sonda que sencillamente no alcanza su servidor es inofensiva — la región siguiente lo consigue y la racha se reinicia.
Un fallo mientras otra ubicación va bien es degradado y no caído. Caído debe querer decir que su sitio es inalcanzable, no que un punto de observación no lo ve. Sigue contando como fallo y sigue abriéndose un incidente, con gravedad degradado.
Un cortafuegos no es una caída
Un sitio bloqueado en una ubicación falla todas las comprobaciones desde allí mientras funciona en todas partes. Contar eso como tiempo caído convertiría su cifra de disponibilidad en una afirmación sobre nuestro enrutado y no sobre su servicio.
Por eso una región que nunca ha alcanzado un monitor queda excluida de él tras tres fallos. Una región que antes lo alcanzaba y ya no, sigue contando para siempre, porque desde allí es una caída de verdad y ocultarla sería peor.
Si el mundo ha cambiado alrededor de un sitio — un bloqueo gubernamental, una ruta perdida, un filtro geográfico añadido después —, puede recalibrar un monitor desde su página. Eso descarta el historial de todas las regiones para ese único monitor, de modo que el comportamiento actual pasa a ser la nueva referencia. Es por monitor y a propósito, porque la medición por sí sola no distingue un bloqueo permanente de una caída permanente.
Dónde se ejecutan las comprobaciones y qué enviamos allí
Algunos puntos de observación están fuera del EEE. Una comprobación cuya configuración pudiera contener datos personales — una cabecera, un cuerpo de petición — solo se ejecuta desde dentro. Lo impone el planificador y no una política, y se prueba contra una base de datos real en cada build. snmp y smpp y los cinco tipos de base de datos están confinados igual, porque en todos ellos la credencial es el protocolo.
Sin probar no es aprobado
En tls_audit, cada prueba tiene tres resultados y no dos: admitido, rechazado o sin probar. El OpenSSL 3 de Node no compila ni RC4 ni 3DES, así que esas dos familias no pueden ofrecerse nunca desde nuestra flota — y el silencio bajo esos epígrafes se leería como «lo miramos y están desactivados», que es un visto bueno falso justo sobre los hallazgos por los que se abre una auditoría TLS.
Dependencias
Dígale a un monitor de qué depende — una base de datos, una pasarela, una API aguas arriba — y cuando la dependencia se caiga, lo que hay detrás se marca como consecuencia en lugar de abrir incidentes propios. Un incidente, no cuarenta, y la página nombra la causa y no los síntomas.
Ventanas de mantenimiento
Programe una ventana y, mientras esté abierta, no se avisa a nadie. Úselo para un despliegue que sabe que va a dejar la cosa fuera de servicio. Por omisión las comprobaciones se siguen ejecutando y registrando, así que esos minutos cuentan para la disponibilidad como cualquier otro: la ventana quita el aviso, no el historial. Desactive «seguir comprobando» y no se comprueba nada mientras la ventana está abierta, lo que deja un hueco en el historial en lugar de un bajón. Una ventana puede repetirse a diario, cada semana o cada mes, y cada repetición retiene los avisos, no solo la primera.
Pausar
Un monitor en pausa no se comprueba y no cuenta contra nada. Conserva su historial, así que pausar y reanudar no pierde el registro.