“可观测性”到底是什么？
学习资料：IT运维管理社区专家讲堂直播300期视频回放
“可观测性”到底是什么？
最近在编写ITIL4《事件管理实践》的落地方案，事件管理实践落地的PSF（实践成功要素）其一：是要能够“尽早发现事件”；其二是“快速有效地解决事件”，这两个成功要素的工具支撑部分都需要如何利用监控和自动化工具来满足：“尽早发现事件”和“快速有效地解决事件”。当前云原生在企业或组织中大量应用，可观测性作为云原生的主要运维技术也成为事件管理事件落地的重要技术工具。本文就详细介绍一下“可观测性”，以辅助大家在落地ITIL4事件管理实践时工具选择的依据。
1.什么是可观测性（Observability）？
1.1可观测性的定义
可观测性这一术语源于控制理论，可观测性是衡量一个系统从其外部输出的知识中推断系统内部状态的一种度量。换句话说，如果你可以观察系统的外部以确定它内部发生了什么，那么该系统就具有可观测性。在IT运维领域，是指获知基础设施、编排平台和服务应用所有层面的必要信息，从而观察所有系统的各类行为是否存在异常。可观测性是通过对开发测试、IT运维、业务运营、安全合规等全业务运营流程，借助日志、指标、链路等机器数据进行关联分析，衡量、预防、发现、定位、解决业务问题，实现业务效能提升的一种能力。可观测性是从系统内部出发，基于白盒化的思路去监测系统内部的运行情况。可观测性贯穿应用开发的整个生命周期，通过分析应用的指标、日志和链路等数据，构建完整的观测模型，从而实现故障诊断、根因分析和快速恢复。
1.2可观测性的本质？
云原生环境，一切以业务应用为核心。“可观测性”能力亦是如此。由于云原生应用的创新迭代速度加快，“可观测性”将传统监控的外延放大，把研发纳入“可观测性”能力体系之中，改变传统被动监控的方式，主动观测与关联应用的各项指标，以“上帝视角”让系统恰当地展现自身状态。
2.可观测性的来源与发展
可观测性的来源
可观测性，虽然它似乎是最近的流⾏词，但该术语起源于⼏⼗年前的控制理论（它是关于描述和理解⾃我调节系统的）。2018年，可观测性（Observability）被引入IT领域，CNCF-Landscape率先出现了Observability的分组。自此以后，“可观测性”逐渐取代“监控”，成为云原生技术领域最热门的话题之一。
CNCF云原生全景图（CNCFcloudnativelandscape），云原生全景图的目标是收集和组织所有的云原生开源项目和商业产品，对其进行分类以提供当前生态整体的预览。拥有云原生项目或产品的组织可以通过提交请求将其添加到全景图中。
云原生计算基金会(CloudNativeComputingFoundation,CNCF)是非营利的Linux基金会的一部分，成立于2015年7月，围绕“云原生”服务云计算，致力于维护和集成开源技术，支持编排容器化微服务架构应用。目前，CNCF有会员公司超过300家，其中包括AWS、Azure、Google、阿里云等大型云计算厂商。
什么是云原生？
云原生（CloudNative）是一种理念，本质上是一套“以利用云计算技术为用户降本增效”的最佳实践与方法论。云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。目前，云原生越来越多地应⽤于提⾼分布式IT系统的性能。在这种情况下，可观测性使⽤三种类型的遥测数据⸺指标、⽇志和跟踪⸺来提供对分布式系统的深⼊可⻅性，并允许团队找到⼤量问题的根本原因并提⾼系统性能。
可观测性的发展趋势
Gartner发布的《2023年十大战略技术趋势》中，提到了可观测性的发展趋势解读。Gartner表示：“可观测性应用使企业机构能够利用他们的数据特征来获得竞争优势。它能够在正确的时间提高正确数据的战略重要性，以便根据明确的数据分析结果采取快速行动，因此可观测性是一种强大的工具。如果能够在战略中予以规划并成功执行，可观测性应用将成为数据驱动型决策的最强支撑。”与此同时，由InfoQ发布的《中国软件技术发展洞察和趋势预测报告2023》中，可观测性技术也傲然上榜，目前还处于早期采用者阶段。或许在不久的将来，将会有越来越多的企业使用可观测性技术。Gartner预测，到2024年，将有30%的企业会通过可观测技术来提升数字化业务的运行性能，相比2020年的10%提升了3倍。2023年，全球可观测市场规模预计将达到164.94亿美元。随着云原生架构的演进，可观测的边界与分工被重新定义，传统的容器、应用、业务分层监控边界被打破，Dev、Ops、Sec的分工逐渐模糊。
业界开始意识到，IT系统作为一个有机的整体，对IT系统状态的监测与诊断也需要一体化的方案。因此，AllinONE思想逐渐成为主流，运维行业也随之发生了三个变化：一是企业视角发生变化。以前企业更多关注系统运维层面机房建设、底层服务器的搭建、购买，现在基于云化基础设施，企业更注重业务搭建、业务体验优化以及业务运营。二是运维职责发生变化。云化基础设施对企业而言是不可见、不可控的，因此需要往平台型、业务的方向转型，转向DevOps和SRE方向。三是监控技术发生变化。云原生导致微服务和分布式趋势增强，使得现在系统很难运维，需要监控技术从“监控”走向“可观测”，构建起一套高效的排障体系。
3.为什么会出现可观测性？
3.1云原生的大量应用催生可观测性
在过去⼏年中，企业从单体架构发展到分布式架构，以微服务、⽆服务器和容器技术的形式迅速采⽤了云原⽣基础设施服务。进而产生了大量的分布式系统，这些系统运行时环境容器化、业务系统依赖关系复杂化，运行实例生命周期短等等，监控也随着进行实时动态调整，这就导致在这些分布式系统中追踪事件的起源需要在云上、本地或两者上运⾏的数千个进程。但是传统的监控技术和⼯具很难跟踪这些分布式架构中的许多通信路径和相互依赖关系，IT基础设施变得愈发不可控，更别提排查问题并定位根本原因了。因此，传统预先配置再监控的方式已经无法满足云原生的场景。同时，Gartner认为数字化转型以业务为中心，服务和用户体验是关键目标。而IT监控以系统可用为中心，仅关注系统可用性指标对于转型中的企业而言是一场灾难。到2023年，依赖于“正常运行时间”指标的监控实践将抑制90%的转型计划。因此，云原生可观测性是指，从传统软件监控及数据分析可视化工具中，总结出在云原生领域中，从底层容器基础设施、通用技术组件到业务应用系统全链路监控运维、运营治理等产品化体系化的能力诉求，确切的体现了云原生的核心理念。
相比监控可观测性更多偏向自动化工具，可以替代人自动监控系统异常，云原生可观测性不仅包含传统监控的能力，更多的是面向业务，强调将业务全过程透明化的理念。可观测性使团队能够更有效地监控现代系统，并帮助他们找到并连接复杂链中的影响，并将其追溯到原因。此外，它还使系统管理员、IT运营分析师和开发⼈员能够了解他们的整个架构。当监控无法再单独以运维的视角、被动地解决故障为目标，而要追随IT架构的改变和云原生技术的实践，融入开发与业务部门的视角，具备比原有监控更广泛、更主动的能力，“可观测性”概念诞生了。
3.2“快速发现”和“有效解决事件”需要“可观测性”
业界将“可观测性”能力划分为5个层级，其中告警（Alerting）与应用概览（Overview）属于传统监控的概念范畴。由于触发告警的往往是明显的症状与表象，但随着架构与应用部署方式的转变，不告警并非意味着一切正常，因此，获取系统内部的信息就显得尤为重要，而这些信息则须借助“可观测性”能力的另一大组成部分——主动发现（Preactive）。“主动发现”，由排错、剖析与依赖分析三部分组成：•排错（Degugging），即运用数据和信息去诊断故障出现的原因；•剖析（Profiling），即运用数据和信息进行性能分析；•依赖分析（DependencyAnalysis），即运用数据信息厘清系统之前的模块，并进行关联分析。这三部分同样存在严谨的逻辑关系：首先，无论是否发生告警，运用主动发现能力都能对系统运行情况进行诊断，通过指标呈现系统运行的实时状态；其次，一旦发现异常，逐层下钻，进行性能分析，调取详细信息，建立深入洞察；再次，调取模块与模块间的交互状态，通过链路追踪构建“上帝视角”。主动发现能力的目的并不是为了告警与排障，而是通过获取最全面的数据与信息，构建对系统、应用架构最深入的认知，而这种认知可以帮助我们提前预测与防范故障的发生。
4.与监控系统的区别和联系？
4.1“监控”是“可观测性”能力的一部分
任何时代都需要监控，但监控早已不再是核心需求。运维是传统监控的使用主体，通过告警与整体分析往往可以快速排障。然而，一旦需要剖析导致故障产生的深层原因往往就需要研发的介入。云原生环境，系统架构愈发复杂，通过研发追溯源代码定位故障节点难度较大，需要在设计系统之初就考虑这些问题。DevOps作为云原生技术的基础能力之一，改变了开发、运维之间的协作方式，从根本上为实现“可观测性”能力创造前提。
4.2可观测性告诉你为什么业务出问题
监控告诉我们系统哪些部分是工作的，而可观测性，则告诉我们那里为什么不工作了。虽然可观测性是由传统监控发展而来，但是他们有着本质的不同。传统监控更多的是指运维自动化工具，主要用途是替代人自动监控系统运行情况，在系统发生异常时告警，最终还是需要人工去分析异常、故障诊断和根因分析。但现代IT系统的关键词是分布式、池化、大数据、零信任、弹性、容错、云原生等，越来越庞大，越来越精细，越来越动态，同时也越来越复杂。通过人去寻找各种信息的关联性，再根据经验判断和优化，显然是不可行的，耗时耗力还无法找到问题根因。可观测性不仅包含传统监控的能力，更多的是面向业务，强调将业务全过程透明化的理念，实现全景监控、智能运维和自修复能力等体系化的服务能力。相比监控只能展示系统出问题的地方，可观测性则能够“更一进步”告诉我们为什么出问题，还会有哪里出问题。一个组织的系统可观测性越强，就能越迅速地了解为什么出现问题并修复。通过应用可观测性来对组织运营产生的实际数据进行分析，将所有数字化产品赋予可观测能力，在较短时间内推动主动决策，更进一步满足以用户为中心的数字化转型需求，从而增强企业竞争力。
5.如何构建可观测性？
5.1可观测性需要三种类型的数据？
可观测性使⽤三种类型的遥测数据：日志（logs）、指标（metrics）与链路（trace）来提供对分布式系统的深⼊可⻅性，并允许团队找到⼤量问题的根本原因并提⾼系统性能。遥测数据（telemetrydata）:用于确定应用程序是否健康并按设计执行的信息称为遥测数据。5.1.1监控指标信息（Monitoringmetrics）Metrics作为可聚合性数据，通常为一段时间内可度量的数据指标，透过其可以观察系统的状态与趋势。指标是在⼀段时间内测量的数值，包括特定属性，例如时间戳、名称、KPI和值。与⽇志不同，指标在默认情况下是结构化的，这使得查询和优化存储变得更加容易，让您能够将它们保留更⻓时间。云原生监控指标可观测产品大都是从传统的监控产品发展而来的，传统监控中Zabbix以其高可用和图形化展示而广受欢迎。而在云原生时代，CNCF孵化的监控工具Prometheus取代了以Zabbix为代表的众多传统监控工具，已基本成为云原生监控体系通用的解决方案，并可以通过配合Grafana工具实现监控数据图形化进行可视化分析。5.1.2事件日志（Logging）⽇志是在特定时间发⽣的事件的⽂本记录，包括说明事件发⽣时间的时间戳和提供上下⽂的有效负载。⽇志有三种格式：纯⽂本、结构化和⼆进制。纯⽂本是最常⻅的，但结构化⽇志⸺包括额外的数据和元数据并且更容易查询⸺正变得越来越流⾏。当系统出现问题时，⽇志通常也是您⾸先查看的地⽅。在业界中，事件日志可观测产品也已经是一片红海。日志管理方案大都包含日志收集、日志聚合、日志存储与分析几个模块，具体过程是日志收集工具与应用程序容器一起运行，并直接从应用程序收集消息，然后将消息转发到中央日志存储以进行汇总和分析。在这方面ElasticStack日志解决方案独占鳌头，几乎覆盖了日志管理的全流程，其中一大变数是用于日志聚合、过滤等业务的Logstash效能较差，在未来可能会被CNCF孵化的Fluentd取代。5.1.3链路追踪（Tracing）跟踪表示请求通过分布式系统的端到端旅程。当请求通过主机系统时，对其执⾏的每个操作（称为“跨度”）都使⽤与执⾏该操作的微服务相关的重要数据进⾏编码。通过查看跟踪，每个跟踪都包含⼀个或多个跨度，您可以通过分布式系统跟踪其进程并确定瓶颈或故障的原因。比起监控日志与事件日志，链路追踪可观测的产品竞争要相对激烈得多。其根本原因在于链路数据与实际业务和业务实现协议、编程语言等细粒度具体场景密切相关。这也导致针对不同产品实现和网络协议的链路追踪产品层出不穷，但是他们在功能实现上并没有太本质的差距，却又受制于实现细节，彼此互斥，很难搭配工作。
5.2数据统一与关联是基础
传统的工具是垂直向的，在引入一个新的组件的同时也会引入一个与之对应的观测工具。尽管保证了数据的全面性，但丢失了数据的关联性和分析排查的连贯性。如果有一个统一的数据平台，把所有数据放在一个平台，似乎就能解决关联性的问题。但实际情况往往是，建立了一个观测指标、日志、链路的统一平台，数据堆在了一个地方，用的时候还是按传统的方式各看各的，关联性还得靠人的知识和经验。因此，可观测性能力的构建，最关键的其实是解决数据统一和关联的问题：把之前需要人去比对、过滤的事交给程序去处理，人的时间更多的用在判断和决策上。中国信通院《可观测性技术发展白皮书》指出，可观测平台能力的构建，需要具备统一数据模型、统一数据处理、统一数据分析、数据编排、数据展示的能力。那么，如何做数据统一和关联呢？在统一数据平台上，由于数据是来自于各种观测工具的，虽然在数据格式上统一了，但不同工具的元数据截然不同。如果在统一数据平台上去梳理和映射这些元数据，将是庞杂、难维护、不可持续的。那么该如何做呢？答案就是标准化。只有将标准化、结构化的数据喂给观测平台，观测平台才能从中发现巨大价值。统一数据平台只是在数据格式上进行了标准化，而要想将数据关联还必须建立context的标准化，context就是数据的空间信息，再叠加上时间信息的关联就可以发挥真正的观测价值。目前，CNCF为了统一这一乱象，推出了OpenTelemetry（遥测）以期实现理想状态下的大一统：统一Logs、Trace、Metrics三种数据协议标准，使用一个Agent完成所有可观测性数据的采集和传输，适配众多云厂商，兼容CNCF上众多的开源与商业项目。可以说OpenTelemetry（遥测）是一套与平台无关、与厂商无关、与语言无关的追踪协议规范，意在让链路追踪可观测更加规范化。但遗憾是，至今未有厂商或开源项目可以统一OpenTelemetry后端，三种数据源的统一存储、展示与关联分析仍面临极大挑战，而解决以上问题的前提，仍然是统一数据源（数据格式）。总的来说，云原生可观测性方兴未艾，因为云原生的应用系统趋于规模化和复杂化，越是复杂的庞大机器越是会强调其可靠性和稳定性。未来，云原生可观测未来需要一个大一统的可落地产品，通过统一的标准汇聚三者的数据，挖掘交叉区域的价值。
6.可观测性能解决什么问题？
谷歌给出可观测性的核心价值很简单：快速排障（troubleshooting）。可观测性犹如整个IT系统的眼睛，它是运维人员发现问题、定位问题、解决问题的第一步，同时，也是运维监控的实现“先知、先觉、先行”的重要条件。同时在一下方面也表现突出：整合数据孤岛•以数据虚拟化和机器数据湖架构，整合机器数据孤岛，提升数字化效能，基于系统目标、结构、行为的数据治理•与多维度关联分析，有的放矢地处理问题，提升问题处理效能快速高效排障•多种机器数据联动分析、全息观测、高效定位根因，智能降噪•以统一工作台实现业务问题衡量、预防、发现、定位、解决的端到端闭环提升业务敏捷•内置可观测性场景化应用及低代码开发平台，为开发测试、IT运维、业务运营、安全合规等全业务运营流程提供可观测性能力，实现高效运维和运营•DevOps全流程数据分析，提升研发效能•用户旅程端到端数据实时反馈，助力提升业务运营效能•业务SLO和成本实时监控与告警降噪，提升IT运维效能•日志数据实时采集和分析，提供安全与合规保障
7.可观测性的实施路径
为了实现可观测性，您需要对系统和应⽤程序进⾏适当的⼯具来收集适当的遥测数据。您可以通过构建⾃⼰的⼯具、使⽤开源软件或购买商业可观测性解决⽅案来制作可观测系统。在运维过程中可观测性是核心基础，如果无法了解系统状态，运维动作就无从发起。因此，阶段一：可观测性阶段是运维的基础阶段，在有健全的可观测性数据后才能结合大数据和人工智能来辅助运维，到达阶段二AIOPS阶段即智能运维。最终的智能化运维系统应该会如图方式建设：
7.1可观测性阶段
可以初略将下四层（数据源、数据采集层、数据存储层、应用与展示层）定义为可观测性阶段需要建设的内容，也是当前大多数企业正在实践的部分。在云原生理念中可观测性是指目标系统可以基于日志（Logging）、链路（Tracing）、指标（Metric）三个维度的数据来观测状态，该状态能够体现该系统的所有的需要关注的内容。7.1.1数据源可观测的数据源大致分为三类，硬件、操作系统与网络以及软件。硬件如服务器的硬盘、电源、风扇和主板等；网络设备如交换机、路由器和网关等设备；安全设备如防火墙；机房设施如空调、电力等；这些硬件在运行时都会产生状态数据。操作系统其实也是一种软件，由于其特殊性这里将其单独归类，操作系统内会有CPU、内存、存储相关的使用和状态数据，操作系统间会有通信的网络数据。应用软件是为了某种特定的用途而被开发的软件，他们是核心要保障稳定对象，特别是业务应用。无论是硬件、操作系统还是应用软件，在云原生场景下都会为容器云提供资源或使用容器云的资源，这也是我们在云原生最佳七步实践要第一步就进行建设容器云的原因。7.1.2数据采集在了解数据源后，对数据进行分析总结出三种独立的数据类型，他们分别从三个不同的维度来展示应用的状态，这三种数据类型分别是日志数据（Logging）、链路数据（Tracing）和指标数据（Metric）日志是记录了发生在运行中的操作系统或其他软件中的事件。常见于事件日志、事物日志、消息日志等，而与可观测性相关主要就是事件日志。事件日志（Eventlogs）记录了在系统运行期间发生的事件，以便于了解系统活动和诊断问题。它对于了解复杂系统的活动轨迹至关重要，尤其是只有很少用户交互的应用程序（例如服务器应用程序）。日志数据的采集目前在CNCF推荐的Fluentd是日志采集工具，也可以选择许多企业正在采用Filebeat和Logstash。由网易开源的、目前已经是CNCF沙盒项目的Loggie，由于其专为云原生场景设计，具有不错的发展潜力。链路追踪即调用链监控，特点是通过记录多个在请求间跨服务完成的逻辑请求信息，帮助开发人员优化性能和进行问题追踪。链路追踪可以捕获每个请求遇到的异常和错误，以及即时信息和有价值的数据。链路追踪的技术选型推荐使用的是CNCF中的FJaeger，也有很多企业选择SkyWalking或Zipkin。指标数据是应用程序运行时产生的内部指标，以API接口的方式提供查询。指标数据具有时间的特性，不同的时间点的指标是不同的，因此用以存储指标数据的数据库一般称为时序列数据库。Prometheus是指标数据的集大成者，是云原生场景下的不二选择。指标数据的采集可由Prometheus直接采集应用（如请求/metrics接口），或由应用的Exporter间接采集。介绍可观测性还有一个无法绕开的话题就是OpenTelemetry，OpenTelemetry目标是将以上三个维度的数据格式进行标准化范。OpenTelemetry是一组API、SDK、工具和集成，旨在创建和管理遥测数据，例如Trace、Metrics和Logs。该项目提供了一个与供应商无关的实现，可以将其配置为将遥测数据发送到您选择的后端。它支持各种流行的开源项目，包括Jaeger和Prometheus｡主要解决的问题是观测性领域模型的统一，观测性数据收集的统一，观测性数据输出的统一。这些统一性主要体现在API规范，SDK实现规范，接口规范等。OpenTelemetry不会负责观测数据的存储，需要存储这些观测数据的backend。OpenTelemetry定义数据输出的规范，由各大厂商自行完成数据的持久化。7.1.3数据存储
采集到的数据需要进行一定的处理并进行存储保存，为下一步的数据应用和展示提供数据基础。
一般场景日志数据和链路追踪数据存储推荐使用ElasticSearch，在大规模日志采集场景下可以添加Kafka作为缓冲。对需要进行大数据分析等场景时，也可以选择HDFS/HBase存储。对于指标数据推荐使用Prometheus存储（Prometheus本身也实现了TSDB数据库），但是原生的TSDB对于大数据量的保存及查询支持不太友好，该数据库不能保证可靠性，且无法支持Prometheus集群架构。而Thanos和Cortex都是在数据可靠性和集群高可用方面进行了优化增强，目前都是CNCF孵化中的项目，也是不错的选择。在大规模场景下还可以选择openTSDB或Clickhouse来进行指标数据存储。7.1.4应用与展示层应用与展示层是可观测性的最上层，是对采集数据的基础应用，也是当前企业主要的应用场景。图表展示是可观测性面向用户最为直观的呈现，将复杂的数据以图或表形式展示出来，便于运维人员快速了解应用状态，基于经验做出判断或预测。对于日志数据和链路追踪数据的查看可以通过Kibana查看，对于指标数据推荐使用Grafana进行展示，也可以使用原生的Prometheus、Thanos或Cortex查看。服务拓扑是通过数据流向和调用关系，以UI的方式将服务依赖关系拓扑呈现出来。实际业务中，应用之间的关联与依赖非常复杂，需要通过全局视角检查具体的局部异常。可以在服务拓扑查看应用在指定时间内的调用及其性能状况。监控告警是最常用的场景，也是目前建设可观测系统的核心目标。监控告警通过事前配置好阈值，数据采集上来后通过计算与阈值比对，对于不符合规则要求的数据生成告警事件，通过告警渠道发送到目标设备，如邮箱、手机、企业IM等。推荐使用Prometheus生态中的Alertmanager进行告警通知，它能够满足大多数企业的告警需求。对于可观测性数据的初级应用除以上几项外，有些企业还会尝试尽可能多的将三者的数据进行关联，使同一个应用不同维度的事件立体化的展示出来。如请求发生异常时，应用一般会将请求以日志的方式输出，调用链路也会上报调用异常，这两类数据可以通过RquestID或TraceID进行关联。
7.2AIOPS阶段
将可观测性阶段成果+智能化层定义为AIOPS要建设的内容。AIOPS是将人工智能和大数据应用于运维的场景，辅助运维实现自动化、智能化，以达到无人值守亦能保证业务服务高效稳定运行的目的。AIOPS辅助运维的场景大致可以分为三大类：智能分析、智能决策和智能展示。
页:
[1]