監視と警告を実施する

監視システムの大部分は専用サーバーに展開される場合がありますが、インフラストラクチャ全体のさまざまなソースからデータを収集する必要があります。 これを行うには、監視エージェント（データを収集して収集エンドポイントに転送するように設計された小さなアプリケーション）をネットワーク全体の個々のマシンにインストールします。 これらのエージェントは、インストールされているホストから統計と使用メトリックを収集し、中央監視ソフトウェアに送信します。

エージェントは、システム全体の各ホストで常時オンのデーモンとして実行されます。 リモートデータエンドポイントで安全に認証し、データ頻度またはサンプリングポリシーを定義し、ホストのデータに一意の識別子を設定するための基本構成を含めることができます。 他のサービスへの影響を軽減するために、エージェントは最小限のリソースを使用し、ほとんど管理なしで運用できる必要があります。 理想的には、新しいノードにエージェントをインストールし、中央監視システムにメトリックの送信を開始するのは簡単なはずです。

監視エージェントは通常、一般的なホストレベルのメトリックを収集しますが、Webサーバーやデータベースサーバーなどのソフトウェアを監視するエージェントも利用できます。 ただし、ほとんどの特殊なタイプのソフトウェアでは、ソフトウェア自体を変更するか、ソフトウェアのステータスエンドポイントまたはログエントリを解析するサービスを作成して独自のエージェントを構築することにより、データを収集およびエクスポートする必要があります。 多くの一般的な監視ソリューションには、カスタムインスツルメンテーションをサービスに簡単に追加できるライブラリが用意されています。 エージェントソフトウェアの場合と同様に、カスタムソリューションがフットプリントを最小限に抑え、アプリケーションの状態やパフォーマンスに影響を与えないように注意する必要があります。

これまでのところ、エージェントが中央の場所にデータをプッシュするモニタリング用のプッシュベースのアーキテクチャについていくつかの仮定を行ってきました。 ただし、プルベースのデザインも利用できます。 プルベースの監視システムでは、個々のホストが、アクセス可能なエンドポイントで既知の形式でメトリックを収集、集約、提供します。 監視サーバーは、各ホストのメトリックエンドポイントをポーリングして、メトリックデータを収集します。 エンドポイントを介してデータを収集して提示するソフトウェアには、エージェントと同じ要件の多くがありますが、他のマシンへのアクセス方法を知る必要がないため、多くの場合、必要な構成が少なくなります。

監視システムで最も忙しい部分の1つは、メトリック入力コンポーネントです。 データは絶えず生成されているため、収集プロセスは、大量のアクティビティを処理し、ストレージレイヤーと調整して着信データを正しく記録するのに十分な堅牢性を備えている必要があります。

プッシュベースのシステムの場合、メトリック入力エンドポイントは、各監視エージェントまたは統計アグリゲーターが収集したデータを送信するネットワーク上の中央の場所です。 エンドポイントは、多数のホストから同時にデータを認証および受信できる必要があります。 メトリックシステムの入力エンドポイントは、多くの場合、信頼性と大量のトラフィックに対応するために、負荷分散または大規模に分散されています。

プルベースのシステムの場合、対応するコンポーネントは、個々のホストで公開されているメトリックエンドポイントに到達して解析するポーリングメカニズムです。 これにはいくつかの同じ要件がありますが、いくつかの責任が逆転します。 たとえば、個々のホストが認証を実装する場合、メトリック収集プロセスは、ログインして安全なエンドポイントにアクセスするための正しい資格情報を提供できる必要があります。

データ管理層は、メトリック入力コンポーネントからの着信データを編成および記録し、管理層からのクエリおよびデータ要求に応答します。 メトリクスデータは通常、時間の経過に伴う値の変化を表すtime seriesと呼ばれる形式で記録されます。 時系列データベース（このタイプのデータの保存とクエリに特化したデータベース）は、監視システム内で頻繁に使用されます。

データ管理層の主な役割は、ホストから受信または収集された受信データを保存することです。 少なくとも、ストレージレイヤーは、報告されているメトリック、観測された値、値が生成された時刻、およびそれを生成したホストを記録する必要があります。

長期間にわたって持続するために、ストレージレイヤーは、コレクションが処理、メモリ、またはストレージのローカル制限を超えたときにデータをエクスポートする方法を提供する必要があります。 その結果、ストレージレイヤーは、必要に応じてシステムに履歴データを再取得するために、データを一括でインポートできる必要もあります。

データ管理層は、保存された情報への組織的なアクセスを提供する必要もあります。 時系列データベースを使用するシステムの場合、この機能は組み込みのクエリ言語またはAPIによって提供されます。 これらは、インタラクティブなクエリとデータ探索に使用できますが、主な消費者はデータプレゼンテーションダッシュボードとアラートシステムです。

データ管理層の上に構築されるのは、収集されるデータを理解するために対話するインターフェースです。 メトリックは時系列データであるため、データはx軸に時間を持つグラフとして最適に表されます。 これにより、値が時間とともにどのように変化するかを簡単に理解できます。 さまざまなタイムスケールでメトリックを視覚化して、長期間にわたる傾向や、現在システムに影響を与えている可能性のある最近の変更を把握できます。

