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

システムの状態を理解することは、アプリケーションとサービスの信頼性と安定性を確保するために不可欠です。 デプロイメントの健全性とパフォーマンスに関する情報は、チームが問題に対応するのに役立つだけでなく、自信を持って変更を加えるためのセキュリティも提供します。 この洞察を得る最良の方法の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つの特性のそれぞれについて、以下で説明します。

ガイドラインとして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つのゴールデンシグナルにはかなりの重複があるため、彼の推奨事項のいくつかを、サーバーコンポーネントから収集するデータを把握するための出発点として使用できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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