メトリック、監視、およびアラートの概要

前書き

サービスの信頼性と安定性を確保するには、インフラストラクチャとシステムの状態を理解することが不可欠です。 デプロイメントの健全性とパフォーマンスに関する情報は、チームが問題に対応するのに役立つだけでなく、自信を持って変更を加えるためのセキュリティも提供します。 この洞察を得る最良の方法の1つは、メトリックを収集し、データを視覚化し、問題が発生したように見える場合にオペレーターに警告する堅牢な監視システムを使用することです。

このガイドでは、メトリック、監視、アラートとは何かについて説明します。 それらが重要である理由、それらが提供する機会の種類、追跡したいデータの種類について説明します。 途中でいくつかの重要な用語を紹介し、このスペースの探索中に出くわすかもしれない他の用語の短い用語集で終わります。

メトリック、監視、アラートとは何ですか?

メトリック、監視、アラートはすべて相互に関連する概念であり、これらが一緒になって監視システムの基礎を形成します。 システムの状態を可視化し、使用状況や動作の傾向を理解し、加えた変更の影響を理解するのに役立ちます。 メトリックが予想範囲外にある場合、これらのシステムは通知を送信してオペレーターに確認を促し、情報の浮上を支援して考えられる原因を特定することができます。

このセクションでは、これらの個々の概念とそれらがどのように適合するかを見ていきます。

メトリックスとは何ですか?なぜそれらを収集するのですか?

メトリックは、システム全体で監視および収集できるリソース使用量または動作の生の測定値を表します。 これらは、オペレーティングシステムによって提供される低レベルの使用状況の概要である場合もあれば、1秒あたりのリクエストやWebサーバーのプールのメンバーシップなど、特定の機能やコンポーネントの動作に関連する高レベルのデータである場合もあります。 総容量に関連して表示されるメトリックもあれば、コンポーネントの「ビジー」を示すレートとして表されるメトリックもあります。

多くの場合、最初の最も簡単なメトリックは、オペレーティングシステムによって既に公開されているもので、基礎となる物理リソースの使用状況を表します。 ディスク容量、CPU負荷、スワップ使用量などに関するデータ 既に利用可能で、すぐに価値を提供し、多くの追加作業なしで監視システムに転送できます。 多くのWebサーバー、データベースサーバー、およびその他のソフトウェアも独自のメトリックを提供しており、これらのメトリックも転送できます。

他のコンポーネント、特に独自のアプリケーションの場合、関心のあるメトリックを公開するためにコードまたはインターフェースを追加する必要があります。 メトリックを収集して公開することは、* instrumentation *をサービスに追加することとして知られています。

メトリックは、特に集約して分析する場合に、システムの動作と正常性に関する洞察を提供するので便利です。 これらは、監視システムが環境の全体像を構築し、変更への対応を自動化し、必要に応じて人間に警告するために使用する原材料を表します。 メトリックは、履歴の傾向を理解し、さまざまな要因を相関させ、パフォーマンス、消費、またはエラー率の変化を測定するために使用される基本的な値です。

監視とは

メトリックはシステム内のデータを表しますが、監視はこれらの値を収集、集計、分析して、コンポーネントの特性と動作の認識を向上させるプロセスです。 環境のさまざまな部分からのデータは、値が特定の要件を満たしたときに、ストレージ、集約、視覚化、および自動応答の開始を担当する*監視システム*に収集されます。

一般に、メトリックと監視の違いは、データと情報の違いを反映しています。 データは未処理の未処理のファクトで構成され、情報はデータを分析および整理して価値を提供するコンテキストを構築することで生成されます。 監視では、メトリックデータを取得して集計し、さまざまな方法で表示して、人間が個々の断片のコレクションから洞察を抽出できるようにします。

監視システムは多くの関連機能を果たします。 彼らの最初の責任は、着信データと履歴データを受け入れて保存することです。 現在の時点を表す値は有用ですが、ほとんどの場合、過去の値に関連してそれらの数値を表示して、変化や傾向に関するコンテキストを提供する方が便利です。 これは、監視システムが一定期間にわたってデータを管理できる必要があることを意味します。これには、古いデータのサンプリングや集計が含まれる場合があります。

