嘉宾 | 杨金全    整理 | 山河已无恙

出品 | CSDN云原生

2022年4月26日，在CSDN云原生系列在线峰会第2期“可观测性与APM峰会”上，听云研发总监杨金全分享了以Tracing为核心的可观测性体系。

戳👇观看杨金全分享视频

为什么需要可观测性

IT架构的变迁

应用架构的模式变迁经历了由单体架构到分布式架构，再到如今以K8s微服务为代表的云原生架构的过程。

现在所处的云原生时代是以DevOps开发模式为开发的基准，采用微服务架构，所有的微服务都运行在容器上，所有的容器跑在私有云或公有云上。这样的话会给系统会带来什么样的挑战呢？

云原生时代下的系统复杂性越来越严重

• 用户体验和应用比以往任何时候都重要。数字化转型使得企业及客户都依赖于体系化的IT系统来实现增长。

• 在构建数字化转型整个过程中，应用的数量、数据的体量，变化的频率和增加的速度，都已经远远超越了仅通过固定仪表板就可以管理复杂IT系统的能力。

• 多云/混合云的部署模式都是容器化且动态变化的。容器创建的速度和规模及其生命周期超出数据中心时代管理边界。

• 多种多样的开发语言和各种各样的运行时，以及当前所采用的各种大数据组件、支持软件及数据库都已经超越了IT从业者的沟通界面，单独的沟通形式已无法满足不同的开发者之间的沟通需求。

• 企业的资源是有限的，不断增加的系统复杂性以及故障排查的难度，正在消耗企业IT从业者的时间，窃取企业的创新时间。

在挑战重重的背景下查看复杂系统，正如上图所示，从广度上看，一个系统要与30多个应用交互；从深度上看，一笔交易的完成可能需要调用170多个微服务。可以说，无论是从广度或是深度，其服务的覆盖面、交互面都越来越广，使目前的系统变得越来越复杂。

APM面临的挑战

当业务系统越来越复杂时，对于管理者来说，其责任域和控制域是不匹配的。以往为了解决复杂系统的问题，我们多采用监控工具和手段。但在如今可观测性场景下，APM、原有的监控技术和手段会面临众多挑战：

• 目前，一个应用、一个服务、每笔交易、每个用户每一秒的体验都非常重要。APM原本的采样方法已经不合时宜，无法做到全面全量的监控。

• 应用被拆分成多个微服务，每一个微服务都需要快速的更新。这使得监控的对象和指标呈指数级增长，原有APM后端模型已捉襟见肘，无法支撑海量的数据采集和分析。

• 全面监控不仅意味着要收集每一笔交易的性能指标，还包括交易所相关的日志、追踪、依赖项、拓扑关系与元数据。

• 所有的服务都是动态运行的，这意味着微服务与容器以闪电般的速度创建和销毁。

• 企业在数字化转型中创新的步伐需要越来越快，APM代理需要自动探测新容器的创建和销毁，并适配新技术的监控需求。

真实用户场景下，面临很多的不确定性，这时就需要用观测性的能力来匹配现有的监控的复杂系统，那么到底什么是可观测性？

什么是可观测性

维基百科上对可观测性的定义是：可观测性是一种方法，通过检查系统的外部输出来衡量整个系统内部状态的一种能力。因此，可观测性是一个关于解决“未知的未知”和“未知的已知”问题域的能力模型。

可观测性可以让你在系统不可用时，快速了解问题的现状和影响，并能够深入探索、跟踪问题的根因。

可观测性VS监控

可观测性和现在的所采用的监控有什么样的区别？

High Performance MysQl 作者 Baron Schwartz在解释Observability和Monitoring的区别时说：

“Monitoring tells you whether system works，observability lets you ask why it is not working.”

监控是为了提高系统可观测性而使用的手段；可观测性是系统的核心能力，以提升系统的性能。

监控是用来观察系统性能的一个行为，而可观测性其实是一种度量，它是通过系统的输入、输出来衡量系统内部状态。监控需求提前了解需要监控的关键Telemetry数据，可观测性通过探索，结合领域知识来寻找某一个问题的关键Telemetry数据。

所以在当前聚焦系统可观测性时，我们认为可观测性是IT建设过程中的必要手段。在开发的整个生命周期、维护的生命周期中，都应具备可观测性的核心能力，用来提高业务的转化率。

