软件架构技术22、云原生系统可观测性构建

随着云计算技术的飞速发展，云原生概念逐渐深入人心。云原生技术以其高可用性、高弹性、自动化部署和运维等特性，正推动着软件架构和开发模式的变革。在这种背景下，可观测性成为了云原生架构设计中的关键要素。本文将探讨在云原生环境下如何设计一个高效的可观测性架构。

一、可观测性概念

1、可观测性的定义

可观测性被定义为根据系统产生的输出数据（如日志，指标和链路追踪）来衡量当前系统运行状态的能力。

可观测性目前被广泛的用于提升分布式 IT 系统的稳定性（系统复杂度成倍提升，在故障或者异常时很难快速定位和解决），它利用指标、日志和链路追踪三种类型数据，为分布式系统内部运行状态提供了深度透视能力，协助 DevOps 工程师解决各种问题并提升系统性能。

如果您还不明白什么是可观测性，那么让我们这样说吧: 可观测性是可以帮助团队高效调试其系统的工具或技术解决方案。可观测性基于探索事先未定义的属性和模式（帮助我们主动地探索事先未定义的属性和规律，类似于解谜过程中的探索和揭示隐藏信息的能力）。

2、可观测性与监控系统的区别

1）“监控”是“可观测性”能力的一部分

任何时代都需要监控，但监控早已不再是核心需求。运维是传统监控的使用主体，通过告警与整体分析往往可以快速排障。然而，一旦需要剖析导致故障产生的深层原因往往就需要研发的介入。云原生环境，系统架构愈发复杂，通过研发追溯源代码定位故障节点难度较大，需要在设计系统之初就考虑这些问题。DevOps作为云原生技术的基础能力之一，改变了开发、运维之间的协作方式，从根本上为实现“可观测性”能力创造前提。

2）可观测性告诉你为什么业务出问题

监控告诉我们系统哪些部分是工作的，而可观测性，则告诉我们那里为什么不工作了。

虽然可观测性是由传统监控发展而来，但是他们有着本质的不同。

传统监控更多的是指运维自动化工具，主要用途是替代人自动监控系统运行情况，在系统发生异常时告警，最终还是需要人工去分析异常、故障诊断和根因分析。

但现代IT系统的关键词是分布式、池化、大数据、零信任、弹性、容错、云原生等，越来越庞大，越来越精细，越来越动态，同时也越来越复杂。通过人去寻找各种信息的关联性，再根据经验判断和优化，显然是不可行的，耗时耗力还无法找到问题根因。

可观测性不仅包含传统监控的能力，更多的是面向业务，强调将业务全过程透明化的理念，实现全景监控、智能运维和自修复能力等体系化的服务能力。

相比监控只能展示系统出问题的地方，可观测性则能够“更一进步”告诉我们为什么出问题，还会有哪里出问题。一个组织的系统可观测性越强，就能越迅速地了解为什么出现问题并修复。通过应用可观测性来对组织运营产生的实际数据进行分析，将所有数字化产品赋予可观测能力，在较短时间内推动主动决策，更进一步满足以用户为中心的数字化转型需求，从而增强企业竞争力。

3、可观测性能解决什么问题？

谷歌给出可观测性的核心价值很简单：快速排障。可观测性犹如整个IT系统的眼睛，它是运维人员发现问题、定位问题、解决问题的第一步，同时，也是运维监控的实现“先知、先觉、先行”的重要条件。同时在一下方面也表现突出：

整合数据孤岛

•以数据虚拟化和机器数据湖架构，整合机器数据孤岛，提升数字化效能，基于系统目标、结构、行为的数据治理

•与多维度关联分析，有的放矢地处理问题，提升问题处理效能

快速高效排障

•多种机器数据联动分析、全息观测、高效定位根因，智能降噪

•以统一工作台实现业务问题衡量、预防、发现、定位、解决的端到端闭环

提升业务敏捷

•内置可观测性场景化应用及低代码开发平台，为开发测试、IT运维、业务运营、安全合规等全业务运营流程提供可观测性能力，实现高效运维和运营

