Thanos のクイックスタート: 高可用性 Prometheus

何千ものサービスとアプリケーションが複数のインフラストラクチャに展開されている世界では、高可用性環境での監視は、あらゆる開発プロセスに不可欠な部分になっています。

この記事では、Thanos を使用して EKS マルチクラスター アーキテクチャ上の複数のクラスターの Prometheus メトリクスを保存する際の思考プロセスと学んだ教訓について説明します。

導入

HiredScore の製品と顧客基盤が拡大するにつれ、当社にとって最も大きなハードルの 1 つであり、おそらく監視インフラストラクチャの最大の部分である Kubernetes への移行と急速な導入が始まりました。当社は Prometheus / Grafana スタックを使用した監視の経験があり、実現可能でコスト効率の高いデータ保持機能を備えた、より優れた高可用性と回復力のあるインフラストラクチャを構築したいと考えていました。また、これにより HiredScore の急成長に備えることができることもわかりました。

CNCF は、これらの監視の問題点に対処し、高可用性、データ保持、コスト効率を備えた監視を可能にするさまざまなインフラストラクチャを推進しています。

必要とする

• 単一の観測ポイントで、あらゆるリージョンのすべてのクラスターからのすべてのデータが集約されます。
• Prometheus の高可用性と回復力を備えたインフラストラクチャ。
• すべてのアプリケーション データの保持。
• 費用対効果の高いソリューション。

私たちは、Bitnami の Kube-Prometheus ソリューションと Thanos-io の Kube-Thanos ソリューションを選択しました。このソリューションは非常にうまく機能し、私たちのニーズをすべて満たしました。

プレイヤーたちを紹介します:

• Prometheus​ — イベント監視およびアラート用の無料ソフトウェア アプリケーションです。柔軟なクエリとリアルタイムアラートを備えた HTTP プル モデルを使用して構築された時系列データベースにリアルタイム メトリックを記録します。
• Thanos — グローバル規模の高可用性監視システムを作成するための Prometheus コンポーネントに基づくオープンソースの CNCF サンドボックス プロジェクト。簡単な手順で Prometheus をシームレスに拡張します。

どのように機能しますか?

図からわかるように、各 EKS クラスターには同じ名前空間内に 2 つの Prometheus ポッドがあり、クラスターの動作をスクレイピングして監視します。各 Prometheus ポッドは、最後の数時間を専用の PVC に保存し、指定された保持時間が経過すると、データは Thanos サイドカーを介して S3 バケットに送信されます。この方法により、少量のローカル ストレージにかかるコストを節約し、他のすべてのストレージを 1 か所 (S3) に集中させることができます。

k8s クラスターから Grafana データを表示するために、thanos-sidecar コンテナー (デフォルトではポート 10901 で公開) に接続された GRPC を使用して各クラスターからすべてのリアルタイム (過去 2 時間) データを直接収集し、S3 バケット (構成ストレージ) からリモート データを取得する専用クラスターを作成しました。

実装の詳細を見てみましょう。

• 最初のフェーズでは、各クラスターに kube-prometheus と Thanos サイドカーを実装します。
• 2 番目のフェーズは、「統合」クラスターに kube-thanos を実装することです。すべてのクラスターからのリアルタイム データと、S3 バケット (ObjectStore) に送信された永続データからデータを収集する役割を担います。

それは素晴らしいですね。では、実際にどのように行うのでしょうか?

フェーズ1

ここでは、監視する各クラスターに Prometheus と Thanos サイドカーをデプロイして構成する方法に焦点を当てます。各クラスターに、monitoring という名前空間を作成します。

 kubectl ns モニタリングを作成する

Prometheus が日付を保持できるようにストレージクラスを作成する

 apiバージョン: ストレージ。 k8s 。 io / v1
 種類: ストレージクラス
メタデータ:
 名前: プロメテウス- ストレージ- クラス
プロビジョナー: kubernetes .io / aws - ebs
 パラメータ:
 タイプ: gp3
 回収ポリシー: 保持
ボリューム拡張を許可する: true
 ボリュームバインディングモード: 即時

 kubectl apply -f prometheus - ストレージクラス。 ​ yaml - n モニタリング

