Check traceroute

Ce qu’il vérifie

Un monitor traceroute exécute le traceroute du système vers l’hôte depuis chacune de ses régions, à chaque intervalle. Il envoie une sonde par saut avec 2 s d’attente et suit jusqu’à 20 sauts par défaut. Le résultat contient le nombre de sauts et la dernière ligne, et la cible compte comme atteinte quand ce dernier saut a répondu. Le type ne mesure aucun temps de réponse et ne rend aucun verdict de disponibilité. Une cible non atteinte donne un état dégradé, pas une panne, et n’ouvre jamais d’incident.

À utiliser quand

• Un check ping ou HTTP(S) à côté échoue, et vous voulez consigner par région si le chemin atteignait encore la cible à ce moment-là.
• Un hôte répond depuis certaines régions mais pas depuis d’autres, et vous voulez consigner le nombre de sauts et le dernier saut de chaque région.
• Le nombre de sauts et la ligne du dernier saut doivent être journalisés à chaque check, par région, pour qu’un changement de routage ait un horodatage.

Un résultat de traceroute n’est pas un verdict de disponibilité. Une cible qui filtre le dernier saut donne dégradé, jamais en panne, et un chemin non abouti n’ouvre aucun incident. Pour la joignabilité, utilisez le check ping, et pour une réponse de service, le check HTTP(S) ou TCP.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Configuration

Cible. Un nom d’hôte ou une adresse IP, sans port. Le nœud résout la première adresse de la famille choisie par son propre résolveur et la valide. Les adresses de boucle locale, privées, link-local et de métadonnées cloud sont refusées, le monitor ne peut donc pas être pointé vers un réseau interne.

Familles IP

La route est tracée par famille IP, une adresse chacune, et chaque famille devient son propre sous-résultat. Une famille dont l’adresse ne se résout pas ou est bloquée échoue. Une telle famille sur deux est jugée par family_fail_severity, et deux familles dans ce cas font échouer le check. Une famille qui se résout mais n’atteint pas la cible est dégradée, et le check retient le pire des deux. Le formulaire ne propose IPv6 que si l’hôte a un enregistrement AAAA ou est un littéral IPv6, et seules les régions qui sondent IPv6 restent alors sélectionnables.

Déroulement d’un check

1. Chaque région dont l’intervalle est échu résout l’hôte par le résolveur du nœud. Elle prend la première adresse de la famille choisie et la valide contre les plages bloquées.
2. Le nœud exécute le traceroute du système vers l’hôte, épinglé à cette famille. Il utilise la sortie numérique, une sonde et 2 s d’attente par saut, et max_hops sauts au plus. L’exécution entière peut durer jusqu’à 20 s, la plus grande valeur entre 20 s et la limite de 10 s du monitor.
3. La sortie est lue : la ligne d’en-tête est écartée, les lignes de sauts sont comptées et la dernière ligne est conservée.
4. La cible compte comme atteinte quand la dernière ligne ne porte pas de *, c’est-à-dire quand le dernier saut a répondu. Sinon, ou quand aucune ligne de saut n’est revenue, le résultat est dégradé.
5. Le résultat de la région part au plan de contrôle. La politique d’alerte décide ensuite, selon son quorum, si une résolution en échec ou une cible bloquée devient un incident. Un chemin dégradé n’en ouvre pas.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Ce que contient un résultat

Nombre de sauts

Combien de lignes de sauts l’exécution a produites, par région et par famille.

Dernier saut

La dernière ligne de la sortie de traceroute, telle quelle. C’est le saut de la cible quand celle-ci a été atteinte, ou une ligne * quand le dernier saut est resté muet.

Ligne de détail

Une ligne par check qui porte le nombre de sauts et le dernier saut.

Atteinte ou non

Si le dernier saut a répondu. C’est ce qui départage ok et dégradé.

Région et famille

