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 は次のことを前提としています。

CLICKHOUSE_HOST (デフォルトのローカルホスト) にある Clickhouse サーバーエンドポイント。
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 を単一のリーダーシステムのように使用し、連続的な一貫性を実現します。