開発者ドキュメント

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

getdocs

序章

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

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

メトリック、監視、およびアラートとは何ですか？

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

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

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

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

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

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

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

モニタリングとは何ですか？

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

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

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

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

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

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

アラートとは何ですか？

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

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

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

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

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

追跡することが重要な情報の種類は何ですか？

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

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

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

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

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

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

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

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

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

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

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

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

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

外部の依存関係の指標

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

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

監視対象の選択に影響を与える要因

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

収集して行動することを選択することに影響を与える可能性のあるいくつかの要因は次のとおりです。

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

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

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

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

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

信頼性と信頼性

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

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

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

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

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

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

役立つ関連機能は、既存のデータセットを簡単にインポートする機能です。 履歴メトリックの情報密度を下げることが魅力的なオプションではない場合は、古いデータを長期ストレージソリューションにオフロードすることをお勧めします。 この場合、システム内で古いデータを維持する必要はありませんが、分析または使用する場合は、データを一括で再ロードできる必要があります。

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

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

新しい指標やインフラストラクチャの追跡を簡単に開始できます

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

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

柔軟で強力なアラート

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

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

追加の用語

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

結論

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

モバイルバージョンを終了