从监控到可观测性

• 服务的调用路径变长，使得流量的走向变得不可控，故障排查的难度增大
• 引入 Kubernetes、Docker、Service Mesh 等云原生系统，基础设施层对业务开发团队来说变得更加黑盒

在传统的监控系统中，我们往往会关注虚拟机的 CPU、内存、网络、应用服务的接口请求量、资源使用率等指标，但在复杂的云原生系统中，仅仅关注单点或者单个维度的指标，并不足以帮助我们掌握系统的整体运行状况。在此背景下，对分布式系统的“可观测性”应运而生。通常，我们认为可观测性相对于过去监控，最大的变化就是系统需要处理的数据，从指标为主，扩展到了更广的领域。综合起来，大约有几类数据被看作是可观测性的支柱：

• Metrics
• Logging

为了统一可观测性系统中的数据采集和标准规范，同时提供与供应商无关的接口，CNCF 把 OpenTracing 和 OpenCensus 合并成 OpenTelemetry 项目。OpenTelemetry 通过 Spec 规范了观测数据的数据模型以及采集、处理、导出方法，但对于数据如何去使用、存储、展示和告警是不涉及的，官方目前的推荐方案是：

• 使用 Prometheus 和 Grafana 做 Metrics 的存储和展示
• 使用 Jaeger 做分布式追踪的存储和展示

得益于云原生开源生态的蓬勃发展，技术团队可以轻而易举建设一套监控体系，比如使用 Prometheus + Grafana 搭建基础监控，使用 SkyWalking 或 Jaeger 搭建追踪系统，使用 ELK 或 Loki 搭建日志系统。但对于可观测性系统的用户来说，不同类型的观测数据分散存储在不同的后端，排查问题仍需要在多个系统之间跳转，效率和用户体验都得不到保证。为解决可观测性数据的融合存储和分析，我们自研的统一存储和查询引擎，提供了指标、追踪和日志数据的无缝关联分析。在本文的其他部分，将详细介绍我们是如何提供针对服务的可观测性分析能力。

虽然在大多数时间里这个方法是行之有效的，但我们并不认为这是一个对系统进行观测的最佳实践：

• 业务开发团队需要去熟悉 Metrics、Tracing 和 Logging 系统的各种概念和使用。如果基于开源组件搭配的监控系统，还需要在各个系统之间不断跳转才能完成一次问题的排查，这在今天很多公司里是经常见的

我们在不同领域用户的监控需求的实践中，发现拓扑可以天然的作为观测系统的入口。不同于常见的分布式追踪平台，我们不仅仅把拓扑作为应用系统的运行时架构展示，在基于 100% 采样的真实请求关系绘制出拓扑后，更进一步在拓扑节点上透出服务的请求和服务实例状态（未来还会透出更多的观测数据，比如流量比例、物理节点的状态等）。

在拓扑页面的布局上，我们把页面切分为左右两栏，右边的状态栏会显示我们需要观测的系统关键指标，如服务实例数、服务的错误请求、代码异常和告警次数等。当我们点击拓扑节点时，状态栏会检测节点类型的不同而显示不同的状态数据。当前我们支持展示状态的节点类型有 API Gateway、服务、外部服务和中间件。

拿上面提到的接口异常为例，我们的故障排查方式为：在事务分析页查询触发异常的接口 ，然后点击请求或延迟趋势图上的数据点关联接口采样到的慢事务追踪和错误事务追踪，在弹出的追踪列表中查看请求链路详情和请求关联的日志定位错误根源。