•DevOps全流程数据分析，提升研发效能

•用户旅程端到端数据实时反馈，助力提升业务运营效能

•业务SLO和成本实时监控与告警降噪，提升IT运维效能

•日志数据实时采集和分析，提供安全与合规保障

二、如何构建可观测性

1、可观测性需要三种类型的数据？

可观测性使⽤三种类型的遥测数据：日志（logs）、指标（metrics）与链路（trace）来提供对分布式系统的深⼊可⻅性，并允许团队找到⼤量问题的根本原因并提⾼系统性能。

1.1 监控指标信息（Monitoring metrics）

Metrics作为可聚合性数据，通常为一段时间内可度量的数据指标，透过其可以观察系统的状态与趋势。指标是在⼀段时间内测量的数值，包括特定属性，例如时间戳、名称、KPI 和值。与⽇志不同，指标在默认情况下是结构化的，这使得查询和优化存储变得更加容易，让您能够将它们保留更⻓时间。

云原生监控指标可观测产品大都是从传统的监控产品发展而来的，传统监控中Zabbix以其高可用和图形化展示而广受欢迎。

而在云原生时代，CNCF孵化的监控工具Prometheus取代了以Zabbix为代表的众多传统监控工具，已基本成为云原生监控体系通用的解决方案，并可以通过配合Grafana工具实现监控数据图形化进行可视化分析。

1.2 事件日志（Logging）

⽇志是在特定时间发⽣的事件的⽂本记录，包括说明事件发⽣时间的时间戳和提供上下⽂的有效负载。⽇志有三种格式：纯⽂本、结构化和⼆进制。纯⽂本是最常⻅的，但结构化⽇志⸺包括额外的数据和元数据并且更容易查询⸺正变得越来越流⾏。当系统出现问题时，⽇志通常也是您⾸先查看的地⽅。

在业界中，事件日志可观测产品也已经是一片红海。日志管理方案大都包含日志收集、日志聚合、日志存储与分析几个模块，具体过程是日志收集工具与应用程序容器一起运行，并直接从应用程序收集消息，然后将消息转发到中央日志存储以进行汇总和分析。

在这方面Elastic Stack日志解决方案独占鳌头，几乎覆盖了日志管理的全流程，其中一大变数是用于日志聚合、过滤等业务的Logstash效能较差，在未来可能会被CNCF孵化的Fluentd取代。

1.3 链路追踪（Tracing）

跟踪表示请求通过分布式系统的端到端旅程。当请求通过主机系统时， 对其执⾏的每个操作（称为“跨度”）都使⽤与执⾏该操作的微服务相关的重要数据进⾏编码。通过查看跟踪，每个跟踪都包含⼀个或多个跨度，您可以通过分布式系统跟踪其进程并确定瓶颈或故障的原因。

比起监控日志与事件日志，链路追踪可观测的产品竞争要相对激烈得多。其根本原因在于链路数据与实际业务和业务实现协议、编程语言等细粒度具体场景密切相关。

这也导致针对不同产品实现和网络协议的链路追踪产品层出不穷，但是他们在功能实现上并没有太本质的差距，却又受制于实现细节，彼此互斥，很难搭配工作。

2、数据统一与关联是基础

传统的工具是垂直向的，在引入一个新的组件的同时也会引入一个与之对应的观测工具。尽管保证了数据的全面性，但丢失了数据的关联性和分析排查的连贯性。如果有一个统一的数据平台，把所有数据放在一个平台，似乎就能解决关联性的问题。但实际情况往往是，建立了一个观测指标、日志、链路的统一平台，数据堆在了一个地方，用的时候还是按传统的方式各看各的，关联性还得靠人的知识和经验。因此，可观测性能力的构建，最关键的其实是解决数据统一和关联的问题：把之前需要人去比对、过滤的事交给程序去处理，人的时间更多的用在判断和决策上。

中国信通院《可观测性技术发展白皮书》指出，可观测平台能力的构建，需要具备统一数据模型、统一数据处理、统一数据分析、数据编排、数据展示的能力。

那么，如何做数据统一和关联呢？

