Est-ce en panne, ou est-ce seulement vous ?

Le problème du « chez moi ça marche »

Chaque canal d’incidents a entendu les deux phrases dans la même heure : « le site est en panne » et « chez moi ça marche ». Les deux peuvent être des rapports honnêtes. Un test exécuté depuis un seul point de vue — votre portable, votre bureau, une machine de supervision — mesure exactement une chose : l’expérience de ce seul réseau, sur ce seul chemin, à ce seul moment. Il ne peut pas distinguer un service en panne pour tout le monde d’un chemin cassé seulement pour vous : un fournisseur de transit malade, une règle de filtrage régionale, un résolveur DNS qui renvoie des réponses empoisonnées ou périmées, un différend de peering à trois réseaux de distance dont vous n’avez jamais entendu parler. Vue de l’intérieur du point de vue unique, tout cela a exactement la même apparence — une panne sans adresse de retour.

Les tickets de support et les pages de statut souffrent de la même géométrie. Une page de statut dit « opérationnel » parce que les sondes du fournisseur lui-même — assises dans le propre quartier du fournisseur — atteignent le service sans peine, pendant qu’une région entière ne le peut pas. Un utilisateur signale « en panne » parce que son FAI avale le trafic dans un trou noir, pendant que le service ronronne. Aucun des deux camps ne ment ; tous deux généralisent depuis une seule chaise. La correction n’est pas plus de précision depuis la même chaise. Ce sont plus de chaises.

Ce qu’un second point de vue prouve

Ajoutez des sondes sur d’autres réseaux — d’autres systèmes autonomes, d’autres pays, d’autres types de connexion — et exécutez le test identique depuis toutes en même temps. Désormais, c’est le motif qui argumente. Si des sondes sur cinq réseaux répartis sur trois continents échouent toutes de la même manière au même moment, le facteur commun est la cible : le service, son hôte ou son propre réseau est en panne, et aucune quantité de bricolage local ne changera cela. Si quatre réussissent et que seule la sonde la plus proche de votre situation échoue — ou que seul vous échouez — le facteur commun s’inverse : la cible est debout, et la cassure se trouve quelque part sur le chemin que les points de vue en échec partagent. L’accord entre points de vue indépendants est ce qui se rapproche le plus d’une preuve pour la question « est-ce en panne ? ».

Les sondes qu’utilise ce site appartiennent au réseau Globalping, exploité par jsDelivr : des milliers de petites sondes logicielles hébergées par des bénévoles dans le monde entier, sur tout, des serveurs de centres de données aux connexions domestiques, qui acceptent des mesures standardisées — ping, traceroute, MTR, DNS et HTTP — et rapportent ce qu’elles ont vu. La valeur n’est aucune sonde individuelle ; une machine bénévole dans une ville est une anecdote. La valeur est que les anecdotes sont indépendantes : réseaux différents, upstreams différents, modes de panne différents, tous répondant à la même question au même moment.

L’avertissement anycast et CDN

Voici le piège, et tout le monde y tombe une fois : des réponses différentes venues d’endroits différents peuvent être toutes correctes. Les services modernes ne sont pas une machine en un lieu. Anycast annonce la même adresse depuis de nombreux endroits, si bien qu’une sonde à Francfort et une sonde à São Paulo qui envoient des paquets à « la même » IP parlent à des bords physiques différents, possiblement sur des continents d’infrastructure différents — l’un sain, l’autre en redémarrage. Un CDN oriente chaque client vers un bord proche, et un bord peut être en panne dans une région pendant que le service est impeccable ailleurs. La divergence entre sondes n’est pas automatiquement une contradiction ; pour une cible anycast, la divergence est la conception qui fonctionne comme prévu, et la question devient « en panne où ? » plutôt que « en panne ? ».

Le DNS fait le même point par l’autre côté. Les serveurs faisant autorité et les résolveurs livrent des réponses différentes par conception — GeoDNS renvoie l’adresse du bord « le plus proche », et EDNS Client Subnet permet à un résolveur de demander au nom de votre quartier, si bien que le résolveur d’une sonde à Tokyo et celui d’une au Texas reçoivent légitimement des adresses différentes pour le même nom (comparez-les côte à côte avec le vérificateur de propagation DNS quand la question est de savoir quels enregistrements le monde détient). Des adresses différentes depuis des sondes différentes ne sont pas une preuve d’incohérence. Elles sont la preuve que le nom fait de la localisation — et elles vous disent quel bord les utilisateurs de chaque région rencontreront réellement.

Choisissez la mesure qui répond à la question

Le ping global offre cinq types de mesure, et bien choisir compte plus qu’en exécuter beaucoup. Chacun répond à une question différente, et exécuter le mauvais produit une réponse pleine d’assurance à quelque chose que vous n’avez pas demandé. Associez le type au symptôme avant de regarder les résultats de quiconque.

