调用链追踪系统在伴鱼:实践篇.docxVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
调用链追踪系统在伴鱼:实践篇 1.1 对接 Jaeger 2021 年,公司内部的微服务数量逐渐添加,调用关系日趋简单,工程师做功能分析、问题排查的难度变大。这时亟需一套调用链追踪系统挂念我们添加对服务端全貌的了解。经过调研后,我们打算接受同样基于 Go 言语搭建的、由 CNCF 孵化的项目 Jaeger。当时,服务的开发和管理都尚未引入?context,不论进程内部调用还是跨进程调用,都没有上下文传递。因而晚期引入调用链追踪的工作重心就落在了服务及服务管理框架的改造,包括: 在 HTTP、Thrift 和 gRPC 的服务端和客户端注入上下文信息 在数据库、缓存、消息队列的接入点上埋点 快速往既有项目仓库中注入?context?的命令行工具 部署方面:测试环境接受?all-in-one,线上环境接受 direct-to-storage 方案。整个过程前后大约耗时一个月,我们在 2021 年 Q3 上线了第一版调用链追踪系统。协作广泛被接受的 prometheus + grafana 以及 ELK,我们在微服务群的可观测性上最终凑齐了 metrics、logs 和 traces 三个要素。 1.2 遇到的问题 在?理论篇?中,我们引见过 Jaeger 支持三种采样方式: Const:要么全采样,要么不采样 Probabilistic:按固定概率采样 Rate Limiting:限流采样,即保证每个进程在固定时间内最多采 k 个 这些采样方式都属于头部连贯采样 (head-based coherent sampling),我们在?理论篇?中曾争辩过其优劣势。伴鱼的生产环境中使用的是限流采样策略:每个进程每秒最多采 1 条 trace。这种策略虽然很节省资源,但其缺点在一次次线上问题排查中渐渐暴露: 一个进程中包含多个接口:不论按固定概率采样还是限流采样,都会导致小流量接口饿死。 线上服务出错是小概率大事,导致出错的恳求被采中的概率更小,就导致采到的调用链信息量不大,引发问题的调用链却丢失的问题。 2. 调用链通路改造 2.1 使用场景 2021 年,我们不断收到业务研发的反馈:能不能全量采集 trace? 这促使我们开头重新思考如何改进调用链追踪系统。我们做了一个简约的容量预估:目前 Jaeger 每天写入 ES 的数据量接近 100GB/天,假如要全量采集 trace 数据,保守假设平均每个 HTTP API 服务的总 QPS 为 100,那么完整存下全量数据需要 10TB/天;乐观假设 100 名服务器研发每人每天查看 1 条 trace,每条 trace 的平均大小为 1KB,则全体信噪比千万分之一。可以看出,这件事情本身的 ROI 很低,考虑到将来业务会持续增长,存储这些数据的价值也会连续降低,因而全量采集的方案被放弃。退一步想:全量采集真的是本质需求吗?实际上并非如此,我们想要的其实是「有意思」的 trace 全采,「没意思」的 trace 不采。 依据?理论篇?中引见的应用场景,实际上第一版调用链追踪系统只支持了稳态分析,而业务研发亟需的是特别检测。要同时支持这两种场景,我们必需借助尾部连贯采样 (tail-based coherent sampling)。相对于头部连贯采样在第一个 span 处就做出能否采样的打算,尾部连贯采样可以让我们在猎取 (接近) 完整的 trace 信息后再做出推断。抱负情况下,只需能合理地制定采样的推断规律,我们的调用链追踪系统就能做到「有意思」的 trace 全采,「没意思」的 trace 不采。 2.2 架构设计 Jaeger 团队从 2021 年就开头争辩引入 tail-based sampling 的可能性,但至今未有定论。在一次与 Jaeger 工程师 jpkrohling 的一对一沟通中,对方也证明白目前 Jaeger 尚没有相关的支持方案。因而,我们不得不另辟蹊径。经过一番调研,我们找到了刚刚进驻 CNCF SandBox 的 OpenTelemetry,它的 opentelemetry-collector 子项目恰好能支持我们在现有架构上引入尾部连贯采样。 2.2.1 OpenTelemetry Collector 整个 OpenTelemetry 项目目的在于统一市面上可观测性数据 (telemetry data) 的标准,同时供应推动这些标准实施的组件和工具。opentelemetry-collector 就是这个生态中的一个重要组件,它的架构图如下: collector 内部有 4 个核心组件: Receivers:担任接收不同格式的 telemetry data,对于 trace 来说就是 Zipkin、Jaeger、OpenCensus 以及其自研的 otlp。

文档评论(0)

136****7795 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档