Sentry モニタリング - Snuba データ ミドル プラットフォーム アーキテクチャ (Kafka+Clickhouse) の紹介

[[427651]]

この記事はWeChatの公開アカウント「Hacker Afternoon Tea」から転載したもので、著者はShaoです。この記事を転載する場合は、Hacker Afternoon Tea公式アカウントまでご連絡ください。

Snuba は、Clickhouse 上に豊富なデータ モデルと、高速な取り込みコンシューマー (Kafka から直接データを取得) およびクエリ オプティマイザーを提供するサービスです。

Snuba はもともと、Postgres と Redis の組み合わせを置き換えて、Sentry エラーに関する集計データを検索および提供するために開発されました。それ以来、現在の形に進化し、複数のデータセットで時系列関連の Sentry 機能のほとんどをサポートするようになりました。

関数

• ClickHouse 分散データ ストレージ用のデータベース アクセス レイヤーを提供します。
• SQL のような機能を提供する SnQL 言語を通じてクライアントがクエリを実行できるグラフィカルな論理データ モデルを提供します。
• 1 回のインストールで複数の個別のデータセットをサポートします。
• ルールベースのクエリ オプティマイザーを提供します。
• 単一ノードおよび分散環境で ClickHouse に DDL 変更を適用するための移行システムを提供します。
• Kafkaから直接データを取り込む
• ポイントインタイムクエリとストリーミングクエリをサポートします。

Sentry の使用例:

• イベント データセットは、問題ページなどの機能のサポートを提供します。ここでの検索機能とすべての集約機能は Snuba によって提供されています。
• 検出データセットは、パフォーマンス監視に関連するすべての機能をサポートします。
• セッション データセットは、リリース機能のサポートを提供します。具体的には、データセットは大量のデータ ポイントを取り込み、事前に集計されたデータを保存して、大量のデータの高速クエリを可能にします。
• 結果データセットは統計ページを強化します。

Snubaを使い始める

これは、Sentry 開発環境で Snuba をすばやく起動するためのガイドです。

必要条件

Snuba は次のことを前提としています。

1. CLICKHOUSE_HOST (デフォルトのローカルホスト) にある Clickhouse サーバー エンドポイント。
2. REDIS_HOST (デフォルトは localhost) で実行されている redis インスタンス。ポート6379。

これらのサービスを実行する簡単な方法は、sentry をセットアップして、以下を使用することです。

セントリー開発サービスアップ--exclude=snuba  

Snuba ではすべてが UTC 時間で実行されていると想定していることに注意してください。そうしないと、タイムゾーンの不一致の問題が発生する可能性があります。

セントリー + スヌーバ

~/.sentry/sentry.conf.py に次の行を追加/変更します。

 SENTRY_SEARCH = 'sentry.search.snuba.EventsDatasetSnubaSearchBackend'  
 SENTRY_TSDB = 'sentry.tsdb.redissnuba.RedisSnubaTSDB'  
 SENTRY_EVENTSTREAM = 'sentry.eventstream.snuba.SnubaEventStream'  

走る：

セントリー開発サービスアップ

オリジナルの Clickhouse クライアント (psql に類似) にアクセスします。

 docker exec -it sentry_clickhouse クリックハウスクライアント

データはsentry_localテーブルに書き込まれます: select count() from sentry_local;

設定

設定はsettings.pyで確認できます。

• クラスター: クラスターのリストと、各クラスターで実行する必要があるホスト名、ポート、およびストレージ セットを指定します。各クラスターには、ローカル設定と分散設定もあります。
• REDIS_HOST: ここで redis が実行されています。

Snuba アーキテクチャの概要

Snuba は、Clickhouse を利用した時系列データ ストレージ サービスです。これは、Snuba が提供するクエリの種類に適した列指向の分散データベースです。

• https://clickhouse.tech/

データは Clickhouse テーブルとマテリアライズド ビューに完全に保存され、入力ストリーム (現在は Kafka トピックのみ) を介して取り込まれ、ポイントインタイム クエリまたはストリーミング クエリ (サブスクリプション) を介してクエリできます。

ストレージ

Clickhouse がバッキング ストアとして選択されたのは、Snuba に必要なリアルタイム パフォーマンス、分散および複製された性質、ストレージ エンジンに関する柔軟性、および一貫性の保証の間で適切なバランスが取れているためです。

Snuba データは Clickhouse テーブルと Clickhouse マテリアライズド ビューに保存されます。テーブルのターゲットに応じて複数の ClickHouse ストレージ エンジンを使用します。

• https://clickhouse.tech/docs/en/engines/table-engines/

Snuba データは、データ モデルの独立したパーティションを表す複数のデータセットに編成されます。詳細については、Snuba データ モデルのセクションを参照してください。

摂取

