
内容整理自官方开发文档
本文档的目标是将 Sentry SDK 中性能监控功能的演变置于上下文中。
我们首先总结了如何将性能监控添加到 Sentry 和 SDK,
然后我们讨论 identified issues(已确定的问题) 吸取的经验教训以及解决这些问题的举措。
介绍
早在 2019 年初,Sentry 就开始尝试向 SDK 添加跟踪功能。Python 和 JavaScript SDK 是设计和开发第一个概念的测试平台。
概念验证于 2019 年 4 月 29 日 发布,
并于 2019 年 5 月 7 日交付给 Sentry。Python 和 JavaScript 是显而易见的选择,因为它们允许我们试验检测 Sentry 自己的后端和前端。
- https://github.com/getsentry/sentry-python/pull/342
- https://github.com/getsentry/sentry-javascript/pull/1918
- https://github.com/getsentry/sentry-python/releases/tag/0.7.13
- https://github.com/getsentry/sentry/pull/12952
请注意,上述工作与 OpenCensus 和 OpenTracing 合并形成 OpenTelemetry 是同时代的。Sentry 的 API 和 SDK 实现借鉴了 OpenTelemetry 1.0 之前版本的灵感,并结合了我们自己的想法。
例如,我们的 Span 状态列表与 2019 年底左右在 OpenTelemetry 规范中可以找到的匹配。
- https://medium.com/opentracing/a-roadmap-to-convergence-b074e5815289
- https://github.com/getsentry/relay/blob/55127c75d4eeebf787848a05a12150ee5c59acd9/relay-common/src/constants.rs#L179-L181
使用 API 后,性能监控支持随后扩展到其他 SDK。Sentry 的性能监控 解决方案于 2020 年 7 月普遍可用。OpenTelemetry 的跟踪规范 1.0 版于 2021 年 2 月发布。
- https://blog.sentry.io/2020/07/14/see-slow-faster-with-performance-monitoring
- https://medium.com/opentelemetry/opentelemetry-specification-v1-0-0-tracing-edition-72dd08936978
我们最初的实现重用了我们现有的错误报告机制:
- Event type 扩展了新字段。 这意味着我们可以节省时间并快速开始向
Sentry发送事件,而不是设计和实现全新的摄取管道,这一次,不是error,而是一种新的transaction事件类型。 - 由于我们只是发送一种新型事件,因此也重用了
SDK传输层。 - 由于我们共享
摄取管道(ingestion pipeline),这意味着我们共享存储以及发生在所有事件上的处理的许多部分。
我们的实现演变成明确强调 Transaction 和 Span 之间的区别。部分原因是重用 Event 接口的副作用。
Transaction 与客户产生了良好的共鸣。
他们允许突出显示代码中的重要工作块,例如浏览器页面加载或 http 服务器请求。
客户可以查看和浏览 transaction 列表,而在 transaction 中,span 为更细粒度的工作单元提供详细的时间安排。
在下一节中,我们将讨论当前模型的一些缺点。
已确定的问题
虽然统一 SDK 架构(hub、client、scope)
和 transaction ingestion 模型的重用有其优点,但经验揭示了一些我们将其分为两类的问题。

本文介绍了Sentry在SDK开发中性能监控功能的演进,包括Scope传播的问题,如当前Span确定的挑战,以及Span摄取模型带来的复杂JSON序列化和事务处理难题。Sentry的实现与OpenTelemetry规范相融合,但面临并发处理、事件传播和数据模型的局限性,这些问题需要通过重构和改进来解决。
最低0.47元/天 解锁文章
1087

被折叠的 条评论
为什么被折叠?