第二に、監視システムは通常、データの視覚化を提供します。 メトリックは個々の値またはテーブルとして表示および理解できますが、視覚的に意味のある方法で情報を整理する場合、人間は傾向を認識し、コンポーネントがどのように適合するかを理解するのがはるかに優れています。 通常、監視システムは、構成可能なグラフとダッシュボードで測定するコンポーネントを表します。 これにより、ディスプレイを一見することにより、システム内の複雑な変数または変更の相互作用を理解することができます。

監視システムが提供する追加機能は、さまざまな入力からのデータの整理と関連付けです。 メトリックが有用であるためには、管理者は異なるリソース間およびサーバーのグループ間でパターンを認識できる必要があります。 たとえば、アプリケーションでエラー率が急上昇した場合、管理者は監視システムを使用して、そのイベントが関連リソースの容量の枯渇と一致するかどうかを検出できる必要があります。

最後に、監視システムは通常、アラートを定義およびアクティブ化するためのプラットフォームとして使用されます。これについては次に説明します。

アラートとは何ですか?

アラートは、メトリック値の変更に基づいてアクションを実行する監視システムの応答コンポーネントです。 アラート定義は、2つのコンポーネントで構成されます:メトリックベースの条件またはしきい値、および値が許容条件外になったときに実行するアクション。

監視システムは、積極的な解釈と調査に非常に役立ちますが、完全な監視システムの主な利点の1つは、管理者がシステムから解放されることです。 アラートを使用すると、ソフトウェアの受動的な監視に依存して変化する状態を監視しながら、積極的に管理する意味のある状況を定義できます。

責任当事者への通知はアラートの最も一般的なアクションですが、一部のプログラムによる応答は、しきい値違反にも基づいてトリガーできます。 たとえば、現在の負荷を処理するためにより多くのCPUが必要であることを示すアラートは、アプリケーションのその層を自動スケーリングするスクリプトで対応できます。 これは通知にならないため、厳密にはアラートではありませんが、同じ監視システムメカニズムを使用してこれらのプロセスを開始することもできます。

ただし、アラートの主な目的は、システムの現在のステータスに人間の注意を向けることです。 応答の自動化は、知識のある人間による検討が必要な状況でのみ通知がトリガーされるようにするための重要なメカニズムです。 アラート自体には、何が間違っているのか、追加情報を見つけるためにどこに行くのかに関する情報が含まれている必要があります。 アラートに応答した個人は、監視システムとログファイルなどの関連ツールを使用して、問題の原因を調査し、軽減戦略を実装できます。

中程度の複雑さのインフラストラクチャでも、問題の規模に適した方法を使用して責任のあるチームまたは個人に通知できるように、アラートの重大度を区別する必要があります。 たとえば、ストレージの使用率の上昇は作業チケットまたは電子メールを必要とする場合がありますが、クライアント側のエラー率の増加または無応答性はオンコールスタッフへのページ送信を必要とする場合があります。

どの種類の情報を追跡することが重要ですか?

監視する値の種類と追跡する情報は、インフラストラクチャの進化に伴いおそらく変化します。 通常、システムは階層的に機能するため、より複雑なレイヤーがより原始的なインフラストラクチャ上に構築されるため、監視戦略を計画する際にこれらのさまざまなレベルで利用可能なメトリックについて考えると便利です。

ホストベースのメトリック

プリミティブメトリックの階層の最下部には、ホストベースのインジケータがあります。 これらは、アプリケーションスタックとサービスを現時点では無視して、個々のマシンの正常性またはパフォーマンスの評価に関係するものです。 これらは主に、オペレーティングシステムまたはハードウェアの使用状況またはパフォーマンスで構成されています。

  • CPU

  • 記憶

  • ディスクスペース

  • プロセス

これらは、単一のコンピューターが安定した状態を維持したり、作業を実行したりする能力に影響を与える可能性のある要因の感覚を与えることができます。

アプリケーションメトリック

