sentry.png

流程解釋

數(shù)據(jù)寫入

• Relay 收到原始數(shù)據(jù)后，主要做這幾件事。
  1. 對其格式進行有效性校驗
  2. 查詢內(nèi)存或者從 Redis 拉取緩存得到項目配置信息，校驗請求是否合法（項目是否存在或者有沒有觸發(fā)限流，沒觸發(fā)限流則會對 API 額度進行累計，寫入 Redis）
  3. 發(fā)起一個異步請求給定時任務（SentryWorker）做下一步處理
• Kafka 和 Worker
  1. 應用解耦和異步保存數(shù)據(jù) Relay 數(shù)據(jù)轉(zhuǎn)發(fā)到 Kafka 的 ingest-events Topic（Ingest 即攝?。M者消費后把消息放入 postprocess-event 這個 Celery 定時任務服務排隊處理。隊列做的事情如下
     a. Symbolicate-event，在 iOS 上有個叫 symbolicate-crash 的工具，是將機器的崩潰日志轉(zhuǎn)化為可讀的崩潰代碼定位日志，這里的 Symbolicator 同樣承擔類似的職能，由它經(jīng)手的消息，我們就可以在頁面上看到代碼在哪里出錯了。
     b. process-event，字面含義就是處理消息，在 Sentry 上啟用的插件（Plugins or Integration）會在這個步驟中應用到消息體上，例如，整合了一個 Slack bot（機器人），就會在這個步驟發(fā)送告警。
     c. save-event，消息經(jīng)過簡化，保存到數(shù)據(jù)庫，同時再次發(fā)到 Kafka，但這次換到 event Topic，Snuba 這個搜索組件內(nèi)部會有一個消費者，對這部分數(shù)據(jù)批量寫入到 ClickHouse。因為 ClickHouse 雖然大數(shù)據(jù)量處理能力很強，但頻繁寫入能力是真的菜雞（假設(shè)做了主從，那就更災難了，把從庫和 Zookeeper 都一起拉下水），所以需要 Snuba 來限制寫入頻率。
• Sentry Web 這邊主要跟配置等持久化數(shù)據(jù)打交道，創(chuàng)建項目、權(quán)限控制、限流分配等都是它負責。查詢搜索錯誤消息、Dashboard 聚合等功能則是 Snuba 承擔，由它來當翻譯官，把用戶查詢條件轉(zhuǎn)化為 SQL 語句發(fā)給 ClickHouse。