应云而生，一文看懂端到端的可观测体系构建 | Q推荐

作者 | 张雅文  

2021 年初，可观测性的概念在国内市场还鲜少有人提到，但到了 2021 年下半年，有关可观测性的研讨和实践却开始如雨后春笋般层出不穷，知名公司 Grafana 甚至直接将原来的监控工具改成了可观测性技术栈并推了一系列服务。可观测性真的能够解决传统监控体系面临的诸多问题吗？又该如何构建可观测体系？本期，亚马逊云科技 Tech Talk 特别邀请到观测云 CEO 蒋烁淼带来分享《构建端到端的可观测体系最佳实践》。

1 可观测性为何突然“火出圈”

可观测性看似是个新鲜词，但其实它的起源远比我们的认知要早得多。可观测性最早是匈牙利裔工程师鲁道夫·卡尔曼针对线性动态系统提出的概念。若以信号流图来看，若所有的内部状态都可以输出到输出信号，此系统即有可观测性。1948 年伯特·维纳发表的著作《控制论 - 关于动物和机器中控制和通讯的科学》同样提到了可观测性。控制理论中的可观测性是指系统可以由其外部输出推断其内部状态的程度。

随着云计算的发展，可观测性的概念逐渐走入计算机软件领域。为什么近期可观测性的热度显著提升了呢？

蒋烁淼认为，这很大程度是由于系统复杂性的增强。IT 系统的本质是一个数字化的系统，过去，系统本身结构简单，多为单体式架构，且基础设施相对固定，可以通过监控去查看系统。但随着云原生时代的到了，管理对象从单一主机逐渐变成云，后来又变成云原生的分布式复杂系统，传统的面向基础设施的监控、简单的日志和简单的 APM 没有办法解决问题，因此，需要构建系统完整的可观测性。

可观测性中使用的主要数据类是指标、日志、链路。它们通常被称为“可观测性的三大支柱”。

• 指标（Metric）：指标是连续时间下的系统的值的记录，基础指标通常用于描述两种数据类型，一种是计数（Count），一种是计量（Gauge）。

• 日志（Log）：系统 / 应用输出的时间相关的记录，通常由系统 / 软件开发人员输出，方便定位系统的错误和状态。

• 链路（Tracing）：基于有向无环图构建的软件各个模块直接地调用关系。

三大支柱至关重要，开发者正是通过这三个维度的数据来判定应用系统的状况。和传统监控相比，可观测体系拥有诸多优势。

传统监控面向已知的问题，只能去发现和通知那些已知可能会发生的故障，如：CPU>90%。主要监控对象是 IT 对象，仅面向服务端的组件，解决基础的运维问题。

而可观测性则能够协助发现并定位未知的问题。其核心是不断收集系统产生的各种核心指标与数据，通过数据分析的方式来保障和优化业务，如：发现小程序客户端在某个城市的支付失败率非常高，从而判断是否是代码层面上导致这样一个异常。可观测性主要监测的对象不仅仅是 IT 对象，还有应用和业务，面向云、分布式系统、APP/ 小程序。

在分享中蒋烁淼谈到，随着基础设施的发展，传统监控将逐步被可观测性所取代。

他将构建可观测性的价值总结为以下五点：

• 让 SLO 可视化，清晰的目标和现状

• 发现与定位未知问题

• 减少团队间的澄清成本

• 降低业务异常造成的无法预知的经济损失

• 提升最终用户体验和满意度

2 开源 or SaaS，可观测性构建正确的打开方式是？

相比于传统监控体系，构建可观测性既然有诸多优势和价值。那么该如何构建可观测性呢？

首先，需要尽可能地收集所有组件系统的所有相关⾯的基础数据，包括云、主机、容器、Kubernetes 集群，应⽤和各种终端。实时收集这些数据的成本并不⾼，但如果没有收集，⼀旦系统故障需要排查分析的时候，就⽆法有效评估当时的状态。

