監視と警告を実施する

前書き

監視システムは、インフラストラクチャとアプリケーションの可視性を高め、パフォーマンスと信頼性の許容範囲を定義するのに役立ちます。 どのコンポーネントを測定し、さまざまなシナリオに焦点を当てる最も適切なメトリックを理解することにより、サービスのすべての重要な部分をカバーする監視戦略の計画を開始できます。 https://www.digitalocean.com/community/tutorials/gathering-metrics-from-your-infrastructure-and-applications [インフラストラクチャおよびアプリケーションからメトリックを収集]に関するガイドでは、高い価値を特定するための一般的なフレームワークを導入しましたさまざまな段階で何を収集するかを議論するために、デプロイメントをレイヤーに分割しました。

このガイドでは、監視システムを構成するコンポーネントと、それらを使用して監視戦略を実装する方法について説明します。 まず、効果的で信頼性の高い監視システムの基本的な責任を確認します。 その後、監視システムの要素がこれらの機能要件を満たす方法を説明します。 次に、監視ポリシーをダッシュ​​ボードに変換し、不当な時間に注意を要求することなく必要な情報をチームに提供するアラートポリシーに変換する最適な方法について説明します。

メトリックス、モニタリング、アラートシステムの重要な品質のレビュー

https://www.digitalocean.com/community/tutorials/an-introduction-to-metrics-monitoring-and-alerting [メトリック、モニタリング、アラートの概要]ガイドの最終セクションの1つで、 the効果的な監視システムの最も重要な品質。 これらのシステムのコアコンポーネントについてはすぐに検討するため、有用または必要であると判断した特性を確認すると便利です。

  • 他のほとんどのインフラストラクチャから独立:データを正確に収集し、パフォーマンスへの悪影響を回避するために、ほとんどの監視コンポーネントは他のアプリケーションとは別個の専用リソースを使用する必要があります。

  • 信頼性と信頼性:監視は他のシステムの健全性を評価するために使用されるため、監視システム自体が正しく利用可能であることを確認することが重要です。

  • 簡単に要約ビューと詳細ビューを使用:データがわかりにくい場合や実用的でない場合、データは役に立ちません。 オペレータがサマリービューを表示し、重要な領域の詳細を発見できるようにすることは、調査中に非常に貴重です。

  • 履歴データを維持するための効果的な戦略:異常を認識するためには、典型的なパターンがどのようなものかを理解することが重要です。 より長いタイムラインでは、これには、システムが取得およびアクセスできる必要がある古いデータへのアクセスが必要になる場合があります。

  • 異なるソースからの要因を相関させることができる:展開の異なる部分からの情報を体系的に表示することは、パターンと相関する要因を識別するために重要です。

  • 新しいメトリクスまたはインフラストラクチャの追跡を開始しやすい:アプリケーションおよびインフラストラクチャの変更に合わせて、監視システムを進化させる必要があります。 監視範囲が古いか不完全であると、ツールとデータに対する信頼が低下します。

  • 柔軟で強力なアラート:アラート機能は、定義する条件に応じて、さまざまなチャネルと優先度で通知を送信できる必要があります。

これらの属性を念頭に置いて、監視システムを構成するものを見てみましょう。

監視システムの部品

監視システムは、いくつかの異なるコンポーネントとインターフェイスで構成され、すべてが連携して展開の健全性を収集、視覚化、レポートします。 以下に、基本的な個々の部品について説明します。

分散監視エージェントとデータエクスポーター

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

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

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

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

メトリックスイングレス

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

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

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

データ管理層

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

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

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

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

視覚化とダッシュボードレイヤー

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

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

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

アラートおよびしきい値機能

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

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

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

ブラックボックスおよびホワイトボックスの監視

監視システムのさまざまな部分が展開の可視性の向上にどのように寄与するかを説明したので、チームに最適なサービスを提供するためのしきい値とアラートを定義する方法について説明します。 まず、ブラックボックスモニタリングとホワイトボックスモニタリングの違いについて説明します。

ブラックボックスおよびホワイトボックス監視は、監視用の異なるモデルを説明します。 これらは相互に排他的ではないため、多くの場合、システムは各タイプの混合を使用して独自の長所を利用します。

*ブラックボックス監視*は、外部から見える要因のみに基づいてアラート定義またはグラフを記述します。 このスタイルの監視では、アプリケーションまたはサービスのパブリックな振る舞いに焦点を当てるために、外部の視点を取ります。 基盤となるコンポーネントの正常性に関する特別な知識がないため、ブラックボックスモニタリングは、ユーザーの観点からシステムの機能に関するデータを提供します。 このビューは制限的に見えるかもしれませんが、この情報は顧客に積極的に影響を与えている問題に密接に対応しているため、アラートトリガーの良い候補です。

