一、云原生时代的挑战

一般来说，企业应用服务建设初期都是快速启动、快速试错，随着业务规模扩大再从单体架构迁移传统的SOA架构。随着现在K8s的出现，微服务、容器化、服务网格等云原生的架构概念也逐渐在企业应用中流行。

架构的发展进程不是跳跃式的，而是不断演进、新旧共存的。为了在云原生时代里避免单云的故障，同时不被单云绑定，我们更多采取多云、多区、多集群架构的方式。但在过渡到云原生时代的过程中，我们发现了以下挑战：

1、多样性：主要表现在异构语言、多云、多区、传统与云原生共存；

2、动态化：容器化、服务快速部署和销毁、弹性扩缩容；

3、大规模：数千个服务、万级容器、亿级指标；

在这三大挑战下，我们如何建设好可观测体系呢？

二、可观测体系的建设思路

从我们SRE稳定性治理的全景来看，我们要降低故障频次，同时在故障发生的时候，要尽量缩短故障时长MTTR，整体来说要做好故障预防、故障感知、故障定位、故障恢复和故障改造。

而建设可观测性的重点，就是为稳定性治理提供故障感知和故障定位能力，核心或基础就是做好采集、处理、存储、关联分析等。

可观测性主要包含三大块：Traces/Logs/Metrics，在这三块能力建设的基础上，我们的还多加了Events（事件）。我们从各种复杂、多变的资源中采集调用链、日志、指标、事件，然后对数据进行处理、存储、关联、智能分析。

单一的指标或事件分析的价值是不大的，只有以应用为中心去关联数据，才能发挥数据的价值，从而打造我们的故障感知、故障定位能力。

三、建设过程中的问题与解决方案

1、建设以应用为中心的CMDB

云原生时代下，如何去管理多样性、动态化的资源呢？

建设以应用为中心的CMDB经历了以下几个阶段：

• CMDB 1.0：实现IT资源的数字化资产管理和数据查询；
• CMDB 2.0：促进技术平台化管理互通标准化、数据建模、配置自动发现；
• CMDB 3.0：以应用为中心、运维场景驱动，梳理和分析运维对象及关系，从面向资源转为面向业务；
• CMDB 4.0：运维世界必不可少的数字地图。

目前趣丸科技处于3.0的阶段，前面提到我们建设可观测性是以应用为中心去做关联分析，这些关联关系就是以CMDB 3.0为基础的，运维场景需要将什么资源纳入管理，我们就去管理什么资源；运维场景需要将什么资源关联起来，我们就去实现自动关联。

CMDB的下一个阶段——CMDB 4.0，是运维世界必不可少的数字地图，可以帮助运维人员快速找到他们需要的信息，理解IT环境的复杂性，能有效地进行事故管理、问题管理、变更管理等运维工作，是运维人员进行IT环境管理不可缺失的工具。同时CMDB4.0也是智能运维的基石，除了传统的资产外，我们也会将指标、算法都放进CMDB进行管理，通过CMDB建立各种关联关系，最终实现根因分析、影响分析、告警收敛等智能运维场景。

2、建设去中心化的采集和存储能力

在做好CMDB的同时，我们同步还在建设去中心化的采集和存储能力。在多云、多Region的背景下，如何管理大规模、海量的指标呢？

Prometheus当前基本成为了云原生监控的标准，包括我们运行基座K8S等多数的应用，都按照Prometheus的标准提供metries接口，来暴露自身的指标让Prometheus去采集的。

但是，因为我们是多云、多Region，K8S集群也非常多，Prometheus单机部署又存在单点故障的风险，因此不能进行中心化。

因此，我们采用了Thanos+Prometheus的模式，实现指标采集存储去中心化，让各个云、各个集群通过它们自己的Prometheus去采集、存储指标，实现自治；查询指标时，Thanos通过Prometheus的sidecar去同时查询数据，然后聚合去重，达到统一查询入口、去中心采集和存储的效果、这也是我们整个可观测性体系的基础。

在去中心化的采集模式下，资源分散在多云、多区，我们的Prometheus也一样分散在各云各区，当前我们大概有150套Prometheus。

那么，我们的Prometheus如何发现资源？由哪个Prometheus去采集呢？基于这个问题，我们建立了一个资源发现和采集调试的组件——Solo（搜罗）。Solo通过与CMDB交互发现资源，然后根据资源属性、所在区调度相应的Prometheus去采集，实现自动发现可监控资源，并自动补充指标的关键label，如区域、CMDB ID等。

