Service de surveillance des pannes pour DownDetector

• Service web qui vérifie en temps réel l’état de fonctionnement du site DownDetector depuis plusieurs régions
• Mesure du code de réponse HTTP et de la latence depuis 3 serveurs régionaux à Londres, Auckland et New York
• Le site renvoie le code HTTP 200 (réponse normale) dans toutes les régions, ce qui indique qu’il fonctionne normalement
• La latence moyenne selon les régions est affichée dans une plage de 478 à 586 ms
• Peut être utilisé comme outil de vérification de la fiabilité des principales plateformes de surveillance des pannes

---

Résultats de vérification par région

• Dans la région de Londres, Royaume-Uni, l’état est Up, le code HTTP est 200 et la latence est de 547 ms
• Dans la région d’Auckland, Nouvelle-Zélande, l’état est Up, le code HTTP est 200 et la latence est de 478 ms
• Dans la région de New York, États-Unis, l’état est Up, le code HTTP est 200 et la latence est de 586 ms
• Les mêmes résultats se répètent dans toutes les régions, confirmant que le service DownDetector fonctionne normalement

Aperçu du service

• Ce site est une page de monitoring dédiée à la surveillance de l’état de DownDetector
• Il mesure et affiche périodiquement, pour chaque région, le code de réponse HTTP et la latence
• Il fournit un indicateur de référence pour vérifier la disponibilité de la plateforme de surveillance des pannes elle-même
• Aucune information supplémentaire dans le texte source

[GN⁺]

Commentaires Hacker News

• En tant que développeur solo basé en Europe, il a migré toute son infrastructure vers des services européens depuis le début de l’année
  Bunny.net à la place de Cloudflare, Hetzner à la place d’AWS, et Infomaniak pour les e-mails professionnels
  Jusqu’à présent, pas une seule panne, et la sensation d’être complètement détaché des services américains lui plaît vraiment

  • Ces services sont plus petits, mais justement pour cette raison, ils sont beaucoup plus engagés sur la fiabilité
    Dans les grandes entreprises, on entend souvent « si on avait utilisé AWS, ça ne serait pas arrivé ». Un peu comme IBM autrefois
    Hetzner propose un ensemble de services bien plus simple qu’AWS, donc avec moins de complexité
    Cela dit, la notoriété de la marque et l’aspect « est-ce que ça fait professionnel ? » restent des facteurs culturels importants
  • Ce n’est pas qu’AWS ou Cloudflare tombent réellement plus souvent en panne. C’est juste qu’ils ont tellement d’utilisateurs que les incidents sont davantage médiatisés
    Chacun est libre de choisir son infrastructure, mais la perception de la disponibilité peut différer de la réalité
  • En début d’année, un serveur Hetzner qu’il gérait a redémarré sans raison apparente
    Il y avait bien une annonce de maintenance, mais ce serveur ne figurait pas dans la liste des systèmes concernés
    Ce n’est pas pour dire que Hetzner est mauvais, simplement qu’en Europe aussi, ce genre de petits incidents arrive
  • Il apprécie beaucoup Bunny.net, mais Cloudflare est très fort sur les fonctions de « défense intelligente », comme le filtrage des scrapers IA et du trafic malveillant
    Il se demande si Bunny.net peut vraiment remplacer Cloudflare sur ce point aussi
  • Il aimerait comparer Infomaniak et Proton. Infomaniak semble offrir davantage d’outils de productivité bureautique, mais il se demande ce que valent la messagerie et le drive

• Lors de la panne de Cloudflare hier, Downdetector est tombé en panne lui aussi, ce qui a bien fait rire tout le monde. Le timing était parfait

  • Quelqu’un a raconté qu’à l’époque où il travaillait dans une entreprise de CDN, leur fournisseur de page d’état était devenu leur client, ce qui les avait forcés à changer de page d’état

• Il y avait une blague du type : « Trois Down Detector entrent dans un bar »
  Le premier répond « Je ne sais pas », le deuxième aussi, et le troisième répond « Oui »

  • Quelqu’un a réagi en disant que c’étaient sans doute des Down Detectors aveugles
  • Un autre a dit que c’était tellement drôle qu’il allait absolument la lui voler

• Un autre a dit « ça, c’est de l’or pur », avant d’enchaîner avec la blague méta : « alors qui surveille le Down Detector qui surveille le Down Detector qui surveille le Down Detector ? »

  • La page de surveillance de Downdetector sur isitdownrightnow.com a été partagée
  • Quelqu’un a aussi répondu : « Celui qui est en train d’y accéder, c’est toi ! »
  • Plus sérieusement, faire se surveiller mutuellement plusieurs Down Detectors ayant des zones de disponibilité et des bases de code différentes est une approche assez pratique
  • Certains ont dit qu’on pourrait en faire une idée de Down Detector distribué et la publier comme projet sur HN
  • Une autre proposition était de créer un méta Down Detector chargé de surveiller lequel des trois est en panne

• En réalité, Downdetector lui-même n’était pas complètement hors service : c’est le module de vérification humaine de Cloudflare qui posait problème
  Techniquement, le site était donc « en état de marche », mais dans les faits il était inutilisable

• Il y avait aussi la blague selon laquelle « il faut un autre Down Detector pour vérifier si ton Down Detector est bien vivant »
  Certains parlaient d’une structure de type Downdetectorsdown qui se prolonge à l’infini

  • Le lien downdetectorsdowndetectorsdowndetector.com a été partagé
  • L’idée a aussi été avancée que, s’il y en a plusieurs, une partie sera toujours en panne, donc il serait utile d’avoir un site qui suit cette proportion
  • Au fond, c’est une question de centralisation vs décentralisation vs systèmes distribués
    Si les Down Detectors se surveillent mutuellement par heartbeat, on peut concevoir une architecture où le système global reste vivant même si certains nœuds tombent
    Avec une architecture auto-réparatrice, le réseau deviendrait bien plus résilient
  • La formule « les Down Detectors s’enchaînent à l’infini » a aussi été répétée
  • Quelqu’un a même plaisanté sur une structure en liste chaînée, décrite comme le « N-ième Down Detector »

• Il y avait aussi un commentaire façon mème : « Sup dawg, I heard you like down detectors »

• La page d’état de Downdetector a été partagée directement

• Quelqu’un a lancé le défi de créer un nouveau CDN capable d’absorber la charge provoquée quand une panne de Cloudflare fait tomber Downdetector, ce qui reporte ensuite de la charge sur CloudFront

  • Mais quelqu’un d’autre a réagi de façon plus pragmatique : « pour du HTML statique sans images, est-ce qu’un CDN est vraiment nécessaire ? »

• Une question a été posée : comment Downdetector détecte-t-il qu’un service est en état normal ?
  Pendant la panne de Cloudflare, la page d’index renvoyait peut-être quand même un code 200
  Et si on essayait de vérifier avec un navigateur headless en prenant une capture d’écran, Cloudflare risquerait probablement de le bloquer

  • En réalité, le site génère de fausses données
    Dans script.js, fetchStatus() appelle generateMockStatus() pour créer des temps de réponse aléatoires
    Autrement dit, il ne vérifie pas le véritable état du service, il affiche simplement des données d’état simulées