关注【搜狐技术】公众号，第一时间获取技术干货
导 读
分布式追踪系列文章来了！
本周推送为该系列的上篇，主要介绍了分布式追踪系统的原理、“可观察性” 的三大支柱、OpenTracing，同时对当前主流的开源分布式追踪系统进行简单对比。
图片来源: Dapper, a Large-Scale Distributed Systems Tracing Infrastructure随着应用容器化和微服务的兴起，借由 Docker 和 Kubernetes 等工具，服务的快速开发和成为可能，构建微服务应用变得越来越简单。但是随着大型单体应用拆分为微服务，服务之间的依赖和调用变得极为复杂，这些服务可能是团队开发的，可能基于的语言，微服务之间可能是利用 RPC、RESTful API，也可能是通过消息队列实现调用或通讯。如何理清服务依赖调用关系、如何在这样的环境下快速 debug、追踪服务处理耗时、查找服务性能瓶颈、合理对服务的容量评估都一个棘手的事情。
可观察性(Observability)及其三大支柱
为了应对这些问题，可观察性(Observability) 这个概念被引入软件领域。传统的监控和报警主要关注系统的异常情况和失败因素，可观察性更关注的是从系统自身出发，去展现系统的运行状况，更像是一种对系统的自我审视。一个可观察的系统中更关注应用的状态，而不是所处的机器或者网络这样的间接证据。我们希望直接得到应用当前的吞吐和延迟信息，为了这个目的，我们就需要合理主动更多应用运行信息。在当前的应用开发环境下，面对复杂系统我们的关注将逐渐由点到点线面体的结合，这能让我们更好的理解系统，知道What，更能回答Why。
可观察性目前主要以下三大支柱：
日志(Logging):Logging 主要记录一些离散的事件，应用往往通过将定义好格式的日志信息输出到文件，然后用日志收集收集起来用于分析和聚合。目前已经有 ELK 这样的成熟方案, 相比之下日志记录的信息最为全面和丰富，占用的存储资源正常情况下也最多，虽然可以用时间将所有日志点事件串联起来，但是却很难展示完整的调用关系路径；度量(Metrics)Metric 往往是一些聚合的信息，相比 Logging 丧失了一些具体信息，但是占用的空间要比完整日志小的多，可以用于监控和报警，在这方面 Prometheus 已经基本上成为了事实上的；分布式追踪(Tracing)Tracing 介于 Logging 和 Metric 之间， 以请求的维度，串联服务间的调用关系并记录调用耗时，即了的信息，又将分散的日志事件通过 Span 串联，我们更好的理解系统的行为、辅助调试和排查性能问题，也是本文接下来介绍的重点。Logging，Metrics 和 Tracing 既各自有其专注的，也有相互重叠的。
© 版权声明