モニタリングとアラートの実践
序章
監視システムは、インフラストラクチャとアプリケーションの可視性を高め、パフォーマンスと信頼性の許容範囲を定義するのに役立ちます。 測定するコンポーネントと、さまざまなシナリオで焦点を当てる最も適切なメトリックを理解することで、サービスのすべての重要な部分をカバーする監視戦略の計画を開始できます。 インフラストラクチャとアプリケーションからの指標の収集に関するガイドでは、価値の高い指標を特定するための一般的なフレームワークを紹介し、展開をレイヤーに分割して、さまざまな段階で何を収集するかについて話し合いました。
このガイドでは、監視システムを構成するコンポーネントと、それらを使用して監視戦略を実装する方法について説明します。 まず、効果的で信頼性の高い監視システムの基本的な責任を確認します。 その後、監視システムの要素がこれらの機能要件をどのように満たすかについて説明します。 次に、監視ポリシーをダッシュボードに変換し、不当な時間に注意を要求することなくチームに必要な情報を提供するアラートポリシーに変換する最善の方法について説明します。
メトリック、監視、およびアラートシステムの重要な品質のレビュー
メトリック、監視、およびアラートの概要ガイドの最後のセクションの1つで、効果的な監視システムの最も重要な品質のいくつかについて説明しました。 これらのシステムのコアコンポーネントをすぐに見ていくので、有用または必要であると特定した特性を確認することは有用です。
- 他のほとんどのインフラストラクチャから独立：データを正確に収集し、パフォーマンスへの悪影響を回避するために、ほとんどの監視コンポーネントは、他のアプリケーションとは別の専用リソースを使用する必要があります。
- 信頼性と信頼性：監視は他のシステムの状態を評価するために使用されるため、監視システム自体が正しく、使用可能であることを確認することが重要です。
- 使いやすいサマリービューと詳細ビュー：データが理解可能または実用的でない場合、データは役に立ちません。 オペレーターが要約ビューを表示し、重要な領域の詳細を発見できるようにすることは、調査中に非常に価値があります。
- 履歴データを維持するための効果的な戦略：異常を認識するためには、典型的なパターンがどのようなものかを理解することが重要です。 より長いタイムラインでは、システムが取得してアクセスできる必要がある古いデータへのアクセスが必要になる場合があります。
- さまざまなソースからの要因を相関させることができる：展開の異なる部分からの情報を整理された方法で表示することは、パターンと相関する要因を識別するために重要です。
- 新しいメトリクスまたはインフラストラクチャの追跡を簡単に開始：アプリケーションとインフラストラクチャの変更に応じて、監視システムを進化させる必要があります。 監視範囲が古くなっているか不完全であると、ツールとデータの信頼性が低下します。
- 柔軟で強力なアラート：アラート機能は、定義した条件に応じて、さまざまなチャネルと優先度で通知を送信できる必要があります。
これらの属性を念頭に置いて、監視システムを構成するものを見てみましょう。
監視システムの一部
監視システムは、いくつかの異なるコンポーネントとインターフェイスで構成されており、これらすべてが連携して、展開の状態を収集、視覚化、およびレポートします。 以下では、基本的な個々の部分について説明します。
分散監視エージェントとデータエクスポーター
監視システムの大部分は専用サーバーに展開される場合がありますが、データはインフラストラクチャ全体のさまざまなソースから収集する必要があります。 これを行うために、監視エージェント（データを収集して収集エンドポイントに転送するように設計された小さなアプリケーション）が、ネットワーク全体の個々のマシンにインストールされます。 これらのエージェントは、インストールされているホストから統計と使用状況のメトリックを収集し、それらを中央監視ソフトウェアに送信します。
エージェントは、システム全体の各ホストで常時オンのデーモンとして実行されます。 これらには、リモートデータエンドポイントで安全に認証し、データ頻度またはサンプリングポリシーを定義し、ホストのデータに一意の識別子を設定するための基本構成が含まれる場合があります。 他のサービスへの影響を減らすために、エージェントは最小限のリソースを使用し、ほとんどまたはまったく管理せずに運用できる必要があります。 理想的には、新しいノードにエージェントをインストールして、中央監視システムにメトリックを送信し始めるのは簡単なはずです。
監視エージェントは通常、一般的なホストレベルのメトリックを収集しますが、Webサーバーやデータベースサーバーなどのソフトウェアを監視するエージェントも利用できます。 ただし、ほとんどの特殊なタイプのソフトウェアでは、ソフトウェア自体を変更するか、ソフトウェアのステータスエンドポイントまたはログエントリを解析するサービスを作成して独自のエージェントを構築することにより、データを収集およびエクスポートする必要があります。 多くの一般的な監視ソリューションには、サービスにカスタムインストルメンテーションを簡単に追加できるライブラリがあります。 エージェントソフトウェアと同様に、アプリケーションの正常性やパフォーマンスに影響を与えないように、カスタムソリューションのフットプリントを最小限に抑えるように注意する必要があります。
これまで、エージェントがデータを中央の場所にプッシュする、監視用のプッシュベースのアーキテクチャについていくつかの仮定を行ってきました。 ただし、プルベースの設計も利用できます。 プルベースの監視システムでは、個々のホストが、アクセス可能なエンドポイントで既知の形式のメトリックを収集、集約、および提供する責任があります。 監視サーバーは、各ホストのメトリックエンドポイントをポーリングして、メトリックデータを収集します。 エンドポイントを介してデータを収集して提示するソフトウェアには、エージェントと同じ要件の多くがありますが、他のマシンにアクセスする方法を知る必要がないため、多くの場合、構成が少なくて済みます。
メトリック入力
常に監視システムで最も忙しい部分の1つは、メトリック入力コンポーネントです。 データは常に生成されているため、収集プロセスは、大量のアクティビティを処理し、ストレージレイヤーと調整して、受信データを正しく記録するのに十分な堅牢性を備えている必要があります。
プッシュベースのシステムの場合、メトリック入力エンドポイントは、各監視エージェントまたは統計アグリゲーターが収集したデータを送信するネットワーク上の中央の場所です。 エンドポイントは、多数のホストから同時にデータを認証および受信できる必要があります。 メトリックシステムの入力エンドポイントは、信頼性と大量のトラフィックに対応するために、負荷分散されるか、大規模に分散されることがよくあります。
プルベースのシステムの場合、対応するコンポーネントは、個々のホストに公開されているメトリックエンドポイントに到達して解析するポーリングメカニズムです。 これには同じ要件がいくつかありますが、一部の責任は逆になります。 たとえば、個々のホストが認証を実装する場合、メトリック収集プロセスは、ログインして安全なエンドポイントにアクセスするための正しい資格情報を提供できる必要があります。
データ管理レイヤー
データ管理レイヤーは、メトリック入力コンポーネントからの受信データを整理および記録し、管理レイヤーからのクエリとデータ要求に応答する役割を果たします。 メトリクスデータは通常、時系列と呼ばれる形式で記録されます。これは、時間の経過に伴う値の変化を表します。 時系列データベース（このタイプのデータの保存とクエリに特化したデータベース）は、監視システム内で頻繁に使用されます。
データ管理レイヤーの主な責任は、ホストから受信または収集された受信データを保存することです。 少なくとも、ストレージレイヤーは、報告されているメトリック、観測された値、値が生成された時刻、およびそれを生成したホストを記録する必要があります。
長期間にわたって永続化するために、ストレージレイヤーは、コレクションが処理、メモリ、またはストレージのローカル制限を超えたときにデータをエクスポートする方法を提供する必要があります。 その結果、ストレージレイヤーは、必要に応じて履歴データをシステムに再取り込みするために、データを一括でインポートできる必要もあります。
データ管理レイヤーは、保存された情報への組織的なアクセスも提供する必要があります。 時系列データベースを使用するシステムの場合、この機能は組み込みのクエリ言語またはAPIによって提供されます。 これらはインタラクティブなクエリとデータ探索に使用できますが、主な利用者はデータプレゼンテーションダッシュボードとアラートシステムである可能性があります。
視覚化とダッシュボードレイヤー
データ管理レイヤーの上に構築されているのは、収集されているデータを理解するために対話するインターフェースです。 メトリックは時系列データであるため、データはx軸に時間のあるグラフとして最もよく表されます。 このようにして、値が時間の経過とともにどのように変化するかを簡単に理解できます。 メトリックをさまざまな時間スケールで視覚化して、長期間にわたる傾向や、現在システムに影響を及ぼしている可能性のある最近の変更を理解できます。
視覚化レイヤーとデータ管理レイヤーはどちらも、さまざまなホストまたはアプリケーションスタックのさまざまな部分からのデータをオーバーレイして全体的に表示できるようにするために使用されます。 幸いなことに、時系列データは、影響がさまざまなタイプのインフラストラクチャに分散している場合でも、同時に発生したイベントまたは変更を識別するのに役立つ一貫したスケールを提供します。 インタラクティブにオーバーレイするデータを選択できるため、オペレーターは目前のタスクに最も役立つ視覚化を構築できます。
一般的に使用されるグラフとデータは、多くの場合、保存されたダッシュボードに整理されます。 これらは、常時表示のディスプレイの現在のヘルスメトリックの継続的な表現として、またはシステムの特定の領域のトラブルシューティングや詳細な調査のための焦点を絞ったポータルとして、さまざまな状況で役立ちます。 たとえば、フリート全体の物理ストレージ容量の詳細な内訳を示すダッシュボードは、容量計画の際に重要になる可能性がありますが、日常の管理のために参照する必要はない場合があります。 一般化されたダッシュボードと焦点を絞ったダッシュボードの両方を簡単に構築できるようにすることで、データへのアクセスと実用性を高めることができます。
アラートおよびしきい値機能
グラフとダッシュボードは、システム内のデータを理解するための頼りになるツールですが、人間のオペレーターがページを表示している状況でのみ役立ちます。 監視システムの最も重要な責任の1つは、チームメンバーがシステムを積極的に監視することから解放し、より価値のある活動を遂行できるようにすることです。 これを実現可能にするには、システムが必要に応じて注意を促し、重要な変更に気付くことができると確信できるようにする必要があります。 監視システムは、ユーザー定義のメトリックしきい値とアラートシステムを使用してこれを実現します。
アラートシステムの目的は、データが重要な変更を示したときにオペレーターに確実に通知し、それ以外の場合はそのままにしておくことです。 これには、システムが重要なイベントと見なすものを認識している必要があるため、アラート基準を定義する必要があります。 アラート定義は、通知方法と、システムが受信データに基づいて継続的に評価するメトリックしきい値で構成されます。 しきい値は通常、指定された時間枠でのメトリックの最大または最小の平均値を定義し、通知方法はアラートの送信方法を記述します。
アラートの最も難しい部分の1つは、アラートを過剰に行わずに問題に対応できるバランスを見つけることです。 これを実現するには、実際の問題を最もよく示す指標、早急な対応が必要な問題、さまざまなシナリオに最適な通知方法を理解する必要があります。 これをサポートするには、しきい値定義言語が、基準を適切に記述するのに十分強力である必要があります。 同様に、通知コンポーネントは、さまざまなレベルの重大度に適した通信方法を提供する必要があります。
ブラックボックスとホワイトボックスの監視
監視システムのさまざまな部分が展開の可視性の向上にどのように貢献するかを説明したので、チームに最適なサービスを提供するためにしきい値とアラートを定義する方法のいくつかについて説明します。 まず、ブラックボックスとホワイトボックスの監視の違いについて説明します。
ブラックボックスとホワイトボックスの監視では、監視のさまざまなモデルについて説明します。 これらは相互に排他的ではないため、多くの場合、システムはそれぞれのタイプを組み合わせて使用し、独自の長所を活用します。
ブラックボックス監視は、外部から見える要因のみに基づいたアラート定義またはグラフを記述します。 このスタイルの監視は、アプリケーションまたはサービスの一般的な動作に焦点を合わせ続けるために、外部の視点を取ります。 基盤となるコンポーネントの状態に関する特別な知識がなくても、ブラックボックスモニタリングは、ユーザーの観点からシステムの機能に関するデータを提供します。 このビューは制限されているように見えるかもしれませんが、この情報は顧客に積極的に影響を与えている問題に密接に対応しているため、アラートトリガーの候補として適しています。
代替のホワイトボックスモニタリングも非常に便利です。 ホワイトボックス監視は、インフラストラクチャに関する特権的な内部情報に基づく監視について説明します。 内部プロセスの量は外部から見える動作を大幅に上回っているため、ホワイトボックスデータの割合がはるかに高くなる可能性があります。 また、システムに関するより包括的な情報で動作するため、ホワイトボックス監視には予測的な機会があります。 たとえば、リソース使用量の変化を追跡することで、新しい需要を満たすために特定のサービスを拡張する必要がある場合に通知できます。
ブラックボックスとホワイトボックスは、システムにさまざまなタイプのパースペクティブを分類する方法にすぎません。 システムの内部が表示されているホワイトボックスデータにアクセスできると、問題の調査、根本原因の評価、および問題がわかっている場合や通常の管理目的での相関要因の発見に役立ちます。 一方、ブラックボックスモニタリングは、ユーザーへの影響を即座に示すことにより、重大な問題を迅速に検出するのに役立ちます。
重大度とアラートタイプの一致
アラートと通知は、監視システムで正しく機能するための最も重要な部分の一部です。 重要な変更に関する通知がない場合、チームはシステムに影響を与えるイベントを認識しないか、ダッシュボードを積極的に監視して最新情報を入手する必要があります。 一方、誤検知の割合が高い、過度に攻撃的なメッセージング、緊急ではないイベント、またはあいまいなメッセージングは、利益よりも害を及ぼす可能性があります。
このセクションでは、通知のさまざまな層と、それぞれを最大限に活用して効果を最大化する方法について説明します。 その後、アラートの対象と通知の実行内容を選択するためのいくつかの基準について説明します。
ページ
ページは、最も優先度の高いアラートタイプから始まり、システムの重大な問題に緊急に注意を喚起しようとする通知です。 このカテゴリのアラートは、重大度が高いために即時の解決が必要な状況で使用する必要があります。 ページングシステムには、問題の解決に取り組む責任と力を持つ人々に連絡するための信頼できる積極的な方法が必要です。
ページは、システムの重大な問題のために予約する必要があります。 それらが表す問題のタイプのため、それらはシステムが送信する最も重要なアラートです。 優れたページングシステムは、信頼性が高く、永続的で、十分に攻撃的であるため、合理的に無視することはできません。 応答を確実にするために、ページングシステムには、最初のページが特定の時間内に確認されなかった場合に、セカンダリの個人またはグループに通知するオプションが含まれていることがよくあります。
ページは本質的に非常に破壊的であるため、慎重に使用する必要があります。操作上許容できない問題があることが明らかな場合に限ります。 多くの場合、これは、ブラックボックス技術を使用して、ページがシステムで観察された症状に関連付けられていることを意味します。 接続を最大化するバックエンドWebホストの影響を判断するのは難しいかもしれませんが、ドメインに到達できないことの重要性ははるかに曖昧ではなく、ページを必要とする場合があります。
二次通知
重大度を下げるのは、電子メールやチケットなどの通知です。 これらは、オペレーターが適切な位置にいるときに、開発中の状況を調査する必要があることを永続的に思い出させるように設計されています。 ページとは異なり、通知スタイルのアラートは、即時のアクションが必要であることを示すことを意図していないため、通常、オンコールの従業員にアラートを出すのではなく、作業スタッフによって処理されます。 あなたのビジネスに常に管理者が働いていない場合、通知は翌営業日まで待つことができる状況に合わせる必要があります。
監視によって生成されたチケットと電子メールは、チームが次にアクティブになるときに焦点を当てるべき作業を理解するのに役立ちます。 通知は、現在本番環境に影響を与えている重大な問題には使用しないでください。通知は、すぐに解決する必要のある進化する問題を予測または特定できるホワイトボックスインジケーターに基づいていることがよくあります。
また、通知アラートは、ページングアラートと同じ動作を監視するように設定されていますが、より低く、重要度の低いしきい値に設定されています。 たとえば、アプリケーションが一定期間にわたってレイテンシーのわずかな増加を示しているときに通知アラートを定義し、レイテンシーが不当な量に増加したときに対応するページを送信することができます。
一般に、通知は応答が必要な状況で最も適切ですが、システムの安定性に差し迫った脅威をもたらすことはありません。 このような場合、問題を認識させて、チームがを調査し、がユーザーに影響を与えたり、より大きな問題に変化する前に軽減したりできるようにします。
ロギング情報
技術的にはアラートではありませんが、すぐに誰かの注意を引くことなく、後で簡単にアクセスできる場所で、特定の観察された動作に注意したい場合があります。 このような状況では、単にlog情報を取得するしきい値を設定すると便利です。 これらはファイルに書き込んだり、監視システム内のダッシュボードのカウンターをインクリメントするために使用したりできます。 目標は、調査目的ですぐにコンパイルできる情報を提供して、情報を収集するためにオペレーターが作成する必要のあるクエリの数を減らすことです。
この戦略は、優先度が非常に低く、それ自体で応答する必要がないシナリオでのみ意味があります。 それらの最大の有用性は、関連する要因を相関させ、後で補足ソースとして参照できる時点データを要約することです。 このタイプのトリガーはおそらく多くないでしょうが、問題が発生するたびに同じデータを検索していることに気付いた場合に役立つ可能性があります。 同じ利点のいくつかを提供する代替手段は、保存されたクエリとカスタム調査ダッシュボードです。
アラートを回避するタイミング
チームにアラートが何を示すべきかを明確にすることが重要です。 各アラートは、手動による人間のアクションまたは決定への入力を必要とする問題が発生していることを示す必要があります。 この焦点があるため、注意を喚起する指標を検討するときは、反応を自動化できる機会があることに注意してください。
自動修復は、次の場合に設計できます。
- 認識可能な署名により、問題を確実に特定できます
- 応答は常に同じになります
- 応答には、人間の入力や意思決定は必要ありません
一部の応答は他の応答よりも自動化が簡単ですが、一般に、上記の基準に適合するシナリオはすべてスクリプト化できます。 応答はアラートのしきい値に関連付けることができますが、メッセージを人に送信する代わりに、トリガーはスクリプトによる修正を開始して問題を解決できます。 これが発生するたびにログを記録することで、システムの状態、メトリックしきい値および自動測定の有効性に関する貴重な情報を提供できます。
自動化されたプロセスでも問題が発生する可能性があることに注意することが重要です。 自動化が失敗したときにオペレーターに通知されるように、スクリプト化された応答にアラートを追加することをお勧めします。 このように、ハンズオフ応答がケースの大部分を処理し、介入が必要なインシデントがチームに通知されます。
効果的なしきい値とアラートの設計
利用可能なさまざまなアラートメディアと、それぞれに適したシナリオのいくつかについて説明したので、適切なアラートの特性について説明します。
実際のユーザーに影響を与えるイベントによってトリガーされる
前述のように、実際のユーザーに影響を与えるシナリオに基づくアラートが最適です。 これは、さまざまな障害またはパフォーマンス低下のシナリオを分析し、それらがユーザーが対話するレイヤーにいつどのようにバブルアップするかを理解することを意味します。
これには、インフラストラクチャの冗長性、さまざまなコンポーネントの関係、および可用性とパフォーマンスに関する組織の目標を十分に理解する必要があります。 あなたの目的は、現在または差し迫ったユーザーに影響を与える問題を確実に示すことができる症候性の測定基準を発見することです。
重大度が段階的なしきい値
症候性の指標を特定したら、次の課題は、しきい値として使用する適切な値を特定することです。 一部の指標の適切なしきい値を見つけるには、試行錯誤が必要になる場合があります。
可能な場合は、過去の値を確認して、過去に修正が必要なシナリオを特定します。 メトリックごとに、ページをトリガーする「緊急」しきい値と、優先度の低いメッセージングに関連付けられている1つまたは複数の「カナリア」しきい値を定義することをお勧めします。 新しいアラートを定義した後、チームの期待に最も合うようにシステムを微調整できるように、しきい値が過度に積極的であるか、または十分に敏感でないかについてのフィードバックを求めます。
適切なコンテキストを含む
レスポンダーが問題の調査を開始するのにかかる時間を最小限に抑えることで、インシデントからの回復を早めることができます。 このためには、アラートテキスト内にコンテキストを提供して、オペレーターが状況をすばやく理解し、適切な次のステップに取り掛かることができるようにすることが役立ちます。
アラートは、影響を受けるコンポーネントとシステム、トリガーされたメトリックしきい値、およびインシデントが開始された時刻を明確に示す必要があります。 アラートは、詳細情報を取得するために使用できるリンクも提供する必要があります。 これらは、トリガーされたメトリックに関連付けられた特定のダッシュボードへのリンク、自動チケットが生成された場合のチケットシステムへのリンク、またはより詳細なコンテキストが利用可能な監視システムのアラートページへのリンクである可能性があります。
目標は、オペレーターに最初の対応を導き、目前の事件に集中するのに役立つ十分な情報を提供することです。 イベントに関するすべての情報を提供することは必須でも推奨でもありませんが、次に進むべき場所に関するいくつかのオプションを含む基本的な詳細を提供することで、応答の最初の発見段階を短縮できます。
適切な人に送信
アラートは、実行可能でない場合は役に立ちません。 多くの場合、アラートが実行可能かどうかは、応答する個人が持っている知識、経験、および許可のレベルに依存します。 特定の規模の組織の場合、メッセージを送信する適切な人物またはグループを決定するのが簡単な場合もあれば、あいまいな場合もあります。 さまざまなチームのオンコールローテーションを開発し、具体的なエスカレーションプランを設計することで、これらの決定におけるあいまいさの一部を取り除くことができます。
オンコールローテーションには、燃え尽き症候群を回避し、疲労を警告するのに十分な有能な個人を含める必要があります。 アラートシステムにオンコールシフトをスケジュールするメカニズムが含まれている場合が最適ですが、含まれていない場合は、スケジュールに基づいてアラート連絡先を手動でローテーションする手順を開発できます。 システムの特定の部分の所有者が複数のオンコールローテーションを設定している場合があります。
エスカレーション計画は、インシデントが正しい人に確実に届くようにするための2番目のツールです。 システムを24時間体制でカバーするスタッフがいる場合は、オンコールローテーションではなく、監視システムから生成されたアラートをオンシフトの従業員に送信するのが最適です。 その後、レスポンダーは自分で軽減を実行するか、追加のヘルプや専門知識が必要な場合は、オンコールオペレーターを手動でページングすることを決定できます。 問題がいつどのようにエスカレートされるかを概説する計画を立てることで、不要なアラートを最小限に抑え、ページが表すことを意図した緊急性を維持できます。
結論
このガイドでは、実際のシステムで監視とアラートがどのように機能するかについて説明しました。 まず、監視システムのさまざまな部分が、組織の認識と応答性のニーズを満たすためにどのように機能するかを確認しました。 さまざまなアラートキューについて考えるためのフレームワークとして、ブラックボックスモニタリングとホワイトボックスモニタリングの違いについて説明しました。 その後、さまざまな種類のアラートと、インシデントの重大度を適切なアラートメディアと一致させる最善の方法について説明しました。 最後に、チームの応答性を向上させるシステムの設計に役立つ効果的なアラートプロセスの特性について説明しました。