在统一数据平台上，由于数据是来自于各种观测工具的，虽然在数据格式上统一了，但不同工具的元数据截然不同。如果在统一数据平台上去梳理和映射这些元数据，将是庞杂、难维护、不可持续的。

那么该如何做呢？答案就是标准化。

只有将标准化、结构化的数据喂给观测平台，观测平台才能从中发现巨大价值。统一数据平台只是在数据格式上进行了标准化，而要想将数据关联还必须建立context的标准化，context就是数据的空间信息，再叠加上时间信息的关联就可以发挥真正的观测价值。

目前，CNCF为了统一这一乱象，推出了Open Telemetry（遥测）以期实现理想状态下的大一统：统一Logs、Trace、Metrics三种数据协议标准，使用一个Agent完成所有可观测性数据的采集和传输，适配众多云厂商，兼容CNCF上众多的开源与商业项目。

可以说Open Telemetry（遥测）是一套与平台无关、与厂商无关、与语言无关的追踪协议规范，意在让链路追踪可观测更加规范化。

但遗憾是，至今未有厂商或开源项目可以统一Open Telemetry后端，三种数据源的统一存储、展示与关联分析仍面临极大挑战，而解决以上问题的前提，仍然是统一数据源（数据格式）。总的来说，云原生可观测性方兴未艾，因为云原生的应用系统趋于规模化和复杂化，越是复杂的庞大机器越是会强调其可靠性和稳定性。未来，云原生可观测未来需要一个大一统的可落地产品，通过统一的标准汇聚三者的数据，挖掘交叉区域的价值

3、可观测性实现面临哪些挑战？

虽然实现可观测性一直以来都是一个具有挑战性的难题，但是随着云服务的复杂性日益增加并且企业加速采用云服务的趋势，解决这个问题变得至关重要。特别是在微服务和容器化应用的环境下，云服务所产生的监控数据变得更加广泛和复杂。与过去相比，它们不仅数量更多，而且种类和规模也更大，超出了传统监控系统所能提供的数据范畴。

关于可观测性实现，通常会面临以下困难：

1. 数据孤岛：由于存在众多采集代理程序、用不同的数据源和独立的监控工具，各工具之间没有很好的集成或协同工作，很难全面理解应用程序、各种云服务和数字渠道（包括 Web 、移动网络和物联网）之间的相互依赖关系。

2. 大规模、高速度、多样性和复杂性挑战：在使用 AWS、Azure 和 GCP ( Google Cloud Platform )等现代云服务基础设施的架构中，各服务和组件产生的原始指标数据量非常庞大，选择之前的监控方案，几乎不可能找到答案（很难有效地处理和分析这些数据，从中获取有用的信息和答案）。使用 Kubernetes 和容器进行快速扩缩容的能力，导致了更频繁的数据生成和变动，增加了对数据管理和分析的挑战。

3. 缺乏预生产环境：尽管进行了预生产模拟高负载的测试，但开发人员依然缺少准确观测或理解实际情况的方法，代码发布前无法在生产环境中，了解到真实用户的操作（真实行为、网络延迟、不同地理位置的访问等因素）如何影响应用程序和基础设施。

4. 排查故障耗费大量时间：为了解决问题并试图确定问题源头，实施团队，运维团队，基数设施团队，开发团队和数字体验团队（ DX ，客户与企业所有数字渠道互动的方式，是您整体客户体验的重要组成部分）都被纳入故障排除工作。但是结果是，宝贵的时间被浪费在猜测和理解指标数据上。

三、如何实践可观测性

1、可观测性落地

要实现可观测性，您的系统和应用程序必须提供指标收集必要的指标数据。您可以通过自己创造的工具、利用开源软件或购买商业的可观测性解决方案来创建一个可观测的系统。

以下是开始实践可观测性的几个步骤：

1）确定业务目标：通过优化系统资源来减少基础设施支出、并且通过支持容量规划以促进业务增长，以及提高关键业务指标的表现（如平均恢复时间），强大的可观测性配置可以帮助提高利润或净收入。通过向支持人员提供额外的上下文数据，可以促进问题的透明度，甚至创造积极的客户体验。然而，针对不同的业务目标，所需的可观测性配置可能会有很大的差异。一旦您确定了主要的业务目标，您需要制定一个可观测性策略，以确保您拥有适当的手段和工具来支持这些目标的实现。