其次，要明确系统可观测性构建的责任。谁是这个组件的构建者，谁负责定义这个组件的 SLI，谁负责收集所有的相关基础数据并构建相应的仪表盘以及谁为相关的组件的 SLO 负责，需要责任到人。

第三，开发者需要为可观测性负责。开发者要将⾃⼰开发系统的可观测性数据暴露作为软件质量⼯程的⼀部分，如果说单元测试是为了保证最⼩单元代码的可⽤性，那么开发者标准化暴露可观测性基础数据也将作为⽣产系统可靠性的必要条件。

第四，需要建⽴统⼀的指标、⽇志、链路规范，统⼀团队的⼯具链。即采取相同的指标命名规范，相同的⽇志格式，相同的链路系统。如果在遵循 OpenTelemetry 标准后，仍有不同，则可定义串联整个系统的统⼀TAG 规范，如：所有错误都是 state:error。

第五，要持续优化改进整体可观测性。针对整个系统的可观测，包括数据收集，视图构建，TAG 体系建⽴，这些步骤均需要时间，不能因为覆盖度或者构建的仪表盘未能在某次事故中发挥作⽤而继续⽤过去的⽅式处理问题。每次未被观测的故障都是进⼀步提升可观测范围的绝佳机会。

从可观测性构建的路径不难看出，其过程是非常复杂的。那么，主流的构建方式有哪些？蒋烁淼介绍了两种最为常见的可观测性构建方式，分别是通过开源的方式构建和采用 SaaS 产品进行构建。

得益于开源生态的蓬勃发展，为可观测性的构建提供了诸多选择。采用开源的方式构建，需要构建者从前端的数据抓取到后端的数据处理，包括数据展示、告警等周边功能的相关知识有非常详尽的了解掌握。因此，这种方式适合于那些有足够实力或者学习成本及时间成本相对充足的团队。

相比于开源的方式，采用成熟的 SaaS 产品构建可观测性是一种更加高效的方式。蒋烁淼以观测云的产品为例，介绍了这种方式的四点优势。

• 不做缝合怪：在服务器内仅安装一个 agent 就可以收集这台主机所有相关的系统数据，避免成堆的 agent 和配置项。

• 不做小白鼠：能提供端到端的完整覆盖，并能做到开箱即用，避免良莠不齐的集成，如：观测云就能够支持超过 200 种技术栈，实现端到端的覆盖。

• 不封闭、高度可编程：可实现轻松构建任意的可观测场景，甚至将业务数据参数引入到整体的观测中，灵活性强。此外，还能够避免死板的集成，拥有强大的二次开发能力。

• 不留隐患：观察云对用户侧代码永久开源，单向通讯，不会也不能向客户环境下发指令。所有的数据收集默认脱敏且用户可对整个过程进行控制。

前面提到，可观测性的构建是应“云”而生的，不仅如此，观测云本身也是完完全全的云原生产品。观测云中整套产品包括数据平台，都是部署在亚马逊云科技的 EKS 之上的，并基于容器进行编排。观测云的整体架构非常简单，即通过一个 agent 将海量数据进行统一，进入数据平台，然后通过平台的能力提供完整的可观测性。整个系统分为核心平台层、Web 层和数据接入层，核心平台层是完全由观测云进行自研的，没有进行开源。上层的 Web 层，在核心数据处理平台上有一套与平台对接的 API。蒋烁淼说：“对于客户来说，更推荐直接选择观测云的 SaaS 产品，如果愿意，客户也可以在亚马逊上完全孤立地进行部署，也是非常方便的，只不过整体费用要比直接采用 SaaS 产品高得多。

为什么会选择亚马逊云科技？主要是基于以下考量：

• 观测系统本身要有高一个数量级的可靠性和更高的 SLA：观测云是帮助客户构建可观测性系统的平台，因此需要自身拥有很高的可靠性，如果不能提供足够高的可靠性，一旦观测系统出现故障，便无法及时提醒客户，提供详细的分析更无从谈起。此外，选择云服务本身也能够让一部分观测云平台的 SLA 由亚马逊来提供。