視覚化層とデータ管理層の両方が、さまざまなホストまたはアプリケーションスタックのさまざまな部分からのデータをオーバーレイして全体的に表示できるようにすることに関与しています。 幸いなことに、時系列データは一貫したスケールを提供し、さまざまな種類のインフラストラクチャに影響が分散している場合でも、同時に発生したイベントまたは変更を識別するのに役立ちます。 どのデータをインタラクティブにオーバーレイするかを選択できるため、オペレーターは目前のタスクに最も役立つ視覚化を構築できます。

一般的に使用されるグラフとデータは、保存されたダッシュボードに整理されることがよくあります。 これらは、常時オンのディスプレイの現在のヘルスメトリックの継続的な表現として、またはトラブルシューティングやシステムの特定の領域への詳細なダイビングのための集中ポータルとして、多くのコンテキストで役立ちます。 たとえば、フリート全体の物理ストレージ容量の詳細な内訳を含むダッシュボードは、容量計画の際に重要になる可能性がありますが、毎日の管理では参照する必要がない場合があります。 一般化されたダッシュボードとフォーカスされたダッシュボードの両方を簡単に作成できると、データをよりアクセスしやすく実用的にすることができます。

グラフとダッシュボードは、システム内のデータを理解するための重要なツールですが、人間のオペレーターがページを表示しているコンテキストでのみ役立ちます。 監視システムの最も重要な責任の1つは、チームメンバがシステムを積極的に監視することを軽減し、より価値のあるアクティビティを追求できるようにすることです。 これを実行可能にするために、システムは、重要な変更を認識できると確信できるように、必要なときに注意を促すことができる必要があります。 監視システムは、ユーザー定義のメトリックしきい値と警告システムを使用してこれを実現します。

アラートシステムの目的は、データが重要な変更を示した場合に確実にオペレータに通知し、それ以外の場合はそのままにしておくことです。 これには、システムが重要なイベントとみなすものを知る必要があるため、アラート条件を定義する必要があります。 アラート定義は、通知方法と、システムが受信データに基づいて継続的に評価するメトリックしきい値で構成されます。 しきい値は通常、指定された時間枠でのメトリックの最大または最小平均値を定義し、通知方法はアラートの送信方法を説明します。

アラートの最も難しい部分の1つは、アラートを過剰に出さずに問題に対応できるバランスを見つけることです。 これを実現するには、実際の問題の指標として最適な指標、早急な対応が必要な問題、およびさまざまなシナリオに最適な通知方法を理解する必要があります。 これをサポートするために、しきい値定義言語は、基準を適切に記述するのに十分強力でなければなりません。 同様に、通知コンポーネントは、さまざまなレベルの重大度に適した通信方法を提供する必要があります。

優先度が最も高いアラートタイプから始めて、pagesは、システムの重大な問題に緊急に注意を喚起しようとする通知です。 このカテゴリのアラートは、重大度のためにすぐに解決する必要がある状況で使用する必要があります。 ページングシステムには、問題の解決に取り組む責任と力を持つ人々に手を差し伸べる信頼できる積極的な方法が必要です。

システムに関する重大な問題のためにページを予約する必要があります。 それらが表す問題のタイプのため、それらはシステムが送信する最も重要なアラートです。 優れたページングシステムは信頼性が高く、永続的であり、十分に攻撃的であるため、合理的に無視することはできません。 応答を確実にするために、ページングシステムには、最初のページが一定時間内に確認されなかった場合に、二次的な人またはグループに通知するオプションが含まれることがよくあります。

ページは本質的に信じられないほど破壊的であるため、慎重に使用する必要があります。操作上容認できない問題があることが明らかな場合のみです。 多くの場合、これはページがブラックボックス技術を使用してシステムで観察された症状に結び付けられることを意味します。 バックエンドWebホストが接続を最大限に使用することの影響を判断するのは難しいかもしれませんが、ドメインに到達できないことの重要性はそれほど曖昧ではなく、ページが必要になる場合があります。

重大度を下げるのは、電子メールやチケットのようなnotificationsです。 これらは、オペレータが適切な状況にある場合に、オペレータが開発状況を調査する必要があるという永続的な注意を喚起するように設計されています。 ページとは異なり、通知スタイルのアラートは即時のアクションが必要であることを示すためのものではないため、通常、オンコールの従業員にアラートを出すのではなく、作業スタッフが処理します。 ビジネスに常に管理者がいない場合、通知は翌営業日まで待機できる状況に合わせて調整する必要があります。

監視によって生成されたチケットとメールは、チームが次に活動するときに焦点を当てるべき作業をチームが理解するのに役立ちます。 現在生産に影響を与えている重要な問題には通知を使用しないでください。そのため、通知は、すぐに解決する必要のある進化する問題を予測または特定できるホワイトボックスインジケータに基づいていることがよくあります。

その他の場合、通知アラートは、ページングアラートと同じ動作を監視するように設定されますが、重要度の低いしきい値に設定されます。 たとえば、アプリケーションが一定期間にわたってレイテンシのわずかな増加を示している場合に通知アラートを定義し、レイテンシが不合理な量になったときに対応するページを送信することができます。

