序章

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

メトリック、監視、およびアラートガイドの概要では、ソフトウェアとインフラストラクチャの監視に関連するいくつかのコアコンセプトについて説明しました。 メトリックは、追跡対象のシステムのまとまりのあるビューを構築するために監視システムによって処理される主要な資料です。 どのコンポーネントを監視する価値があり、どの特定の特性を確認する必要があるかを知ることは、ソフトウェアとハードウェアの状態に関する信頼できる実用的な洞察を提供できるシステムを設計するための最初のステップです。

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

モニタリングの黄金の信号

非常に影響力のあるGoogleSRE（サイト信頼性エンジニアリング）ブックでは、分散システムの監視に関する章で、測定する最も重要な要素を表す監視の4つの黄金信号と呼ばれる便利なフレームワークを紹介しています。ユーザー向けシステムで。 これらの4つの特性のそれぞれについて以下で説明します。

レイテンシー

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

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

トラフィック

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

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

エラー

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

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

飽和

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

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

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

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

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

  • 個々のサーバーコンポーネント
  • アプリケーションとサービス
  • サーバーのコレクション
  • 環境依存性
  • エンドツーエンドのエクスペリエンス

上記の順序は、後続の各レイヤーで抽象化の範囲とレベルを拡張します。

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

収集することが重要な基本レベルのメトリックは、システムが依存している基盤となるコンピューターに関連するメトリックです。 最新のソフトウェア開発では、物理コンポーネントと低レベルのオペレーティングシステムの詳細を抽象化するためにかなりの努力が払われていますが、すべてのサービスは、基盤となるハードウェアとオペレーティングシステムに依存して作業を行っています。 このため、マシンの基本的なリソースを監視することは、システムの状態を理解するための最初のステップです。

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

影響力のあるパフォーマンスエンジニアであるBrendanGregg は、パフォーマンス分析のための USEメソッド（ u tilization、 s aturation、および e rrors）。 USEメソッドと4つのゴールデンシグナルの間には大きな重複があるため、サーバーコンポーネントから収集するデータを把握するための出発点として、彼の推奨事項のいくつかを使用できます。

CPU を測定するには、次の測定が適切な場合があります。

  • レイテンシー：CPUスケジューラーの平均または最大遅延
  • トラフィック：CPU使用率
  • エラー：プロセッサ固有のエラーイベント、CPUの障害
  • 飽和：実行キューの長さ

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

  • レイテンシー:(なし-適切な測定方法を見つけるのは難しく、実用的ではありません）
  • トラフィック：使用されているメモリの量
  • エラー：メモリ不足エラー
  • 飽和：OOMキラーイベント、スワップ使用

ストレージデバイスの場合：

  • レイテンシ：平均待機時間（await）読み取りおよび書き込み用
  • トラフィック：I/Oレベルの読み取りと書き込み
  • エラー：ファイルシステムエラー、ディスクエラー /sys/devices
  • 飽和：I/Oキューの深さ

networking 信号は、次のようになります。

  • レイテンシー：ネットワークドライバーキュー
  • トラフィック：1秒あたりの着信および発信バイトまたはパケット
  • エラー：ネットワークデバイスエラー、パケットのドロップ
  • 飽和：オーバーラン、パケットのドロップ、セグメントの再送信

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

アプリケーションとサービスのために収集するメトリック

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

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

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

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

  • レイテンシー：リクエストを完了する時間
  • トラフィック：1秒あたりのリクエスト数
  • エラー：クライアント要求の処理またはリソースへのアクセス時に発生するアプリケーションエラー
  • 飽和：現在使用されているリソースの割合または量

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

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

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

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

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

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

  • レイテンシー：プールがリクエストに応答する時間、ピアと調整または同期する時間
  • トラフィック：1秒あたりにプールによって処理されたリクエストの数
  • エラー：クライアント要求の処理、リソースへのアクセス、またはピアへの到達時に発生するアプリケーションエラー
  • 飽和：現在使用されているリソースの量、現在容量で稼働しているサーバーの数、使用可能なサーバーの数。

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

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

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

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

  • レイテンシー：サービスからの応答の受信またはプロバイダーからの新しいリソースのプロビジョニングにかかる時間
  • トラフィック：外部サービスにプッシュされる作業の量、外部APIに対して行われるリクエストの数
  • エラー：サービスリクエストのエラー率
  • 飽和：使用されるアカウント制限付きリソースの量（インスタンス、APIリクエスト、許容可能なコストなど）

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

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

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

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

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

  • レイテンシー：ユーザーリクエストを完了する時間
  • トラフィック：1秒あたりのユーザーリクエスト数
  • エラー：クライアント要求の処理またはリソースへのアクセス時に発生するエラー
  • 飽和：現在使用されているリソースの割合または量

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

結論

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

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