はじめに

このブログはパート２で、パート１の記事では、Kubernetesクラスターの監視は、適切なツールを使用すれば克服できる課題であることを理解しました。 また、デフォルトのKubernetesダッシュボードでは、クラスター内で実行されているさまざまなリソースを監視できることも理解しましたが、これは非常に基本的なことです。 cAdvisor、Kube-state-metrics、Prometheus、Grafana、Kubewatch、Jaeger、MetricFireなどのツールとプラットフォームを提案しました。

このPart2のブログでは、観察可能なシステムを構築するための4つのゴールデンシグナルを見てから、Prometheusがこれらのルールの適用にどのように役立つかを見ていきます。

開始するには、MetricFireの無料トライアルにサインアップしてください。このトライアルでは、ほとんどセットアップなしでHostedPrometheusを試すことができます。

何が壊れているのか、そしてその理由は？

DevOpsチームの仕事の大部分は、開発チームが運用上の責任に参加できるようにすることです。 DevOpsは、アプリケーションをより迅速に、より安価に、より高品質で設計、開発、および展開するための、実践方法に関するさまざまなITプレーヤー間の協力に基づいています。

アプリケーションの実行を担当するには、DevOpsチームが本番環境で監視する適切なメトリックを選択することを含め、アプリケーションの監視などの他のサブタスクに関与する必要もあります。監視対象と表示されるデータは、DevOpsアプローチに影響を与えます。

また、従来の監視タスクにチームを参加させるだけでは不十分です。監視を使用すると、本番インフラストラクチャで何が起こっているかを識別できます。サーバーまたはサーバーのプールに大量のアクティビティがあるかどうかを判別できます。ただし、可観測性（またはホワイトボックスモニタリング）を使用すると、問題が発生する前に問題を検出できます。

適切なメトリクスの選択に関しては、すぐに使用できる方法論はありません。すべては、チームの技術的およびビジネス上のニーズによって異なります。ただし、次のアプローチを参照してみるのもいいかもしれません。

• GoogleのGoogleSREブック
• ブレンダン・グレッグのUSE Method
• トムウィルキーのRED Method

GoogleのFour Golden Signalsに基づくkubernetesベースの本番システムで監視する必要のある一般的なメトリクスをいくつかを紹介していきたいと思います。

分散システムの監視：Four Golden Signals

有名なGoogleSREの本の第6章で、Googleは常に監視される4つの主要なシグナルを定義しています。 これらの4つのシグナルは、遅延、トラフィック、エラー、飽和の4つのゴールデンシグナルと呼ばれます。

これらのシグナルは、アプリケーションの高い可用性を確保するために不可欠であるため、非常に重要です。 それぞれの意味を簡単に説明していきます。

レイテンシー

レイテンシーは、リクエストを送信してレスポンスを受信するのに必要な時間です。 通常はサーバー側で測定されますが、ネットワーク速度の違いを考慮してクライアント側で測定することもできます。 運用チームはサーバー側の遅延を最も制御できますが、クライアント側の遅延はエンドクライアントにとってより適切です。

選択するターゲットしきい値は、アプリケーションの種類によって異なる場合があります。 また、失敗したリクエストはさらに処理しなくてもすぐに失敗することが多いため、成功したリクエストと失敗したリクエストのレイテンシを明確に追跡する必要があります。

トラフィック

トラフィックは、ネットワークを通過する要求数の尺度です。 これらは、WebサーバーまたはAPIサーバーに送信されるHTTPリクエスト、または処理キューに送信されるメッセージです。 トラフィックのピーク期間は、インフラストラクチャにストレスを与え、インフラストラクチャを限界まで押し上げる可能性があり、ダウンストリームに影響を与える可能性があります。 そのため、トラフィックが重要なシグナルです。 これは、同じ結果をもたらす2つの異なる根本原因を区別するのに役立ちます。システム構成の問題はトラフィックが少ない場合でも問題を引き起こす可能性があるため、容量の問題と不適切なシステム構成です。

分散システム、特にKubernetesの場合、これは将来の需要を満たすために事前に容量を計画するのに役立ちます。

エラー

エラーは、コードのバグ、未解決の依存関係、またはインフラストラクチャの構成エラーについて教えてくれます。 エラー率のスパイクを生成するデータベース障害の例を取り上げ、通常は結果に同じスパイクを引き起こすネットワークエラーの場合と比較します。 エラー率だけでは問題がわからない。

Kubernetesデプロイメントの変更後、エラーは、テスト中に検出されなかった、または本番システムにのみ表示されたコードのバグを示している可能性があります。

