Herramienta de monitorización de API: uptime, tiempo de respuesta y validación desde 300+ ubicaciones

El monitoreo de API REST se parece superficialmente al monitoreo de uptime y es un trabajo distinto. Una API la consume código, no personas, y el código es implacable de formas en que un navegador no lo es. Un visitante humano tolera una página que se renderiza ligeramente mal; una integración que recibe un campo del tipo equivocado simplemente se rompe. Así que el monitoreo de API tiene que verificar más capas que "¿respondió el servidor?", y HostTracker las verifica en orden, fallando en la primera que no se cumple.

Las capas uno a tres son lo que te da una comprobación de uptime común. La cuatro y la cinco son lo que convierte esto en monitoreo de API - y son las capas donde realmente viven la mayoría de los incidentes reales de API.

Antes de que se pueda validar nada, el monitor tiene que hacer la solicitud que tu API espera. La superficie completa de solicitud está disponible en un monitor de API:

La forma más expresiva de validar una respuesta es escribirle reglas. Cada regla es una línea, las reglas se combinan con AND, y un monitor puede llevar hasta veinte de ellas. Este es el paquete inicial verificado para una API JSON:

status isOk
header("Content-Type") contains "json"
body.json.path("$.count") gt 0
time lt 5s

Cuatro líneas, y entre ellas cubren las cuatro capas que importan: el endpoint respondió con un 2xx, respondió con JSON en lugar de una página de error, el payload contiene un resultado real en lugar de uno vacío, y lo hizo todo dentro del presupuesto. Reglas individuales útiles del mismo catálogo incluyen body.json.path("$.status") eq "ok" para el propio veredicto de salud de una API, body.json.path("$.error") absent para un miembro de error que aparece en una respuesta por lo demás exitosa, body.json.path("$.version") eq "2.4.1" para detectar un retroceso no intencionado, redirects.count eq 0 para un endpoint que debe responder directamente, y cert.days.left gt 14 para el certificado de la misma conexión.

De qué puede hablar una regla

Las reglas leen sujetos de la respuesta y los comparan. Los sujetos cubren el código de estado; el tiempo de respuesta total y sus componentes de conexión, TLS, DNS, cabeceras y cuerpo; el cuerpo sin procesar junto con su tamaño y un hash del mismo; consultas estructuradas dentro del payload como JSON, XML, HTML o YAML; cabeceras de respuesta individuales; la URL final y la original y sus partes; la cadena de redirecciones, salto por salto; los días restantes, el emisor y los nombres del certificado; el protocolo y el cifrado TLS negociados; las direcciones que devolvió el DNS; y Set-Cookie. Las comparaciones van desde lo obvio - igual, menor que, mayor que - hasta contains, startsWith, endsWith, matches para una expresión regular, containsAny y containsAll para un conjunto, in para una lista de valores aceptables, y exists, isNumber y unique.

También hay un eje de detección de cambios: una regla puede comparar el valor de esta ejecución con el de la anterior, así que puedes verificar que un contador nunca retrocede o que un hash del cuerpo no ha cambiado - la forma de regla que detecta un retroceso silencioso o un cambio de contenido no autorizado en lugar de una caída.

Junto al lenguaje de reglas hay un camino más simple, de un solo valor, que ha formado parte del monitoreo de API aquí desde hace mucho tiempo y a menudo es todo lo que necesita una comprobación. Le dices al monitor cómo interpretar el cuerpo, cómo seleccionar un valor de él, y qué debe ser ese valor:

• Interpretar como JSON, y el selector es una expresión JSONPath.
• Interpretar como XML, y el selector es una expresión XPath - lo que hace que SOAP y otros servicios XML sean sencillos de verificar.
• Tratarlo como texto plano, y el selector es una expresión regular multilínea que no distingue mayúsculas de minúsculas.

El predicado aplicado al valor seleccionado cubre igual y distinto, menor-que y mayor-que en sus formas estricta e inclusiva, pertenencia a una lista de valores aceptables o exclusión de ella, dentro de un rango numérico o fuera de él, y una prueba de que el valor sea nulo o esté ausente por completo.

Cada fallo en esta tabla devuelve HTTP 200. Ese es todo el problema de monitorear una API solo por su código de estado: el transporte tuvo éxito, así que el transporte reporta éxito.

Esa última fila vale la pena hacerla de forma deliberada. Un segundo monitor que no envía credenciales y verifica un 401 es la forma más barata de descubrir que una capa de autorización se desactivó por accidente - un fallo que ninguna cantidad de pruebas positivas hará salir a la superficie jamás.

Los monitores de API se ejecutan desde la flota pública de puntos de verificación de HostTracker - más de 300 puntos de verificación en 158 ciudades -, y tú eliges qué ubicaciones usa un monitor determinado. La geografía importa más para una API que para un sitio web: un endpoint servido por una CDN o un balanceador de carga geo-enrutado puede estar saludable en Fráncfort y fallando en São Paulo, y una comprobación de una sola ubicación no tiene forma de verlo. Lo mismo ocurre con el DNS - un registro obsoleto o mal configurado a menudo se propaga de forma desigual, lo que se ve como una caída intermitente desde dentro y como una caída regional desde fuera.

Ejecutarse desde muchos lugares plantea un riesgo obvio: más puntos de verificación, más oportunidades de que una ruta de red inestable dé falsas alarmas. HostTracker maneja eso con un quórum de confirmación. Cuando un punto de verificación reporta un fallo, la comprobación se repite en puntos de verificación independientes adicionales y el cambio de estado solo se confirma una vez que están de acuerdo - por defecto un veredicto por mayoría entre hasta siete agentes, con un mínimo de tres. Puedes hacerlo más estricto, exigiendo un número determinado de agentes que reporten el fallo o el acuerdo total entre ellos, para un endpoint donde una falsa alarma es peor que una lenta.

