Sentry监控-Snuba数据中台架构简介（Kafka+Clickhouse）

Sentry监控-Snuba数据中台架构简介（Kafka+Clickhouse）
系列
Snuba 是⼀种在 Clickhouse 之上提供丰富数据模型以及快速摄取消费者(直接从 Kafka 获取数据)和查询优化器的服务。

Snuba 最初的开发⽬的是取代 Postgres 和 Redis 的组合，以搜索和提供有关 Sentry 错误的聚合数据。

从那时起，它已经演变成⽬前的形式，在多个数据集上⽀持⼤多数与时间序列相关的 Sentry 功能。

功能
为 Clickhouse 分布式数据存储提供数据库访问层。

提供⼀个图形逻辑数据模型，客户端可以通过 SnQL 语⾔查询，该语⾔提供类似于 SQL 的功能。

在单个安装中⽀持多个单独的数据集。

提供基于规则的查询优化器。

提供⼀个迁移系统，将 DDL 更改应⽤于单节点和分布式环境中的 Clickhouse。

直接从 Kafka 摄取数据
⽀持时间点查询和流式查询。

Sentry 中的⼀些⽤例：
events 数据集为 Issue Page 等功能提供⽀持。

此处的搜索功能由 Snuba 以及所有聚合(aggregation)函数提供⽀持。

discover 数据集为所有性能监控(Performance Monitoring)相关功能提供⽀持。

sessions 数据集为发布(Releases)功能提供⽀持。

具体来说，该数据集会摄取⼤量数据点并存储预先聚合的数据，以允许对⼤量数据进⾏快速查询。

outcomes 数据集为统计页⾯(Stats page)提供⽀持。

开始使⽤ Snuba
这是在 Sentry 开发环境中快速启动 Snuba 的指南。

必要条件
Snuba 假设如下：
⼀个 Clickhouse 服务器端点位于 CLICKHOUSE_HOST（默认 localhost）。

在 REDIS_HOST（默认 localhost）上运⾏的 redis 实例。

在端⼝ 6379 上。

让这些服务运⾏的快速⽅法是设置 sentry，然后使⽤：
sentry devservices up --exclude=snuba
请注意，Snuba 假设⼀切都在 UTC 时间运⾏。

否则，您可能会遇到时区不匹配的问题。

Sentry + Snuba
在 ~/.sentry/sentry.conf.py 中添加/更改以下⼏⾏：
SENTRY_SEARCH = 'sentry.search.snuba.EventsDatasetSnubaSearchBackend'
SENTRY_TSDB = 'sentry.tsdb.redissnuba.RedisSnubaTSDB'
SENTRY_EVENTSTREAM = 'sentry.eventstream.snuba.SnubaEventStream'
运⾏：
sentry devservices up
访问原始 clickhouse client（类似于 psql）：
docker exec -it sentry_clickhouse clickhouse-client
数据写⼊表 sentry_local: select count() from sentry_local;
设置
设置可以在 settings.py 中找到
CLUSTERS：提供集群列表以及应该在每个集群上运⾏的主机名(hostname)、端⼝(port)和存储集(storage sets)。

每个集群也设置了本地与分布式(Local vs dis tributed)。

REDIS_HOST：redis 正在运⾏此处。

Snuba 架构概述
Snuba 是⼀个由 Clickhouse ⽀持的⾯向时间序列的数据存储服务，它是⼀个列式存储分布式数据库，⾮常适合 Snuba 服务的查询类型。

数据完全存储在 Clickhouse 表和物化(materialized)视图中，它通过输⼊流（⽬前只有 Kafka topic）摄取，并且可以通过时间点查询或流式查询（subscriptions）进⾏查询。

存储
之所以选择 Clickhouse 作为后备存储，是因为它在 Snuba 需要的实时性能、分布式和复制性质、存储引擎⽅⾯的灵活性和⼀致性保证之间提供了良好的平衡。

Snuba 数据存储在 Clickhouse 表和 Clickhouse 物化视图(materialized views)中。

根据表的⽬标使⽤多个 Clickhouse 存储引擎。

Snuba 数据组织在多个数据集中，这些数据集表⽰数据模型的独⽴分区。

更多细节见 Snuba 数据模型部分。

摄取
Snuba 不提供⽤于插⼊⾏的 api 端点（除⾮在调试模式下运⾏）。