3、如何解决高基指标问题？

在微服务、云原生架构下，我们还会面临高基指标问题。

什么是高基？高基就是高基数，即同一个指标、标签的总体数值的计数，即每个标签的值范围相成的总数。

如上图是Istio的一个指标，这个指标是用来统计请求耗时的，就是平常类似于P99、P90的指标。经过指标统计，我们发现这里面有56个标签，单单抽取几个重要的指标，它的指标基数是50*50*3*5*50*20（结果是3750万个基数）。一般情况下，一个指标有1万个基数就认为是高基了，但是现在我们可能达到了千万级别。

需要注意的是，高基指标会导致监控变慢，还可能会无法加载甚至崩溃，计算资源开销也会变得非常大，经常出现OOM问题。

那么，如何解决高基问题呢？

总的来说，就是降基数、降维度。

这里我们引用了VictoriaMetrics的流计算能力。当然，用Flink也可能做到，但需要人工写很多逻辑处理，而victoriaMetrics的vmagnet组件自带这个功能，只需要配置即可。同时，我们使用的是VM社区版，不支持集群方式，因此我们自研了VM网关，去调整后面的各个vmagent。

整个流程就是指标先到Promethues，然后远程写到路由网关，由网关调度分析任务，再经过VM进行流计算集群处理，生成新指标再写回Prometheus中。

效果：之前在P99等请求耗时的指标里，我们有时15分钟内的数据都无法查询，现在基本上能在500ms查询出来，1小时内的数据1s内就可以查询出来，极大利用了流计算的能力。

在采用VM流计算能力之前，我们的方案是引用了列式数据库ClickHouse，利用不一样的存储方式，同时通过CK的物化视图进行预聚合，构建流计算能力，整个查询性能效果也更加明显、整体处理流程也更加简洁，这也是我们可观测性平台在用的另一种方案。

4、建设告警能力

在解决指标的采集、存储，及高基指标问题后，我们还需要打造最基础的告警能力、主动感知能力，基于告警我们做了以下几个实践：

1）告警网关（告警系统的开放能力）：提升API给业务调用，实现它们的自定义告警，同时用来作为云商告警的回调。接收到云商告警之后，再将这些告警转化为内部的告警，方便我们进行统一管理、分析。

2）告警处理器：告警信息通过告警网关后，我们的告警处理器会通过CMDB找到资源负责人，谁负责的资源和应用，谁就会收到告警，不需要主动去订阅。同时，我们还做了告警抑制，实现有效标记、认领等功能。

3）告警通知：我们目前将告警推送到飞书上，但因为飞书机器人有频率控制，因此，我们增加了一个智能调度功能，每个告警群会增加多个飞书机器人，通过调度器决定哪个飞书机器人去发送告警，解决了频控问题。

4）告警升级：主要补充飞书告警信息被忽略或长时间未解决告警问题，进行电话升级，如果15分还没有人介入处理，告警会自动通过电话通知服务开发人员和业务运维，如超过一定时间没处理好的问题，则会自动电话通知再上一级的负责人。

5）告警收敛：主要目的是减少大量的冗余告警，让运维人员更快地定位和解决问题，当前我们这块做得也还不是很深入，业界常用的一些收敛做法包括：

• 告警聚合：把一些关联的告警聚合在一起处理。比如同时出现的网络故障和服务器崩溃，可以合并为一条告警进行处理；
• 时间窗口：在一定的时间窗口内，将连续发生的同一类型的告警合并为一条，避免造成告警风暴；
• 根源问题分析：快速定位故障原因并解决，避免重复的警告；
• 学习模式以及人工智能：使用机器学习和人工智能来学习监控数据的模式，从而可以减少不必要的告警，例如通过智能预测系统故障。

5、建设以应用为中心的观测平台

构建好故障感知能力之后，如何构建故障定位能力，实现快速定位问题呢？

我们认为，核心还是要提升关联分析能力。因此，我们做了一个以应用为中心的可观测性平台，以应用为视角去关联数据库、缓存、消息队列等中间件，同时还支持多观测视角，服务端视角、客户端视角、服务实例视角、服务接口视角、服务拓扑等，当某个服务有告警时，可以从不同视角快速发现是某个实例的问题，还是单个接口的问题，还是依赖下游服务的问题。

