sentry.png

流程解释

数据写入

• Relay 收到原始数据后，主要做这几件事。
  1. 对其格式进行有效性校验
  2. 查询内存或者从 Redis 拉取缓存得到项目配置信息，校验请求是否合法（项目是否存在或者有没有触发限流，没触发限流则会对 API 额度进行累计，写入 Redis）
  3. 发起一个异步请求给定时任务（SentryWorker）做下一步处理
• Kafka 和 Worker
  1. 应用解耦和异步保存数据 Relay 数据转发到 Kafka 的 ingest-events Topic（Ingest 即摄取），消费者消费后把消息放入 postprocess-event 这个 Celery 定时任务服务排队处理。队列做的事情如下
     a. Symbolicate-event，在 iOS 上有个叫 symbolicate-crash 的工具，是将机器的崩溃日志转化为可读的崩溃代码定位日志，这里的 Symbolicator 同样承担类似的职能，由它经手的消息，我们就可以在页面上看到代码在哪里出错了。
     b. process-event，字面含义就是处理消息，在 Sentry 上启用的插件（Plugins or Integration）会在这个步骤中应用到消息体上，例如，整合了一个 Slack bot（机器人），就会在这个步骤发送告警。
     c. save-event，消息经过简化，保存到数据库，同时再次发到 Kafka，但这次换到 event Topic，Snuba 这个搜索组件内部会有一个消费者，对这部分数据批量写入到 ClickHouse。因为 ClickHouse 虽然大数据量处理能力很强，但频繁写入能力是真的菜鸡（假设做了主从，那就更灾难了，把从库和 Zookeeper 都一起拉下水），所以需要 Snuba 来限制写入频率。
• Sentry Web 这边主要跟配置等持久化数据打交道，创建项目、权限控制、限流分配等都是它负责。查询搜索错误消息、Dashboard 聚合等功能则是 Snuba 承担，由它来当翻译官，把用户查询条件转化为 SQL 语句发给 ClickHouse。