数据从多个输⼊流加载，由⼀系列消费者处理并写⼊ Clickhouse 表。

⼀个 consumer 消费⼀个或多个 topic 并写⼊⼀个或多个表。

到⽬前为⽌，还没有多个消费者写⼊表。

这允许下⾯讨论的⼀些⼀致性保证。

数据摄取(Data ingestion)在批处理中最有效（对于 Kafka 但尤其是对于 Clickhouse）。

我们的 consumer ⽀持批处理并保证从 Kafka 获取的⼀批事件⾄少传递给 Clickhouse ⼀次。

通过正确选择 Clickhouse 表引擎对⾏进⾏重复数据删除，如果我们接受最终⼀致性，我们可以实现恰好⼀次语义。

查询
最简单的查询系统是时间点。

查询以 SnQL 语⾔（SnQL 查询语⾔）表⽰，并作为 HTTP post 调⽤发送。

查询引擎处理查询（Snuba 查询处理中描述的过程）并将其转换为 ClickHouse 查询。

流式查询（通过订阅引擎完成）允许客户端以推送⽅式接收查询结果。

在这种情况下，HTTP 端点允许客户端注册流查询。

然后订阅 Consumer 消费到⽤于填充相关 Clickhouse 表以进⾏更新的 topic，通过查询引擎定期运⾏查询并在订阅 Kafka topic 上⽣成结果。

数据⼀致性
不同的⼀致性模型在 Snuba 中并存以提供不同的保证。

默认情况下，Snuba 是最终⼀致的。

运⾏查询时，默认情况下，不能保证单调读取(monotonic reads)，因为 Clickhouse 是多领导者(multi-leader)，查询可以命中任何副本，并且不能保证副本是最新的。

此外，默认情况下，不能保证 Clickhouse 会⾃⾏达到⼀致状态。

通过强制 Clickhouse 在执⾏查询之前达到⼀致性（FINAL keyword），并强制查询命中 consumer 写⼊的特定副本，可以在特定查询上实现强⼀致性。

这本质上使⽤ Clickhouse，就好像它是⼀个单⼀的领导系统(single leader system)，它允许顺序⼀致性(Sequential consistency)。

Sentry 部署中的 Snuba
本节解释了 Snuba 在展⽰主要数据流的 Sentry 部署中扮演的⾓⾊。

如果您单独部署 Snuba，这对您没有⽤处。

Errors 和 Transactions 数据流
图表顶部的主要部分说明了 Events 和 Transactions 实体的摄取过程。

这两个实体为 Sentry 和整个 Performance 产品中的⼤多数问题/错误(issue/errors)相关功能提供服务。

只有⼀个 Kafka topic（events）在 errors 和 transactions 之间共享，为这条管道提供信息。

此 topic 包含 error 消息和 transaction 消息。

Errors consumers 使⽤ events topic，在 Clickhouse errors 表中写⼊消息。

提交后，它还会⽣成关于 snuba-commit-log topic 的记录。

错误警报由 Errors Subscription Consumer ⽣成。

这是同步消费者(synchronized consumer)，它同时消费主 events topic 和 snuba-commit-log topic，因此它可以与主 consumer 同步进⾏。

synchronized consumer 然后通过查询 Clickhouse ⽣成警报，并在 result topic 上⽣成结果。

transactions 存在于⼀个相同但独⽴的管道。

Errors 管道还有⼀个额外的步骤：写⼊ replacements topic。

Sentry 在 events topic 上产⽣ Errors mutations(合并/取消合并/再处理/等等)。

然后，Errors Consumer 将它们转发到 replacements topic，并由 Replacement Consumer 执⾏。

events topic 必须按 Sentry project id 在语义上进⾏分区，以允许按顺序处理项⽬中的事件。

⽬前为⽌，这是 alerts 和 replacements 的要求。

Sessions 与 Outcomes
Sessions 和 Outcomes 以⾮常相似和更简单的⽅式⼯作。

特别是 Sessions 增强 Release Health 功能，⽽ Outcomes 主要向 Sentry 统计页⾯提供数据。

两个管道都有⾃⼰的 Kafka topic，Kafka consumer，它们在 Clickhouse 中写⾃⼰的表。

变更数据捕获管道
这条管道仍在建设中。

它使⽤ cdc topic 并填充 Clickhouse 中的两个独⽴表。