サノス - スケーラブルなプロメテウス

記事の翻訳はコースの学生向けに特別に用意されました 「DevOps の実践とツール」.

ファビアン・ライナルツ ソフトウェア開発者であり、囲碁マニアであり、問​​題解決者でもあります。彼は Prometheus のメンテナーであり、Kubernetes SIG インストルメンテーションの共同創設者でもあります。以前は SoundCloud のプロダクション エンジニアであり、CoreOS のモニタリング チームを率いていました。現在はGoogleに勤務。

バルテック プロトカ - Improbable のインフラストラクチャ エンジニア。新しい技術や分散システムの問題に興味を持っています。彼は、Intel での低レベルのプログラミング経験、Mesos でのコントリビューターの経験、および Improbable での世界クラスの SRE 制作の経験を持っています。マイクロサービスの世界を改善することに専念しています。彼の 3 つの愛は、Golang、オープンソース、バレーボールです。

当社の主力製品である SpatialOS を見ると、Improbable には数十の Kubernetes クラスターを備えた非常に動的な世界規模のクラウド インフラストラクチャが必要であることが推測できます。当社は監視システムを最初に使用したうちの 1 つです プロメテウス。 Prometheus は、何百万ものメトリクスをリアルタイムで追跡でき、必要な情報を抽出できる強力なクエリ言語が付属しています。

Prometheus の主な利点の 1 つは、そのシンプルさと信頼性です。しかし、ある程度の規模を超えると、いくつかの欠点に遭遇しました。これらの問題を解決するために私たちは開発しました Thanosさん は、既存の Prometheus クラスターを無制限の履歴データ ストレージを備えた単一の監視システムにシームレスに変換するために、Improbable によって作成されたオープン ソース プロジェクトです。 Thanos は Github で入手できます ここで.

Improbable からの最新ニュースを入手してください。

サノスとの目標

一定の規模になると、バニラの Prometheus の能力を超えた問題が発生します。ペタバイト単位の履歴データを確実かつ経済的に保存するにはどうすればよいでしょうか?応答時間を犠牲にすることなくこれを実行できるでしょうか?単一の API リクエストで、異なる Prometheus サーバーにあるすべてのメトリクスにアクセスすることは可能ですか? Prometheus HA を使用して収集されたレプリケートされたデータを結合する方法はありますか?

これらの問題に対処するために、私たちは Thanos を作成しました。次のセクションでは、これらの問題にどのようにアプローチしたかを説明し、目標について説明します。

複数の Prometheus インスタンスからのデータのクエリ (グローバル クエリ)

Prometheus は、シャーディングに対する機能的なアプローチを提供します。単一の Prometheus サーバーでも、ほぼすべてのユースケースで水平シャーディングの複雑さからユーザーを解放するのに十分なスケーラビリティを備えています。

これは優れたデプロイメント モデルですが、多くの場合、単一の API または UI、つまりグローバル ビューを介して、さまざまな Prometheus サーバー上のデータにアクセスする必要があります。もちろん、1 つの Grafana パネルに複数のクエリを表示することは可能ですが、各クエリは 1 つの Prometheus サーバーでのみ実行できます。一方、Thanos を使用すると、複数の Prometheus サーバーはすべて単一のエンドポイントからアクセスできるため、それらのサーバーからデータをクエリおよび集約できます。

以前は、Improbable で全体的なビューを取得するために、Prometheus インスタンスをマルチレベルに編成しました。 階層連合。これは、各リーフ サーバーからメトリクスの一部を収集する 1 つの Prometheus メタ サーバーを作成することを意味します。

このアプローチには問題があることが判明しました。その結果、構成がより複雑になり、潜在的な障害点が追加され、フェデレーション エンドポイントが必要なデータのみを受信するようにするための複雑なルールが適用されるようになりました。さらに、この種のフェデレーションでは、単一の API リクエストからすべてのデータを利用できるわけではないため、真のグローバル ビューを取得することはできません。