kube-prometheus をインストールします。

 helm リポジトリにbitnami を追加しますhttps://charts.bitnami.com/bitnami
 helm リポジトリの更新

設定する関連値をローカル フォルダーにコピーします。値に適用する必要があるいくつかの変更:

ステップ 1: Prometheus を高可用性にする: Prometheus レプリカ数を設定します (必要な Prometheus レプリカの数 (2 以上))

• https://github.com/bitnami/charts/blob/master/bitnami/kube-prometheus/values.yaml
• https://github.com/bitnami/charts/blob/46afe376ae87a5af32504bc230a25d9c7e4522e2/bitnami/kube-prometheus/values.yaml#L760

 ## @ パラメータprometheus 。 replicaCount 必要なPrometheus レプリカの数
 ##
 レプリカ数: 2

ステップ 2: ポッド リソース制限を定義する Prometheus リソース - Prometheus がすべてのサービス リソースを消費しないようにするためにこれを定義します。

 リソース：
 リクエスト:
 CPU : 512m
 メモリ: 3072 マイル
制限:
 CPU : 512m
 メモリ: 4096 Mi

ステップ3: Thanosサイドカーの作成を有効にする

 サノス:
 ## @ パラメータprometheus 。 サノス。 Thanos サイドカーコンテナを作成する
 ##
 作成: true

ステップ 4: Thanos サイドカー サービスのタイプを ClusterIP から LoadBalancer に変更します。これにより、AWS クラシック ロード バランサー エンドポイントが作成され、GRPC ポート (10901) でサイドカーが公開されます。その後、このエンドポイントを使用して、route53 経由で DNS 名 thanos-prometheus-(cluster_name) にルーティングできます。独自のクラスターで Thanos エンドポイント prometheus.thanos.service を公開します。

https://github.com/bitnami/charts/blob/46afe376ae87a5af32504bc230a25d9c7e4522e2/bitnami/kube-prometheus/values.yaml#L1034

 サービス：
 タイプ: ロードバランサー
ポート: 10901
 注釈:
 サービス。 ベータ。 Kubernetes 。 io / aws - ロードバランサー- 内部: "true "

CLB を作成したら、それを kube-thanos マニフェストに実装する必要があります。これについては、フェーズ 2 で後ほど説明します。

ステップ 5: 圧縮を無効にして保持を定義する - これは、Thanos サイドカー経由でデータをアップロードするための非常に重要なステップです。

https://prometheus.io/docs/prometheus/latest/storage/#operational-aspects

Thanos サイドカーアップロードを使用するには、これら 2 つの値が --storage.tsdb.min-block-duration、--storage.tsdb.max-block-duration と等しくなければなりません。デフォルトでは 2 時間に設定されています。 Prometheus の推奨保持時間は、最小ブロック期間の 3 倍以上、つまり 6 時間です。追加の手順については、こちらをご覧ください:

https://thanos.io/tip/components/sidecar.md/

 保持時間: 12 時間

圧縮を無効にする: true

ステップ 6: 構成キーを有効にする – オブジェクト ストレージ構成を有効にすると、S3 またはその他のサポートされている BlockDevice にデータを書き込むことができます。長期データの永続性を確保するため。

 ## @ パラメータprometheus 。 サノス。 objectStorageConfig sideCar コンテナのobjectStorageConfig の Secret のマウントをサポートします。
 オブジェクトストレージ構成:
 secretName : thanos - objstore - config
 秘密キー: サノス。 ヤム

ソースファイルthanos-storage-config.yamlはこの形式である必要がありますが、

 タイプ: s3
 設定:
 バケット: thanos - ストア#S3 バケット名
エンドポイント: s3 。 < 地域> 。 アマゾンズ。 com #S3 地域エンドポイント
アクセスキー: <aws アカウント ID>
 secret_key : <aws アカウントのシークレット>

現時点では、次のコマンドを使用してキーを作成するために使用できるのは単一の S3 バケット (ObjectStore) のみであることに注意してください。

 kubectl -n モニタリングは、 ジェネリックのthanos -objstore -config --from -file = thanos というシークレットを作成します。 yaml = thanos - storage - config 。 ヤム

