ブログ

Kubernetesでゴールデンシグナルを監視する方法

Kubernetesでゴールデンシグナルを監視する方法

本文の内容は、2020年7月9日にCarlos Arillaが投稿したブログ(https://sysdig.com/blog/golden-signals-kubernetes/を元に日本語に翻訳・再構成した内容となっております。

ゴールデンシグナルメトリクスとは何でしょうか?Kubernetesアプリケーションでゴールデンシグナルをどのように監視しますか?ゴールデンシグナルは、マイクロサービスアプリケーションの問題を検出するのに役立ちます。これらのシグナルは、ユーザーまたはコンシューマーの観点からサービスの広い視野を提供する縮小されたメトリクスのセットであるため、アプリケーションの動作に直接影響している可能性のある潜在的な問題を検出できます。

ゴールデンシグナル、Kubernetesアプリケーションモニタリングの標準

おめでとうございます。アプリケーションがKubernetesに正常にデプロイされました。これは、古い監視ツールがほとんど役に立たず、潜在的な問題を検出できないことを発見した瞬間です。従来の監視ツールは通常、静的な構成ファイルに基づいており、マイクロサービスやコンテナではなく、マシンを監視するように設計されています。コンテナの世界では、物事は急速に変化します。コンテナは信じられないほどのペースで作成および破棄され、特定のサービス検出機能なしに追いつくことは不可能です。最新のSysdigコンテナ使用レポートによると、コンテナの 22%は10秒未満、54%は5分未満です。

最新の監視システムのほとんどは、さまざまな目的のために非常に多様なメトリクスを提供しています。メトリクスに溺れ、アプリケーションに実際に関連するものの焦点を失うことは非常に簡単です。あまりにも多くの無関係なアラートを設定すると、永続的な緊急状態に陥り、「アラートが燃え尽きる」可能性があります。頻繁に使用され、常に負荷アラートが発生しているノードを想像してください。ノードのサービスが機能している限り、それについて何もしていません。アラートが多すぎると、重要なアラートが無関係の海でマスクされてしまうため、アラートがないと同じくらい良くありません。

これは多くの人が直面している問題であり、幸いにも誰かがすでに解決しています。答えは、Google SREハンドブックで最初に使用された4つのゴールデンシグナルです。ゴールデンシグナルは4つのメトリクスであり、ファイナルユーザーであるか、マイクロサービスアプリケーション内の別のサービスであるかに関係なく、そのサービスとやり取りするアクターから見た、アプリケーションの実際の状態とパフォーマンスの非常に良いアイデアを提供します。

20200710-title.jpg

Denise Yu@ deniseyu21)からの画像

ゴールデンシグナルメトリクス:レイテンシーの説明

レイテンシーは、システムがサービスに対するリクエストを処理するのにかかる時間です。これは、パフォーマンスの低下の問題を検出するための重要な兆候です。

レイテンシーを使用する場合、誤解を招く可能性があるため、平均値を使用するだけでは不十分です。たとえば、平均100ミリ秒のレスポンスタイムを示すサービスがあります。この情報だけでかなり良いと考えることができますが、ユーザーからのフィードバックは遅いと認識されているということです。

この矛盾に対する答えは、標準偏差などのさまざまな統計パラメーターを使用して発見できます。これにより、レイテンシー値のばらつきがわかります。2種類のリクエストがあり、1つは非常に高速で、もう1つはデータベースに負荷がかかるために遅い場合はどうでしょう。一般的なユーザーインタラクションで1つの遅い要求と10つの速い要求がある場合、平均はおそらくかなり低くなりますが、アプリケーションは遅くなります。平均値だけでなく、ボトルネック分析も重要です。

この動作を回避する優れたツールは、ヒストグラムメトリクスです。これらは、異なるレイテンシーしきい値の下でのリクエストの数を示し、パーセンタイルで集計できるようにします。パーセンタイルは、メジャーの特定のパーセンテージが下回る値です。たとえば、p99は、私のリクエストの99%がパーセンタイルよりもレイテンシ値が低いことを示しています。