Ping répond à la question la plus étroite : la cible est-elle joignable d’ici, et combien se perd en route ? C’est le bon test pour « ce réseau peut-il voir cette machine tout court ? », et le mauvais test pour tout ce qui concerne l’application — une machine peut répondre au ping pendant que son service web est mort. HTTP répond à la question de l’utilisateur : une vraie requête réussit-elle depuis là-bas, avec quel code de statut, et combien de temps le tout a-t-il pris ? Quand la dispute est « le site marche / le site ne marche pas », HTTP depuis plusieurs sondes est la preuve que les deux camps devraient accepter. DNS répond à la question du nom : quelles adresses chaque région reçoit-elle réellement pour ce nom ? C’est ainsi que vous séparez « le service est en panne » de « ma région est envoyée vers le bord mort ».

Traceroute répond à la question du où : saut par saut, où le chemin de cette sonde vers la cible s’arrête-t-il, se bloque-t-il, ou dévie-t-il vers un endroit inattendu ? Exécutez-le depuis le point de vue qui échoue, pas depuis un qui marche. MTR est traceroute dans le temps — le même chemin sondé de façon répétée, de sorte que la perte et le délai se montrent par saut sous forme de taux plutôt que d’un unique échantillon figé ; c’est l’outil pour « ça casse par intermittence », là où un seul traceroute attrape le chemin un jour de bon comportement. La discipline sur les cinq : décidez quelle panne vous testez, choisissez la seule mesure qui peut la voir, et laissez les autres attendre.

Lire les résultats sans vous tromper vous-même

Commencez par séparer les deux nombres que l’on fusionne par habitude. La perte — les requêtes qui ne sont jamais revenues — est un dommage ; la latence — les requêtes revenues lentement — est un inconfort, et les deux ont des causes et des corrections différentes. Une sonde affichant 100 % de perte a trouvé un mur ; une sonde affichant zéro perte et une latence élevée a trouvé une route longue ou congestionnée, et rapporter la seconde comme « en panne » est la façon dont les services sains se font réveiller en pleine nuit. Puis comparez ce qui est comparable : prenez la sonde médiane comme histoire, ni la meilleure ni la pire. Une sonde qui renvoie une valeur aberrante sauvage — une latence énorme, un délai dépassé que personne d’autre n’a vu — est une affirmation sur le moment de cette sonde, son hôte ou son upstream. Elle ne devient une preuve sur la cible que lorsque des sondes indépendantes sont d’accord avec elle.

Surveillez aussi la comptabilité. Une sonde qui signale la cible « hors ligne » pendant que ses voisines réussissent s’est très probablement signalée elle-même — une sonde plantée, une connexion domestique qui a lâché, un filtre local — et les sondes bénévoles ont tout cela ; c’est le prix d’un réseau que personne n’exploite centralement. Notez les horodatages et traitez les résultats périmés ou mis en cache comme de l’histoire, pas comme des nouvelles. Et quand chaque sonde s’accorde sur le fait que la cible est debout mais que vos utilisateurs ne peuvent toujours pas l’atteindre, croyez les deux : vous avez appris que la panne est réelle et étroite — elle habite un chemin qu’aucune de vos sondes ne partageait par hasard, ce qui est une découverte, pas une contradiction.

Limites honnêtes

Les sondes sont bénévoles, et le réseau se comporte comme tel. Les sondes vont et viennent — un emplacement disponible ce matin peut être hors ligne ce soir, la couverture est dense dans certains pays et mince jusqu’à inexistante dans d’autres, et vous ne pouvez pas exiger une sonde à l’intérieur d’un FAI précis au seul motif que vos utilisateurs y sont. Les sondes siègent aussi pour la plupart dans des centres de données et sur des connexions d’amateurs, pas sur les réseaux résidentiels et mobiles depuis lesquels vos vrais utilisateurs naviguent ; une sonde de centre de données prouve que le service est joignable depuis des endroits bien connectés, ce qui est la majeure partie de la question, mais pas sa totalité. Traitez la carte comme un échantillon des réseaux du monde, généreusement dessiné — pas comme le monde.

L’usage que ce site fait du réseau est délibérément modeste : il fonctionne sur le niveau gratuit anonyme et partagé de Globalping, de sorte que les vérifications comportent des limites par visiteur et que les résultats sont brièvement mis en cache au lieu de marteler une ressource bénévole — si une vérification vous demande d’attendre, c’est le niveau partagé qui est partagé. Dans ces limites, le schéma de travail est : exécutez ici la vérification multi-points de vue pour trancher « en panne ou seulement moi ? », puis creusez du côté du gagnant — la vérification de santé de site web pour tout ce qu’un seul regard détaillé sur le site peut vous dire, et une nouvelle tournée depuis le ping global une fois que vous avez changé quelque chose. En-panne-pour-tout-le-monde et en-panne-juste-pour-vous demandent des après-midi différents ; dix minutes des points de vue des autres sont la façon de découvrir quel après-midi vous êtes en train de vivre.

Questions fréquentes