こんにちは、みんな！ 彼の中で 前の記事 マイクロサービス アーキテクチャ向けのモジュール型監視システムの編成について書きました。 何も止まっているわけではなく、私たちのプロジェクトは常に成長しており、保存されているメトリクスの数も増加しています。 高負荷条件下で Graphite+Whisper から Graphite+ClickHouse への移行をどのように整理したか、そこからの期待とカットでの移行の結果についてお読みください。

Graphite+Whisper でのメトリクスの保存から Graphite+ClickHouse への移行をどのように計画したかを説明する前に、そのような決定を下した理由と、私たちが長い間使用してきた Whisper の欠点について説明したいと思います。

グラファイト+ウィスパーの問題

1. ディスクサブシステムの高負荷

移行時には、1.5 分あたり約 30 万のメトリクスが到着していました。 このようなフローでは、サーバー上のディスク使用率は最大 10% でした。 一般に、これはまったく許容範囲内でした。すべてが安定して動作し、迅速に書き込まれ、迅速に読み取られました...開発チームの 100 つが新機能を公開し、毎分 XNUMX 万のメトリクスを送信し始めるまでは。 そのとき、ディスク サブシステムが強化され、使用率が XNUMX% になりました。 問題はすぐに解決されましたが、残留物が残りました。

2. レプリケーションと一貫性の欠如

おそらく、Graphite+Whisper を使用しているすべてのユーザーと同様に、フォールト トレランスを構築するために、同じメトリクス ストリームを一度に複数の Graphite サーバーに注ぎ込んだのでしょう。 そして、サーバーの 5 つが何らかの理由でクラッシュするまで、これには特別な問題はありませんでした。 場合によっては、障害が発生したサーバーをすぐに回復できたり、carbon-c-relay がキャッシュからメトリクスをロードできたりすることもありましたが、そうでない場合もありました。 そしてメトリクスに穴があったので、rsync で埋めました。 手続きはかなり長かったです。 唯一の救いは、このようなことがほとんど起こらなかったことです。 また、定期的にメトリックのランダムなセットを取得し、それらをクラスターの隣接ノード上の同じタイプの他のメトリックと比較しました。 約 XNUMX% のケースでは、いくつかの値が異なっていましたが、これはあまり満足できませんでした。

3. 設置面積が大きい

Graphite ではインフラストラクチャだけでなくビジネス メトリクス (そして現在は Kubernetes のメトリクスも) を記述しているため、メトリクスに数個の値しか含まれておらず、すべての保持を考慮して .wsp ファイルが作成されているという状況がよく発生します。事前に割り当てられた量のスペースを占有します (私たちの場合、最大 2MB でした)。 時間の経過とともに類似したファイルが多数出現し、それらのファイルに基づいてレポートを作成するときに空のポイントを読み取るのに多くの時間とリソースがかかるという事実によって、問題はさらに悪化します。

上記の問題は、さまざまな方法を使用し、効果の程度はさまざまですが、受信するデータが増えれば増えるほど、問題はさらに悪化することにすぐに注意してください。

上記をすべて満たしていること（前述の内容を考慮して） 記事）、受信したメトリクスの数が常に増加しているため、すべてのメトリクスを 30 秒の保存間隔で転送したいという要望もあります。 (必要に応じて最大 10 秒)、Whisper の有望な代替手段として Graphite+ClickHouse を試すことにしました。

グラファイト+クリックハウス。 期待

Yandex のメンバーの交流会をいくつか訪れ、以下の記事を読んだことがあります。 ハブレに関するいくつかの記事ドキュメントを調べて、Graphite で ClickHouse をバインドするための適切なコンポーネントを見つけたので、行動を起こすことにしました。

以下のものを受け取りたいと思います。

• ディスク サブシステムの使用率を 30% から 5% に削減します。
• 占有スペースの量を 1TB から 100GB に削減します。
• 毎分 100 億のメトリクスをサーバーに受信できる。
• すぐに使えるデータ複製とフォールトトレランス。
• このプロジェクトを XNUMX 年間放置せず、妥当な期間内に移行してください。
• ダウンタイムなしで切り替えられます。

かなり野心的ですよね？

グラファイト+クリックハウス。 コンポーネント

Graphite プロトコル経由でデータを受信し、それを ClickHouse に記録するには、次のオプションを選択しました。 カーボンクリックハウス (ゴーラン)。

ClickHouse の最新リリースである安定バージョン 1.1.54253 が、時系列を保存するデータベースとして選択されました。 作業中に問題が発生しました。山ほどのエラーがログに記録され、それらをどう処理すればよいのか完全に明確ではありませんでした。 との議論中 ロマン・ロモノーソフ (カーボンクリックハウス、グラファイトクリックハウス、その他多数の作者) 古いものが選択されました リリース1.1.54236。 エラーは消え、すべてが順調に動作し始めました。

ClickHouse からデータを読み取るように選択されました グラファイトクリックハウス (ゴーラン)。 GraphiteのAPIとして- カルボナピ (ゴーラン)。 ClickHouse はテーブル間のレプリケーションを整理するために使用されました 動物園の飼育係。 ルーティング メトリクスについては、最愛のメトリクスをそのまま残しました。 カーボン-c-リレー （C） （前回の記事を参照）.

グラファイト+クリックハウス。 テーブル構造