20200710-01.png

スクリーンショットを見るとわかるように、平均レイテンシーは許容範囲ですが、パーセンタイルを見ると、値に多くのばらつきがあることがわかり、実際のレイテンシーの認識がよくわかります。異なるパーセンタイルは異なる情報を表します。p50は通常、一般的なパフォーマンスの低下を表し、p95またはp99は、システムの特定の要求またはコンポーネントのパフォーマンスの問題の検出を可能にします。

リクエストの1%で高いレイテンシーは大きな問題ではないと思われるかもしれませんが、今度は、複数のリクエストを完全にロードして表示する必要があるWebアプリケーションを考えてみてください。この一般的なシナリオでは、1%のリクエストでレイテンシーが高くなると、最終ユーザーの割合が高くなる可能性があります。これらの複数のリクエストの1つがアプリケーション全体のパフォーマンスを低下させるためです。

レイテンシー値を分析するためのもう1つの便利なツールはAPDEXスコアであり、SLA条件が与えられれば、パーセンタイルに基づいてシステム状態がどの程度良好であるかについての一般的な考えを提供できます。

ゴールデンシグナルメトリクス:エラーの説明

サービスによって返されるエラーの割合は、より深い問題の非常に良いメトリクスです。明示的なエラーだけでなく、暗黙的なエラーも検出することが非常に重要です。

