インフラストラクチャとアプリケーションからメトリックを収集する

前書き

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

https://www.digitalocean.com/community/tutorials/an-introduction-to-metrics-monitoring-and-alerting [メトリック、モニタリング、アラートガイドの紹介]で、関連するコアコンセプトのいくつかについて説明しました。監視ソフトウェアとインフラストラクチャ。 メトリックは、追跡システムの一貫したビューを構築するために監視システムによって処理される主要な素材です。 どのコンポーネントが監視する価値があるか、どの特定の特性に注目すべきかを知ることは、ソフトウェアおよびハードウェアの状態に関する信頼できる実用的な洞察を提供できるシステムを設計する最初のステップです。

このガイドでは、追跡する最も重要なメトリックを識別するために使用される一般的なフレームワークについて説明します。 その後、これらのインジケーターを展開全体のコンポーネントに適用する方法を説明します。 このプロセスでは、最初は個々のサーバーの基本的なリソースに焦点を当ててから、スコープを調整して、ますます大きな関心領域をカバーします。

監視の黄金のシグナル

非常に影響力のあるhttps://landing.google.com/sre/book.html[Google SRE(サイト信頼性エンジニアリング)Book]の分散システムの監視に関する章では、「監視の4つのゴールデンシグナル」と呼ばれる便利なフレームワークを紹介しています。ユーザー向けシステムで測定する最も重要な要素を表します。 これら4つの特性のそれぞれについて、以下で説明します。

待ち時間

レイテンシは、アクションを完了するのにかかる時間の測定値です。 これを測定する方法の詳細はコンポーネントによって異なりますが、一般的な類似点には処理時間、応答時間、または移動時間があります。

レイテンシを測定すると、特定のタスクまたはアクションが完了するまでにかかる時間の具体的な測定値が得られます。 さまざまなコンポーネントのレイテンシをキャプチャすると、システムのさまざまなパフォーマンス特性の全体的なモデルを構築できます。 これは、ボトルネックの発見、アクセスに最も時間が必要なリソースの把握、およびアクションが予想よりも突然長くなった場合の通知に役立ちます。 SRE本の著者は、レイテンシを計算する際に成功したリクエストと失敗したリクエストを区別することの重要性を強調しています。サービスの平均を歪める可能性のある非常に異なるプロファイルを持っている可能性があるためです。

トラフィック

トラフィックは、コンポーネントとシステムの「忙しさ」を測定します。 これにより、サービスの負荷または需要がキャプチャされるため、システムが現在実行している作業量を把握できます。

高いまたは低いトラフィック数が持続する場合は、サービスがより多くのリソースを必要としている可能性があるか、問題によりトラフィックが正しくルーティングされないことを示している可能性があります。 ただし、ほとんどの場合、トラフィックレートは、他の信号によって表面化した問題を理解するのに最も役立ちます。 たとえば、遅延が許容レベルを超えて増加する場合、その時間枠をトラフィックの急増と相関させることができると便利です。 トラフィックを使用して、処理できるトラフィックの最大量と、負荷のさまざまな段階でサービスが低下または失敗する方法を理解できます。

エラー

エラーを追跡して、コンポーネントの状態と、リクエストに適切に応答できない頻度を把握することが重要です。 一部のアプリケーションまたはサービスは、クリーンで既製のインターフェイスでエラーを公開しますが、他のプログラムからデータを収集するには追加の作業が必要になる場合があります。

さまざまなタイプのエラーを区別すると、アプリケーションに影響を与えている問題の正確な性質を簡単に特定できます。 これにより、アラートの柔軟性も高まります。 あるタイプのエラーが表示された場合、すぐにアラートが必要になる場合がありますが、別のタイプの場合は、レートが許容可能なしきい値を下回っている限り心配する必要はありません。

飽和

飽和度は、特定のリソースがどれだけ使用されているかを測定します。 明確な総容量を持つリソースでは、割合または分数が頻繁に使用されますが、明確に定義されていない最大値を持つリソースでは、より創造的な測定が必要になる場合があります。

飽和データは、サービスまたはアプリケーションが効果的に動作するために依存するリソースに関する情報を提供します。 あるコンポーネントによって提供されるサービスは別のコンポーネントによって消費される可能性があるため、飽和は、基礎となるシステムの容量の問題を浮き彫りにする接着指標の1つです。 そのため、1つの層の飽和および遅延の問題は、基礎となる層のトラフィックまたはエラー測定の著しい増加に対応する場合があります。