あなたが見たいかもしれないメトリックの次のカテゴリは、アプリケーションのメトリックです。 これらは、サービスやアプリケーションなどのホストレベルのリソースに依存する処理または作業の単位に関するメトリックです。 調べる特定のタイプのメトリックは、サービスが提供しているもの、サービスが持っている依存関係、サービスが相互作用する他のコンポーネントによって異なります。 このレベルのメトリックは、アプリケーションの正常性、パフォーマンス、または負荷の指標です。

  • エラー率と成功率

  • サービスの失敗と再起動

  • 応答のパフォーマンスと遅延

  • リソース使用量

これらのインジケータは、アプリケーションが正しく機能しているかどうかを判断するのに役立ちます。

ネットワークと接続のメトリック

ほとんどのタイプのインフラストラクチャでは、ネットワークと接続性の指標は調査する価値のある別のデータセットになります。 これらは、外向きの可用性の重要な尺度ですが、複数のマシンにまたがるシステムの場合、他のマシンがサービスにアクセスできるようにするためにも不可欠です。 これまでに説明した他の指標と同様に、ネットワークの全体的な機能の正確性と、以下を確認して必要なパフォーマンスを提供する能力を確認する必要があります。

  • 接続性

  • エラー率とパケット損失

  • 待ち時間

  • 帯域利用率

ネットワーク層を監視すると、内部サービスと外部サービスの両方の可用性と応答性を向上させるのに役立ちます。

サーバープールメトリック

水平に拡張されたインフラストラクチャを扱う場合、メトリックを追加する必要があるインフラストラクチャの別のレイヤーはサーバーのプールです。 個々のサーバーに関するメトリックは有用ですが、大規模なサービスは、作業を実行して要求に適切に応答するマシンのコレクションの能力として表されます。 このタイプのメトリックは、多くの点でアプリケーションおよびサーバーのメトリックの高レベルの外挿にすぎませんが、この場合のリソースはマシンレベルのコンポーネントではなく同種のサーバーです。 追跡する可能性のあるデータは次のとおりです。

  • プールされたリソースの使用

  • スケーリング調整インジケーター

  • 劣化したインスタンス

サーバーのコレクションの正常性を要約するデータを収集することは、負荷を処理して変更に対応するシステムの実際の機能を理解するために重要です。

外部依存性メトリック

システムに追加したい他のメトリックは、外部依存関係に関連するメトリックです。 多くの場合、サービスはサービスの停止を検出するためのステータスページまたはAPIを提供しますが、これらをシステム内で追跡し、サービスとの実際のやり取りと同様に、運用に影響を与える可能性のあるプロバイダーの問題を特定するのに役立ちます。 このレベルでの追跡に適用される可能性のあるアイテムは次のとおりです。

  • サービスのステータスと可用性

  • 成功率とエラー率

  • 稼働率と運用コスト

  • リソースの枯渇

収集に役立つ他の多くのタイプのメトリックがあります。 さまざまな焦点レベルで最も重要な情報を概念化すると、問題の予測または特定に最も役立つインジケーターを特定するのに役立ちます。 上位レベルで最も価値のあるメトリックは、下位レイヤーによって提供されるリソースである可能性が高いことに留意してください。

監視対象の選択に影響する要因

安心のために、理想的な世界では、アイテムがいつかあなたに関連するかもしれない場合に備えて、システムに関連するすべてを最初から追跡します。 ただし、これが不可能な場合や望ましくない場合も多くの理由があります。

収集および処理の選択に影響を与える可能性があるいくつかの要因は次のとおりです。

  • 追跡に利用できるリソース:人的資源、インフラストラクチャ、および予算に応じて、追跡する対象の範囲を、実装および合理的に管理できる範囲に制限する必要があります。

  • アプリケーションの複雑さと目的:アプリケーションまたはシステムの複雑さは、追跡対象の選択に大きな影響を与える可能性があります。 一部のソフトウェアにとってミッションクリティカルなアイテムは、他のソフトウェアではまったく重要ではない場合があります。

  • 展開環境:堅牢な監視は運用システムにとって最も重要ですが、ステージングおよびテストシステムも監視の恩恵を受けますが、重大度、粒度、および測定される全体的なメトリックに違いがある場合があります。

  • メトリックが有用である可能性:何かを測定するかどうかに影響を与える最も重要な要因の1つは、将来的に役立つ可能性です。 追跡される追加のメトリックごとに、システムの複雑さが増し、リソースが占有されます。 データの必要性も時間とともに変化する可能性があり、定期的な再評価が必要です。

  • 本質的な安定性:簡単に言えば、安定性と稼働時間は、特定のタイプの個人プロジェクトまたは初期段階のプロジェクトの優先事項ではない場合があります。

