サイトがダウンした3秒後にメール警告が到着し、その後5時間のダウンタイムはもう起こらない

すべてのモニタリングストーリーには前後があり、その分岐点は常に同じです。それは、誰も監視していなかったために長すぎた停止です。モニタリング前は、サーバーの問題は偶然に発見されます。同僚がサイトが遅いと思ったと言及します。顧客が怒りのメールを送信します。開発者が更新をデプロイしようとして、サーバーが数時間の間到達不可能だったことを発見します。このパターンは、あらゆる規模の組織全体で悲劇的に一貫しています。モニタリング後、同じサーバーの問題は根本的に異なるエクスペリエンスを生成します。サーバーがダウンします。3秒後、メールが到着します。1分以内に誰かが調査を開始します。ほとんどのユーザーが何かが間違っていることに気付く前に、修正がデプロイされます。これら2つのシナリオの違いは、運や人員レベルではありません。それは、連続的に見守り、何かが間違っていることに気付いた瞬間に発言する自動化されたシステムの有無です。

サーバーモニタリングへの伝統的なアプローチは、専用のインフラストラクチャ予算を持つ操作チーム向けに構築されました。NagiosやZabbixなどのツール、およびPrometheusは強力ですが、設定と保守に大きな専門知識が必要です。それらは独自のサーバーで実行されており、これは哲学的な問題を作成します。誰がモニターを監視しますか。個々の開発者、小規模なエージェンシー、およびブートストラップされたスタートアップの場合、自己ホストされた監視スタックの実行のオーバーヘッドは、検出されていない停止の時折のオーバーヘッドを超えることが多いため、モニタリングは永遠に「後で」に延期され、後で来ることはありません。クラウドベースのモニタリングモデルは、そのオーバーヘッドを完全に排除します。保守するサーバーはありません。管理するコンフィグレーションファイルはありません。ベビーシッターをしたり監視インフラストラクチャはありません。エンドポイントを追加し、アラート設定を構成して、システムがそこから引き継ぎます。

uptime.yeb.toが行うことは、概念的には単純で、実行では細心です。すべての監視対象エンドポイントは、4つの異なる次元にわたって定期的にチェックされます。Ping経由の基本的なネットワーク到達可能性、完全なHTTPSリクエストの完了、SSL証明書の有効性と有効期限のタイムライン、および応答時間測定。各次元は異なるカテゴリの障害をキャッチし、一緒にサービスがオンラインではなく、実際に健全で良好に実行しているかどうかの包括的な画像を提供します。Pingに応答するが、HTTPSチェックに失敗するサーバーはWebサーバーの問題があります。すべてのチェックを合格したが、応答時間が着実に増加している場合を示すサーバーはクラッシュに向かっています。有効なSSL証明書を持つが3日で有効期限が切れるサーバーは、訪問者を追い払うブラウザ警告をトリガーしようとしています。これらの各シナリオは異なる応答が必要で、各応答は積極的な監視がないと見えません。

モニターが実際にチェックするもの、および各レイヤーが重要である理由

Pingモニタリングは最も基本的なレイヤーであり、また最も一般的に誤解されています。成功したPing応答は、サーバー上のオペレーティングシステムが実行されており、監視プローブとサーバーの間のネットワークパスが明確であることを意味します。Webサーバーが実行されていることを意味しません。アプリケーションが機能していることを意味しません。ユーザーが実際にページをロードできることを意味しません。Pingは基礎であり、最小限の生存の兆候であり、その上にはすべてが構築されています。Pingチェックが失敗した場合、問題は深刻です。サーバーが完全にオフラインであるか、トラフィックがマシンに到達するのを防ぐ根本的なネットワークの問題があります。これらは、WebトラフィックだけでなくSSHアクセス、データベース接続、メール配信、およびそのマシンで実行されているすべての他のサービスにも影響する停止です。

HTTPSモニタリングは、Pingが見落とす重要なレイヤーを追加します。HTTPSチェックは、ユーザーがWebサイトにアクセスするときにブラウザが行うのと同じ種類のリクエストである、完全なWebリクエストを実行します。チェックは、Webサーバーが接続を受け入れていること、SSL HandShakeが正常に完了することを確認します。これは、Pingが検出できない問題の広いカテゴリをキャッチします。クラッシュしたWebサーバープロセス、誤ったSSL証明書、HTTP 500ステータスコードを返すアプリケーションエラー、および全体的なプロセスが技術的に「オンライン」であっても、サイトを事実上使用不可能にするパフォーマンスの低下。サーバーが到達可能で、ウェブサイトが使用可能な状態との区別は、HTTPSモニタリングが満たす正確なギャップです。