一般に、通知は応答が必要な状況に最も適していますが、システムの安定性をすぐに脅かすことはありません。 このような場合、チームがユーザーに影響を与えたり、より大きな問題に変化したりするbeforeを調査して軽減できるように、問題を認識させる必要があります。

技術的にはアラートではありませんが、すぐに誰にも気付かれることなく、後で簡単にアクセスできる場所で特定の観察された動作に注意したい場合があります。 このような状況では、単にlogの情報となるしきい値を設定すると便利です。 これらはファイルに書き込むか、監視システム内のダッシュボードのカウンターをインクリメントするために使用できます。 目標は、情報を収集するためにオペレータが構築しなければならないクエリの数を削減するために、調査目的で容易にコンパイルされた情報を提供することです。

この戦略は、優先度が非常に低く、単独で応答する必要がないシナリオにのみ意味があります。 それらの最大の有用性は、関連する要因を相関させ、後で補足ソースとして参照できる特定時点のデータを要約することです。 おそらく、このタイプのトリガーはそれほど多くないでしょうが、問題が発生するたびに同じデータを参照していることに気付く場合に便利です。 同じ利点のいくつかを提供する代替手段は、保存されたクエリとカスタム調査ダッシュボードです。

前述したように、実際のユーザーへの影響があるシナリオに基づくアラートが最適です。 これは、さまざまな障害またはパフォーマンス低下のシナリオを分析し、ユーザーが対話するレイヤーにバブルが発生する方法と時期を理解することを意味します。

これには、インフラストラクチャの冗長性、さまざまなコンポーネントの関係、および可用性とパフォーマンスに関する組織の目標を十分に理解する必要があります。 目的は、現在または差し迫ったユーザーに影響を与える問題を確実に示すことができる症状の指標を発見することです。

症候性指標を特定したら、次の課題は、しきい値として使用する適切な値を特定することです。 一部のメトリックの適切なしきい値を見つけるには、試行錯誤が必要になる場合があります。

可能な場合は、履歴値を確認して、過去に修復が必要なシナリオを判断します。 各指標について、ページをトリガーする「緊急」のしきい値と、優先度の低いメッセージングに関連付けられた1つまたは複数の「カナリア」のしきい値を定義するとよいでしょう。 新しいアラートを定義した後、システムの微調整を行ってチームの期待に最も合うように、しきい値が過度に強すぎたか、または十分に敏感でないかについてフィードバックを求めます。

レスポンダーが問題の調査を開始するのにかかる時間を最小限に抑えると、インシデントからより迅速に回復するのに役立ちます。 このため、アラートテキスト内にコンテキストを提供して、オペレーターが状況をすばやく理解し、適切な次のステップで作業を開始できるようにすることが役立ちます。

アラートは、影響を受けるコンポーネントとシステム、トリガーされたメトリックしきい値、およびインシデントが開始された時間を明確に示す必要があります。 アラートは、さらに情報を取得するために使用できるリンクも提供する必要があります。 これらは、トリガーされたメトリックに関連付けられた特定のダッシュボードへのリンク、自動チケットが生成された場合のチケットシステムへのリンク、またはより詳細なコンテキストが利用可能な監視システムのアラートページへのリンクです。

目標は、オペレーターに最初の対応を導き、当面のインシデントに集中できるように十分な情報を提供することです。 イベントについてのすべての情報を提供することは必須でも推奨でもありませんが、次に進むべきいくつかのオプションを備えた基本的な詳細を提供すると、応答の最初の発見フェーズを短縮できます。

アラートは、アクション可能でない場合は役に立ちません。 多くの場合、アラートが実行可能かどうかは、応答する個人が持っている知識、経験、許可のレベルに依存します。 特定の規模の組織では、メッセージを送信する適切な個人またはグループを決定するのは簡単な場合もあれば、あいまいな場合もあります。 さまざまなチームのオンコールローテーションを開発し、具体的なエスカレーションプランを設計することで、これらの決定のあいまいさを解消できます。

オンコールローテーションには、燃え尽きを防ぎ、疲労を覚悟するのに十分な能力のある個人を含める必要があります。 アラートシステムにオンコールシフトをスケジュールするメカニズムが含まれている場合が最適ですが、そうでない場合は、スケジュールに基づいてアラートコンタクトを手動でローテーションする手順を開発できます。 システムの特定部分の所有者が複数のオンコールローテーションを設定する場合があります。

エスカレーションプランは、インシデントが正しい人々に届くようにする2番目のツールです。 24時間体制でシステムを担当するスタッフがいる場合、オンコールローテーションではなく、監視システムから生成されたアラートをオンシフトの従業員に送信することをお勧めします。 その後、レスポンダーは軽減策を自分で実行するか、追加のヘルプや専門知識が必要な場合にオンコールオペレーターを手動でページングすることを決定できます。 問題のエスカレーションのタイミングと方法を概説する計画を立てることで、不要なアラートを最小限に抑え、ページが表す緊急性の感覚を保つことができます。