蚂蚁金服在云原生架构下的可观察性的探索和实践 | Meetup#3 回顾

做者：苟利（陈自欣），蚂蚁金服中间件产品专家， 负责蚂蚁金服分布式链路跟踪系统的产品化工做，在日志分析、监控领域有多年工做经验。

本文根据 8 月 11 日 SOFA Meetup#3 广州站 《蚂蚁金服在云原生架构下的可观察性的探索和实践》主题分享整理。现场回顾视频以及 PPT 查看地址见文末连接。

前言

随着应用架构往云原生的方向发展，传统监控技术已经不能知足云原生时代运维的需求，所以，可观察性的理念被引入了 IT 领域。

下面我将会就可观察性在云原生的起源，可观察性发展动力，可观察性与监控的关系，可观察性的三大支柱，社区发展方向及产品现状，以及蚂蚁金服对相关问题的理解及实践进行探讨。

才疏学浅，欢迎拍砖。

为何云原生时代须要可观察性

可观察性的由来

在云原生语境下的可观察性这个词，最先出现于2017年7月， Cindy Sridharan 在 Medium 写的一篇博客，"Monitoring and Observability"，谈到了可观察性与云原生监控的关系。

而在2017年10月，来自 Pivotal 公司的 Matt Stine，在接受 InfoQ 采访的时候，对云原生的定义进行了调整，将Cloud Native Architectures 定义为具备如下六个特质：

• 模块化 （Modularity） (经过微服务)
• 可观察性 （Observability）
• 可部署性 （Deployability）
• 可测试性 （Testability）
• 可处理性 （Disposability）
• 可替换性 （Replaceability）

可见，在2017年下半年，可观察性成为了一个 buzzword（时髦词），正式出如今了云计算领域。

可观察性的定义

虽然“可观察性”这个词在 IT 行业是一个新的术语，但它实际上是在上世纪60年代，由匈牙利裔工程师鲁道夫·卡尔曼提出的概念。

术语“可观察性”，源于控制论，是指系统能够由其外部输出推断其内部状态的程度。

这个外部输出，在云原生的语境下，即 Telemetry，遥测，一般由服务（services）产生，划分为三个维度或者说支柱，Tracing（跟踪），Metrics（指标）, Logging（日志）。

为何云原生须要可观察性

近年能够看到，云计算对基础架构改变甚为巨大，不管是互联网行业，仍是传统行业，云化在提高资源利用率，提升业务敏捷性的价值已经成为了公式。而在应用层面，因为业务特性的缘由，互联网公司大部分已经完成云化，应用架构也不一样程度上，完成了从单体应用向微服务应用演进。在转型后，总体系统复杂性大大增长，倒逼相应的工具及方法论进行升级改造， 去 hold 住这么复杂的局面。

上图为 Uber 展现的整体调用链图。

考虑到业务多样性及复杂度，在蚂蚁金服内部，相关调用关系只会更为复杂，用人类的智力，已经没有办法去理解如此复杂的调用关系。而上图只是展现了可观察性的链路调用，若是再加上指标及日志，不对工具及方法论进行革新，是难以实现对复杂微服务架构的管控的。

微服务只是云原生的模块化特性的体现，再考虑到近年被普遍应用容器，Kubernetes , 以及你们关注度极高的 Service Mesh , Istio， 每个新的技术的出现，在带来了更优雅的架构、更灵活的调度、更完善的治理的同时，也带来更多新的复杂性。

所以，可观察性对于云原生的应用架构，是必不可少的特性。

可观察性和传统监控的区别

说半天，很多同窗就会说，这个可观察性与咱们谈的最多的监控有什么区别。虽然有很多的人认为，这词就是个buzzword，就是赶时髦的，没有太大的意义，可是我结合网上的讨论，我的认为可观察性与监控，含义上虽然接近，可是也有一些理念上的差异，使得讨论可观察性这个词，是有具备现实意义，并能真正产生相应的价值。

• 监控更多关注的是基础设施，更多与运维工程师相关，更强调是从外部经过各类技术手段去看内部，打开黑盒系统。
• 可观察性更多的是描述应用，在咱们谈论具体某应用，或者是某些应用是否具有客观性的时候，一般与开发人员相关，由于在常见的可观察性的实践之中，开发人员须要在应用的开发过程当中嵌入例如 statd 或者是 opentracing，或者是 opencensus 等所提供的库，对相关的 telemetry 进行输出，或者是俗话说的埋点。经过埋点，将服务内部的状态白盒化，使得其在运维阶段具有可观察性。某种程度上能够说，可观察性遵循了  DevOps 及 SRE 的理念，即研发运维一体化，从开发侧就考虑系统的可运维性。