環境全体で重要なデータを測定する

ガイドラインとして4つのゴールデンシグナルを使用して、システムの階層全体でこれらのメトリックがどのように表現されるかを確認できます。 多くの場合、サービスはより基本的なコンポーネントの上に抽象化層を追加することで構築されるため、展開の各レベルで洞察を追加するようにメトリックを設計する必要があります。

一般的な分散アプリケーション環境に存在するさまざまなレベルの複雑さを見ていきます。

  • 個々のサーバーコンポーネント

  • アプリケーションとサービス

  • サーバーのコレクション

  • 環境依存

  • エンドツーエンドの経験

上記の順序により、後続の各レイヤーで抽象化の範囲とレベルが拡張されます。

個々のサーバーコンポーネントについて収集するメトリック

収集することが重要な基本レベルのメトリックは、システムが依存する基盤となるコンピューターに関連するものです。 現代のソフトウェア開発では、物理コンポーネントと低レベルのオペレーティングシステムの詳細の抽象化にかなりの労力が費やされていますが、すべてのサービスは、基盤となるハードウェアとオペレーティングシステムに依存して動作します。 このため、システムの正常性を理解するための最初のステップは、マシンの基本的なリソースに注目することです。

マシンレベルで収集するメトリックを検討する際には、利用可能な個々のリソースについて検討してください。 これらには、サーバーのハードウェアの表現だけでなく、プロセスやファイル記述子など、OSによって提供されるコアの抽象化も含まれます。 4つのゴールデンシグナルの観点から各コンポーネントを見ると、特定のシグナルが明らかな場合もあれば、推論するのがより難しい場合もあります。

有力なパフォーマンスエンジニアであるhttp://www.brendangregg.com [Brendan Gregg]は、Linuxシステムからコアメトリックを取得して、彼がhttp://www.brendangregg.com/usemethodと呼ぶフレームワークのニーズを満たす多くの方法を概説しています。 .html [パフォーマンス分析のためのUSEメソッド]( u tilization、 s aturation、および e rrors)。 USEメソッドと4つのゴールデンシグナルにはかなりの重複があるため、彼の推奨事項のいくつかを、サーバーコンポーネントから収集するデータを把握するための出発点として使用できます。

  • CPU *を測定するには、次の測定が適切です。

  • レイテンシ:CPUスケジューラの平均または最大遅延

  • トラフィック:CPU使用率

  • エラー:プロセッサ固有のエラーイベント、障害のあるCPU

  • 飽和:実行キューの長さ

  • memory *の場合、信号は次のようになります。

  • 遅延:(なし-良い測定方法を見つけるのは難しく、実行不可能です)

  • トラフィック:使用されているメモリの量

  • エラー:メモリ不足エラー

  • 彩度:OOMキラーイベント、スワップ使用

