|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
監視のベストプラクティス
適切な監視とアラートルールの設定は、プロダクションワークロードを安全かつ信頼性高く運用するために重要です。KubernetesやRancherを使用する場合も同様です。幸いなことに、統合された監視とアラート機能により、このプロセス全体が大幅に簡素化されます。
Rancher監視ドキュメントは、完全なPrometheusおよびGrafanaスタックのセットアップ方法を説明しています。これにより、クラスター内のすべてのシステムおよびKubernetesコンポーネントから監視データを収集し、開始するための適切なダッシュボードとアラートを提供します。しかし、信頼性の高いセットアップを実現するためには、自分のワークロードを監視し、PrometheusとGrafanaを自分の特定のユースケースやクラスターサイズに適応させる必要があります。この文書は、そのためのベストプラクティスを提供することを目的としています。
何を監視するか
Kubernetes自体と、その内部で実行されているアプリケーションは、異なるコンポーネントが相互に作用する分散システムを形成します。システム全体および各個別のコンポーネントについて、パフォーマンス、可用性、信頼性、スケーラビリティを確保する必要があります。詳細な情報を提供する良いリソースは、Googleの無料の サイト信頼性エンジニアリングブックであり、特に 分散システムの監視に関する章が参考になります。
Prometheusリソース使用量の設定
統合監視スタックをインストールする際、Rancherはクラスターのサイズやその中で実行されているワークロードに依存するいくつかの設定を構成することを許可します。この章では、これらについてより詳細に説明します。
ストレージとデータ保持
Prometheusに必要なストレージの量は、保存する時系列とラベルの量、および設定したデータ保持に直接関連しています。Prometheusは長期的なメトリクスストレージとして使用されることを意図していないことに注意することが重要です。データ保持期間は通常数日であり、数週間や数ヶ月ではありません。その理由は、Prometheusが保存されたメトリクスに対して集約を行わないためです。これは素晴らしいことです。なぜなら、集約はデータを希薄化する可能性がありますが、必要なストレージが時間とともに直線的に増加することも意味するからです。
必要なストレージを計算する一つの方法は、このクエリを使用してPrometheusのストレージチャンクの平均サイズを見ることです。
rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[1h])
次に、1秒あたりのデータ取り込み率を確認してください。
rate(prometheus_tsdb_head_samples_appended_total[1h])
その後、これを保持時間で掛け算し、バッファとして数パーセントを追加します。
average chunk size in bytes * ingestion rate per second * retention time in seconds * 1.1 = necessary storage in bytes
必要なストレージを計算する方法についての詳細は、この ブログ記事で確認できます。
Prometheusのストレージ概念についての詳細は、 Prometheusのドキュメントで読むことができます。
CPUおよびメモリのリクエストと制限
大規模なKubernetesクラスターでは、Prometheusはかなりのメモリを消費する可能性があります。Prometheusが必要とするメモリの量は、保存する時系列の数とラベルの数、そしてそれらが記録されるスクレイプ間隔に直接関連しています。
必要なメモリを計算する方法についての詳細は、この ブログ記事で確認できます。
必要なCPUの量は、実行しているクエリの数に関連しています。
フェデレーションと長期ストレージ
Prometheusは長期間メトリクスを保存することを目的としていませんが、短期間のストレージのためにのみ使用されるべきです。
いくつか、またはすべてのメトリクスを長期間保存するためには、Prometheusの リモート読み取り/書き込み機能を活用して、 Thanos、 InfluxDB、 M3DBなどのストレージシステムに接続できます。この ブログ記事に例のセットアップがあります。
カスタムワークロードのスクレイピング
統合されたRancher Monitoringは、クラスターのノードやシステムコンポーネントからシステムメトリクスをすでにスクレイピングしていますが、Kubernetesにデプロイしたカスタムワークロードもデータのためにスクレイピングされるべきです。そのためには、Prometheusを設定して、特定の間隔でアプリケーションのエンドポイントにHTTPリクエストを行うことができます。これらのエンドポイントは、その後、Prometheus形式でメトリクスを返す必要があります。
一般的に、クラスター内で実行されているすべてのワークロードからデータをスクレイピングしたいので、アラートや問題のデバッグに使用できます。インシデント発生時に初めて、実際に必要なメトリクスが求められることに気づくことがよくあります。すでにスクレイピングされて保存されているのであれば、それは良いことです。Prometheusは短期的なメトリクスストレージを目的としているため、大量のデータをスクレイピングして保持することは通常それほど高価ではありません。Prometheusを使用して長期的なストレージソリューションを利用している場合、実際にどのデータを永続化し保持するかを決定することができます。
Prometheusエクスポーターについて
データベース、キュー、ウェブサーバーなどの多くのサードパーティのワークロードは、すでにPrometheus形式でメトリクスを公開することをサポートしているか、ツールのメトリクスとPrometheusが理解できる形式との間で変換するエクスポーターを提供しています。通常、これらのエクスポーターをワークロードのPodに追加のサイドカーコンテナとして追加できます。多くのHelmチャートには、正しいエクスポーターをデプロイするオプションがすでに含まれています。エクスポーターの厳選されたリストは ExporterHubで見つけることができます。
プログラミング言語とフレームワークにおけるPrometheusのサポート
独自のカスタムアプリケーションメトリクスをPrometheusに取り込むには、アプリケーションのコードからこれらのメトリクスを直接収集して公開する必要があります。幸いなことに、ほとんどの人気のあるプログラミング言語とフレームワークに対して、これを支援するためのライブラリや統合がすでに利用可能です。その一例が、 Spring FrameworkにおけるPrometheusのサポートです。
ServiceMonitors and PodMonitors
すべてのワークロードがPrometheus形式でメトリクスを公開したら、Prometheusを構成してそれらをスクレイピングする必要があります。内部では、Rancherは prometheus-operatorを使用しています。これにより、ServiceMonitorsとPodMonitorsを使用してスクレイピングターゲットを簡単に追加できます。多くのHelmチャートには、これらのServiceMonitorやPodMonitorを直接作成するオプションがすでに含まれています。Rancherのドキュメントでもさらに情報を見つけることができます。
Prometheus Push Gateway
Prometheusによってスクレイプするのが伝統的に難しいワークロードがいくつかあります。これらの例としては、ジョブやCronJobのような短命のワークロードや、PHPアプリケーションのように個別に処理されるリクエスト間でデータを共有できないアプリケーションがあります。
これらのユースケースのメトリクスを取得するために、 prometheus-pushgatewaysを設定することができます。CronJobまたはPHPアプリケーションは、プッシュゲートウェイにメトリクスの更新をプッシュします。プッシュゲートウェイはそれらを集約し、HTTPエンドポイントを通じて公開し、その後Prometheusによってスクレイプされることができます。
Prometheusブラックボックスモニター
時には、外部からワークロードを監視することが有用です。そのために、HTTP、HTTPS、DNS、TCP、ICMPを介して任意のエンドポイントをプローブできる Prometheus blackbox-exporterを使用できます。
（マイクロ）サービスアーキテクチャにおける監視
クラスター内の複数の個別のワークロードが相互に通信している（マイクロ）サービスアーキテクチャを持っている場合、これらのワークロードがどのように相互に通信しているか、またどこに問題やボトルネックがあるかを理解するために、詳細なメトリクスとトレースを持つことが非常に重要です。
もちろん、すべてのワークロード内の内部トラフィックを監視し、これらのメトリクスをPrometheusに公開することができます。しかし、これはすぐにかなりの作業負担になる可能性があります。RancherでワンクリックでインストールできるIstioのようなサービスメッシュは、これを自動的に行い、すべてのサービス間のトラフィックに関する豊富なテレメトリを提供できます。
リアルユーザーモニタリング
すべての内部ワークロードの可用性とパフォーマンスを監視することは、安定して信頼性が高く迅速なアプリケーションを運営するために非常に重要です。しかし、これらのメトリクスは全体の一部しか示しません。完全なビューを得るためには、エンドユーザーが実際にどのようにそれを認識しているかを知ることも必要です。そのために、さまざまな リアルユーザーモニタリングソリューションを調べることができます。
セキュリティモニタリング
パフォーマンス、可用性、またはスケーラビリティの問題を検出するためにワークロードを監視することに加えて、クラスターとその中で実行されているワークロードも潜在的なセキュリティ問題について監視する必要があります。良い出発点は、クラスターがセキュリティのベストプラクティスに従って構成されているかどうかを確認するコンプライアンススキャンを頻繁に実行し、アラートを出すことです。
ワークロードについては、Kubernetesや NeuVector、 Falco、 Aqua Kubernetes Security、 SysDigのようなコンテナセキュリティソリューションを確認できます。
アラートの設定
すべてのメトリクスを監視システムに取り込み、ダッシュボードで可視化することは素晴らしいですが、何か問題が発生した場合には、積極的にアラートを受け取りたいと思います。
統合されたRancherの監視は、どのKubernetesクラスターでも意味のある適切なアラートのセットを自動的に構成します。これらを拡張して、特定のワークロードやユースケースをカバーする必要があります。
アラートを設定する際は、アプリケーションの可用性にとって重要なすべてのワークロードに対して構成してください。ただし、アラートがあまりにも騒がしくならないようにしてください。理想的には、受信するすべてのアラートは、注意を要する問題があるためであり、修正が必要です。常に発生しているが、それほど重要でないアラートがある場合、アラートを完全に無視し始めて、本当に重要なアラートを見逃す危険があります。ここでは、少ない方が多いかもしれません。まずは本当に重要なメトリクスに焦点を当ててください。例えば、アプリケーションがオフラインの場合にアラートを出すことです。発生するすべての問題を修正し、その後、より詳細なアラートの作成を開始してください。
アラートが発生し始めたが、現時点で何もできない場合は、一定の時間アラートを一時的に停止して、後で確認できるようにするのも問題ありません。
アラートと通知チャネルの設定方法についての詳細は、Rancher Documentationで確認できます。