Slack利用定制化追踪架构解决通知交付问题

Slack通过其定制的追踪架构SlackTrace，成功解决了通知交付问题。这一架构使通知问题的解决速度提高了30%，并减少了对开发团队的升级请求。此外，它还简化了分析流程，并为数据科学团队解锁了新的用例。

通知交付问题的背景

消息通知是Slack用户体验的关键组成部分。然而，由于通知流程涉及Slack平台中的多个组件（包括服务器端和客户端），当客户体验团队报告问题时，调查这些通知问题变得非常复杂。开发团队通常需要花费数天时间查看多个系统，这些系统具有不同的日志后端和格式。

SlackTrace架构的引入

Slack此前创建了SlackTrace追踪架构，用于追踪常规消息交付，其中1%的客户端请求被追踪。公司决定创建自己的追踪解决方案，因为现有的第三方解决方案无法完全满足其需求。

通知追踪的实施

为了追踪消息通知，团队通过识别重要事件和确定属性映射，将流程映射到追踪中。他们决定将通知追踪与消息请求追踪分开，以便支持100%的通知流程采样，这是Slack客户体验团队的要求。

通知追踪带来的好处

通知追踪改善了问题分类和调试过程。客户体验团队成员可以自行使用追踪数据来了解问题所在，并回答客户的查询，而无需涉及开发团队。这一新功能还帮助iOS和Android工程师开始使用Grafana来监控移动应用中的通知交付。最后，数据科学团队从追踪数据中获得了洞察，他们通过漏斗分析更好地理解通知打开率，并利用历史通知追踪数据识别了应用程序和检测代码中的错误。

SlackTrace架构的技术细节

SlackTrace架构包括一个Go Web服务器应用程序，它将追踪跨度事件发布到Apache Kafka，以及一个Go消费者服务，负责将事件持久化到实时存储（ElasticSearch）和数据仓库中。后端服务使用Zipkin和Jaeger检测库来报告跨度，这些跨度被转换为内部跨度表示，而桌面和移动应用程序则直接使用跨度API。

简单的跨度表示

Slack选择了简单的跨度表示，这使得解决方案更加灵活，不再仅仅围绕请求和网络追踪。简单的跨度结构允许数据存储在单个表中，支持广泛的查询选项，工程师可以提取所需的数据来回答特定问题。

总结

Slack通过其定制的SlackTrace架构，显著提高了通知交付问题的解决效率，简化了分析流程，并为多个团队提供了新的洞察和工具。这一架构的灵活性和简单性使其成为Slack技术栈中不可或缺的一部分。