Slack利用自定义的跟踪架构来协助排查消息通知问题

Slack 利用其自定义的跟踪架构来协助排查通知发送问题。该跟踪架构的帮助下，他们解决通知问题的速度提高了 30%，而且减少了将问题升级给开发团队的次数。该架构还简化了分析管道，并为数据科学团队解锁了新的应用场景。

消息通知是 Slack 用户体验的关键组成部分。然而，由于通知流横跨 Slack 平台的许多组件，包括服务器端和客户端，所以要对客户体验团队收到的问题进行排查，有时候并不容易。开发团队经常不得不花费好几天的时间，查看多个具有不同日志记录后端、不同日志记录格式的系统。

之前，Slack 创建了一个自定义的 SlackTrace 跟踪架构，并使用它来跟踪日常的消息传递。他们用它跟踪了 1% 的客户端请求。接下来，该公司决定构建自己的跟踪解决方案，因为他们发现，没有一个现成的第三方解决方案能完全满足他们的需求。

为了跟踪消息通知，团队识别出值得注意的事件并确定了属性映射，从而实现流和跟踪的映射。他们决定将通知跟踪与消息请求跟踪分开。这样，他们就可以支持通知流的 100% 采样，从而满足 Slack 客户体验团队的要求。

通知跟踪改进了问题归类和调试。客户体验团队的成员自己就可以使用跟踪数据来了解出错的位置，不需要求助开发团队就可以解答客户的疑问。这个新功能也为 iOS 和 Android 工程师开始使用 Grafana 来监控移动应用程序中的通知发送提供了帮助。最后，数据科学团队从跟踪数据中获得了洞察。他们通过漏斗分析来加深对通知打开率的理解，并利用历史通知跟踪数据来识别应用程序中的 Bug 和工具代码。

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/

声明：本文为 InfoQ 翻译，未经许可禁止转载。