*ストレージデバイス*の場合:

  • レイテンシ:読み取りおよび書き込みの平均待機時間( + await +

  • トラフィック:I / Oレベルの読み取りと書き込み

  • エラー:ファイルシステムエラー、 `+ / sys / devices +`のディスクエラー

  • 飽和度:I / Oキューの深さ

*ネットワーキング*シグナルは次のようになります。

  • 遅延:ネットワークドライバーキュー

  • トラフィック:1秒あたりの着信および発信バイトまたはパケット

  • エラー:ネットワークデバイスエラー、ドロップされたパケット

  • 飽和:オーバーラン、ドロップされたパケット、再送信されたセグメント

物理リソースの表現とともに、制限が適用されているオペレーティングシステムの抽象化に関連するメトリックを収集することもお勧めします。 このカテゴリに分類される例には、ファイルハンドルとスレッドカウントがあります。 これらは物理的なリソースではなく、オペレーティングシステムによって設定された上限を備えた構造であり、プロセスが過剰に拡張するのを防ぎます。 ほとんどは「+ ulimit +」などのコマンドで調整および設定できますが、これらのリソースの使用状況の変化を追跡すると、ソフトウェアの使用状況に潜在的に有害な変化を検出するのに役立ちます。

アプリケーションおよびサービスについて収集するメトリック

レイヤーを上に移動して、サーバーで実行されるアプリケーションとサービスの処理を開始します。 これらのプログラムは、作業を行うためのリソースとして以前に扱った個々のサーバーコンポーネントを使用します。 このレベルのメトリックは、単一ホストアプリケーションおよびサービスの健全性を理解するのに役立ちます。 これらの構成で最も重要な要因を明確にするために、分散マルチホストサービスを個別のセクションに分けました。

最後のセクションのメトリックは、個々のコンポーネントとオペレーティングシステムの機能とパフォーマンスの詳細を示していますが、ここのメトリックは、アプリケーションが要求する作業をどれだけうまく実行できるかを示しています。 また、アプリケーションがどのリソースに依存しており、それらの制約をどれだけうまく管理しているかを知りたいです。

このセクションのメトリックは、前回使用した一般的なアプローチからの逸脱を表していることに留意することが重要です。 この時点から最も重要なメトリックは、アプリケーションの特性、構成、およびマシンで実行しているワークロードに大きく依存します。 最も重要なメトリックを識別する方法については説明できますが、結果はサーバーが具体的に何を求められているかによって異なります。

クライアントにサービスを提供するアプリケーションの場合、多くの場合、4つのゴールデンシグナルは簡単に選択できます。

  • 遅延:リクエストを完了するまでの時間

  • トラフィック:1秒あたりのリクエスト数

  • エラー:クライアント要求の処理またはリソースへのアクセス時に発生するアプリケーションエラー

  • 彩度:現在使用されているリソースの割合または量

追跡する必要がある重要な指標のいくつかは、依存関係に関連するものです。 多くの場合、これらは個々のコンポーネントに関連する飽和メトリックによって最も適切に表現されます。 たとえば、アプリケーションのメモリ使用率、使用可能な接続、開いているファイルハンドルの数、アクティブなワーカーの数は、物理サーバーのコンテキストに適用された構成の影響を理解するのに役立ちます。

4つのゴールデンシグナルは主に分散マイクロサービス用に設計されているため、クライアントサーバーアーキテクチャを想定しています。 クライアント/サーバーアーキテクチャを使用しないアプリケーションでは、同じ信号が依然として重要ですが、「トラフィック」信号を少し再考する必要があるかもしれません。 これは基本的に忙しさの測定であるため、アプリケーションにとって同じ目的に役立つことを適切に表すメトリックを見つけることです。 詳細は、プログラムの実行内容によって異なりますが、一般的な代替物は、1秒あたりに処理される操作またはデータの数です。

サーバーのコレクションとその通信を測定するメトリック

特に本番環境で運用する場合、ほとんどのサービスは複数のサーバーインスタンスにまたがってパフォーマンスと可用性を向上させます。 このレベルの複雑さにより、監視することが重要な追加の表面積が追加されます。 分散コンピューティングおよび冗長システムはシステムをより柔軟にすることができますが、ネットワークベースの調整は単一ホスト内の通信よりも脆弱です。 堅牢な監視は、信頼性の低い通信チャネルを処理する際のいくつかの困難を軽減するのに役立ちます。

分散サービスの場合、ネットワーク自体を超えて、サーバーグループの正常性とパフォーマンスは、個々のホストに適用される同じ手段よりも重要です。 サービスは単一のホストに限定されると、実行するコンピューターに密接に結び付けられますが、冗長マルチホストサービスは複数のホストのリソースに依存しながら、1台のコンピューターへの直接の依存関係から切り離されます。

このレベルのゴールデンシグナルは、前のセクションのサービスヘルスを測定するシグナルと非常によく似ています。 ただし、グループメンバー間で必要な追加の調整を考慮します。

  • レイテンシ:プールがリクエストに応答する時間、ピアと調整または同期する時間

  • トラフィック:1秒あたりのプールで処理されたリクエストの数

  • エラー:クライアント要求の処理、リソースへのアクセス、またはピアへの到達時に発生するアプリケーションエラー

  • 飽和:現在使用されているリソースの量、現在容量で動作しているサーバーの数、利用可能なサーバーの数。

これらは、単一ホストサービスの重要なメトリックと明確に類似していますが、各信号は分散すると複雑さが増します。 処理は複数のホスト間の通信を必要とする可能性があるため、遅延はより複雑な問題になります。 トラフィックは単一のサーバーの機能の機能ではなく、グループの機能と作業の分散に使用されるルーティングアルゴリズムの効率の要約です。 ネットワーク接続またはホスト障害に関連する追加のエラーモードが導入されています。 最後に、飽和は、ホストで使用可能な結合リソース、各ホストを接続するネットワークリンク、および各コンピューターが必要とする依存関係へのアクセスを適切に調整する機能を含むように拡張されます。

外部依存関係と展開環境に関連するメトリック

収集する最も価値のあるメトリックのいくつかは、直接的な制御の範囲外で、アプリケーションまたはサービスの境界に存在します。 ホスティングプロバイダーやアプリケーションが依存するように構築されているサービスに関連するものを含む外部依存関係。 これらは、直接管理できないリソースを表しますが、独自のサービスを保証する能力を損なう可能性があります。

外部依存関係は重要なリソースを表しているため、完全に停止した場合に利用できる唯一の軽減戦略の1つは、操作を別のプロバイダーに切り替えることです。 これは、コモディティサービスにとって実行可能な戦略であり、それでも事前の計画とプロバイダーとの疎結合が必要です。 緩和が困難な場合でも、アプリケーションに影響する外部イベントの知識は非常に貴重です。

外部依存関係に適用されるゴールデンシグナルは、次のようになります。

  • 遅延:サービスから応答を受信するか、プロバイダーから新しいリソースをプロビジョニングするのにかかる時間

  • トラフィック:外部サービスにプッシュされる作業量、外部APIに対して行われるリクエストの数

  • エラー:サービスリクエストのエラー率

  • 飽和:アカウントで制限されたリソースの使用量(インスタンス、APIリクエスト、許容コストなど)

これらのメトリックは、依存関係の問題を特定し、リソースの枯渇が差し迫っていることを警告し、費用を管理するのに役立ちます。 サービスにドロップインの選択肢がある場合、このデータを使用して、メトリックが問題の発生を示しているときに作業を別のプロバイダーに移動するかどうかを決定できます。 柔軟性の低い状況の場合、少なくともメトリックを使用して、状況に対応し、利用可能な手動の軽減オプションを実装するようオペレーターに警告することができます。

全体的な機能とエンドツーエンドのエクスペリエンスを追跡するメトリック

最高レベルのメトリックは、ユーザーが対話する最も外側のコンポーネントのコンテキストでシステムを介してリクエストを追跡します。 これは、サービスへのリクエストの受信と調整を担当するロードバランサーまたはその他のルーティングメカニズムである可能性があります。 これはシステムとの最初の接点であるため、このレベルでメトリックを収集すると、ユーザーエクスペリエンス全体の概算が得られます。

前述のメトリックは非常に便利ですが、このセクションのメトリックは、アラートを設定するために最も重要な場合がよくあります。 応答の疲労を避けるために、アラート、特にページは、ユーザーエクスペリエンスに明らかな悪影響を与えるシナリオ用に予約する必要があります。 これらのメトリックで表面化した問題は、他のレベルで収集されたメトリックを使用してドリルダウンすることで調査できます。

ここで探す信号は、前に説明した個々のサービスの信号に似ています。 主な違いは、ここで収集するデータの範囲と重要性です。

  • 遅延:ユーザーリクエストを完了するまでの時間

  • トラフィック:1秒あたりのユーザーリクエスト数

  • エラー:クライアント要求の処理中またはリソースへのアクセス中に発生するエラー

  • 彩度:現在使用されているリソースの割合または量

これらのメトリックはユーザーの要求に対応するため、これらのメトリックの許容範囲外の値は、ユーザーへの直接的な影響を示している可能性があります。 顧客向けまたは内部SLA(サービスレベル契約)に適合しない遅延、深刻なスパイクまたはドロップオフを示すトラフィック、エラー率の増加、およびリソースの制約のためにリクエストを処理できないことはすべて、このレベルで。 メトリックが正確であると仮定すると、ここでの値は、可用性、パフォーマンス、および信頼性の目標に対して直接マッピングできます。

結論

このガイドでは、まず、システムの影響のある変化を発見して理解するのに最も役立つ傾向がある4つのゴールデンシグナルについて説明しました。 その後、信号をレンズとして使用して、展開のさまざまな層で追跡する最も重要な要因を評価しました。

システムを上から下まで評価すると、信頼性の高いパフォーマンスの高いサービスを実行するために必要な重要なコンポーネントと相互作用を特定するのに役立ちます。 4つのゴールデンシグナルは、システムの状態を最適に示すメトリックを構造化するための優れた出発点となります。 ただし、ゴールデンシグナルは優れたフレームワークですが、状況に固有のその他のメトリックに注意する必要があることに注意してください。 問題を警告したり、問題が発生した場合のトラブルシューティングに役立つと思われるデータを収集します。

前の投稿:MySQLエラーログにアクセスする方法
次の投稿:MySQLで破損したテーブルを修正する方法