传统意义上实现“可观测性的三大支柱”

传统意义上可观测性有三大支柱：Metrics 、Logging、Tracing。

割裂的可观测性生态

当前有很多可观测性的工具，但这些工具单一、没有整合。

• 若想了解日志，需要搭建一套Elasticsearch+Kibana+Metricbeat平台。

• 若想看指标，需要搭一套Prometheus+Grafana+NodeExporter的平台看指标的变化。

• 若想看追踪，则需要采用一些追踪的工具，比如Tracing来观测每一个Trace的链路状态。

这些数据在传统的可观测性的三大支柱中是非常割裂的，需要部署不同的技术栈来去解决不同可观测性数据的采集和展示。

复杂系统下海量Metrics和Logs带来的负担

以典型的银行场景为例，一套系统需要在每一个节点上部署指标采集的agent，需要部署log日志采集的组件，在每一个服务上都需要去安装采集器进行数据收集。

这样的话，数据量会非常庞大，可能会带来更加严峻的挑战。首先，在海量的服务中进行日志检索非常困难。其次，日志与日志之间并没有相关性，因果很难通过原有的监控体系进行判断。

以Tracing为核心融合可观测性三大支柱

当把三大支柱中的Tracing作为核心时，可以通过Tracing将所有的指标和日志相关联。当问题出现时，只需关注某一个链路的相关数据即可。这样可以给整个系统带来好处：

• 更加精准的定位问题

• 检索的数据更加精准

• 检索反馈的过程更加高效

以Tracing为核心的高级可观测性

若想构建高级的可观测性，所需要的不仅仅是指标，还有日志、Tracing以及更多的数据帮助实现。

可观测性平台应该具备什么样的能力

• 全面的数据采集能力

• 全量的数据采集能力

• 通过自动化技术实现可伸缩性和完整性能力

• 高级分析的能力

• 超大规模实时计算能力

• 多源集成能力

• 基于AI和确定性因果关系的根因分析能力

• 业务实时洞察能力

基调听云通过对300+技术栈进行适配扩展，将追踪、日志、指标、行为、业务、OpenTelemetry等多源数据统一采集、处理和分析模型，构建基调听云可观测中台，纳入现有技术实践成果，对其进行融合分析，通过OneTrace模型展示整个生态下的调用结构，结合独有的AI能力实现根因诊断、异常监测、智能告警，最终建立基于业务分析的可视化模型，更深入地帮助用户实现业务可能性。

可观测性平台实际的案例

案例一：客户投诉

无论是什么行业，面向to B或者to C客户时，经常会遇到客户投诉的场景。面对这种情况，按照原有的监控手段，首先会将信息流转给IT部门，运维要登录到每一台机器上，先查看这个服务在哪台机器上部署，再分析查询条件以便检索用户相关的日志，该排查过程可能还需要研发介入来提供帮助。

若在拥有可观测器平台情况下，面对这种场景，只需知道用户的标识即可解决问题。

比如在上图的场景中，可以看到用户李强在做一笔交易，以及在做这笔交易时的完整链路过程。在这个场景下，能够轻松得知客户投诉的上下文、本次投诉的原因，能够快速地帮助客户解决问题。

案例二：基于确定性AI的服务端错误根因分析

当海量的数据里出现故障时，可观测性平台可以帮助IT运维人员快速锁定故障原因。

在该场景里面，某一台数据库服务的错误率非常高，这时可以通过确定性AI的服务端去识别出错的根本原因。从上图场景可以看出当前数据库服务产生了SQL语句上的错误、每一个错误发生的次数、错误率的大小、影响了哪些用户。

此时基于这些再去进行深入分析，可以得知错误具体由哪几条SQL引起、由哪些用户在做什么业务的时候触发，最终得出该错误产生的的根因。

总之，可以通过数据的聚合算法、AI的学习能力帮助用户去寻找问题的根本原因，若能在该场景中解决大部分问题，会非常有利于整个服务问题的解决，大幅减少对业务的影响。

5月10日Apache SkyWalking 峰会，期待你的到来

扫描图片二维码获取峰会PPT

---

聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生CSDN云原生微信公众号～