ステップ 7: これで、関連するカスタマイズを使用して Helm チャートをインストール/アップグレードできます。

 helm install kube - prometheus - f 値​​.yaml bitnami / kube - prometheus - n モニタリング

または

 helm アップグレードkube - prometheus - f 値​​.yaml bitnami / kube - prometheus - n モニタリング

ここまでの作業が完了したら、Thanos サイドカー コンテナを備えた実行中の Prometheus ポッドが作成され、一方ではスクレイピングされたデータが GRPC 経由でマニフェストに送信され、他方では同じサイドカーが (約 2 時間後に) データを S3 バケット (構成ストレージ) に送信しているはずです。おめでとう！

フェーズII

メインの可観測性クラスターに Thanos をデプロイして構成する方法に焦点を当てます。前述したように、これは第 1 フェーズで展開したすべてのクラスターからすべてのデータを収集する役割を担います。

このために、kube-thanos マニフェストを使用します。私たちの目的には、クエリとストレージ部分のみを実装する必要があることがわかりました。

ステップ 1: kube-thanos をインストールしてカスタマイズします。メインの可観測性クラスターに thanos という名前空間を作成します。

 kubectl ns サノスを作成

kube-thanos リポジトリをクローンしてマニフェスト フォルダーを使用するか、kube-thanos マニフェストを自分でコンパイルするかを選択できます。最後の方法では、リポジトリ全体をコピーする必要はなく、マニフェスト ファイルだけをコピーします。

ステップ 2: 最初のステージに合格すると、最初のステージの thanos-query-deployment.yaml と他のクラスター間の通信が処理されます。これを行うには、以下を追加する必要があります。

 -- ストア= dnssrv + _grpc 。 _tcp 。 thanos - prometheus - < クラスター名> 。 < ドメイン名> : 10901

上記で公開および定義した Thanos サイドカー GRPC エンドポイントの args セクションを入力します (手順 4)。

 -引数:
 - クエリ
- -- grpc - アドレス= 0.0 .0 .0 : 10901
 - -- http - アドレス= 0.0 .0 .0 : 9090
 - --log.level = 情報
- --log.format = ログフォーマット
-- クエリ。 レプリカ- ラベル= prometheus_replica
 -- クエリ。 レプリカ- ラベル= ルールレプリカ
-- ストア= dnssrv + _grpc 。 _tcp 。 サノス- ストア。 サノス。 svc 。 クラスター。 ローカル: 10901
 -- ストア= dnssrv + _grpc 。 _tcp 。 thanos - 受信- インジェスター- デフォルト。 サノス。 svc 。 クラスター。 ローカル: 10901
 -- ストア= dnssrv + _grpc 。 _tcp 。 thanos - prometheus - < クラスター名> 。 < ドメイン名> : 10901
 -- クエリ。 自動ダウンサンプリング

ステップ 3: ここで、最初のステージからデータを送信するように構成した thanos-store と S3 バケット (ObjectStore) 間の通信を処理します。したがって、最初のステップで行ったように、注入された環境 thanos-store-statefulSet.yaml の部分で、Thanos ストレージ ポッドに要求される名前を構成する必要があります。

 環境:
 - 名前: OBJSTORE_CONFIG
 値の開始値:
 シークレットキーリファレンス:
 キー： サノス。 ヤム
名前: サノス- オブジェクトストレージ

その後、最初のステージから同じソース ファイルを再利用し、thanos-storethanos-storage-config.yaml のシークレットを作成できます。

 kubectl -n thanos は、 汎用のthanos -objectstorage --from -file = thanos というシークレットを作成します。 yaml = thanos - storage - config 。 ヤム

ステップ 4: インストール チェックリスト:

 kubectl apply -f マニフェスト-n thanos

これでループは閉じられるはずです。 Thanos は、thanos-query デプロイメントを介して他のクラスターからリアルタイム データを受信し、thanos-store-statefulSet を介して S3 バケット (ObjectStore) からデータを永続化します。

結論は

Thanos は、Prometheus の可用性、耐久性、コスト効率を向上することで、Prometheus に対する考え方を変えました。多くの Kubernetes クラスターに Thanos と Prometheus を実装するには多大な労力が必要ですが、高可用性の Prometheus を確保することに関心がある場合は、その価値はあります。