代替の*ホワイトボックスモニタリング*も非常に便利です。 ホワイトボックス監視は、インフラストラクチャに関する特権のある内部情報に基づいた監視を記述します。 内部プロセスの量は、外部から見える動作を大きく上回るため、ホワイトボックスデータの割合がはるかに高くなる可能性があります。 また、システムに関するより包括的な情報を使用して動作するため、ホワイトボックス監視は予測する機会があります。 たとえば、リソース使用の変化を追跡することにより、新しい需要を満たすために特定のサービスをスケーリングする必要がある場合に通知できます。

ブラックボックスとホワイトボックスは、異なるタイプのパースペクティブをシステムに分類する方法にすぎません。 システムの内部が見えるホワイトボックスデータにアクセスできることは、問題の調査、根本原因の評価、および問題がわかっている場合や通常の管理目的で相関する要因を見つけるのに役立ちます。 一方、ブラックボックスモニタリングは、ユーザーへの影響をすぐに示すことにより、深刻な問題を迅速に検出するのに役立ちます。

重大度とアラートタイプの一致

警告と通知は、監視システムを正しく動作させるための最も重要な部分の一部です。 重要な変更に関する通知がなければ、チームはシステムに影響を与えるイベントを認識しないか、ダッシュボードを積極的に監視して最新情報を入手する必要があります。 一方、誤検知、緊急でないイベント、またはあいまいなメッセージングの割合が高い過度に攻撃的なメッセージングは​​、良いことよりも害になる可能性があります。

このセクションでは、通知のさまざまな層と、それぞれの効果を最大限に活用するための最適な使用方法について説明します。 その後、アラートの対象と通知の達成方法を選択するためのいくつかの基準について説明します。

ページ数

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

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

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

二次通知

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

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

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

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

ロギング情報

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

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

アラートを回避する場合

チームに通知するアラートを明確にすることが重要です。 各アラートは、人間による手動のアクションまたは決定に関する入力を必要とする問題が発生していることを示す必要があります。 この焦点のため、アラートを出すメトリックを検討する際に、反応が自動化される可能性があることに注意してください。

自動修復は、次の場合に設計できます。

  • 認識可能な署名により、問題を確実に特定できます

  • 応答は常に同じです

  • 応答には、人間の入力や意思決定は必要ありません

一部の応答は他の応答よりも自動化が簡単ですが、一般に、上記の基準に適合するシナリオはスクリプト化できます。 応答は引き続きアラートのしきい値に関連付けることができますが、トリガーを使用してメッセージを人に送信する代わりに、スクリプトによる修正を開始して問題を解決できます。 これが発生するたびにログを記録すると、システムの健全性、およびメトリックしきい値と自動測定の有効性に関する貴重な情報が得られます。

自動化プロセスでも問題が発生する可能性があることに留意することが重要です。 自動化が失敗したときにオペレーターに通知されるように、スクリプト化された応答にアラートを追加することをお勧めします。 このようにして、ほとんどのケースをハンドオフ対応で処理し、介入を必要とするインシデントをチームに通知します。

有効なしきい値とアラートの設計

利用可能なさまざまなアラートメディアと、それぞれに適したいくつかのシナリオについて説明したので、優れたアラートの特性について説明します。

実際のユーザーに影響を与えるイベントによってトリガーされる

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

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

段階的な重大度のしきい値

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

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

適切なコンテキストを含む

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

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

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

適切な人に送信

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

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

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

結論

このガイドでは、実際のシステムで監視と警告がどのように機能するかについて説明しました。 まず、監視システムのさまざまな部分がどのように機能して、認識と応答性に対する組織のニーズを満たすかを調べることから始めました。 異なるアラートキューを考えるためのフレームワークとして、ブラックボックスモニタリングとホワイトボックスモニタリングの違いについて説明しました。 その後、さまざまな種類のアラートと、インシデントの重大度を適切なアラートメディアと最適に一致させる方法について説明しました。 最後に、効果的なアラートプロセスの特性を取り上げて、チームの応答性を向上させるシステムの設計を支援しました。

前の投稿:Ubuntu 18.04にownCloudをインストールして設定する方法
次の投稿:Synology NASをDigitalOcean Spacesにバックアップする方法