したがって、エラーメッセージは、問題に関するより正確なレポートを提供します。 エラーは、レイテンシを人為的に削減するなど、他の指標にも影響を与える可能性があり、エラーは繰り返し試行を引き起こし、Kubernetesクラスターを溺死させる可能性があります。

サチュレーション

サチュレーションは、ネットワークやCPUなどのサーバーのリソースに対する負荷として定義されます。 各リソースには制限があり、それを超えるとパフォーマンスが低下するか、完全に使用できなくなります。

サチュレーションは、ディスク容量（1秒あたりの読み取り/書き込み操作）、CPU使用率、メモリ使用量、およびその他のリソースなどのリソースに適用されます。 Kubernetesクラスターの設計では、サービスのどの部分が最初にサチュレーション状態になる可能性があるかに対応する必要があることを認識する必要があります。

多くの場合、使用されるメトリックは先行メトリクスであるため、パフォーマンスが低下する前に容量を調整できます。 たとえば、ネットワークがサチュレーション状態になると、パケットがドロップオフする可能性があります。 また、CPUがいっぱいになると、応答が遅れる可能性があり、ディスクがいっぱいになると、ディスクの書き込みエラーやデータの損失が発生する可能性があります。

Prometheusと4つのゴールデンシグナル

Prometheusは、監視と警告を行うためのオープンソースツールです。 SoundCloudによって開発され、その後CNCFに寄付されました。 このツールは、メトリックエクスポータを使用して、ネイティブまたは間接的に他のアプリケーションと統合します。 Prometheus Operatorを使用すると、Kubernetes上でのPrometheusのインストールと管理が予想よりも簡単になります。 Prometheus Operatorは、Kubernetesクラスター内でPrometheusAlertmanagerとGrafanaを実行する簡単な方法です。 では、4つのゴールデンシグナルを実装するために監視するPrometheusのメトリクスは何でしょうか？

Prometheusによって収集および保存されるメトリックはたくさんありますが、それらのいくつかをデモンストレーションとして見ることにします。 したがって、次のリストはすべてを網羅しているわけではありません。

まず、「http_requests_total」は、発行されたHTTP応答の数をカウントし、コードとメソッドによって分類します。 トラフィックの監視に使用できます。

例：

sum(rate(http_requests_total[1m]))

「node_network_transmit_bytes」や「node_network_receive_bytes」などの他のメトリックを使用してトラフィックを監視できます。 適切なメトリックの選択は、測定する必要のあるものとユースケースによって異なります。 HTTPリクエストTCPリクエスト、送受信されたバイトを監視したいのか、それは人それぞれとなります。

もう1つのゴールデンシグナルであるレイテンシーは、「http_request_duration_seconds」などのメトリックを使用して観察することもできます。 PromQLを使用すると、たとえば、400ミリ秒以内に完了したリクエストの割合を取得できます。

sum(rate(http_request_duration_seconds_bucket{le="0.4"}[1m])) / sum(rate(http_request_duration_seconds_count[1m]))

エラーの割合は、「http_status_500_total」や「http_responses_total」などのメトリックを使用して、ほぼ同じ方法で測定できます。

rate(http_status_500_total [1m]) / rate(http_requests_total [1m])

または、

sum(rate(http_responses_total{code="500"}[1m])) / sum(rate(http_responses_total[1m]))

サチュレーションを測定するには、通常、メモリ、ディスク、CPUなどのシステムメトリックを参照する必要があります。 これらのタイプのメトリックはKubernetesノードから直接収集され、インストルメンテーションに依存しません。 たとえば、CPUの飽和状態を監視するには、ノードエクスポータからの「cpu」などのメトリックを時間の平均関数と組み合わせて使用する必要があります。

avg_over_time(cpu[1m])

ディスクなどの他のリソースに同じものを適用する必要がある場合は、次のようなものを使用できます。

avg_over_time (node_disk_io_time_seconds_total[1m])

まとめ

Kubernetesクラスターの設計とそれが実行するサービスの性質を理解すれば、適切なメトリクスを簡単に選択でき、4つのゴールデンシグナルは、観測可能なシステムの設計に役立ちます。 ただし、Prometheusの機能を最大限に活用するには、基本的なメトリクスの使用からAlertManagerなどの他の高度な機能に拡張してから、データとアラートをGrafanaダッシュボードに統合する必要があります。 AlertManagerの使用方法の詳細については、AlertManagerの上位5つの落とし穴に関する記事をご覧ください。 また、MetricFireの無料トライアルにサインアップ、またはデモを予約して、Prometheusメトリック監視について詳しく、お問い合わせください。