sentry架构

milk
3,024 阅读2分钟

Overview

关键组件

  • load balancer：如nginx
  • relay：处理客户端接口请求。relay会从web获取project配置信息，然后缓存在内存与redis中
  • snuba：在任意字段上提供快速事件搜索，筛选和聚合的服务
  • sentry
    • sentry（web）：sentry前端页面
    • sentry（work）：业务处理，数据持久化，报警
    • sentry（cron）：定时任务，活性检测

基础服务

  • kafka：消息队列
  • zookeeper
  • clickhouse：列式数仓，主要被snuba依赖
  • redis:缓存，限流等
  • memcached
  • postgres：存储event
  • symbolicator：处理一些符号事件。（不太明白是什么）

relay：

「 运行在应用与sentry之间的独立服务 」

功能

  • 安全：在中间层提供数据清理能力
  • 快速：对请求响应时间非常快，但由于是异步的，对于失败的事件可能也会返回200。详见「 Reference-relay 」
  • 代理：将http请求到自定义域名。

事件存储过程

流程图：getsentry.github.io/event-inges…

1.缓存中获取项目信息：relay默认2分钟从projectconfigs endpoint获取一次配置信息，刷新缓存，信息主要包括：是否存在/启用禁用/限流信息/DSNs

2.根据上述信息可能丢弃事件：是否存在等

3.事件解析与标准化：cpu密集，可能丢弃事件

4.应用过滤器

5.应用限流器

6.写入kafka，topic：ingest-event

7.消费kafka，consumer group：ingest-consumer

8.redis会缓存event

9.celery异步执行任务-分布式异步任务队列（流转如下图）

10.最后save_event任务会存储到postgresSQL，Sunbe kafaka（event topic），NodeStore（Bigtable，不知道是啥）

11.snuba-consumers消费kafka的event topic。snuba存储到clickhouse提供搜索能力。

sentry-web

sentry worker数据存储的过程应该和上文消费ingest-event后的过程是类似的。

Tips

  • sentry可以使用官方服务/也可以自建。注意参考文档不同
  • 两条存储的线，根据请求不同会分别走web存储和relay存储。
  • clickhouse存储的多是异常信息
  • sentry压力最大的是postgres。推荐监控postgres，redis,clickhouse,kafka
  • sentry并不对外暴露prometheus metric,但支持StatsD收集relay的metric。

Reference

avatar
文章
阅读
粉丝