明示的なエラーは、あらゆる種類のHTTPエラーコードです。エラーコードは応答ヘッダーから簡単に取得できるため、これらは簡単に識別でき、多くのシステム全体で一貫しています。これらのエラーの例としては、認証エラー(503)、コンテンツが見つからない(404)、サーバーエラー(500)などがあります。エラーの説明は非常に具体的な場合があります(418 - I'm a teapot)。

一方、暗黙のエラーは検出が難しい場合があります。HTTP応答コード200が含まれているが、コンテンツにエラーメッセージが含まれる要求はどうですか?さまざまなポリシー違反もエラーと見なす必要があります。

  • タイムアウトよりも時間がかかったリクエストとして、HTTP応答を生成しないエラー。
  • 明らかに成功したリクエストのコンテンツエラー。

ダッシュボードを使用してエラーを分析する場合、平均値またはパーセンタイルは意味がありません。エラーの影響を正しく確認するには、レートを使用するのが最善の方法です。1秒あたりのエラーで終了するリクエストの割合は、システムがいつ失敗し始めたのか、どのような影響があるのかについての詳細な情報を提供します。

ゴールデンシグナルメトリクス:トラフィック/接続の説明

トラフィックまたは接続は、時間単位あたりのサービスの使用量のメトリクスです。APIへのリクエスト数やストリーミングアプリが消費する帯域幅など、システムの性質に応じて、さまざまな値を設定できます。

応答コードやビジネスロジックに関連するさまざまなパラメーターに応じてトラフィックインジケーターをグループ化すると便利です。

ゴールデンシグナルメトリクス:サチュレーションの説明

このメトリクスは、質問に対する答えである必要があります。私のシステムはどの程度満杯ですか?

通常、サチュレーションは最大容量のパーセンテージで表されますが、サチュレーションを測定する方法はシステムごとに異なります。パーセンテージは、アプリケーションから直接または推定に基づいて取得されたユーザーまたは要求の数を意味します。

ほとんどの場合、サチュレーションはCPUやメモリなどのシステムメトリクスから導出されるため、計測に依存せず、Prometheusノードエクスポーターなどのさまざまな方法を使用してシステムから直接収集されます。Kubernetesノードからシステムメトリクスを取得することは、他のシステムと基本的に同じです。結局のところ、それらはLinuxマシンです。

適切なメトリクスを選択し、できるだけ使用しないことが重要です。サチュレーションを正しく測定するための鍵は、システムのパフォーマンスを制約しているメトリクスを選択することです。アプリケーションがプロセッサを集中的に使用する場合は、CPU負荷を使用します。メモリを集中的に使用する場合は、使用済みメモリを選択します。多くの場合、サチュレーションメトリクスを選択するプロセスは、アプリケーションのボトルネックを検出するための優れた演習です。

通常、サチュレーションが80%を超えるとパフォーマンスが大幅に低下するため、ある程度のマージンでサチュレーションを検出するためにアラートを設定する必要があります。

KubernetesでのゴールデンシグナルとREDメソッドとUSEメソッド

アプリケーションの効率的な監視システムを設計する方法はいくつかありますが、一般的には4つのゴールデンシグナルに基づいています。REDメソッドなどの一部のメソッドは、リクエスト率、エラー、レイテンシーなどのオーガニックメトリクスをより重要視します。その他、USEメソッドなど、システムレベルのメトリクスと、CPU、メモリ、I/Oの使用などの低レベルの値に焦点を当てています。それぞれのアプローチをいつ使用する必要があるのでしょうか?

RED方式

REDメソッドは、アプリケーションを実行するインフラストラクチャーを考慮せずに、アプリケーションのパラメーターに焦点を当てています。これはサービスの外観であり、クライアントがサービスをどのように見るかを示します。ゴールデンシグナルは、システムメトリクスから必然的に暗示されるサチュレーション値を追加することにより、インフラコンポーネントを追加しようとします。このようにして、すべてのサービスがそれを実行するインフラストラクチャーに不可避的に結び付けられるため、より深い見方をすることができます。たぶん、外見はいいかもしれませんが、サチュレーション状態は、サービスが障害から「どれくらい」離れているかを理解するのに役立ちます。

USEメソッド

USEメソッドは、リクエストのエラーを含め、リソースの使用率を強調し、問題の唯一の外部インジケーターとして使用します。この方法では、サービスの一部に影響を与える問題を回避できます。クエリーの最適化が不適切でデータベースが遅い場合はどうなりますか?レイテンシーは増加しますが、サチュレーション状態では目立ちません。ゴールデンシグナルは、外部の監視可能パラメータとシステムパラメータを含む両方の方法の最良のものを取得しようとします。

そうは言っても、これらの方法にはすべて共通の目標があります。つまり、インシデントの検出を容易にするために、複雑なシステムを均質化および簡略化しようとします。少数のメトリクスで問題を検出できる場合、監視を多数のシステムにスケーリングするプロセスはほとんど簡単です。

モニタリングを簡素化、良い副作用

良い副作用として、インシデント検出に関連するメトリクスの数を減らすと、疑いもなく実際の問題になるか、明確な直接的なアクションパスがないメトリクスに設定された任意のアラートによるアラートの疲労を減らすことができます。

弱点として、単純化すると受信した情報の詳細が削除されます。ゴールデンシグナルが進行中または将来の問題を検出するための優れた方法であるにもかかわらず、問題が検出されると、調査プロセスでは問題の根本原因をより深く掘り下げるためにさまざまな入力を使用する必要があることに注意することが重要です。ログ、カスタムメトリクス、またはさまざまなメトリクスの集計など、手元にあるツールはトラブルシューティングプロセスに役立ちます。

Kubernetesでのゴールデンシグナルメトリクス計測

Prometheusメトリクス/カスタムメトリクスを使用したコードインストルメンテーション

Prometheusでゴールデンシグナルを取得するには、コードの変更(計測)が必要です。このトピックは非常に広範であり、Prometheusメトリクス/ OpenMetricsコードインストルメンテーションなど、以前の多くの記事で取り上げられています。

Prometheusはメトリクス収集のデファクトスタンダードとして位置付けられているため、ほとんどの言語には、アプリケーションにカスタムメトリクスをより便利な方法で実装するためのライブラリがあります。それにもかかわらず、カスタムメトリクスをインスツルメントするには、アプリケーションの機能を深く理解する必要があります。

不完全に実装されたコードインストルメンテーションは、時系列のカーディナリティ爆撃と、メトリクス収集システムを崩壊させる現実の機会をもたらす可能性があります。たとえば、リクエストIDをラベルとして使用すると、リクエストごとに時系列が生成されます(実際のユースケースで見られます)。明らかに、これは情報を収集するために必要なリソースを増加させ、ダウンタイムを引き起こす可能性があるため、監視システムに望ましくないものです。正しい集計方法を選択することは、監視アプローチを成功させる鍵となります。

Sysdig eBPFシステムコールの可視性(インストルメンテーションなし)

Sysdigモニターは、eBPFプロトコルを使用して、すべてのシステムコールの情報をカーネルから直接取得します。このようにして、コードやコンテナランタイムのどちらでも、アプリケーションを変更する必要はありません。ノードで実行されているのは、コード(またはバイナリ)を変更せずに、ライブラリの正確なバージョンを使用して構築したコンテナです。

システムコールは、実行中のプロセス、メモリ割り当て、ネットワーク接続、ファイルシステムへのアクセス、リソースの使用状況などに関する情報を提供します。この情報を使用して、システムで何が起こっているかについての多くの情報を提供する意味のあるメトリクスを取得することが可能です。

ゴールデンシグナルは、すぐに使用できるメトリクスの一部であり、レイテンシー、リクエストレート、エラー、サチュレーションを提供します。これらのメトリクスはすべて、Kubernetes APIから収集された情報と関連付けられます。この相関により、意味のある集計を行い、複数のディメンションを使用して情報を表すことができます。

  • ノードごとのグループレイテンシー:これは、Kubernetesインフラストラクチャーのさまざまな問題に関する情報を提供します。
  • デプロイメントごとのグループレイテンシー:これにより、さまざまなマイクロサービスまたはアプリケーションの問題を追跡できます。
  • ポッドごとのグループレイテンシー:デプロイメント内のポッドが正常でない可能性があります。

これらのさまざまなレベルの集約により、データをスライスして問題を特定し、クラスターからノード、デプロイ、ポッドまで、Kubernetesエンティティのさまざまなレベルを掘り下げることで、トラブルシューティングタスクを支援します。

インストルメンテーションコードAPM / Opentracing

さまざまなAPM(アプリケーションパフォーマンス監視)アプリケーションは、特定のアクションを担当するコードの検索など、アプリケーションに関する非常に具体的な情報を提供できます。これには、コードの変更またはアプリケーションコンテナの調整を伴うインストルメンテーションが必要です。

この方法では、コードを明示的に、または(バイナリのプリロードまたは変更されたランタイムによって)暗黙的に、アプリケーションにライブラリをロードするモニタリングエージェントが必要です。つまり、本番環境で実行されているものは、開発時にプログラミングした正確なコードではない可能性があり、予期しない問題や制御されていないソフトウェアアップデートのリスクを意味します。インストルメンテーションコードのクラッシュが原因で、アプリケーションがクラッシュすることさえあります。APMがすべてのデータを取得するにはさらに多くの作業が必要になるため、パフォーマンスの低下も問題になる可能性があります。

さらに、インストルメンテーションでサードパーティのコードを実行しています。セキュリティチームはAPMライブラリのコードを監査していますか?

オープントレーシングは不可知論的な計測方法を提供するため、商用APMの優れた代替手段となります。多くの異なるオープンソースや商用ソリューションで使用でき、ライブラリの信頼性とセキュリティを管理する優れたコミュニティがあります。もう1つ、CNCFの傘下にあります。

APMとゴールデンシグナルの関係は、サチュレーションなどの一部のパラメーターがインフラストラクチャーに関連しているため、どういうわけか複雑であり、多くの場合、これはAPMアプローチの最も弱い部分です。

このトピックの詳細については、こちらをご覧ください:コードのインストルメント化方法:カスタムメトリクス vs APM vs OpenTracing

Istio

Istioはサービスメッシュであり、Kubernetesにデプロイされたアプリケーションのレイヤーであり、カナリアデプロイ、インテリジェントルーティング、サーキットブレーカー、ロードバランシング、ネットワークポリシーの適用、ヘルスチェックなどのネットワーク機能を管理するためのさまざまな機能を提供します。

Istioが提供する機能の1つは、トレース機能が制限されたサービスの可視性です。レイテンシー、エラー、リクエストに関する情報を提供するため、ゴールデンシグナルを簡単に取得するための非常に優れたアプローチです。Istioメトリクスの取得について詳しくは、ブログ:Istioを監視する方法をご覧ください。

Kubernetesでのゴールデンシグナルの実用的な例

ゴールデンシグナルの使用を説明する例として、Prometheusインストルメンテーションを使用した簡単なgoアプリケーションの例をデプロイしました。このアプリケーションは、レイテンシーの使用可能な情報を提供するために、0〜12秒のランダムな遅延を適用します。トラフィックはcurlで生成され、いくつかの無限ループがあります。

レイテンシーとリクエストに関連するメトリクスを収集するためのヒストグラムが含まれています。これらのメトリクスは、最初の3つのゴールデンシグナル(レイテンシー、リクエストレート、エラーレート)を取得するのに役立ちます。この例では、ノードのCPUの割合を使用して、Prometheusとnode-exporterで直接サチュレーションを取得します。

20200710-02.png

view raw

PrometheusとGrafanaを使用してアプリケーションをKubernetesクラスターにデプロイし、ゴールデンシグナルを使用してダッシュボードを生成しました。ダッシュボードのデータを取得するために、次のPromQL文を使用しました。

レイテンシー:

sum(greeting_seconds_sum)/sum(greeting_seconds_count)  //Average
histogram_quantile(0.95, sum(rate(greeting_seconds_bucket[5m])) by (le)) //Percentile p95 

リクエストレート:

sum(rate(greeting_seconds_count{}[2m]))  //Including errors
rate(greeting_seconds_count{code="200"}[2m])  //Only 200 OK requests 

1秒あたりのエラー:

sum(rate(greeting_seconds_count{code!="200"}[2m]))

サチュレーション:

node-exporterで取得したCPU使用率を使用しました:

100 - (avg by (instance) (irate(node_cpu_seconds_total{}[5m])) * 100)

結果ダッシュボード:

このようにして、ゴールデンシグナルを含むこのダッシュボードを取得します。

20200710-03.png

このクラスターには、Sysdigエージェントもインストールされています。Sysdigを使用すると、インストルメンテーションを使用せずにこれらの同じゴールデンシグナルを取得できます(ただし、SysdigはPrometheusメトリクスも取り込むことができます!)。Sysdigを使用すると、デフォルトのダッシュボードを使用でき、同じ意味のある情報をすぐに入手できます。

20200710-04.png

アプリケーションの性質に応じて、さまざまな集計を行うことができます。

  • レスポンスコードで分割されたレスポンス時間
  • レスポンスコードで分割されたエラーレート
  • サービスまたはデプロイメントごとのCPU使用率

Kubernetesのゴールデンシグナルに関する注意事項

ゴールデンシグナルは、考えられる問題を検出するための最良の方法の 1つですが、問題が検出されたら、追加のメトリクスと手順を使用して問題をさらに診断する必要があります。問題の検出と解決は2つの異なるタスクであり、アプリケーションの個別のツールとビューが必要です。

平均は常に意味があるわけではありません。特にレイテンシーに関しては、標準偏差もチェックしてください。アプリケーションのリクエストパスを考慮して、ボトルネックを探します。平均の代わりに(またはそれらに加えて)パーセンタイルを使用する必要があります。

CPUまたは負荷が高くなるたびに警告することは意味がありますか?おそらく違います。「アラートバーンアウト」設定アラートは、問題を明確に示すパラメータにのみ設定しないでください。実用的なアラートではない場合は、削除してください。

パラメータは見た目は良くないが、アプリケーションに直接影響を与えていない場合は、アラートを設定しないでください。代わりに、バックログにタスクを作成して動作を分析し、長期的に考えられる問題を回避します。

この記事は2019年6月11日に最初に公開され、それ以降更新されています。

関連コンテンツ

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top