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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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