Chaque résultat porte la région qui l’a mesuré et un sous-résultat par famille IP. Il n’y a pas de sous-résultat par adresse ni par saut, et la liste complète des sauts n’est pas conservée.

Temps de réponse et code de statut

Le type n’enregistre ni l’un ni l’autre, le graphique des temps de réponse dans la vue du monitor reste donc vide.

États et gravité

• okLe dernier saut a répondu : la cible a été atteinte en max_hops sauts au plus.
• dégradéLa cible n’a pas été atteinte, parce que la dernière ligne porte un *, ou l’exécution n’a renvoyé aucune ligne de saut. À la gravité par défaut, une famille IP qui ne se résout pas pendant que l’autre trace rend aussi le check dégradé.
• en panneL’hôte ne se résout pas ou se résout en adresse bloquée. Avec les deux familles et family_fail_severity réglé sur failed, une famille qui ne se résout pas met aussi le check en panne. Le chemin lui-même ne produit jamais cet état.
• erreurLe nœud ne peut pas exécuter le check, parce que le binaire traceroute manque ou que l’exécution a dépassé son plafond de 20 s. L’état compte comme une panne de gravité critique.

Confirmé par quorum : par défaut, 2 régions doivent signaler l’échec avant l’ouverture d’un incident. Par défaut, l’organisation exige 2 régions et 2 checks consécutifs. Un monitor peut porter sa propre règle (nombre ou pourcentage, checks consécutifs, durée minimale). Seuls les états en panne et erreur entrent dans l’évaluation des incidents, un chemin non abouti reste donc dégradé et n’ouvre jamais d’incident par lui-même.

Offres et limites

Intervalle minimal

300 s en Free, 60 s en Pulse et 30 s en Sentinel. Command permet 15 s et Enterprise 10 s, dans les deux cas uniquement par MCP. Le formulaire propose des préréglages de 30 s à 1 h.

Régions

2 sur 6 en Free, 3 sur 6 en Pulse et les 6 à partir de Sentinel.

Monitors

10 en Free, 50 en Pulse, 150 en Sentinel et 500 en Command. Les quotas Enterprise sont sur mesure. Le quota se compte sur l’ensemble des onze types de sonde, et les monitors agent et heartbeat ont leurs propres quotas.

Comparer toutes les limites

Depuis le pipeline ou un agent

La même config fonctionne dans l’étape de déploiement, dans un client MCP comme Claude Code et dans le formulaire ci-dessus. create_monitor exige une clé API valable pour toute l’organisation. Si vous omettez regions, l’offre applique sa valeur par défaut.

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

Chaque interface, avec sa limite

Limites

• Le check sert au diagnostic et ne donne pas de signal de disponibilité : une cible non atteinte est dégradée et n’ouvre aucun incident. L’exécution elle-même ne cause une panne que si traceroute ne peut pas démarrer ou dépasse le plafond de 20 s. Associez-le au check ping ou HTTP(S).
• Chaque saut reçoit une sonde avec 2 s d’attente, et le défaut est de 20 sauts. Toute l’exécution est plafonnée à 20 s.
• max_hops se règle par l’API ou MCP, pas dans le formulaire.
• Le check trace une adresse par famille, sans sous-résultats par adresse ni par saut. Au-delà du nombre de sauts et de la dernière ligne, la liste des sauts n’est pas conservée.
• Le check n’enregistre aucun temps de réponse ni code de statut.
• Les cibles sur des adresses privées, de boucle locale, link-local et de métadonnées cloud sont refusées.
• Toutes les régions ne sondent pas IPv6, sélectionner ipv6 restreint donc les régions utilisables.

Types de checks liés

• Check pingJoignabilité d’un hôte par echo ICMP : réponses, pertes et aller-retour moyen depuis chaque région.
• Check HTTP(S)Disponibilité et réponse d’une URL, avec des assertions sur le statut, le corps et TLS.
• Check de port TCPUn port accepte ou non les connexions, avec en option le certificat qu’il sert.

Tous les types de checks