作者 | Rafal Gancarz
譯者 | 平川
策劃 | Tina
Slack 利用其自定義的跟蹤架構來協助排查通知發送問題。該跟蹤架構的幫助下，他們解決通知問題的速度提高了 30%，而且減少了將問題升級給開發團隊的次數。該架構還簡化了分析管道，並為數據科學團隊解鎖了新的應用場景。
消息通知是 Slack 用戶體驗的關鍵組成部分。然而，由於通知流橫跨 Slack 平台的許多組件，包括伺服器端和客戶端，所以要對客戶體驗團隊收到的問題進行排查，有時候並不容易。開發團隊經常不得不花費好幾天的時間，查看多個具有不同日誌記錄後端、不同日誌記錄格式的系統。
圖片來源：https://slack.engineering/tracing-notifications/
之前，Slack 創建了一個自定義的 SlackTrace 跟蹤架構，並使用它來跟蹤日常的消息傳遞。他們用它跟蹤了 1% 的客戶端請求。接下來，該公司決定構建自己的跟蹤解決方案，因為他們發現，沒有一個現成的第三方解決方案能完全滿足他們的需求。
Slack 高級軟體工程師 Suman Karumuri 將跟蹤的好處總結如下：
將產品分析數據建模為跟蹤，可以在整個複雜的技術棧中以一致的數據格式提供高質量的數據。此外，內置的跟蹤數據會話化免除了額外對跟蹤數據進行去重和會話化的任務，簡化了分析管道。
將產品分析數據建模為跟蹤，可以在整個複雜的技術棧中以一致的數據格式提供高質量的數據。此外，內置的跟蹤數據會話化免除了額外對跟蹤數據進行去重和會話化的任務，簡化了分析管道。
SlackTrace 架構由一個 Go Web 伺服器應用程式和一個 Go 消費者服務組成，前者負責向 Apache Kafka 發布跟蹤 span 事件，後者負責將事件持久化到實時存儲（ElasticSearch）和數據倉庫中。後端服務使用 Zipkin 和 Jaeger 工具庫來報告 span 事件，並轉換為內部 span 表示，而桌面和移動應用程式可以直接使用 span API。
圖片來源：https://slack.engineering/tracing-at-slack-thinking-in-causal-graphs/Slack
選用了一種比較簡單的 span 表示，這使得他們的解決方案更加靈活，不用緊緊圍繞請求和網絡跟蹤來開展。Span 的結構簡單，數據可以存儲在單個表中，並且支持多種查詢選項，工程師可以從中提取他們需要的數據來回答特定的問題。
原文連結：
https://www.infoq.com/news/2023/06/slack-notification-tracing/
對話賈揚清、關濤、張伯翰：AI 平民化趨勢下，數據架構將被徹底顛覆？
一場馬斯克的反爬鬧劇：Twitter一夜回到五年前？
對話開源泰斗陸首群教授：中國開源發展應追求0到1的爆發性創新，而不是0到0的假創新