从监控到稳定性可观测：从问题响应到预防的技术变革

从单体架构到集群架构再到微服务架构，业务越来越庞大，也越来越复杂。每一次架构的升级，在提升了业务吞吐量的同时，必然会带来更大的复杂度。云原生时代背景下，微服务、Service Mesh、 Serverless 等新技术的出现，业务的复杂度很快就远远超越了个人的人力极限，大规模应用更是需要成千上万专业的人协作才能完成。应用稳定性链路中的因素也越来越多，一个应用相关的稳定性指标从基础设施到中间件，再到应用自身的模块、组件、中间件、基础设施等，每个环节都会有致命的因素导致应用无法正常提供服务。

依赖传统的稳定性体系，通过日志服务查看业务日志，通过各个中间件去感知中间件的运行状态， 再通过网络、存储、操作系统层面的监控来查看基础监控信息， 这些信息每一个都只能片面的代表业务链路中的某一个节点的状态，且每个状态与其他节点之间都是割裂且毫无联系的。最终只能依赖人力投入，汇总分析最终判断，再验证。

在互联网时代， 时间就是金钱这个真理从来都没有像今天这样被深刻的践行着，每一秒的不可用时间里都有可能产生大量的损失。于是，稳定性应急就越来越像是高悬头上的达摩克里斯之剑，成为让运维、研发的睡眠质量急速下降的罪魁祸首。

传统的方式下，基于稳定性体系的需求，业务稳定性需要完成：APM 链路监控、 日志服务、指标监控等不同的解决方案才能完成异常因素的覆盖，而正是因为这样技术方案的影响下，稳定性体系变成了一个个割裂的数据孤岛，难以打通，难以联系，这直接导致故障的定位事件及稳定性体系的维护成本十分高昂。

为了快速迭代，很多时候业务都需要很大程度上降低对开发质量的要求选择快速交付，这造成了大量的技术债务堆积。稳定性异常事件和风险高频出现，但稳定性能力建设对快速扩张的业务规模以及业务演进带来的技术复杂性应对不足，无法对复杂业务的稳定性应急提供高效的技术支撑。且在微服务，云原生编排， 弹性伸缩等技术的影响下，业务运行时的数量和位置会随着时间的变化而变化，这种变化虽然使业务更灵活和健壮，但同时也为稳定性带来了混乱，而这种混乱必须被解决。

越复杂的系统可观测越难以实现，越复杂的系统对观测能力的要求越高。

系统可观测性越强，就能越迅速地了解为什么出现问题并修复，在这个分秒必争的时代，快速的解决业务异常问题，是对稳定性最核心的诉求，也是稳定性体系的价值所在，毕竟每秒钟的不可用时间都可能会带来难以承受的损失。

在越来越复杂的业务拓扑下，传统的解决方案：即通过告警被动的发现业务异常已经不能满足应急诉求，通过观测手段主动发现，通过业务链路全貌定位到已存在或者潜在的问题才能更大程度上降低业务出现异常的风险，从而降低损失。

用户对于业务运行质量的要求越来越高，业务需要对运行指标数据做分析，为可持续的技术优化、深度运维等提供有力的支撑，此外还需要通过数据来发现业务瓶颈，协助决策技术的演进方向，管理侧则需要对业务质量有更清晰明确的认知，促使业务优化的可持续性以及方向的正确性。

告警是一个点，告诉我们发生了异常；监控可视化是一个个代表各种因素的平面，例如日志控制台、中间件控制台、基础监控 dashboard、业务监控情况、请求链路情况等等；而可观测性就是一个将各个面联系起来，作为一个能够体现所有因素的整体。基于这个整体，可观测让我们拥有了一个全局的，包含上下游全链路信息的全局视角。在这个视角下，问题的定位将非常快速且清晰。

总的来说：稳定性可观测 >（日志服务 + 业务 APM + 监控告警系统 + 各种稳定性相关的技术栈的组合）。

⽇志是在特定时间发⽣的事件的⽂本记录，常见的⽇志有三种格式：纯⽂本、结构化和⼆进制。

纯⽂本是最常⻅的，也是最容易采集的，但结构化⽇志：通过将日志数据进行结构化处理使得日志更容易检索和定位，同时配合大数据的手段可以基于日志产出更丰富且更灵活的指标，所以结构化日志是目前最为流行的解决方案。通过日志可以体现问题细节，告诉我们具体发生了什么事情。

Trace 表示分布式系统中一个请求从客户端到服务端完整的“旅程”详情，能够体现一个请求事务过程中所发生的每一件事情以及所发生的事情的状态及质量。

指标是在一段时间内测量取样的数值，例如业务及性能的各项指标，可以通过对 Metric 的度量来反应业务运行的质量指标。

传统的模式下，Log、Trace、Metric 这三大支柱是各自独立，互不联系的独立个体，但是我们很容易就能发现：这并不是一种正确的结构化观察的方法。调查问题的步骤通常是：我们通过 metric 的度量（告警）发现了问题， 再去分别查看日志、trace 等去定位原因，孤立的使用每个工具给操作者带来了很大的认知负担。