決定に影響する要因は、利用可能なリソース、プロジェクトの成熟度、および必要なサービスのレベルによって異なります。

メトリックス、監視、および警告システムの重要な品質

各監視アプリケーションまたはサービスには長所と短所がありますが、多くの場合、最良のオプションにはいくつかの重要な特性があります。 監視システムを評価するときに探すべき重要な特性のいくつかを以下に示します。

他のほとんどのインフラストラクチャから独立

適切な監視システムの最も基本的な要件の1つは、他のサービスの外部にあることです。 サービスをグループ化すると便利な場合がありますが、監視システムの中心的な責任、問題の診断における有用性、監視対象システムとの関係は、監視システムが独立してアクセス可能であることが重要であることを意味します。 監視システムは監視するシステムにある程度の影響を与えることは避けられませんが、追跡がパフォーマンスに与える影響を減らし、他のシステムに問題が発生した場合の監視の信頼性を高めるために、これを最小限に抑えることを目指してください。

信頼性と信頼性

もう1つの基本的な要件は信頼性です。 監視システムは価値の高い情報の収集、保存、アクセスの提供を担当しているため、日常的に正しく動作することを信頼できることが重要です。 メトリックの削除、サービスの停止、および信頼性の低いアラートはすべて、インフラストラクチャを効果的に管理する能力に直接的な悪影響を与える可能性があります。 これは、コアソフトウェアの信頼性だけでなく、有効にする構成にも当てはまります。これは、不正確なアラートなどのミスがシステムの信頼を失う可能性があるためです。

使いやすいサマリービューと詳細ビュー

高レベルの要約を表示し、オンデマンドで詳細を要求する機能は、メトリックデータが人間のオペレーターにとって有用で消費可能であることを保証する重要な機能です。 最もよく表示されるデータをすぐに理解できる方法で表示するダッシュボードを設計すると、ユーザーがシステムの状態を一目で理解するのに役立ちます。 さまざまな職務または関心分野に合わせて、多くのさまざまなダッシュボードビューを作成できます。

同様に重要なのは、サマリー表示内からドリルダウンして、現在のタスクに最も関連する情報を表示できることです。 グラフのスケールを動的に調整し、不必要なメトリックを切り替え、複数のシステムからの情報をオーバーレイすることは、調査や根本原因分析にツールをインタラクティブに使用するために不可欠です。

履歴データを維持するための効果的な戦略

監視システムは、長いタイムラインにわたって傾向、パターン、一貫性を確立するのに役立つデータの豊富な履歴がある場合に最も役立ちます。 理想的には、すべての情報は元の粒度で無期限に保持されるため、コストとリソースの制約により、古いデータを低い解像度で保存することが必要になる場合があります。 監視システムは、完全な粒度とサンプリングされた形式の両方でデータを処理する柔軟性を備えており、増え続けるデータを処理するための幅広いオプションを提供します。

関連する便利な機能は、既存のデータセットを簡単にインポートできることです。 履歴メトリックの情報密度を減らすことが魅力的なオプションではない場合は、古いデータを長期的なストレージソリューションにオフロードする方が適切な選択肢になる可能性があります。 この場合、システム内で古いデータを維持する必要はありませんが、分析または使用する場合は、一括で再ロードできる必要があります。

さまざまなソースからの要因を相関させることができます

監視システムは、インフラストラクチャ全体の全体像を提供する役割を担っているため、異なるシステムからのものであったり、異なる特性を持つものであっても、関連情報を表示できる必要があります。 管理者は、インフラストラクチャ全体の潜在的な相互作用と全体的なステータスを理解するために、システムの異なる部分からの情報を自由に結合できる必要があります。 システム間で時刻同期を確実に構成することは、異なるシステムのデータを確実に相関させるための前提条件です。

新しいメトリックまたはインフラストラクチャの追跡を簡単に開始