「graphite」はテーブルを監視するために作成したデータベースです。

「graphite.metrics」 - ReplicatedReplacingMergeTree エンジンを備えたテーブル (複製された マージツリーの置き換え）。 このテーブルには、メトリクスの名前とそれらへのパスが保存されます。

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

「graphite.data」 - ReplicatedGraphiteMergeTree エンジンを備えたテーブル (複製された) グラファイトマージツリー）。 このテーブルにはメトリック値が保存されます。

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

「graphite.date_metrics」は、ReplicatedReplacingMergeTree エンジンを使用して条件付きで入力されるテーブルです。 このテーブルには、その日中に発生したすべてのメトリクスの名前が記録されます。 その作成理由については、セクションで説明されています。 「問題」 この記事の最後に。

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

「graphite.data_stat」 - ReplicatedAggregatingMergeTree エンジン (複製された) を使用して、条件に従って入力されたテーブル 集約マージツリー）。 このテーブルには、受信メトリクスの数が 4 つのネスト レベルに分類されて記録されます。

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

グラファイト+クリックハウス。 コンポーネントの相互作用図

グラファイト+クリックハウス。 データ移行

このプロジェクトからの期待からわかるように、ClickHouse への移行はダウンタイムなしで行われる必要があるため、ユーザーに対して可能な限り透過的に監視システム全体を何らかの方法で新しいストレージに切り替える必要がありました。
これが私たちのやり方です。

• ClickHouse テーブルのレプリケーションに参加しているサーバーの XNUMX つのカーボン クリックハウスに追加のメトリクス ストリームを送信するためのルールがカーボン C リレーに追加されました。

• 私たちは Python で小さなスクリプトを書き、ウィスパーダンプ ライブラリを使用してストレージからすべての .wsp ファイルを読み取り、このデータを 24 スレッドで前述のカーボン クリックハウスに送信しました。 カーボンクリックハウスで受け入れられるメトリクス値の数は 125 億 XNUMX 万/分に達し、ClickHouse は汗をかくことさえありませんでした。

• 既存のダッシュボードで使用される関数をデバッグするために、Grafana に別の DataSource を作成しました。 使用した関数のリストを特定しましたが、それらは Carbonapi に実装されていませんでした。 これらの機能を追加し、carbonapi の作者に PR を送りました (特別に感謝します)。

• バランサー設定で読み取り負荷を切り替えるために、エンドポイントをgraphite-api (Graphite+WhisperのAPIインターフェース)からcarbonapiに変更しました。

グラファイト+クリックハウス。 結果

• ディスク サブシステムの使用率が 30% から 1% に減少しました。

  

• 占有スペースの量が 1 TB から 300 GB に減少しました。
• 毎分 125 億 XNUMX 万のメトリクスをサーバーに受信する能力があります (ピークは移行時に発生します)。
• すべてのメトリクスを XNUMX 秒の保存間隔に転送しました。
• 受信したデータの複製とフォールト トレランス。
• ダウンタイムなしで切り替え可能。
• すべて完了するまでに約 7 週間かかりました。

グラファイト+クリックハウス。 問題点

私たちの場合、いくつかの落とし穴がありました。 これは移行後に私たちが遭遇したものです。

1. ClickHouse は常にその場で設定を再読み込みするわけではなく、場合によっては再起動が必要になることがあります。 たとえば、ClickHouse 構成内の Zookeeper クラスターの説明の場合、クリックハウス サーバーが再起動されるまで使用されませんでした。
2. 大規模な ClickHouse リクエストは通過しなかったため、graphite-clickhouse では ClickHouse 接続文字列は次のようになります。

   url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"

3. ClickHouse は安定版リリースの新しいバージョンを頻繁にリリースしますが、それらには予期せぬものが含まれる場合がありますので注意してください。
4. Kubernetes で動的に作成されたコンテナーは、短くてランダムな有効期間で大量のメトリクスを送信します。 このようなメトリクスのポイントはそれほど多くなく、スペースに問題はありません。 ただし、クエリを作成するとき、ClickHouse は、「メトリクス」テーブルからこれらの同じメトリクスを大量に取得します。 90% のケースでは、時間枠 (24 時間) を超えるとデータがありません。 ただし、「データ」テーブルでこのデータを検索するのに時間がかかり、最終的にはタイムアウトになってしまいます。 この問題を解決するために、私たちは XNUMX 日中に発生したメトリクスに関する情報を別個のビューで維持するようになりました。 したがって、動的に作成されたコンテナーのレポート (グラフ) を作成する場合、常にクエリを実行するのではなく、特定のウィンドウ内で発生したメトリックのみをクエリするため、コンテナーに関するレポートの構築が大幅に高速化されました。 上記の解決策のために、私は以下を収集しました グラファイトクリックハウス（フォーク）これには、date_metrics テーブルの操作の実装が含まれます。

グラファイト+クリックハウス。 タグ

バージョン 1.1.0 で Graphite が正式になりました サポートタグ。 そして私たちは、グラファイト + クリックハウス スタックでこの取り組みをサポートするために何をどのように行うかを積極的に検討しています。

グラファイト+クリックハウス。 異常検出器

上記のインフラストラクチャに基づいて、異常検出器のプロトタイプを実装しました。これは機能します。 しかし、彼については次の記事で詳しく説明します。

購読して上矢印を押して幸せになってください!

出所： habr.com