例如：找到跟一个异常告警相关的异常日志是个成本很高的事情， 或者调查一个请求异常需要先找到网关日志、业务日志、各种中间件日志再到各种基础设施日志， 相关的异常指标情况以及相关的跟踪信息，成本非常高。

图片来自网络

当系统足够庞大时，找到确切的问题日志甚至已经变的不太可能：

图片来自网络

而可观测性则是把 Log、 Trace、 Metric 拧成了一股绳，让三大支柱互相之间建立亲密的“血缘关系”，通过这种关系我们可以结构化的从整体到局部再到具体细节的观测业务：

图片来自网络

如果把业务系统比作一座海上的冰山，监控仅能看到的是冰山之上，可观测性则能全面展现出冰山的全貌：

图片来自网络

Log、 Trace、 Metric 是传统的稳定性解决方案，每一种解决方案都有多种不同的开源或商业软件可以支撑，问题是每个产品都有自己一套数据采集标准和 SDK，异构的数据结构导致我们很难以用统一的方案建立数据关联。于是在这个背景下，诞生了 Opentracing（分布式追踪数据规范）和 OpenCensus（Traces + Metrics 规范）等标准，然后，为了更好的将 Traces、Metrics 和 Logs 融合在一起，通过合并 OpenTracing 和 OpenCensus 这两个标准，诞生了 OpenTelemetry。

OpenTelemetry 旨在管理观测类数据，如 trace、metrics、logs 等 (非固定未来很可能有新的观测类数据类型出现)。OpenTelemetry 自身不提供与可观测性相关的后端服务，这类服务通常需要提供的是存储、查询、可视化等能力，需要基于自身需求来研发迭代。

图片来自网络

图片来自网络

• OpenTelemetry 提供了一组 API 和库来标准化遥测数据的采集和传输。

• 多语言支持：OpenTelemetry 支持多种开发语言的后端。

• OpenTelemetry 通过标准化以及工具体系降低了可观测体系建设的成本，让稳定性体系的建设者可以更专注于业务观测需求本身。

• 作为事实上的标准，OpenTelemetry 具备厂商无关的特性，免于被某个厂商绑定的风险。

• 多语言支持的 SDK，OpenTelemetry 几乎为每个常见语言都实现了对应 SDK，可以方便的完成各种技术栈的适配对接，其中 java agent 利用字节码注入结束，可以实现低侵入的数据采集。

• OpenTelemetry 的工具生态除了多语言的 SDK 支持之外还提供了开源的 Collector 来支持多种数据源的数据的上报采集，处理和输出。

• 就像是 kubernetes 拿下了容器编排的标准一样，OpenTelemetry 带来了可观测所需的标准且已经被广泛应用。标准化的优势在于面对各种技术栈都可以使用同样的解决方案。

对可观测性能力的建设来说，最关键最核心的问题是 解决数据统一和关联让数据产生“血缘”关系。事实上这也是稳定性体系中最为繁重的地方。

要解决这个问题，对于采集到的数据，可观测需要做大量的计算和关联操作。所以可观测并不是一个低成本的解决方案（网络数据：美国企业的可观测性相关投入为例，会占用企业整体 IT 支出的 5%-10%）。无论是研发成本还是资源成本，能力的建设都需要比较大的投入。可观测需要通过长时间的应用，为业务提供大量的数据支撑进行技术性优化，从而产生价值。

数据规模大：可观测数据为无界数据，会持续不断的产生并累加，这就需要大量的存储及计算成本。同时随着数据量大， 计算和检索数据的成本也越来越大，数据的存储成本也持续累加。

数据关联计算成本高：各种中间件的稳定性数据， 埋点数据，基础设施监控数据，业务日志，网关日志等等建立联系需要做大量的计算。所需要投入的研发及资源成本较高。

需求多样化：观测的角度，维度不一样， 可观测建设会产生大量的交互图表和拼装式能力要求。且为了应对多样化的诉求，很多时候都需要基于可观测性数据做二次应用， 例如输出稳定性指标，赋能一些业务场景中的需求等等。这些多样化的需求对可观测的能力灵活性要求很高。

技术生态

客户端数据采集：OpenTelemetry 提供了多语言的 agent， 其中 java 独有的字节码注入技术可以在不侵入应用逻辑的前提下，仅需要添加一个启动项即可完成数据采集， 而目前其他语言则需要再业务逻辑的上下文中引用逻辑。这给业务带来了比较大的侵入性。

一个更优的解决方案是 ebpf，ebpf 通过内核级的代码注入，以“上帝”视角观测操作系统之上的应用程序运行情况。但是 ebpf 本身的技术栈限定了内核态只能通过 C++（rust 也有希望）来开发， 且通过 ebpf 来采集数据需要对 Linux 内核 API 有比较深入的了解，同时还要针对各种协议做解析，因此开发成本较高。