2）关注正确的指标：精心设计的可观测性方法，您可以在问题出现之前就预测到潜在的错误或故障，并准确定位根本原因。为了追求透明度，需要进行多种数据收集、分析以及其他监控和测试技术，以便全面了解和评估所涉及的内容。

3）事件日志：对于架构和开发团队来说，事件日志是分布式系统中可观测性的重要数据源。有很多专为捕获和存储事件日志设计的工具，如Prometheus、Middleware和Splunk。这些事件信息可能包括系统的各种过程的成功信息、重大系统故障、意外停机或导致系统过载的流量变化。因为它为开发人员提供了关键的取证信息，用来发现有缺陷的组件或有交互有问题的部分，所以这对于调试和定位错误处理尤为重要。

4）访问可视化数据：当成功采集到可观测性数据时，这些原始数据必须被压缩成通用的格式。通常再使用各种可视化工具对这些数据进行可视化渲染。通过这样方式，团队成员就可以高效的将该信息传递或分享给其他相关的团队。

5）选择合适的可观测性平台：在选择合适的可观测性平台时，请考虑以下因素：

• 工具是否免费？

• 是否使用开源采集代理工具？

• 工具是否易用？

• 是否具备发挥该工具最大潜力所需的技术知识储备？

• 工具的处理能力可以适应何种数据规模？

通过回答这些问题和其他与业务相关的问题，将帮助您做出明智的决策。

2、APM与APM工具

APM 是Application Performance Managment的缩写，即：“应用性能管理”。

它涉及从面向用户和后端的角度监控应用，发现Web应用程序中的潜在问题和性能瓶颈。

然后使用这些数据来诊断、排除故障和解决问题，以改善用户体验。

1）Skywalking

描述：必须排第一，国货之光。Skywalking是由国内开源爱好者吴晟开源并提交到Apache孵化器的产品，它同时吸收了Zipkin/Pinpoint/CAT的设计思路，支持非侵入式埋点。是一款基于分布式跟踪的应用程序性能监控系统。

总结：Skywalking已经是一个比较完整的APM解决方案了，如果公司体量不是很大，建议使用。

2）ELK stack

描述：ELK Stack是一个流行的工具套件，功能涵盖监控、日志和数据可视化。它由 ElasticSearch, Logstash, and Kibana 三部分组成。其中，Elasticsearch 负责搜索和分析，Logstash 是日志聚积器，而 Kibana则提供华丽的可视化仪表盘。

总结：国内大数据互联网公司都采用ELK做日志采集。

3）prometheus

描述：Prometheus 是一套开源的系统监控报警框架。它受启发于 Google 的 Brogmon 监控系统，由工作在 SoundCloud 的前 google 员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。

2016 年，Prometheus 正式加入 Cloud Native Computing Foundation（CNCF）基金会的项目，成为受欢迎度仅次于 Kubernetes 的项目。2017 年底发布了基于全新存储层的 2.0 版本，能更好地与容器平台、云平台配合。

Prometheus 作为新一代的云原生监控系统，目前已经有超过 650+位贡献者参与到 Prometheus 的研发工作上，并且超过 120+项的第三方集成。

总结：容器化必备监控软件

4）open-falcon

描述：小米开源的企业级监控工具，用 Go 语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案，Open-Falcon从互联网公司的一些需求出发，从各位SRE、SA、DEVS的使用经验和反馈出发，结合业界的一些大的互联网公司做监控，用监控的一些思考出发，设计开发了open-falcon。

总结：用于做服务器端监控是一个不错的选择

6）pinpoint

描述：pinpoint是开源在github上的一款APM监控工具，它是用Java编写的，用于大规模分布式系统监控。它对性能的影响最小（只增加约3％资源利用率），安装agent是无侵入式的。

总结：UI不错，但是不支持多语言，探针也不丰富，个人不建议使用。