DownDetectorのためのダウン監視サービス

 (downdetectorsdowndetector.com)
1 ポイント 投稿者 GN⁺ 2025-11-20 | 1件のコメント | WhatsAppで共有
  • DownDetectorサイトの稼働状況を複数地域からリアルタイムで点検するウェブサービス
  • ロンドン、オークランド、ニューヨークなど3地域のサーバーでHTTPレスポンスコードと**レイテンシー（latency）**を測定
  • すべての地域でHTTPコード**200（正常応答）**を返しており、サイトは正常に稼働中
  • 地域別の平均レイテンシーは478〜586msの範囲で表示
  • 主要な障害監視プラットフォームの信頼性検証ツールとして活用できる可能性

地域別の点検結果

  • London, UK地域で状態はUp、HTTPコード200、レイテンシー547ms
  • Auckland, NZ地域で状態はUp、HTTPコード200、レイテンシー478ms
  • New York, US地域で状態はUp、HTTPコード200、レイテンシー586ms
  • すべての地域で同じ結果が繰り返し確認され、DownDetectorサービスが正常運用中であることを確認

サービス概要

  • このサイトはDownDetectorの状態を監視する専用モニタリングページ
  • 各地域ごとにHTTPレスポンスコードとレイテンシーを定期的に測定して表示
  • 障害監視プラットフォーム自体の可用性検証のための参考指標を提供
  • 原文に追加情報はなし

関連記事

1件のコメント

 
GN⁺ 2025-11-20
Hacker Newsのコメント

  • ヨーロッパ拠点の個人開発者として、今年初めからすべてのインフラをヨーロッパのサービスへ移行したとのこと
    Cloudflareの代わりにBunny.net、AWSの代わりにHetzner、ビジネスメールはInfomaniakに切り替えた
    これまで一度もダウンタイムはなく、米国のサービスから完全に切り離された感覚がとても良いという

    • これらのサービスは規模は小さいが、小さいからこそ信頼性の確保にずっと真剣だという
      大企業の環境では「AWSを使っていればこんなことはなかったのに」という言葉がよくある。昔のIBMのようなものだ
      HetznerはAWSよりはるかにシンプルなサービス群を提供しているので、複雑さが少ない
      ただし、ブランド認知や「プロフェッショナルに見えるか」といった文化的要因も依然として大きい
    • AWSやCloudflareが実際により頻繁に落ちるわけではない。単に利用者が多いため、問題がより大きく報じられるだけだ
      インフラ選びは自由だが、可用性に対する認識が実態と異なることはあり得る
    • 今年初め、自分が管理していたHetznerサーバーが理由もなく再起動したことがあった
      メンテナンス通知はあったが、そのサーバーは影響対象の一覧に入っていなかった
      Hetznerが悪いという話ではなく、ヨーロッパでもこうした小さな事故は起きる
    • Bunny.netのファンではあるが、CloudflareはAIスクレイパーや悪意あるトラフィックのフィルタリングのような「賢い防御」機能が強い
      Bunny.netがそこまで代替できるかは疑問だ
    • InfomaniakとProtonを比べてみたい。Infomaniakの方がオフィス生産性ツールは多そうだが、メールとドライブの品質はどうなのか気になる

  • 昨日のCloudflare障害のとき、Downdetectorまで一緒に落ちていてみんな笑っていた。絶妙なタイミングだった

    • 昔自分が働いていたCDN企業でも、ステータスページ提供会社がうちの顧客になったことでステータスページを切り替えなければならなかった逸話があった

  • 「3つのDown Detectorがバーに入った」というジョークがあった
    1つ目が「わからない」、2つ目も「わからない」、3つ目が「はい」と答える

    • おそらく**『盲目のダウンディテクターたち』**だったのだろう、という反応があった
    • 面白すぎるので、このジョークはぜひ拝借したい

  • 「これは本当に金だ（GOLD）」と言いながら、「じゃあダウンディテクターを監視するダウンディテクターを監視するダウンディテクターは誰が監視するんだ」というメタジョークが続いた

    • 実際にisitdownrightnow.comのDowndetector監視ページが共有された
    • 「今そのサイトにアクセスしているのがまさに君だ！」という反応もあった
    • 真面目な話、異なるアベイラビリティゾーンとコードベースを持つダウンディテクター同士が互いを監視するのは、かなり実用的なアプローチだ
    • これを「分散ダウンディテクター」のアイデアに発展させて、HNにプロジェクトとして投稿できるかもしれないという意見もあった
    • 「3つのうちどれが落ちたかを監視するメタ・ダウンディテクター」を作ろうという提案も出た

  • 実はDowndetector自体が完全に落ちていたわけではなく、Cloudflareの人間認証モジュールが問題だった
    そのため技術的には「正常」だったが、実際には使えなかった

  • 「君のダウンディテクターが生きているか監視する、別のダウンディテクターが必要だ」というジョークもあった
    「Downdetectorsdownが延々と続く構造」という言い方も出ていた

    • downdetectorsdowndetectorsdowndetector.com のリンクが共有された
    • 複数置いておけば一部は常に落ちるだろうから、その比率を追跡するサイトがあるといいというアイデアも出た
    • これは結局、集中化 vs 分散化 vs 分散システムの問題だ
      ダウンディテクター同士が互いにハートビートを送り合って監視すれば、一部が死んでも全体は生き残る構造が可能になる
      自己修復構造を備えれば、はるかに弾力性の高いネットワークになる
    • 「ダウンディテクターが延々と続く」という表現も繰り返され
    • N番目のダウンディテクターで表される連結リスト構造にしよう、という冗談もあった

  • 「Sup dawg, I heard you like down detectors」というミーム調のコメントもあった

  • Downdetectorのステータスページ も直接共有された

  • 「Cloudflare障害でDowndetectorが落ち、そのせいでCloudFrontにまで負荷がかかった状況だ」として、
    その負荷にまで耐えられる新しいCDNを作ってみろという挑戦が示された

    • ただし「画像のない静的HTMLなら、CDNは本当に必要だろうか？」という現実的な反応もあった

  • 「Downdetectorはどうやって**『正常状態』を検知**するのか？」という質問もあった
    Cloudflare障害の際、インデックスページは200を返していたかもしれない
    ヘッドレスブラウザでスクリーンショットを撮って確認しようとすると、Cloudflareにブロックされそうだ

    • 実際には偽データを生成している
      script.js の fetchStatus() が generateMockStatus() を呼び出し、ランダムな応答時間を作り出す構造になっている
      つまり、本当の状態をチェックしているのではなく、模擬的なステータスデータを表示している方式だ