• 更成熟的 Marketplace：用户可通过中国的团队直接在亚马逊上进行产品购买，亚马逊云科技会把产品消费直接在 Marketplace 上记账。需要说明的是，观测云的产品是根据数据规模来付费的，当用户没有数据量的时候几乎是免费的。

• 全球性：亚马逊云科技能够提供比海外产品更好的兼容性，尤其对于中国的技术栈整体成本更低。蒋烁淼在分享中透露：“在春节过后，观测云将会在海外亚马逊云科技节点部署我们的观测平台。观测云希望用中国力量为中国的出海客户提供比海外产品更好的、成本更低的选择。”

• 借力 APN 融入亚马逊云科技全球网络：观测云希望借助亚马逊云科技强大的生态，将可观测性作为最终对客户提供服务的手段，并希望能够借力 APN，帮助更多用户了解可观测性的效果，这个也是观测云选择亚马逊科技非常重要的原因之一。

除了是完完整整的云原生产品，在观测云的系统中，还包含几个非常有趣的设计。首先，在采集侧：

• 观测云把第三方指标, 日志, 链路采集协议统一转为观测云协议

• 插件式采集栈设计, 各插件之间采用 go 协程隔离, 互不影响

• 主动式资源消耗控制防止 agent 端资源压力过大 (cgroup 控制采集资源占用)

• 被动式资源消耗控制防止 server 端压力过大 (背压机制)

• 潮汐机制的分布式日志解析 (pipeline)

其次，在存储查询侧，观测云统一了查询语法，用户无需关心底层数据存储，简单易上手。

第三，在分析侧，观测云实现了全部数据串联，并构建了统一的查看器，将原始数据以类似多维分析和列表的方式进行分析，用户可以去构建自己的查看器。此外，由于数据量大，为避免前端造成用户浏览器压力过大，观测云可以按照指定百分比来采集数据，并提供 SLO/SLI 的面板，帮助客户构建自己应用系统整体可靠性的度量方式。

3 构建端到端的可观测体系实践案例

在对概念层和技术层面进行详细的介绍后，蒋烁淼以某电商客户作为案例，就具体该如何构建端到端的可观测体系进行了讲解。

案例中电商客户面临的问题是：交易流程从客户下单到仓库到最后财务记账，一个订单需要将近 10 次接口调用，其中任何环节都有可能出现问题，例如程序问题，网络异常，库存卡住等。目前没有有效的监控工具能够把对订单流程进行监控，出问题一般都是门店员工反馈过来，然后运维人员根据订单去参照流程去查询问题出在哪里，非常被动，且工作量较大，每天需要运维人员去查询业务接口是否走完。

针对该客户构建端到端的可观测体系的过程大致分为四步：第一步，梳理观测对象集成接入。采用观测云的产品，整个接入过程仅需要 30 分钟左右就可以完成。

第二步，统一查看与分析。具体步骤为，首先，对用户体验进行监测，然后查看该行为下的和后端打通的链路，并点击具体的链路进入链路查看器，最后查看相应链路的日志。

第三，通过查看器实现业务的可观测。

第四，通过 SLO 监控器预警。

通过观测云完成端到端的可观测性构建后，该电商客户将订单流程节点状态可视化，可实现以订单号检索订单流程节点状态，流程卡在哪个环节，报错信息是怎样一目了然。从用户操作界面、网络、后端服务到依赖的中间件、操作系统，任意故障都能够提供清晰的溯源与分析。不仅如此，观测云还提供实时异常监控告警，确保问题能够被及时发现并及时处理。

除电商领域的应用外，观测云的 SaaS 产品还适用于非常多应用场景。在观测云的官网有完整的系统可观测性构建的最佳实践，感兴趣的小伙伴可直接去观测云官网查看相应文档。

戳【阅读原文】直达官网