監視システムをシステムの正確な表現にするためには、マシンとインフラストラクチャの変更に応じて調整できる必要があります。 追加のマシンを追加するときの摩擦は最小限に抑えられます。 同様に重要なのは、関連する収集データを破壊することなく、使用停止されたマシンを簡単に削除できることです。 システムは、インスタンスのプロビジョニングまたはリタイアプロセスの一部として監視の設定を促進するために、これらの操作をできるだけ単純にする必要があります。

関連する重要な機能は、まったく新しいメトリックを追跡するように監視システムを簡単にセットアップできることです。 これは、コア監視構成でのメトリックの定義方法と、メトリックデータをシステムに送信するために使用できるメカニズムの種類と品質に依存します。 通常、新しいメトリックの定義は、マシンの追加よりも複雑ですが、メトリックの追加または調整の複雑さを軽減することで、チームは適切な時間枠で要件の変化に対応できます。

柔軟で強力なアラート

評価する監視システムの最も重要な側面の1つは、アラート機能です。 非常に厳しい信頼性要件の他に、アラートシステムは、複数の媒体を介してオペレータに通知するのに十分な柔軟性と、思慮深く実用的な通知トリガーを作成できるほど強力である必要があります。 多くのシステムは、既存のページングサービスまたはメッセンジャーアプリケーションとの統合を提供することにより、実際に他の関係者に通知を配信する責任を延期します。 これにより、アラート機能の責任が最小限に抑えられ、通常、プラグインは外部APIを使用するだけで済むため、より柔軟なオプションが提供されます。

ただし、監視システムが延期できない部分は、アラートパラメータの定義です。 アラートは許容範囲外の値に基づいて定義されますが、アラートの過剰な発生を避けるために、定義には微妙な違いが必要になる場合があります。 たとえば、瞬間的なスパイクは多くの場合問題ではありませんが、高い負荷を維持するにはオペレーターの注意が必要な場合があります。 アラートのパラメーターを明確に定義できることは、堅牢で信頼できるアラート条件のセットを構成するための要件です。

追加の用語

