作者 | 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的假创新