Tras la confirmación, la alerta sigue el retraso que cada contacto eligió - inmediatamente, o después de 3, 5, 15, 30 o 60 minutos, o de 3, 6, 12 o 24 horas de fallo continuo - a través de los nueve canales de notificación: correo electrónico, SMS, llamada de voz, webhook, Slack y las apps de mensajería Telegram, Discord, Viber, Facebook Messenger y Google Chat. El canal de webhook es la forma en que las alertas llegan a un gestor de incidentes o a una herramienta de chat de equipo.

La comprobación es una solicitud HTTP configurable más un análisis de la respuesta, así que lo que encaja se deriva directamente de eso.

• REST y APIs JSON son el caso cotidiano, y el monitoreo de API REST es lo que configura primero la mayoría de las cuentas: un GET o POST, cabeceras para la credencial, y reglas JSONPath o de aserción sobre el payload.
• GraphQL funciona como un POST con la consulta en el cuerpo, y luego JSONPath dentro de data - y vale la pena verificar que el miembro errors esté ausente, ya que GraphQL es famoso por responder 200 con errores dentro.
• SOAP y servicios XML son un POST con el envelope como cuerpo y XPath como selector, lo que llega a la respuesta exactamente como pretende la especificación.
• Receptores de webhook y endpoints de callback pueden verificarse por accesibilidad y por la respuesta que dan a una solicitud bien formada - valioso, porque un receptor que silenciosamente dejó de aceptar entregas no produce ningún error en ningún lugar de tu propio sistema.
• Los endpoints de health y readiness son el objetivo de mayor valor de todos si los tienes: tu aplicación ya sabe si sus dependencias están saludables, y una aserción sobre ese veredicto convierte su propio conocimiento en una alerta.

Lo que no encaja es una secuencia - obtener un token, usarlo, luego eliminar el recurso. Un monitor de API hace una solicitud por ejecución. Para un recorrido genuino de varios pasos, la verificación de transacción impulsada por navegador es la herramienta; para el tiempo de una página en lugar de un endpoint, mira el monitoreo de tiempos de carga en navegador.

1. Prueba primero el endpoint con la verificación HTTP instantánea gratuita - sin necesidad de iniciar sesión - para que puedas ver el estado, los tiempos y la respuesta contra los que estás a punto de escribir reglas.
2. Añade un monitor y elige el tipo de monitoreo de API. Define el método, y añade las cabeceras o el cuerpo que necesite el endpoint; emite al monitor su propia credencial en lugar de reutilizar la de una persona.
3. Escribe las aserciones. Empieza con el paquete de cuatro líneas de arriba - estado, tipo de contenido, un valor significativo del payload y un presupuesto de tiempo de respuesta -, que es un valor por defecto genuinamente bueno para casi cualquier API JSON.
4. Elige un intervalo entre un minuto y 24 horas. Tres minutos es el valor por defecto y un buen punto de partida; reserva un minuto para los endpoints cuya caída sería un incidente.
5. Elige las ubicaciones. Dos o tres regiones donde realmente viven tus consumidores superan a una sola, y es lo que hace visible un fallo regional.
6. Añade los contactos, y define el retraso de alerta de cada uno. No todos necesitan enterarse en el primer minuto.
7. Déjalo correr un día, y luego mira el historial de tiempos de respuesta antes de ajustar la regla de tiempo. Un presupuesto definido con datos reales se sostiene; uno definido a partir de una suposición termina silenciado.

Son complementarios y con frecuencia se confunden. Una plataforma de observabilidad o APM instrumenta tu código y te dice qué pasó dentro de una solicitud. El monitoreo de API externo se mantiene fuera de tu infraestructura y te dice qué recibe realmente un consumidor. Vale la pena tener ambos; ninguno sustituye al otro.

El patrón en el que se asientan la mayoría de los equipos es monitoreo externo para la detección y telemetría interna para el diagnóstico: HostTracker te dice que un endpoint se rompió, desde dónde y contra qué regla, y tu propio trazado te dice por qué. Junto a él, un monitor de consultas de base de datos a menudo explica una API que se volvió lenta, y el monitoreo de carga de servidor explica el host sobre el que corre.

• Una solicitud por ejecución. Sin intercambio de tokens, sin llamadas encadenadas. Apunta el monitor a un endpoint cuya autenticación no caduque, y usa una verificación de transacción cuando lo que necesitas demostrar es una secuencia.
• Veinte reglas de aserción por monitor. Amplio en la práctica - el paquete de cuatro líneas cubre la mayoría de los endpoints -, pero vale la pena saberlo antes de planear una prueba de contrato de cien reglas.
• El modo de aserción reemplaza los antiguos ajustes de palabra clave y estado. Los dos modelos no pueden combinarse en un mismo monitor; elige el lenguaje de reglas o el modo de palabra clave heredado, no ambos.
• Sin validación de OpenAPI ni de esquema JSON. Verificas valores y estructuras específicas, no un documento de esquema completo.
• El cuerpo de la solicitud tiene un límite de longitud, así que un payload POST muy grande no es la forma para la que está construida esta comprobación.
• Es monitoreo, no pruebas. El objetivo correcto es un endpoint de solo lectura o idempotente. Un monitor que modifica datos cada tres minutos desde varias ubicaciones eventualmente será la causa de un incidente en lugar de lo que lo detecta.