讲Sentry:浅谈架构

Sentry是客户端/服务器(C/S,Client/Server)架构。由Python编写。如果我们在应用中使用Sentry,需要安装Sentry SDK。本文着重讲Sentry Server部分,一窥Sentry的架构思路。

背景

笔者的Sentry Server是通过onpremise进行安装:https://github.com/getsentry/onpremise。阅读前假设您已经了解过以下工具:

  • Dockerdocker-compose
  • Zookeeper:配置维护、统一命名服务、状态同步服务、集群管理等。协调分布式服务。
  • Celery 是Python开发的分布式任务调度模块。
  • Kafka
    • 消息引擎系统
    • Topic
      • 点对点模型:也叫消息队列模型。那么系统A发送的消息只能被系统B接收,其他任何系统都不能读取A发送的消息。一对一
      • 发布/订阅模型:与上面不同的是,它有一个主题(Topic)的概念,你可以理解成逻辑语义相近的消息容器。该模型也有发送方和接收方,只不过提法不同。发送方也称为发布者(Publisher),接收方称为订阅者(Subscriber)。和点对点模型不同的是,这个模型可能存在多个发布者向相同的主题发送消息,而订阅者也可能存在多个,它们都能接收到相同主题的消息。生活中的报纸订阅就是一种典型的发布/订阅模型。 多对多

1615156368000image.png

架构概述

下方是从Sentry官方文档中找到的架构图。

1615156393000image.png

(Sentry Architecture)

从上到下:

  • 第一层
    • Load Balancer(负载均衡器)负责路由转发。错误上报转发到 /api/\d+/store 。这一层承担数据入口。
  • 第二层
    • Sentry Web主要跟配置等持久化数据打交道,创建项目、权限控制、限流分配等都是它负责。查询搜索错误消息、Dashboard 聚合等功能则是 Snuba 承担,由它来当翻译官,把用户查询条件转化为 SQL 语句发给 ClickHouse。
  • 第三层
    • Relay 负责消息中继转发,并把数据先汇集到 Kafka。
    • Snuba 负责接收 SentryWeb 的请求,进行数据的聚合、搜索。
    • Sentry Worker 则是一个队列服务,主要负责数据的存储。
  • 第四层
    • Kafka 作为消息队列。
    • ClickHouse 负责实时的数据分析。
    • Redis 和 Memcached 负责项目配置、错误基础信息的存储和统计。
    • Postgres 承担基础数据持久化(主要是项目、用户权限管理等)。
    • Symbolicator 主要用于错误信息格式化。
  • 第五层
    • 最底下的 Zookeeper 是 Kafka 用于节点信息同步,如果我们设置了多个 ClickHouse 节点,也可以用它来保存主从同步信息或者做分布式表。

Relay ——错误信息处理的中转站

1615156558000image.png

Relay 收到原始请求数据后,主要做这几件事。

  1. 对其格式进行有效性校验
  2. 查询内存或者从 Redis 拉取缓存得到项目配置信息,校验请求是否合法(项目是否存在或者有没有触发请求限流,没触发限流则会对 API 额度进行累计,写入 Redis) https://develop.sentry.dev/services/quotas/
  3. 发起一个异步请求给定时任务(SentryWorker,postprocess-event)做下一步处理

Kafka 和 Celery —— 解耦和异步保存数据

Relay 数据转发到 Kafka 的 ingest-events Topic,Sentry ingest consumer消费后把消息放入 postprocess-event 这个 Celery 定时任务服务排队处理。队列做的事情如下:

  1. celery Sentry依赖它来调度任务。
  2. symbolicate-event将机器的错误日志格式化为可读的错误日志,经过它的消息,我们就可以在页面上看到代码在哪里出错了。
  3. process-event,字面含义就是处理消息,在 Sentry 上启用的插件(Plugins or Integration)会在这个步骤中应用到,例如,整合了一个 飞书 Sentry bot(机器人),就会在这个步骤发送告警。
  4. save-event,简化消息,保存到数据库,同时再次发到 Kafka,但这次换到 event Topic,Snuba 这个搜索组件内部会有一个消费者,对这部分数据批量写入到 ClickHouse。为什么写入Clickhouse,这是因为 ClickHouse 虽然大数据量处理能力很强,但频繁写入能力有限,所以通过** Snuba 来限制写入频率**。

1615156480000image.png

(如果看不清,点击这看原图Event Ingestion Pipeline)

参考

Sentry Architecture

Event Ingestion Pipeline

Sentry:如何从数据存储中获得更强的一致性

日记本

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

赞赏支持
被以下专题收入,发现更多相似内容