Check traceroute

Qué verifica

Un monitor traceroute ejecuta el traceroute del sistema contra el host desde cada una de sus regiones en cada intervalo. Envía una sonda por salto con 2 s de espera y sigue hasta 20 saltos por defecto. El resultado contiene el número de saltos y la última línea, y el objetivo cuenta como alcanzado cuando ese último salto respondió. El tipo no mide tiempo de respuesta ni emite un veredicto de disponibilidad. Un objetivo no alcanzado queda degradado, no caído, y nunca abre un incidente.

Úsalo cuando

• Falla un check ping o HTTP(S) que lo acompaña, y quieres que conste por región si en ese momento la ruta aún llegaba al objetivo.
• Un host responde desde unas regiones y no desde otras, y quieres que consten el número de saltos y el último salto de cada región.
• El número de saltos y la línea del último salto deben registrarse con cada check, por región, para que un cambio de enrutamiento tenga marca de tiempo.

Un resultado de traceroute no es un veredicto de disponibilidad. Un objetivo que filtra el último salto informa degradado, nunca caído, y una ruta no alcanzada no abre ningún incidente. Para la alcanzabilidad, usa el check ping, y para la respuesta de un servicio, el check HTTP(S) o TCP.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Configuración

Objetivo. Un nombre de host o una dirección IP, sin puerto. El nodo resuelve con su propio resolver la primera dirección de la familia elegida y la valida. Las direcciones de loopback, privadas, link-local y de metadatos de nube se rechazan, así que el monitor no puede apuntar a una red interna.

Familias IP

La ruta se traza por familia IP, con una dirección cada una, y cada familia se convierte en su propio subresultado. Una familia cuya dirección no resuelve o está bloqueada falla. Si le ocurre a una de dos familias, decide family_fail_severity, y si les ocurre a las dos, el check falla. Una familia que resuelve pero no alcanza el objetivo queda degradada, y el check toma el peor de los dos resultados. El formulario ofrece IPv6 solo cuando el host tiene un registro AAAA o es un literal IPv6, y entonces solo quedan seleccionables las regiones que sondean IPv6.

Cómo se ejecuta un check

1. Cada región a la que le toca el intervalo resuelve el host con el resolver propio del nodo. Toma la primera dirección de la familia elegida y la valida contra los rangos bloqueados.
2. El nodo ejecuta el traceroute del sistema contra el host, fijado a esa familia. Usa salida numérica, una sonda y 2 s de espera por salto, y como máximo max_hops saltos. La ejecución completa puede tardar hasta 20 s, el mayor valor entre 20 s y el límite de 10 s del monitor.
3. Se lee la salida: la línea de cabecera se descarta, las líneas de salto se cuentan y la última línea se conserva.
4. El objetivo cuenta como alcanzado cuando la última línea no lleva ningún *, es decir, cuando el salto final respondió. En caso contrario, o si no volvió ninguna línea de salto, el resultado es degradado.
5. El resultado de la región va al control plane. Después, la política de alertas decide por su quórum si una resolución fallida o un objetivo bloqueado se convierte en incidente. Una ruta degradada no abre ninguno.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Qué contiene un resultado

Número de saltos

Cuántas líneas de salto produjo la ejecución, por región y por familia.

Último salto

La última línea de la salida de traceroute, literal. Es el salto del objetivo cuando se alcanzó, o una línea con * cuando el salto final se quedó en silencio.

Línea de detalle

Una línea por check con el número de saltos y el último salto.

Alcanzado o no

Si el salto final respondió. Esto decide entre ok y degradado.

Región y familia

Cada resultado lleva la región que lo midió y un subresultado por familia IP. No hay subresultado por dirección ni por salto, y la lista completa de saltos no se guarda.

Tiempo de respuesta y código de estado

El tipo no registra ninguno de los dos, así que la gráfica de tiempo de respuesta de la vista del monitor queda vacía.

Estados y gravedad

• okEl último salto respondió: el objetivo se alcanzó dentro de max_hops.
• degradadoLa última línea lleva un *, así que no se alcanzó el objetivo, o la ejecución no devolvió líneas de salto. Con la gravedad por defecto, una familia IP que no resuelve mientras la otra traza también deja el check degradado.
• caídoEl host no resuelve o resuelve a una dirección bloqueada. Con las dos familias y family_fail_severity en failed, una familia que no resuelve también deja el check caído. La ruta en sí nunca produce este estado.
• errorEl nodo no puede ejecutar el check porque falta el binario de traceroute o la ejecución superó su tope de 20 s. Cuenta como caída con gravedad critical.

Confirmado por quórum: por defecto, 2 regiones deben informar del fallo antes de que se abra un incidente. El valor por defecto de la organización pide 2 regiones y 2 checks consecutivos. Un monitor puede llevar su propia regla (número o porcentaje, checks consecutivos, duración mínima). Solo caído y error entran en la evaluación de incidentes, así que una ruta no alcanzada se queda en degradado y nunca abre un incidente por sí sola.

Planes y límites

Intervalo mínimo

300 s en Free, 60 s en Pulse y 30 s en Sentinel. Command permite 15 s y Enterprise 10 s, ambos solo por MCP. El formulario ofrece valores predefinidos de 30 s a 1 h.

Regiones

2 de 6 en Free, 3 de 6 en Pulse y las 6 desde Sentinel.

Monitores

10 en Free, 50 en Pulse, 150 en Sentinel y 500 en Command. En Enterprise, los cupos son a medida. El cupo se cuenta entre los once tipos de check de sonda, y los monitores de agente y heartbeat tienen cupos propios.

Comparar todos los límites

Desde la pipeline o un agente

La misma config sirve en el paso de despliegue, en un cliente MCP como Claude Code y en el formulario de arriba. create_monitor necesita una clave de API válida para toda la organización. Si omites regions, el plan aplica su valor por defecto.

{
  "name": "Gateway path",
  "type": "traceroute",
  "interval_seconds": 900,
  "config": {
    "host": "gateway.example.com",
    "max_hops": 30,
    "address_families": ["ipv4", "ipv6"],
    "family_fail_severity": "degraded"
  }
}

Cada interfaz, con su límite

Límites

• El check es de diagnóstico, no una señal de disponibilidad, así que un objetivo no alcanzado queda degradado y no abre ningún incidente. La propia ejecución solo causa una caída cuando traceroute no puede arrancar o supera el tope de 20 s. Combínalo con el check ping o HTTP(S).
• Cada salto recibe una sonda con 2 s de espera, y el valor por defecto es de 20 saltos. La ejecución completa tiene un tope de 20 s.
• max_hops se fija por API o MCP, no en el formulario.
• El check traza una dirección por familia, sin subresultados por dirección ni por salto. Aparte del número de saltos y la última línea, la lista de saltos no se guarda.
• El check no registra tiempo de respuesta ni código de estado.
• Se rechazan los objetivos en direcciones privadas, de loopback, link-local y de metadatos de nube.
• No todas las regiones sondean IPv6, así que seleccionar ipv6 restringe las regiones utilizables.

Tipos de check relacionados

• Check pingAlcanzabilidad de un host por ICMP echo: respuestas, pérdida e ida y vuelta media desde cada región.
• Check HTTP(S)Disponibilidad y respuesta de una URL, con aserciones sobre estado, cuerpo y TLS.
• Check de puerto TCPSi un puerto acepta conexiones, opcionalmente con el certificado que sirve.

Todos los tipos de check