（Helmを使用した）EKS上でのPrometheusとThanosを使用したKubernetesマルチクラスタモニタリング

導入

マイクロサービスのアーキテクチャで開発を始めたのですが、それがソフトウェアの世界とDevOpsの世界の両方からマイクロサービスの世界のベストプラクティスを実践するきっかけになりました。

もちろん、DevOpsについての話でマイクロサービスの話をしているときに、私たちはコンテナ化された環境の足元にCIとパイプラインを構築し、コンテナのオーケストレーションツールとしてKubernetesを使用する将来のCDのための準備をし始めました。

CentricaではAWSをクラウドプロバイダーとしていて、長期的な関係を築いているため、K8sクラスタのホストにはEKSを選択しています。

この度、テスト環境とステージング環境に最初のバージョンをリリースし、クラスタを監視してアラートを出すのに最適な監視システムを探していました。

以前の製品では監視サービスとしてZabbixを使用していました。新製品を既存のZabbixシステムに統合することを考えていましたが、調査の結果、Kubernetesの監視ツールの中でナンバーワンであるAKA Prometheusを使用するのがベストであることに気づきました。

さらに調査した結果、2つの主な理由からThanos NextをPrometheusに追加することを決定しました。

1. 最も重要なのは、すべての環境（テスト、ステージング、本番環境）の監視ダッシュボードを1つに集約するということでした。

2.Thanosには長期保存機能があるので、それを利用することができます。

Thanos のメインコンポーネント:

• Sidecar: これはPrometheusに接続し、Query Gatewayによってリアルタイムのクエリ用にエクスポーズしたり、クラウドストレージにデータをアップロードして長期的に使用したりすることができます。
• Query Gateway: 基礎となるコンポーネント（Sidecar やStore Gatewayなど）からデータを集約するためのPrometheusのAPIを実装しています。
• Store Gateway: クラウドストレージのコンテンツをエクスポーズする
• Compactor: クラウドストレージのコンテンツをエクスポーズする
• Receiver: Prometheusのリモート書き込みWALからデータを受信し、それをエクスポーズし、またクラウドストレージにアップロードします。
• Ruler: エクスポーズまたはアップロードのためのThanos内のデータに対する記録とアラートルールを評価します。我々はルーラーを使用しないようにし、各クラスタのための別のアラートマネージャを使用しています。