好消息是随着 ebpf 的生态不断的完善， 社区涌现了不少优秀的开源项目，例如 deepflow，可以通过这些开源项目进行可观测能力的建设， 同时也可以将比较好的思路或者实现提交到社区，与社区一起共建。此外，为了更好的反映出业务的运行情况，同时也需要支持通过其他的 agent 采集所需要的数据，例如政采云的稳定性可观测平台就利用 jvm-profile 不断的采集火焰图数据， 为业务提供某一时刻的“现场”情况，协助业务研发更好的排查问题。

数据处理：OpenTelemetry 提供了 Collector 来进行客户端数据的上报采集，处理和输出，其目的是打造一个万能的数据采集器，在支持各种数据源的数据采集的同时，还可以通过 Collector 对采集到的数据做初步的处理。但是目前 Collector 所提供的的能力未必能够满足实际的业务需求，因此，在政采云的场景中，我们基于 Collector 进行了二次开发，扩充了能力的同时基于自身需求进行了部分逻辑的定制化研发。

数据计算

采集到的数据本身是独立的离散数据，而数据的处理能力是可观测性的核心需求， 例如日志需要做格式化才能支撑更细粒度的关联需求，日志本身的规则，Trace 链路的上下游关系，Metric 度量，以及这三者的关系都需要对数据做大量的计算。

可观测并不只是体现服务自身的情况，从客户端请求开始， 到流量网关，再到业务网关，再到应用， 应用会调用其他应用， 同时每个应用都涉及各种中间件的调用，中间件的运行情况也会对业务造成很大的影响，所以也十分重要，然后再到 Kubernetes 基础设施，再到 IaaS 层的基础设施，这整个链路任何一个环节出现问题最终都会表现为业务问题。

可观测要体现全局的业务情况， 快速的观测到链路中的那个节点出现了问题，就必须将外部数据纳入可观测的体系中。链路中所能体现的稳定性因素占比是衡量可观测能力水平的重要依据。

可观测体系对于数据存储的要求是：满足可进行高速、大数据量查询，能应对数据规模的线性增长的同时保障数据访问效率。因为可观测的数据会不断的持续累加，这导致存储规模的不断增大，不仅仅产生了过高的存储成本，同时很大程度上影响查询效率。因此对于数据就需要做好取舍，规划好日志的存储资源，例如一些业务日志具备存储价值，一些安全审计的日志更是需要长期留存， 同时大部分的业务日志本身具备时效性。

因此，可观测的日志体系就需要对日志定义灵活的存储周期，根据日志的时效性要求灵活的定制存储时长并自动清理。对于 Trace 数据，业务流量巨大的情况下，100% 的存储会造成很大的性能及资源压力，因此可以根据实际情况进行采样存储。

基于数据的计算，各种指标、中间件、应用依赖、告警等等数据产生了联系， 这种联系不仅仅可以为稳定性应急赋能，实际上可观测的定义中， 定位问题只是能力之一，更广义一点的定义：可观测要帮助业务更细粒度的了解自己的业务， 发现潜在风险，发现性能缺陷等等，同时，可观测性数据可以支撑对研发质量的管控：输出考核性指标。

例如：可观测可以告诉你应用存在那些性能低下的 SQL， 告诉你存在那些不合理的调用以及不合理的技术运用。基于有关联的数据，输出这些指标会变的非常容易。

数据的呈现最终要通过可视化来解决，问题是：单一基于需求定制的可视化实际上只能片面的展示一部分维度的数据。很多时候不同的角色，希望看到的指标是不一样的，例如运维希望从全局到局部的去掌握当前存在异常或者风险的点，更关注基础设施的稳定性情况。而研发关心的是：以应用为中心所负责的业务更明细的稳定性指标情况，而部门的主管则关心：平台整体的稳定性质量考核指标是什么样子的。

每一种需求都存在合理性，只是体现的维度不同而已，因此首先可观测的数据体系应该具备多个视角的，例如：运维视角，开发视角，乃至于在稳定性体系之外， 还需要建立指标运营体系来满足指标考核的需要。另外，在不同的业务场景下，所需要关心的业务稳定性的指标很可能是不同的，因此可观测的可视化还需要支持用户可定制的组装式解决方案， 通过可视化界面或者类 SQL 语句来自由定制。例如支持业务研发自定义稳定性大盘。

1. 随着业务系统拓扑的复杂度越来越高，业务对于稳定性的要求也不断升高，稳定性可观测为业务提供了白盒的全局观测能力，支撑业务快速定位异常，很大程度上可以解决稳定性应急效率底下和应急复杂度过高的问题。

2. 稳定性可观测可以各种维度的体现业务运行指标情况，可以赋能业务，感知潜在问题及风险，输出稳定性考核指标，同时通过可观测的数据运营支撑稳定性体系数字化。

3. 可观测性通过为业务提供数据支撑帮助业务持续的进行技术优化而体现价值。可观测体系并不是低成本的解决方案，在实现的过程中需要较多的资源投入。但在当下的进程中数字化已经凸显了对可观测性的强烈需求，在不远的将来，不考虑可观测性体系建设的业务很可能将无法满足用户越来越高的服务水平要求。

汪勋，政采云有限公司运维开发团队负责人，关注 DevOps、平台工程，以及稳定性可观测、持续集成持续交付、云原生技术等各种运维能力。