SSL証明書監視は、ほぼすべてのWebサイトオペレーターが少なくとも1回刺したことのある問題に対応しています。証明書は有効期限が切れます。Let's Encryptの無料証明書は90日間続きます。有料の証明書は通常1年続きます。どちらの場合でも、有効期限は絶対的な確実性で到着し、それでも証明書の更新は驚くべき頻度で見られません。理由は単純です。組み込みのリマインダーシステムはありません。認証機関は常に更新通知を送信しません。自動更新スクリプトは黙ってシステムを停止します。そして、期限切れの証明書の結果は即座で厳しいです。ブラウザはフルページセキュリティ警告を表示します。検索エンジンはサイトにフラグを付けます。これらの警告を見るユーザーはめったに続行しないと、証明書が更新された後でも戻ってこないことがあります。証明書の有効期限をモニタリングし、期限日前にアラートを送信することで、防止可能なインシデントの全体的なカテゴリが排除されます。

応答時間監視は、停止までになっていないが、その方向に向かっている問題の初期警告システムです。健全なWebサーバーは100～300ミリ秒で応答します。応答時間が500、次に800、次に1500ミリ秒上昇し始めると、何かが間違っています。データベースクエリは、テーブルサイズの増加のため、ゆっくり実行されます。メモリはプロセスリークによって消費されることがあります。ディスクI/Oは、ロギングまたはバックアップ操作で飽和する可能性があります。これらの問題は、Pingの失敗やHTTPSエラーをトリガーしていませんが、バウンスレート、コンバージョンレート、および検索エンジンランキングに直接影響するユーザーエクスペリエンスを低下させます。数日間と数週間にわたって応答時間を追跡することで、完全な停止にエスカレートする前に、トレンドは長く見えます。

アラートシステムと3秒間がすべてを変更する理由

検出速度は、ダウンタイムの影響を最小化するための最も重要な変数です。数学は率直です。総ダメージは、1分あたりの影響に分数の数を乗じたものです。検出時間を5時間から3秒に短縮しても、1分あたりの影響は変わりませんが、分数を大幅に削減します。ダウンして10分以内に修正されるサーバーは、その日のおよそ0.002％のダウンタイムを経験します。同じサーバーがダウンして5時間後に発見され、修正が同じ10分を取る場合、0.35％のダウンタイムを経験します。1か月間、これらの数字は「4つの9」の信頼性と、クライアントがステータスページに表示したくない恥ずかしいアップタイムパーセンテージの違いに混合します。

アラート配信メカニズムは、検出速度と同じくらい重要です。誰も見ていないダッシュボードに到着するアラートは、アラートがないのと同じです。メールは、メールが常にオンであり、常にあらゆるデバイスからアクセス可能であり、別のアプリケーションをインストールしたり、別のインターフェイスをチェックしたりする必要がないため、ほとんどのオペレータのための最も信頼できる通知チャネルのままです。uptime.yeb.toが障害を検出すると、メール通知はすべての関連するコンテキストとともに直ちに送出されます。どのエンドポイントが失敗したか、どのタイプのチェックが問題を検出したか、正確なタイムスタンプ、および受信した応答（またはエラーが発生しました）。これは、受信者が監視ダッシュボードに最初にログインする必要なく、メール自体から問題の診断を開始できることを意味します。

回復通知は同じくらい重要で、しばしば見落とされます。サーバーがいつバックオンラインになったかを知ることは、ダウンしたことを知ることと同じくらい価値があります。回復アラートには、停止の総期間が含まれており、これは直接事後分析とレポートに供給されます。また、アラートが受信されても、問題が自分自身で解決した後、フォローアップが送信されないときに発生する不要なエスカレーションも防ぎます。回復通知がなければ、すべてのアラートは、検証が必要なオープンループを作成します。これは、より生産的な作業に費やされる可能性がある時間と注意を消費します。

毎日のダイジェスト、週次レポート、および長いビュー