Snuba は、行を挿入するための API エンドポイントを提供しません (デバッグ モードで実行している場合を除く)。データは複数の入力ストリームからロードされ、一連のコンシューマーによって処理され、Clickhouse テーブルに書き込まれます。

コンシューマーは 1 つ以上のトピックからデータを消費し、1 つ以上のテーブルに書き込みます。これまでのところ、複数のコンシューマーがテーブルに書き込んでいることはありません。これにより、以下で説明する一貫性の保証の一部が可能になります。

データの取り込みはバッチ処理で最も効果的に機能します (Kafka の場合、特に Clickhouse の場合)。私たちのコンシューマーはバッチ処理をサポートしており、Kafka から取得されたイベントのバッチが ClickHouse に少なくとも 1 回は配信されることを保証します。 Clickhouse テーブル エンジンを適切に選択して行の重複を排除することで、最終的な一貫性を受け入れる場合に、正確に 1 回のセマンティクスを実現できます。

クエリ

最も単純なクエリ システムは時間ポイントです。クエリは SnQL 言語 (SnQL クエリ言語) で表現され、HTTP ポスト呼び出しとして送信されます。クエリ エンジンはクエリ (Snuba クエリ処理で説明されているプロセス) を処理し、それを ClickHouse クエリに変換します。

ストリーミング クエリ (サブスクリプション エンジンを介して実行) を使用すると、クライアントはクエリ結果をプッシュ方式で受信できます。この場合、HTTP エンドポイントにより、クライアントはストリーム クエリを登録できます。次に、コンシューマーはトピックにサブスクライブされ、更新のために関連する Clickhouse テーブルにデータを入力し、クエリ エンジンを通じて定期的にクエリを実行し、サブスクライブされた Kafka トピックで結果を生成します。

データの一貫性

Snuba では、さまざまな保証を提供するために、さまざまな一貫性モデルが共存しています。

デフォルトでは、Snuba は最終的に一貫性を持ちます。クエリを実行する場合、デフォルトでは単調な読み取りは保証されません。これは、ClickHouse がマルチリーダーであり、クエリが任意のレプリカにヒットする可能性があり、レプリカが最新であるという保証がないためです。さらに、デフォルトでは、ClickHouse が単独で一貫した状態に到達するという保証はありません。

クエリを実行する前に ClickHouse に一貫性を強制的に達成させ (FINAL キーワード)、コンシューマーが書き込む特定のレプリカにクエリがヒットするように強制することで、特定のクエリで強力な一貫性を実現できます。これは基本的に、ClickHouse を単一のリーダー システムのように使用し、連続的な一貫性を実現します。

スヌーバのセントリー配備

このセクションでは、主なデータ フローを示しながら、Sentry 展開で Snuba が果たす役割について説明します。 Snuba を単独で展開した場合、これは役に立ちません。

エラーとトランザクションのデータフロー

図の上部にあるメインセクションは、イベントおよびトランザクション エンティティの取り込みプロセスを示しています。これら 2 つのエンティティは、Sentry およびパフォーマンス製品全体の問題/エラー関連の機能の大部分を提供します。

このパイプラインの情報を提供する、エラーとトランザクション間で共有される Kafka トピック (イベント) は 1 つだけです。このトピックには、エラー メッセージとトランザクション メッセージが含まれています。

エラー コンシューマーは、イベント トピックを使用して、ClickHouse エラー テーブルにメッセージを書き込みます。コミット後、snuba-commit-log トピックにもレコードが生成されます。

エラー アラートは、エラー サブスクリプション コンシューマーによって生成されます。これは、メイン イベント トピックと snuba-commit-log トピックの両方を消費する同期コンシューマーであるため、メイン コンシューマーと同期して続行できます。

同期されたコンシューマーは、Clickhouse にクエリを実行し、結果トピックで結果を生成することでアラートを生成します。

トランザクションは同じですが独立したパイプラインに存在します。

エラー パイプラインには、置換トピックへの書き込みという追加のステップがあります。 Sentry は、イベント トピックでエラー ミューテーション (マージ/アンマージ/再処理など) を生成します。次に、エラー コンシューマーはそれらを置換トピックに転送し、置換コンシューマーによって実行されます。

プロジェクト内のイベントを順番に処理できるようにするには、イベント トピックを Sentry プロジェクト ID によって意味的に分割する必要があります。これまでのところ、これはアラートと交換の要件です。

セッションと成果

セッションと成果は非常によく似ており、よりシンプルな方法で動作します。特に、セッションはリリースの健全性機能を強化し、成果は主に Sentry 統計ページにデータを提供します。

どちらのパイプラインにも独自の Kafka トピック、Kafka コンシューマーがあり、Clickhouse の独自のテーブルに書き込みます。

変更データキャプチャパイプライン

パイプラインはまだ建設中です。 cdc トピックを使用し、Clickhouse に 2 つの別々のテーブルを作成します。