Thanos と Prometheus を使用して可用性の高い K8S 監視システムを構築する方法

概要

柔軟なスケーリングと高可用性を備えたシステムの場合、通常、大量のインジケーターデータを収集して保存する必要がありますが、そのようなシステム用の監視ソリューションを作成するにはどうすればよいでしょうか? この記事では、Thanos+Prometheus+Grafanaを使用した監視システムの構築方法について説明します。

クラスター容量の概要

ユーザーストーリー

今年の 1 月まで、私は APM にも使用されていたエンタープライズグレードの監視ソリューションを使用して Kubernetes クラスターを監視していました。使用感は自然で、わずかな調整で簡単に Kubernetes と統合でき、APM とインフラストラクチャのメトリクスを統合できます。

この監視ソリューションはデータを簡単に収集して保存できますが、メトリクスを使用してアラートを作成するにはクエリに大きな制限があります。多くの場合、受信するアラートはダッシュボードに表示されるものと異なります。言うまでもなく、クラスターが 6 つあり、収集および保存されるメトリクスの数が非常に多いため、経済的コストが大幅に増加します。

少し検討した結果、この監視ソリューションを使い続けると良いことよりも害の方が大きいことがわかりました。監視ソリューションを置き換える時が来ました! しかし、どの製品やツールを使用すればよいのでしょうか? Grafana は視覚化ツールとして最適なオプションですが、「バックエンド」には柔軟なスケーラビリティと高可用性が必要です。どのツールを使用すればよいですか?

OpenTSDB を純粋に使うとインストールに手間がかかりすぎる、スタンドアロンの Prometheus ではレプリケーション機能が提供されず、複数のデータベースを装備する必要がある、TimeScaleDB は良さそうだが、私は PostgreSQL を使うのがあまり得意ではない。

上記の解決策のいくつかを試した後、CNCF Web サイトをチェックして、最終的に Thanosを見つけました。これは、長期的なデータ保持、複製可能、高可用性、マイクロサービスに適しており、同じデータベースを使用するすべてのクラスターのグローバルビューを備えているなど、すべてのニーズを満たしています。

建築

クラスター上に利用可能な永続ストレージがない (すべてのサービスはステートレスのまま) ため、デフォルトの Prometheus + Thanos サイドカーアプローチは利用できず、メトリックストレージをクラスターの外部に配置する必要があります。さらに、クラスターは相互に分離されており、Thanos コンポーネントを特定のクラスターのセットにバインドすることはできず、クラスターは「外部」から監視する必要があります。

要約すると、高可用性と仮想マシン上で Thanos が実行される可能性を考慮して、最終的なアーキテクチャは次のようになります。

図に示すように、マルチデータセンターアーキテクチャがあります。これらの各センターには、 Grafana + Query サーバーのセット、ストレージサーバーのセット、および 3 つの受信サーバー (クラスターの数の半分) があります。

Grafana が使用するデータベースには AWS RDS もあります。このデータベースは（コストを抑えるために）巨大である必要はなく、私たちのチームが MySQL を管理する必要もありません。

Thanos が提供するすべてのコンポーネントのうち、次の 4 つを実装しました。

受信: TSDB を担当し、TSBD ブロックの受信と S3 へのアップロードを実行しているすべてのサーバー間のレプリケーションも管理します。
Query : 受信データベースへのクエリを担当します。
Store :受信に保存されなくなった長期メトリクスを S3 から読み取ります。
コンパクター: S3 に保存されている TSDB ブロックのデータのダウンサンプリングと圧縮を管理します。

データ統合

すべてのクラスターのデータ取り込みは、クラスター内で実行される専用の Prometheus Podによって管理されます。コントロールプレート (API サーバー、コントローラー、スケジューラー)、etcd クラスター、クラスター内のポッドからインフラストラクチャと Kubernetes 自体 (Kube プロキシ、Kubelet、ノードエクスポーター、状態メトリクス、メトリクスサーバー、およびスクレイピングアノテーションを含むその他の Pod)。

次に、Prometheus ポッドは、リモートストレージ構成で TSDB を管理する受信サーバーの 1 つに情報を送信します。

データの取り込み