これに密接に関連しているのは、高可用性 (HA) Prometheus サーバーで収集されたデータの統合ビューです。 Prometheus の HA モデルは、独立してデータを 2 回収集します。これは、これ以上ないほど単純です。ただし、両方のストリームを結合して重複排除したビューを使用する方がはるかに便利です。

もちろん、可用性の高い Prometheus サーバーが必要です。 Improbable では、分単位のデータ監視を非常に重視していますが、クラスターごとに Prometheus インスタンスが 1 つあると単一障害点になります。構成エラーやハードウェア障害が発生すると、重要なデータが失われる可能性があります。再起動はスクレイピング間隔より大幅に長くなる可能性があるため、単純なデプロイメントであっても、メトリクス収集に軽度の中断が発生する可能性があります。

履歴データの信頼できる保管

安価で、高速で、長期的なメトリクスのストレージは私たちの夢です (ほとんどの Prometheus ユーザーが共有しています)。 Improbable では、メトリクスの保持期間を 1.8 日間に設定する必要がありました (Prometheus XNUMX の場合)。これにより、どれだけ遡ることができるかに明らかな制限が加わります。

Prometheus 2.0 では、時系列の数がサーバーの全体的なパフォーマンスに影響を与えなくなったため、この点が改善されました (「. Prometheus 2 に関する KubeCon 基調講演）。ただし、Prometheus はデータをローカル ディスクに保存します。高効率のデータ圧縮によりローカル SSD の使用量を大幅に削減できますが、最終的には保存できる履歴データの量には依然として制限があります。

さらに、Improbable では、信頼性、シンプルさ、コストを重視しています。大容量のローカル ディスクは、操作とバックアップがより困難になります。コストが高くなり、より多くのバックアップ ツールが必要になるため、不必要な複雑さが生じます。

ダウンサンプリング

過去のデータを扱い始めると、Big-O には根本的な問題があり、数週間、数か月、数年のデータを扱うにつれてクエリの速度がどんどん遅くなることに気づきました。

この問題に対する標準的な解決策は次のようになります ダウンサンプリング (ダウンサンプリング) - 信号のサンプリング周波数を下げます。ダウンサンプリングを使用すると、より大きな時間範囲に「スケールダウン」し、同じ数のサンプルを維持して、クエリの応答性を維持できます。

古いデータのダウンサンプリングは、長期ストレージ ソリューションでは避けられない要件であり、標準的な Prometheus の範囲を超えています。

追加の目標

Thanos プロジェクトの当初の目標の 1 つは、既存の Prometheus インストールとシームレスに統合することでした。 2 番目の目標は、参入障壁を最小限に抑え、操作を容易にすることでした。依存関係は小規模ユーザーと大規模ユーザーの両方にとって簡単に満たされる必要があり、これは基本コストが低いことも意味します。

サノスの建築

前のセクションで目標をリストした後、それらを実行し、サノスがこれらの問題をどのように解決するかを見てみましょう。

グローバルな視点

既存の Prometheus インスタンス上でグローバル ビューを取得するには、単一のリクエスト エントリ ポイントをすべてのサーバーにリンクする必要があります。これはまさに Thanos コンポーネントが行うことです。 サイドカー。これは各 Prometheus サーバーの隣にデプロイされ、プロキシとして機能し、gRPC ストア API を通じてローカルの Prometheus データを提供し、タグと時間範囲によって時系列データを取得できるようにします。

もう一方は、スケールアウトでステートレスな Querier コンポーネントで、標準の Prometheus HTTP API を介して PromQL クエリに応答するだけです。 Querier、Sidecar、その他の Thanos コンポーネントは、 ゴシッププロトコル.

1. Querier はリクエストを受信すると、対応する Store API サーバー、つまりサイドカーに接続し、対応する Prometheus サーバーから時系列データを受信します。
2. その後、応答を結合し、それらに対して PromQL クエリを実行します。 Querier は、Prometheus HA サーバーからの素データと重複データの両方をマージできます。

これにより、分離された Prometheus サーバーからのデータを単一のビューに結合するというパズルの主要な部分が解決されます。実際、Thanos はこの機能にのみ使用できます。既存の Prometheus サーバーに変更を加える必要はありません。

保存期間は無制限！

ただし、遅かれ早かれ、通常の Prometheus 保持時間を超えてデータを保存する必要が生じるでしょう。履歴データを保存するためにオブジェクト ストレージを選択しました。オンプレミスのデータセンターだけでなくあらゆるクラウドでも広く利用でき、コスト効率が非常に優れています。さらに、ほとんどすべてのオブジェクト ストレージは、よく知られた S3 API を通じて利用できます。

Prometheus は、約 2 時間ごとに RAM からディスクにデータを書き込みます。保存されたデータ ブロックには、一定期間のすべてのデータが含まれており、不変です。 Thanos Sidecar は Prometheus データ ディレクトリを参照するだけで、新しいブロックが利用可能になると、それらをオブジェクト ストレージ バケットにロードできるため、これは非常に便利です。

ディスクへの書き込み直後にオブジェクト ストレージに読み込むことで、スクレーパー (Prometheus および Thanos Sidecar) のシンプルさを維持することもできます。これにより、サポート、コスト、システム設計が簡素化されます。

ご覧のとおり、データのバックアップは非常に簡単です。しかし、オブジェクト ストレージ内のデータをクエリする場合はどうでしょうか?

Thanos Store コンポーネントは、オブジェクト ストレージからデータを取得するプロキシとして機能します。 Thanos Sidecar と同様に、ゴシップ クラスターに参加し、Store API を実装します。このようにして、既存の Querier は時系列データの別のソースとしてサイドカーのように扱うことができ、特別な構成は必要ありません。

時系列データ ブロックは、複数の大きなファイルで構成されます。それらをオンデマンドでロードするのは非常に非効率的であり、ローカルにキャッシュするには大量のメモリとディスク容量が必要になります。

代わりに、Store Gateway は Prometheus ストレージ形式を処理する方法を認識しています。スマートなクエリ スケジューラとブロックの必要なインデックス部分のみをキャッシュすることにより、複雑なクエリをオブジェクト ストレージ ファイルへの HTTP リクエストの数を最小限に抑えることができます。このようにして、リクエストの数を 4 ～ 6 桁削減し、ローカル SSD 上のデータへのリクエストと区別するのが一般に困難な応答時間を実現できます。

上の図に示すように、Thanos Querier は、Prometheus ストレージ形式を利用し、関連データを並べて配置することにより、オブジェクト ストレージ データのクエリあたりのコストを大幅に削減します。このアプローチを使用すると、多数の単一リクエストを最小限の一括操作に結合できます。

圧縮とダウンサンプリング

時系列データの新しいブロックがオブジェクト ストレージに正常にロードされると、それは「履歴」データとして扱われ、ストア ゲートウェイを通じてすぐに利用できるようになります。

ただし、しばらくすると、1 つのソース (Sidecar を備えた Prometheus) からのブロックが蓄積され、インデックス作成の可能性を最大限に活用できなくなります。この問題を解決するために、Compactor と呼ばれる別のコンポーネントを導入しました。 Prometheus のローカル圧縮エンジンをオブジェクト ストレージ内の履歴データに適用するだけで、単純な定期バッチ ジョブとして実行できます。

効率的な圧縮のおかげで、長期間にわたってストレージをクエリしても、データ サイズの点で問題が発生することはありません。ただし、10 億の値を解凍し、クエリ プロセッサで実行する潜在的なコストにより、クエリの実行時間は必然的に大幅に増加します。一方で、画面上のピクセルごとに数百のデータ ポイントがあるため、フル解像度でデータを視覚化することさえ不可能になります。したがって、ダウンサンプリングは可能であるだけでなく、精度の顕著な低下につながることはありません。

データをダウンサンプリングするために、Compactor は 5 分および 1 時間の解像度でデータを継続的に集約します。 TSDB XOR 圧縮を使用してエンコードされた生のチャンクごとに、1 つのブロックの最小値、最大値、合計など、さまざまなタイプの集計データが保存されます。これにより、Querier は特定の PromQL クエリに適切な集計を自動的に選択できるようになります。

ユーザーが低精度データを使用するために特別な構成は必要ありません。 Querier は、ユーザーがズームインまたはズームアウトすると、異なる解像度と生データを自動的に切り替えます。必要に応じて、ユーザーはリクエストの「step」パラメータを通じてこれを直接制御できます。

1 GB を保存するコストが低いため、Thanos はデフォルトで生データ、5 分および 1 時間の解像度のデータを保存します。元のデータを削除する必要はありません。

録音ルール

Thanos であっても、記録ルールは監視スタックの重要な部分です。これらにより、クエリの複雑さ、待ち時間、コストが軽減されます。ユーザーがメトリクスごとに集計されたデータを取得するのにも便利です。 Thanos はバニラの Prometheus インスタンスに基づいているため、既存の Prometheus サーバーに記録ルールとアラート ルールを保存することはまったく問題ありません。ただし、場合によっては、これでは不十分な場合があります。

• グローバル アラートとルール (たとえば、サービスが 3 つのクラスターのうち 2 つ以上で動作しない場合のアラート)。
• ローカル ストレージ外のデータに関するルール。
• すべてのルールとアラートを 1 か所に保存したいという要望。

これらすべてのケースに対して、Thanos には Ruler と呼ばれる別のコンポーネントが含まれており、Thanos クエリを介してルールとアラートを計算します。既知の StoreAPI を提供することにより、Query ノードは新しく計算されたメトリクスにアクセスできます。その後、それらはオブジェクト ストレージにも保存され、ストア ゲートウェイを通じて利用できるようになります。

サノスの力

Thanos は、ニーズに合わせてカスタマイズできる柔軟性があります。これは、プレーンな Prometheus から移行する場合に特に便利です。 Thanos コンポーネントについて学んだことを簡単な例で簡単にまとめてみましょう。バニラの Prometheus を「無制限のメトリクス ストレージ」の世界に連れて行く方法は次のとおりです。

1. Thanos Sidecar を Prometheus サーバーに追加します (たとえば、Kubernetes ポッド内のサイドカー コンテナー)。
2. データを表示できるようにするために、複数の Thanos Querier レプリカをデプロイします。この段階では、スクレイパーとクエリアの間でゴシップが簡単に設定されます。コンポーネントの相互作用を確認するには、「thanos_cluster_members」メトリクスを使用します。

これら 2 つの手順だけで、潜在的な Prometheus HA レプリカからグローバル ビューとシームレスなデータ重複排除を実現できます。ダッシュボードを Querier HTTP エンドポイントに接続するか、Thanos UI を直接使用するだけです。

ただし、メトリクスのバックアップと長期保存が必要な場合は、さらに 3 つの手順を完了する必要があります。

1. AWS S3 または GCS バケットを作成します。これらのバケットにデータをコピーするように Sidecar を構成します。ローカル データ ストレージを最小化できるようになりました。
2. Store Gateway をデプロイし、既存のゴシップ クラスターに接続します。これで、バックアップされたデータをクエリできるようになりました。
3. Compactor をデプロイすると、圧縮とダウンサンプリングを使用して長期間にわたるクエリの効率が向上します。

さらに詳しく知りたい場合は、遠慮なくご覧ください。 Kubernetes マニフェストの例 и 始めます!

わずか 5 つのステップで、Prometheus をグローバル ビュー、無制限の保存時間、メトリクスの潜在的な高可用性を備えた信頼性の高い監視システムに変えました。

プル リクエスト: あなたが必要です!

Thanosさん は最初からオープンソース プロジェクトでした。 Prometheus とのシームレスな統合と Thanos の一部のみを使用できるため、監視システムを簡単に拡張するための優れた選択肢となります。

GitHub のプル リクエストと問題はいつでも歓迎します。それまでの間、Github Issues または Slack 経由でお気軽にお問い合わせください。 Improbable-eng #thanosご質問やフィードバックがある場合、または使用体験を共有したい場合は、お気軽にお問い合わせください。 Improbable での取り組みが気に入っていただけましたら、お気軽にお問い合わせください - 私たちは常に空席があります!

コースについて詳しくはこちらをご覧ください。

出所： habr.com