这里值得补充说明的是，目前市面上，有商用或者开源APM 方案，经过入侵 JVM 或者其余技术手段，对应用进行自动埋点的，输出 trace 及 metrics 信息。这一样也是一种可观察性的实现方式，这样作的最大的好处是，不须要对现有的应用进行改造，可是相应的 agent 对应用进行实时的监控，必然会或多或少的增长资源的占用，例如每实例额外 30+MB 内存，5~10% 的 CPU 占用，在大规模的运行环境之中，会有很多的成本增长。

可观察性的三大支柱及社区进展

可观察性的三大支柱

可观察性的三大支柱及其之间的关系，Peter Bourgon 在2017年2月撰写了一篇简明扼要的文章，叫 "Metrics, tracing, and logging" ，有兴趣的能够去看一下，如下仅为简单的说起。

指标数据（Metrics Data）

描述具体某个对象某个时间点的值。在 Prometheus 中，指标有四种类型，分别 Counter（计数器）、Gauge（瞬时值）、Histogram（直方图）和 Summary （概要），经过这四种类型，能够实现指标的高效传输和存储。

日志数据 ( Logging Data）

描述某个对象的是离散的事情，例若有个应用出错，抛出了 NullPointerExcepction，或者是完成了一笔转帐，我的认为 Logging Data 大约等同于 Event Data，因此告警信息在我认为，也是一种 Logging Data。可是也有技术团队认为，告警应该算是可观察性的其中一个支柱。

跟踪数据（Tracing Data）

Tracing Data 这词貌似如今尚未一个权威的翻译范式，有人翻译成跟踪数据，有人翻译成调用数据，我尽可能用Tracing 这个词。Tracing 的特色就是在单次请求的范围内处理信息，任何的数据、元数据信息都被绑定到系统中的单个事务上。一个Trace 有一个惟一的Trace ID，并由多个Span 组成。

社区方案进展

因为可观察性在云原生中，是一个很是重要的特性，所以，在开源世界中，前后出现了两个定位都比较相似的项目，分别是源自 Google 的 OpenCensus （定位上报 Tracing + metris） 和由 CNCF 孵化的 OpenTracing（定位上报 Tracing）。二者都定位于提供厂商中立的技术规范，及实现该规范各类编程语言遥测库，使得用户在使用了相关的库之后，能够将相关的遥测数据，发往不一样厂商的后端， 如 Zipkin , SignalFX，Datdog 等，从而促进云原生的可观察的良性发展。

因为两个项目的定位高度雷同，所以在2019年3月，两个项目社区的主要领导者，决定将两个项目进行融合，产生一个同时向下兼容 OpenCensus 及 OpenTracing 的项目，叫 Open Telemetry，将多个标准，下降为一个。

OpenTelemetry 旨在将可观察性的三大支柱，组合成一组系统组件和特定于语言的遥测库。项目在最初并不会支持日志，但最终会将其合并。这个事情比较好理解，由于日志数据量太大，也缺少相应的初始规范， 社区选择在时机成熟时再进行引入是一个很合理的策略。

简单来讲，之后你在应用开发里头，只要使用了 Open Telemetry的类库进行埋点，则应用就能够经过一个协议，统一上传指标， 跟踪，日志，到不一样厂商的后端，进行后继的分析。

社区产品现状及局限

与协议层，日趋一统状况不同，在产品层面，因为产品的侧重点不一样， 呈现出了百花齐放的局面。

可是，从某种角度来看，目前社区的产品方案有如下的局限：

一、缺少大一统的产品，同时对三个支柱进行支撑，并进行有机的关联

这个无需多言，只要使用过上述的产品，就会发现没有办法找到一个完整开源产品，可以对以上三种遥测进行同时处理。就更没有办法进行统一的关联了。

二、缺少大一统的产品模型，统一展现微服务 + Mesh + Serverless

在不远的未来，传统微服务、Mesh 、Serverless 应用混合交互构成业务系统，将会是一个广泛的状况，可是目前开源的产品，并不具有对以上三种计算模型进行统一的，可识别的管理。

蚂蚁金服对云原生的可观察性的理解及实践

蚂蚁金服在多年的分布式系统的运维过程当中，对可观察性有着本身深刻的理解，结合用户的特色，将其进行产品化及解决方案，并提供给金融用户。

链路跟踪是可观察性的核心，用于故障定位

在微服务及分布式架构中，链路跟踪是用户的核心使用诉求，这里你们都应该比较熟悉了，我也很少作展开。

Tracing + metirce + Log 有机关联是实现可观察性的关键

链路与日志关联

链路与日志关联是一个很重要的场景。在不少时候，某一个调用失败，失败的缘由，并不能体如今 Trace 之上，也许是发生在业务侧，例如余额不作，致使整个调用的失败。所以，不少时候，咱们须要将链路和日志关联，帮助咱们更好的判断究竟是什么缘由，致使链路调用失败，或者是进行进行其余分析。

为此，咱们提供了一个 SDK，用户能够根据咱们官网上的配置，对 log4j 及其余 logger进行配置后，将 TraceId 及 RPCId 从 Tracer 中进行获取，那么在打印的日志的时候，TraceId,RPCId 也会如图上所， 在日志中打印出来。
最后， 而后经过 Trace view，我就能在查看链路的同时，查看关联的日志。

具体的配置方式或者原理，感兴趣的同窗，能够查看蚂蚁金服金融科技官网。

拓扑与指标关联

除了链路与日志关联， 咱们 SOFA 还提供了应用指标的上传功能， 在应用上传 Trace 的同时， 咱们将指标与调用拓扑进行了关联， 用户能够点击应用拓扑中的应用，下转查看响应的拓扑指标。

按照固定采样率进行采样不能知足实践使用需求

有 Tracing 相关产品使用经验的同窗都知道，在业务量大的时候， 相关的 Tracing 产生的数据量会较多，致使存储成本以及处理成本的大幅度增长。在实际的生产中，咱们每每会对 Tracing 进行采样，一般会采用 1/100 甚至是1/1000 的方式进行采样。

具体的采样方式，一般采用 Head-based 采样，即，对 TraceId 进行以 100 或者 1000 来采模，采模后若是是 1 ，则 agent 对该 TraceId 进行进行采集。是否对链路进行采集的决定，发生在链路的第一跳，即 TraceId 产生时，因此叫 Head-based 采样。

这种采样方法好处是实现很是简单，但问题是 100 个链路数据中，可能有 3-5 个是运维人员关心的，一般是调用出错的链路，又或者是调用缓慢的链路，经过这种简单粗暴的采样，能采集到相应链路的机会就会不多。大部分状况下， 用户只能指望异常屡次发生，并在某次被采样命中，而后进行分析。

目前，开源软件中，采用的都是这种方案。

咱们在蚂蚁金服内部，使用的是 Tail-based 的采样方案，简单来讲，咱们会把全部的 Span 数据，都会放到内存里， 但这个时候，并不能决定具体那一条链路是采集仍是不采集，可是当整条链路闭合后，咱们就会对整条的 Trace 根据规则进行判断，若是有调用失败，或者整个调用中有部分 Span 是处于缓慢状态的，系统会将会标记此链路为异常链路，即命中采样，永久保存。这样就能保证运维人员可以无视采样率，具有对异常链路进行查看能力。因为对某一条链路数据是否采集的决定，实际上是处于链路的尾部（非严格意义）才做出的，因此叫 Tail-based 采样。

固然以上 Tail-based 的采样的描述是极其简单及理想化的， 在海量数据量的状况下，以上的方法基本上没有办法使用，很容易就把内存给撑爆了。在实际设计中，咱们还考虑了不少的因素， 进行了更多的细节处理， 使得 Tail-based 采样的资源消耗也在一个能够接受的范围内。

目前这个功能在内部已经落地，对外还在产品化之中。

（想要了解上述更多技术细节，能够查看参考资料[[1]](https://news.ycombinator.com/...[[2]](https://github.com/jaegertrac...）

统一化 微服务 + Mesh + Serverless

将来，能够预期混合使用经典微服务、服务网格的企业必然愈来愈多。所以，如何设计一个通用的模型， 对以上三部分进行统一管控， 这也是蚂蚁金服目前正在实践探索的地方，指望外来有机会向你们分享。

将来展望

综上所述，随着云原生的发展， 咱们相信拥有完整的可观察性三大支柱处理能力，并能在产品层面上对三大支柱进行灵活关联、下转、查看的监控产品，适用于混合的云原生场景的监控的产品，都将会愈来愈多，帮助企业落地云原生。

视频回顾

本次分享的视频回顾以及PPT 查看地址：https://tech.antfin.com/community/activities/779/review

参考资料

[1] https://news.ycombinator.com/item?id=15326272

[2] https://github.com/jaegertracing/jaeger/issues/425

公众号：金融级分布式架构（Antfin_SOFA）