監視エコシステムを探索すると、監視システムの特性、処理されるデータ、および考慮が必要なさまざまなトレードオフを議論するために頻繁に使用される一連の共有用語に遭遇し始めます。 決して完全ではありませんが、以下のリストは、あなたが遭遇する可能性が最も高い用語のいくつかを紹介するのに役立ちます。

  • 観測可能性:厳密に定義されていませんが、観測可能性は、システムに対する認識と可視性の向上に関連するプロセスと技術を説明するために使用される一般的な用語です。 これには、監視、メトリック、視覚化、トレース、およびログ分析が含まれます。

  • リソース:監視およびソフトウェアシステムのコンテキストでは、リソースは、すべての完全な、または限られた依存関係です。 リソースと見なされるものは、議論されているシステムの一部によって大きく異なります。

  • 遅延:遅延は、アクションを完了するのにかかる時間の尺度です。 コンポーネントに応じて、これは処理、応答、または移動時間の尺度になります。

  • スループット:スループットは、システムが処理できる処理またはトラバーサルの最大速度を表します。 これは、ソフトウェアまたはハードウェアの設計に依存する場合があります。 多くの場合、理論的なスループットと実際に観測されるスループットには重要な違いがあります。

  • パフォーマンス:パフォーマンスは、システムがどの程度効率的に作業を完了しているかの一般的な尺度です。 パフォーマンスは包括的な用語であり、多くの場合、スループット、待ち時間、リソース消費などの作業要素が含まれます。

  • 彩度:彩度は、使用されている容量の尺度です。 完全飽和は、容量の100%が現在使用中であることを示します。

  • 視覚化:視覚化とは、メトリックデータをグラフまたはチャートを介してすばやく直感的に解釈できる形式で表示するプロセスです。

  • ログの集計:ログの集計とは、ログファイルをコンパイル、整理、およびインデックス付けして、管理、検索、および分析を容易にすることです。 監視とは別に、集計されたログを監視システムと組み合わせて使用​​して、原因を特定し、障害を調査できます。

  • データポイント:データポイントは、単一のメトリックの単一の測定値です。

  • データセット:データセットは、メトリックのデータポイントのコレクションです。

  • 単位:単位は測定値のコンテキストです。 単位は、測定の大きさ、範囲、または量を定義して、範囲を理解し、比較できるようにします。

  • パーセント単位:パーセント単位は、有限全体の一部として取得される測定値です。 パーセント単位は、値が合計可能量からどれだけ外れているかを示します。

  • レート単位:レート単位は、一定期間におけるメトリックの大きさを示します。

  • 時系列:時系列データは、経時変化を表す一連のデータポイントです。 単一のデータポイントは特定の時間の値を表すことが多く、結果の一連のポイントは時間の経過に伴う変化を示すために使用されるため、ほとんどのメトリックは時系列で最適に表されます。

  • サンプリングレート:サンプリングレートは、連続的な収集の代わりに代表的なデータポイントが収集される頻度の測定値です。 サンプリングレートが高いほど、測定された動作をより正確に表しますが、余分なデータポイントを処理するにはより多くのリソースが必要です。

  • 解像度:解像度とは、データセットを構成するデータポイントの密度を指します。 同じ時間枠でより高い解像度を持つコレクションは、より高いサンプルレートと同じ動作のより詳細なビューを示します。

  • 計測:計測とは、ソフトウェアの動作とパフォーマンスを追跡する機能です。 これは、ソフトウェアにコードと構成を追加して、監視システムで使用できるデータを出力することで実現されます。

  • オブザーバー効果:オブザーバー効果は、監視対象の現象に対する監視システム自体の影響です。 監視はリソースを消費するため、動作とパフォーマンスを測定する行為により、生成される値が変更されます。 監視システムは、この影響を最小限に抑えるために不要なオーバーヘッドを追加しないようにします。

  • 過剰監視:過剰監視は、設定されたメトリックとアラートの量がそれらの有用性に反比例する場合に発生します。 過剰監視は、インフラストラクチャにストレスを与え、関連データを見つけるのを難しくし、チームが監視および警告システムに対する信頼を失う可能性があります。

  • アラート疲労:アラート疲労は、頻繁な、信頼性の低い、または不適切に優先順位付けされたアラートに起因する、感度低下に対する人間の反応です。 アラート疲労により、オペレーターは重大な問題を無視する可能性があり、通常はアラート条件を再評価する必要があることを示しています。

  • しきい値:アラートの場合、しきい値は、許容値と許容できない値の境界であり、超過するとアラートをトリガーします。 多くの場合、アラートは、一時的なスパイクのアラートを送信しないようにするために、値が一定期間しきい値を超えたときにトリガーされるように構成されます。

  • *分位点:分位点は、値に基づいてデータセットを個別のグループに分けるために使用される分割ポイントです。 分位点は、データの母集団のセグメントを表す「バケット」に値を入れるために使用されます。 多くの場合、これは一般的な値を外れ値から分離して、代表的なケースと極端なケースを構成するものをよりよく理解するために使用されます。

  • トレンド:トレンドは、一連の値が示す一般的な方向です。 傾向は、追跡されるコンポーネントの一般的な状態を判断する際に、単一の値よりも信頼性が高くなります。

  • ホワイトボックス監視:ホワイトボックス監視は、測定対象のコンポーネントの内部状態へのアクセスに依存する監視を記述するために使用される用語です。 ホワイトボックス監視は、システムの状態を詳細に理解するのに役立ち、問題の原因を特定するのに役立ちます。

  • ブラックボックス監視:ブラックボックス監視とは、入力、出力、および動作のみを確認することにより、システムまたはコンポーネントの外部状態を監視する監視です。 このタイプの監視は、システムのユーザーエクスペリエンスと密接に連携できますが、問題の原因を見つけるのにはあまり役立ちません。

結論

メトリックの収集、コンポーネントの監視、アラートの構成は、本番インフラストラクチャのセットアップと管理の重要な部分です。 システム内で何が起きているのか、どのリソースに注意が必要なのか、何がスローダウンや停止の原因になっているのかを知ることができることは非常に貴重です。 監視設定の設計と実装は困難な場合がありますが、それはチームが作業の優先順位を付け、監視の責任を自動化システムに委任し、インフラストラクチャとソフトウェアが安定性とパフォーマンスに与える影響を理解するのに役立つ投資です。