6、建设SLA、SLO体系

如何量化整体服务水平？如何管理和持续改进服务质量？如何提升业务方的满意度？带着这几个问题，我们建设了SLA、SLO体系。

首先，我们从业务模块和服务的监控指标中抽取核心、关键的指标形成SLI，并为这些关键指标设定合理组合阈值，组成一个SLO，以分钟为粒度，根据SLI是否达标来反映当时整体SLO是否可用，并为其设置了三个9之类的整体可用性目标，还会根据设置的目标进行承诺，并与业务方签订协议，生成我们的SLA。

我们建设SLA体系的整体方向是，通过量化目标，制定承诺去推进质量持续改进，整体提升用户满意度。

现在SLA体系上线才一个季度，整体的落地效果十分显著。我们划分了27个业务场景，选取422多个SLI，暂时设定了46个SLO，大部分SLO有30%-100%的改善，我们还会通过SLA周会，对齐每周的服务质量情况，持续推进优化改善。

下面是我们落地的产品图：

上面展示我们如何定制一个SLO，可以由多个SLI或多个下级SLO组合成一个新的O。

上面是SLO的燃尽图，明确地展示我们当前这个O离目标还可以有多少时间可以消耗。

7、产品化治理

在可观测平台建设的初期，遇到了监控系统不好用、需求响应慢甚至不响应等问题。造成这些问题的原因我认为有三方面：

1）闭门造车：只埋头做自己认为好用、有用的功能；

2）需求管理混乱：用户提了需求后缺少跟踪管理；

3）重功能、轻运营：只关注完成开发，不重视后续的产品维护。

针对研发阶段，我们进行了产品化的治理，其中包括：

1）规划阶段治理：定期做竞品分析、更新产品蓝图，及时确定产品路线、管理产品需求、确认研发优先级等；

2）研发阶段治理：增加需求、技术方案、任务管理评审环节等；

3）运营阶段管理：增加产品培训，强调使用说明等。

经过阶段性的治理工作后，我们整个可观测性平台的用户满意度得到了较大的提升，因此，实施产品化管理，是工具平台建设成功的关键。

四、未来展望

未来，我们需要去重点关注的问题是：如何覆盖更多观测面？如何更高效、更准确地感知故障和定位问题？

1、如何覆盖更多观测面？

以前，两个服务间的调用经过两个主机网络就可以了。但是在云原生环境下，应用间的调用越来越复杂，需要经过容器网格、sidecar、Node节点等。

所以如果遇到服务性能问题，如何分析是服务本身的问题还是网络问题？以及服务偶尔抖动如何定位根因？pod的性能不达标，如何确定是受哪个异常网络流量的pod影响？

如果单纯依靠手动埋点插入统计代码的方式，对开发人员来说，工作量是非常大的，因此未来我们会引入eBPF技术。

eBPF是什么呢？

Linux内核中的一种虚拟机和框架，允许用户在内核中编写安全高效的程序，用于网络包过滤、系统调用跟踪和内核事件监控等用途。

它的特性包括：

• 动态加载：无需重启服务和服务器；
• 可编程性：可以根据我们的各种需求，在这一层进行编程；
• 高性能：主要体现在这里的代码在内核中高效执行；
• 安全性：eBPF采用沙箱机制，确保在内核中运行的用户程序不会破坏系统的稳定性和安全性。

这里给大家推荐两个完整度非常高的开源项目：一个是国内的deepflow（https://deepflow.io/）,另一个是国外的pixie（https://px.dev/）,我们也在基于这两个项目做一些实践，大家有兴趣的一起研究探讨。

用户体验层观测

当前我们大部分观测工作都围绕着后端服务进行，而用户体验层即客户端，才能更敏感、更准确地感知服务质量和影响范围（比如从客户端到服务端中间的网络问题、DNS问题），单纯从服务端是无法感知的，因此我们正在建设客户端的监控。

2、如何更高效、更准确地感知故障和定位问题？

以往我们设置告警阀值、排查问题，都是依靠个人经验去判定。未来，我们要形成故障感知和故障定位能力，将经验驱动向AI驱动发展，大量应用AIOps等相关技术提升可观测性能力。

陈成禧趣丸科技 SRE平台资深架构师

• 具有十多年研发经验，在过去几年⼀直致力于研究服务稳定性建设和可观测性方面的问题，积累了丰富经验。曾在多家公司主导设计和开发监控相关系统

图片