リアルタイムアラートは緊急の問題を処理します。ダイジェストはすべてを処理します。毎日のダイジェストメールは毎朝到着し、前の24時間の完全なサマリーが含まれています。すべての監視対象エンドポイントのアップタイムパーセンテージ、平均およびピーク応答時間、発生したインシデントと継続時間、およびすべてのHTTPSエンドポイントの証明書有効期限ステータス。このメールはスキャンするのに約30秒かかり、ダッシュボードへのログインやいかなる手動チェックを必要とせずに、「すべてが健全ですか？」という質問への即座の答えを提供します。

週次ダイジェストはさらに引きずり、毎日のレベルで見えないトレンドを明らかにします。週のすべての日に100％のアップタイムを維持したサーバーはあるが、応答時間が毎日50ミリ秒増加した応答時間を示したサーバーは、毎日のダイジェストが明らかにしないかもしれない開発中の問題がありますが、週次トレンドグラフは明白にしています。同様に、週の異なる日の2つの短い停止を経験したサーバーは、一緒に表示されたときにパターンを明らかにする可能性があります。どちらの停止も、自動バックアップウィンドウ中の午前3時に発生し、バックアッププロセスが多くのリソースを消費していて、最適化または再スケジュールする必要があることを示唆しています。これらのパターンは、データが時間をかけて集計されるときにのみ表示され、週次ダイジェストは、これらの正確なインサイトを表示するように設計されています。

インシデント履歴は、ダイジェストが要約する詳細なフォレンジックレコードを提供します。検出されたすべての停止は、開始時刻、終了時刻、期間、影響を受けたチェック、および障害を示した応答データで記録されます。この履歴は複数の目的を果たします。事後レビューと根本原因分析に必要なデータを提供します。SLAコンプライアンスに関するホスティングプロバイダーと対処する場合の説明責任を作成します。ステータスページとクライアントレポートに必要なアップタイム統計を生成します。そして、マイグレーションが迫っているかどうか、または特定のホスティングプロバイダーが信頼性の約束を達成しているかどうかといったインフラストラクチャの決定を知らせることができる長期的な記録を構築します。

マルチリージョンプローブと単一の場所のモニタリングのブラインドスポット

サーバーはフランクフルトから完全にアクセス可能で、同時に東京から完全に到達不可能です。ネットワークルーティングはグローブ全体で均一ではありません。インターネットサービスプロバイダーは、特定の地理的な廊下に影響する地域接続の問題を作成し、他の地域をまったく影響を受けられないままにするルーティング決定を下します。DNS伝播の遅延は、サーバーマイグレーションが1つの大陸から完了および検証されている可能性があり、別の大陸のユーザーがまだ古いサーバーに指向されている可能性があります。CDN誤構成は、他のリージョンが正しい最新のページを受け取っている間に、特定のリージョンに古いまたはエラーコンテンツを提供できます。

単一ロケーション監視は、これらすべてのシナリオに盲目です。監視プローブがサーバーと同じデータセンター領域にある場合、100％のアップタイムを報告し、グローバルユーザーベースの半分がサイトにアクセスできません。6つの地理的に分散された位置からのマルチリージョン監視は、設計によってこれらの不一致をキャッチします。チェックが1つの領域から失敗するが他の領域から合格すると、アラートは地理的なコンテキストを含み、サーバー側の障害ではなく、地域的なルーティングの問題に問題を直ちに絞り込みます。この区別は、診断と応答の非常に重要です。サーバー側の問題はサービスの再起動またはホスティングプロバイダーへの連絡が必要ですが、地域的なルーティングの問題はDNS、CDN設定、またはISPレベルの問題の調査が必要です。

6つの監視位置は、グローバルに主要な人口および交通センターをカバーするために選択されます。つまり、北米、ヨーロッパ、アジア全体の顧客に提供するWebサイトには、これらの各地域の近くまたはその近くにプローブがあり、単一のプローブが作成する監視の幻想ではなく、本物のカバレッジを提供しています。グローバルな可用性に依存する企業にとって、このマルチリージョンアプローチはオプションの強化ではありません。これは、地理的に分散されたユーザーベースのエクスペリエンスを正確に表すことができる最小限の実行可能な監視設定です。uptime.yeb.toをマルチリージョン機能で始めから構築すると、監視は保護するトラフィックと同じくらい包括的であることが保証されます。