すべてのデータは 1 つのサーバーに送信され、その後他のサーバーに複製されます。Prometheus によって使用される DNS アドレスは、各受信サーバーを調査し、正常なサーバー間で DNS 解決のバランスをとり、すべてのサーバー間で負荷を共有する DNS GSLB です。これは、DNS 解決では DNS クエリごとに 1 つの IP しか提供されないためです。

データは単一の受信インスタンスに送信され、そのインスタンスにレプリケーションを管理させる必要があることを強調しておく必要があります。同じメトリックを送信すると、レプリケーションが失敗して誤動作する可能性があります。

このレベルでは、メトリクスも長期保存のために S3 バケットにアップロードされます。Receive は 2 時間ごとにブロックをアップロードします (各 TSDB ブロックが閉じているとき)。これらのメトリクスは、Store コンポーネントを使用したクエリに使用できます。

ローカルデータの保存期間を設定することもできます。この場合、すべてのローカルデータは日常使用とトラブルシューティングのために 30 日間保持されるため、クエリが高速化されます。

30 日より古いデータは S3 でのみ利用でき、長期的な評価と比較のために最大 1 年間保持されます。

データクエリ

データは収集され、クエリのために受信機に保存されます。この部分も複数のデータセンターで利用できるように設定されています。

Grafana と Query を実行している各サーバーでは、一方 (または両方) がダウンした場合に、そのサーバーをより簡単に特定してロードバランサーから削除できます。Grafana では、データソースは localhost として構成されているため、常にローカルクエリを使用してデータを取得します。

クエリ設定の場合、メトリクスを保存するすべてのサーバー (受信者とストア) を認識している必要があります。クエリコンポーネントは、どのサーバーがオンラインであるかを認識し、それらのサーバーからメトリクスを収集できます。

データクエリ

また、すべてのサーバーにクエリを実行してレプリケーションを構成するため、重複排除も管理し、すべてのメトリックに複数のコピーが存在します。これは、メトリクスに割り当てられたラベルとクエリパラメータ () を使用して--query.replica-label=QUERY.REPLICA-LABEL実行できます。これらの構成では、クエリコンポーネントは、Receiver と Store から収集されたメトリクスが重複しているかどうかを認識し、データポイントを 1 つだけ使用します。

長期データ

前述したように、データは最大 30 日間ローカルに保存され、それ以外はすべて S3 に保存されます。ブロックストレージはオブジェクトストレージより高価であるため、これにより、Receiver で必要なスペースの量が減り、コストも削減されます。言うまでもなく、30 日を超えるデータのクエリはあまり一般的ではなく、主にリソース使用量の履歴と予測に使用されます。

リモートデータクエリ

また、ストアは、S3 バケットに保存されている各 TSDB チャンクのインデックスのローカルコピーを保持しているため、30 日を超えるデータをクエリする必要がある場合、データを提供するためにどのチャンクをダウンロードして使用するかを認識します。

データ状況

すべてのクラスターを考慮すると、監視スキームは次のようになります。

6 つの Kubernetes クラスターを監視しました。
670 のサービスのメトリクスを収集。
246 台のサーバーが Node Exporter を使用して監視されました。
1 分あたり約 27 ワットのインジケーターを収集します。
1 日あたり約 7.3 GB、または 1 か月あたり約 226.3 GB のデータを取り込みます。
Kubernetes コンポーネント用に 40 の専用ダッシュボードを作成しました。
Grafana では 116 個のアラームが作成されます。

月額料金については、ほとんどのコンポーネントがオンプレミスで実行されるため、コストは 90.61% 削減され、月額 38,421.25 ドルから 3,608.99 ドルになりました。これには AWS のサービス費用が含まれます。

要約する

上記のアーキテクチャの構成とセットアップには、他のソリューションのテスト、アーキテクチャの検証、実装、クラスター上での収集の有効化、すべてのダッシュボードの作成など、約 1 か月ほどかかりました。

最初の 1 週間で、その効果は明らかでした。クラスターの監視が容易になり、ダッシュボードを迅速に構築してカスタマイズでき、メトリクスの収集はほぼプラグアンドプレイで、ほとんどのアプリケーションはメトリクスを Prometheus 形式でエクスポートし、アノテーションに基づいて自動的に収集されます。

さらに、Grafana の LDAP を統合することで、より詳細なチーム権限制御を実現できます。開発者と SRE は、名前空間、イングレスなどに関する関連メトリクスを含む多数のダッシュボードにアクセスできます。