1.1 可观测系统的演进
可观测性是一种强大的能力，能够通过数据分析以明确的结果指导企业和团队做出正确的战略决策。如果能够在战略中予以规划并成功执行，那么可观测性应用将成为数据驱动型决策强有力的支撑。
最近几年，可观测性的热度开始飙升，那么，可观测系统是如何发展成现在的形态的呢？因为可观测系统的演进与系统架构的演进息息相关，所以本节首先分析系统架构的演进，然后介绍可观测性和监控的关系，最后介绍可观测性技术的现状。
1.1.1 系统架构的演进
众所周知，计算机从诞生到现在还不到100年，但在此期间，硬件技术和软件技术都发生了多次重大变革。计算机和互联网的诞生深深地影响了整个世界的发展。
1946年，第一台通用计算机ENIAC在美国宾夕法尼亚大学诞生，如图1-1所示。这台计算机最初是为了处理弹道计算中的微积分问题而被设计的。计算机一开始是为了科研和计算而被创造的，不但体形巨大，而且价格昂贵。
图1-1
1971年，Intel公司成功研制出第一台能够实际工作的微处理器4004（见图1-2），并于同年对外公布，这标志着计算机正式进入微处理器时代。微处理器的诞生直接使计算机开始进入个人家庭。
图1-2
如今很多机构正在研究量子计算机，并且取得了一些不错的成果。例如，中国科学技术大学潘建伟研究团队，和中国科学院上海微系统与信息技术研究所、国家并行计算机工程技术研究中心合作，成功研制出量子计算原型机“九章”，其处理特定问题的速度比目前最快的超级计算机快100万亿倍。
虽然整个计算机的发展历史还不到100年，但半导体行业大致按照摩尔定律快速发展了半个多世纪，因此计算机的算力也得到了快速提升。
随着硬件技术的不断革新和快速发展，尤其是计算机进入个人家庭以后，计算机的民用软件和应用就开始飞速发展，与此同时，软件和应用的系统架构也在不断演进与发展。
本节涉及的架构指的是软件架构，也就是软件系统的基础结构。软件系统的基础结构规定了如何划分系统中的组件，各个组件如何运行，以及组件与组件之间如何沟通和协作。
系统架构的发展过程通常被定义为4个阶段，分别为单体架构阶段、垂直架构阶段、SOA架构阶段和微服务架构阶段。但其实在20世纪70—80年代，为了弥补单台计算机算力的不足，人们就已经开始对分布式架构进行探索，但由于硬件发展的限制，最终并没有真正实现分布式架构。本节仅对单体架构和微服务架构进行对比，如果读者对垂直架构和SOA架构感兴趣，请自行查阅软件架构的相关资料。
单体架构是最简单的一种软件架构。其实，单体架构是在微服务架构被提出之后才出现的一个相对的概念。目前，许多软件在最初也是用单体架构完成的，之后随着业务的发展才逐渐演变成复杂的微服务架构。单体架构虽然是最早的架构形态，但其开发方便快捷、部署简单、不存在远程调用的性能问题和一致性问题，至今仍广泛应用于小型系统的设计中。因此，单体架构并不是一种被淘汰的架构方案。尤其是在项目启动初期，当业务体量极小时，因为单体架构简单灵活，所以可以促使项目更快地迭代发展。
以电商系统为例，单体架构的架构图如图1-3所示。单体架构将所有的系统都放在一个项目中，并且部署在同一Web服务器上，同时将所有应用的数据库放到一个数据库服务上，甚至可能放在一个数据库的不同表中。
单体架构的缺点是不易扩展，项目的代码都在一个代码仓库中，开发人员提交代码时容易产生冲突，系统在迭代部署时难度极大，每次都需要重新部署所有功能，容易出现因为一个功能问题导致整个系统发生故障而不可用的情况。
图1-3
微服务的概念早在2005年就已经被提出。最初的微服务是指一种专注于单一职责、与语言无关的、细粒度的Web服务。微服务架构的快速发展和应用始于2015年前后，由于硬件设备、互联网、云计算等高速发展和不断革新，软件系统需要应对的场景越来越复杂，单体架构已经无法满足系统的需求（系统朝着越来越庞大、越来越复杂的方向发展），因此微服务架构就成为首选。
微服务架构通过多个小型服务组合来构建单个应用的架构。这些服务是围绕业务能力而非特定的技术标准来构建的，不仅可以采用不同的编程语言、不同的数据存储技术，还可以运行在不同的进程之中。
自Spring Cloud诞生以来，微服务框架呈爆发式增长，这些框架为开发人员提供了快速构建微服务系统的工具，并且基本涵盖了微服务架构所需的全部组件，包括服务发现、配置管理、熔断限流和服务监控等。微服务架构在2018年之后几乎成了系统架构的标准。
以电商系统为例，微服务架构的架构图如图1-4所示。微服务架构将不同的业务拆分为不同的服务。通过将微服务架构和单体架构进行对比可以发现，微服务架构具有组件化、松耦合、自治和去中心化等特点。
微服务架构的特点使其具有如下优点，这些优点使微服务架构非常契合大型系统。
（1）易于扩容
服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。微服务架构的优点是，不仅可以使其中的每个服务专注于自身领域的业务，还可以轻松地根据自身业务特点来配置运行环境，并根据实际情况对不同的服务进行弹性伸缩。
图1-4
（2）服务间松耦合、高容错
由于微服务架构中的服务之间具有松耦合和高容错性，因此一个服务的异常不会导致系统的其他服务不可用。由于每个服务都是独立的，可以单独发布，因此提高了发布效率并且缩小了发布影响范围。每个服务都有单独的代码仓库，一个服务不会有过多的维护人员，这样可以减少开发过程中发生代码冲突的次数。
（3）提高开发效率
微服务架构中的服务都是小型的单个服务，可以根据服务特性选择最合适的技术来开发。开发人员可以通过快速在自身的服务上应用新技术来适应发展的需求。由于每个服务都是以业务为中心的，能够快速响应业务的变化，以及快速实现不同的业务场景，因此可以降低业务试错的成本。
虽然引入微服务架构具有诸多优点，但也存在如下几个问题。
（1）数据一致性问题
服务调用的网络业务系统被拆分成多个服务，服务之间的调用本身就会有额外的网络开销和延迟。如果一项功能涉及多个服务之间的数据提交结果，就会存在事务问题。尤其是电商、银行等需要强一致性的业务场景会涉及整个系统的数据一致性问题。
（2）集群维护问题
微服务架构中除了有庞大的业务节点集群，还有服务发现、配置管理、熔断限流和服务监控等额外的服务组件。整个集群中可能有成百上千个节点，这会导致系统复杂度陡然增加，维护成本也会随之增加。
（3）跨团队沟通问题
由于不同的服务是由不同的团队开发的，这些团队对其他团队开发的模块并不熟悉，业务边界划分也不够清晰，因此会产生额外的合作协调成本。
总体来说，虽然单体架构和微服务架构有各自适用的应用场景，但是受业务复杂度和业务体量的影响，微服务架构已成为众多系统的首选。尤其是当下，微服务已被列为云原生时代的代表技术之一，因此，微服务架构会得到更广泛的应用。
1.1.2 可观测性和监控的关系
1.1.1节介绍了系统架构从单体架构到微服务架构的演变。随着系统架构的变化，在云原生技术的推广和普及下，传统监控已经无法满足需求，可观测性逐渐成为系统建设过程中必不可少的工具。本节主要介绍监控系统的发展历程，以及传统监控和可观测性之间的区别。
在计算机发展过程中，监控系统也一直在发展。当代计算机的发展经历了单机计算机时代、局域网时代、早期互联网时代、移动互联网时代和云原生时代5个阶段，不同阶段对监控系统的要求有所不同，监控系统在这5个阶段呈现出不同的特性。
（1）单机计算机时代
由于单机计算机时代没有网络，因此系统都是单机运行的。当时计算机的存储空间小且性能很低，各个软件的功能也比较单一。
在这种场景下，监控一台计算机就等于监控了整个系统，所以系统中提供了很多监控工具，用来观测计算机资源和应用的运行情况。例如，Windows系统中的资源管理器、macOS系统中的活动监视器等，以及Linux系统中的top命令和ps命令等，都可以用来观测系统当前的运行情况和某个程序的运行情况。在单机计算机时代，这些监控工具已经足以满足需求。在Linux系统中使用top命令显示的监控页面如图1-5所示。
图1-5
（2）局域网时代
由于出现了局域网，因此随之出现了服务器的概念和“客户端-服务端”架构。客户端可以通过数据交互使用服务端提供的系统，客户端和服务端之间的协作随之出现。为了降低单台服务器面临的压力，通常将多台服务器通过网络设备串联起来，由多台服务器共同为客户端提供服务。
这时就需要管理人员同时对多台服务器进行管理。如果继续使用单机监控工具，则管理人员必须分别登录每台服务器才能进行监控管理，这种模式的效率很低，所以就出现了网络监控工具，如MTRG。网络监控工具通过对局域网内部所有服务器的网络情况进行监控来获取所有服务器的健康状态，管理人员可以通过查看网络监控工具来了解局域网中所有服务器的情况。
（3）早期互联网时代
早期互联网时代的用户通过浏览器访问网页以访问服务器上的资源。在这个阶段，虽然出现了互联网，但是互联网技术还极为简单，个人只能通过网页来访问服务器提供的系统，因此出现了“浏览器-服务器”架构。
在早期互联网时代，由于互联网技术的兴起和个人计算机的普及，同时电信运营商提供了一种全新的叫作互联网数据中心的接入技术，因此越来越多的企业或个人以浏览器为窗口通过互联网向全世界提供服务。这个阶段的系统及相关的软件架构开始变得越来越复杂。
此时对于监控来说，以前局域网中的单机监控工具已经无法满足需求，因此出现了以Zabbix为代表的新一代监控工具。新一代监控工具具有跨平台的特性，可以在多个平台上使用，不仅可以将系统中的数据收集起来使其通过浏览器页面被查看，还支持针对其中的某些监控指标设置阈值并发出告警。这些工具侧重于对服务器的网络和硬件进行监控，时至今日还有一定的用户群体。
（4）移动互联网时代
在移动互联网时代，由于iOS系统和Android系统的推出，移动设备迅速在全世界范围内普及。此时连接网络的移动设备开始快速增加，访问服务器提供的服务的客户端也从网页扩展为多种媒介。在硬件设备产生了巨大变革，尤其是海量移动设备加入互联网的情况下，服务器的访问量大幅度提升。同时，由于无线通信技术的发展，设备访问速度越来越快，对系统的性能要求也越来越高。
在移动互联网时代，VMware公司推出的虚拟化技术和Amazon公司推出的互联网托管服务为整个互联网行业带来了巨大的变革。
VMware公司推出的虚拟化技术核心原理是将一台物理服务器分割成多台虚拟机，这样不仅能提高服务器的利用率，还便于高效地管理海量的服务器。
而Amazon公司推出的互联网托管服务，最初是利用闲置的服务器提供网站托管服务的，现在，Amazon公司已经成为市场占有率最高的云厂商，因此大量的中小型企业将服务托管到云上，云技术得到了空前的发展。
在移动互联网时代，庞大的用户意味着庞大的数据量，也意味着背后具有庞大的服务器集群。这意味着监控工具面临着巨大的挑战，不能仅用来监控服务器的硬件和网络，还需要对应用本身的指标进行监控，以及对系统中的服务调用进行追踪。这时出现了APM（Application Performance Monitor，应用性能监控）。APM的目的是通过数据采集的方式将系统指标、调用情况统一收集起来，用于系统发生故障时排查问题和指导提升应用性能。此时出现了各种各样的工具，如Zipkin、Jaeger、SkyWalking等链路追踪系统，以及ELK等日志系统。ELK日志系统如图1-6所示，Zipkin链路追踪系统如图1-7所示。
图1-6
图1-7
（5）云原生时代
云原生计算基金会（Cloud Native Computing Foundation，CNCF）成立于2015年，致力于云原生系统的推广和普及，是Linux基金会下最大的开源子基金会，也是目前最受关注且发展最快的基金会之一。当前CNCF的官方项目已经超过了100个，成为最活跃的社区。图1-8所示是CNCF官网上的云原生全景图（读者可以通过CNCF官网查阅具体内容）。国际数据公司的报告显示，截至2023年，企业云原生系统占比将超过80%，可以认为当前已经步入云原生时代。云原生架构已成为应用部署的主流架构，应用系统已从传统的自建机房迁移到云上，并且在云上以容器的方式运行业务服务。
图1-8
云原生架构能够尽可能剥离云应用中的非业务代码，聚焦功能性业务，从而打造敏捷、智能的云计算服务。从本质上来说，云原生架构也是一种软件架构，其核心特性是运行于云环境之中，对微服务进行延伸。从整体上来看，云原生架构不仅能够对云计算服务与互联网架构进行一体化升级，还可以助力企业快速迭代升级业务，并强化对不同量级流量的承载能力。
云原生的4个关键技术要素是微服务、容器化、持续交付和DevOps。
• 微服务：在微服务架构中，服务被拆分成成百上千个微服务，包含上万个实例，本来系统部署在一台机器上，现在则被分布式部署在上万台机器上。
• 容器化：容器技术使服务部署更加方便、快捷。Docker技术使用户可以标准化地自由组装环境，从而实现真正的“一次打包，随处运行”；Kubernetes技术则解决了容器编排的问题，使运维人员能够轻松编排和管理海量容器的生命周期。
• 持续交付：持续交付意味着随时可以将一个版本发布到生产环境中，从而实现快速迭代。
• DevOps：DevOps强调组织团队之间通过自动化工具来协同完成软件的生命周期管理，从而更快、更稳定地交付版本。
基于云原生时代的特点，传统的监控工具已经无法满足需求。传统的监控工具彼此之间的数据是割裂的，不同监控工具之间的数据无法联动产生“1+1>2”的效果。业务监控和基础设施监控之间也无法统一，当遇到一些边界问题涉及跨团队协作时，需要人工介入比对数据，将不同监控工具的数据进行关联。在这种场景下，虽然不同的数据都有各自的监控工具，但是没有全局的视角，无法了解系统整体的运行情况，也就无法快速、准确地了解当前系统的问题和可能存在的风险。这个时候出现了云原生时代的可观测系统，可观测系统从全局的视角进行观测，能够对系统中存在的异常进行全局的数据支撑和风险预测。
综上可知，由传统的监控工具转变为可观测系统，主要发生了如下几点变化。
• 系统关注的内容发生了变化：传统的监控工具通过监控系统的使用情况来观测系统中正在发生什么；可观测系统则通过系统整体的可观测性数据来了解系统中正在发生什么，以及为什么会发生。
• 团队成员的职责发生了变化：传统的监控工具主要由运维人员负责和关注，开发人员、测试人员通常不会关注；转变为可观测系统之后，开发人员、测试人员和运维人员要协调工作，共同建设统一的可观测系统，提升系统的服务质量。
• 观测数据的模型发生了变化：传统的监控工具采用分层模型，如图1-9所示。不同层的数据采用不同的监控系统，数据之间没有串联起来，如云和基础设施层的网络监控展现当前网络的状态、流量的情况，单从网络监控无法和业务流量进行关联。由于不同的观测数据分布在不同的系统中，因此当出现问题时需要同时使用多个系统来排除故障。可观测系统统一设计数据模型，并且将所有数据上报到一个系统中，使不同的数据之间能够相互关联，如图1-10所示。如果采用统一的数据模型将所有数据都放在一个系统中，就能通过关联关系对所有数据进行深度分析，从而使可观测系统更加高效和自动化。
图1-9
图1-10
传统的监控工具更多的是指运维自动化工具，主要用途是代替人工自动监控系统的运行情况，在系统产生异常时发出告警，最终指导分析异常，以及进行故障诊断和根因分析。
可观测系统包含传统监控工具的能力，更多面向业务，同时强调将业务全过程透明化的理念，实现全景监控、智能运维和自修复等体系化的服务能力。可观测性最重要的能力是通过系统数据分析反映系统内部的状态，及时暴露系统风险，而传统监控系统仅仅对某些特定指标进行数据抓取并通过图标等呈现。
通过学习本节，读者可以了解到可观测系统的本质，即在传统监控工具的基础上进行统一的整合，并对观测的内容进行更深、更广的突破，尤其是对可观测性数据在海量数据下进行分析。
1.1.3 可观测性技术的现状
在Gartner公司发布的2021年基础设施和运维自动化技术成熟度周期表中，可观测性被置于膨胀期顶端（读者可以在Gartner公司的官网中查询详细的报告）。Gartner公司将可观测性定义为软件和系统的一种特性，允许管理人员采集有关系统的外部和内部状态数据，以便回答有关系统行为的问题。其他相关团队也可以利用这些数据来调查异常情况，参与可观测性组件的开发，提高系统性能和正常运行时间。Gartner公司预测，到2024年，30%的基于云架构的公司将使用可观测性技术。
当前，可观测性已经成为最重要的战略技术之一。下面介绍可观测性的起源和可观测性技术的发展历程。
可观测性和可控制性（Controllability）是由Rudolf E.Kálmán针对线性动态控制系统提出的一组对偶属性，原本的含义是“可以通过其外部输出判断其内部运行状态的精确程度”。
可观测性最早应用于电气工程领域。在控制论中，可观测性是衡量一个系统仅凭其外部输出来判断其内部运行状态的精确程度的指标。在互联网领域中，可观测性只是系统的一个属性。由于互联网技术近年来的发展速度非常快，系统的复杂度极速上升，尤其是分布式和云原生技术的普及和应用，因此，传统的监控工具逐渐演变为现在的可观测系统。
可观测性技术的发展历程可以概括为3个阶段，分别为感知系统状态、追踪问题位置和定位问题根因。
（1）阶段一：感知系统状态
在感知系统状态阶段，SRE（Site Reliability Engineering，网站可靠性工程）为用户提供了可靠且实用的方法论和实践经验。SRE最初是由Google提出的，通过Site Reliability Engineering：How Google Runs Production Systems（《SRE：Google运维解密》）被广泛传播。
SRE中有3个核心概念，分别为服务质量指标（Service Level Indicator，SLI）、服务质量目标（Service Level Objective，SLO）和服务质量协议（Service Level Agreement，SLA）。
• 服务质量指标：并不需要选择所有的指标，而是要选择合适的指标作为服务质量指标。通过服务质量指标可以感知系统当前的状态。
• 服务质量目标：在复杂的分布式系统下，当出现问题时往往会同时触发很多告警，无法立刻感知关键信息，因此需要分层设置服务质量目标，并且随着业务和系统的变化，服务质量目标也会变化。
• 服务质量协议：指的是全局协议，包含服务质量指标、服务质量目标，以及达到或没有达到服务质量目标时的结果。服务质量协议更靠近商务层面或产品设计层面。
通过合理地制定服务质量指标和服务质量目标，监控系统能提供有效的故障告警和风险预警。
在SRE运维体系中，Mikey金字塔如图1-11所示。由Mikey金字塔可知，一个成熟的SRE系统已经具备了部分可观测系统的基础能力。在SRE系统中，可以通过监控数据、事故响应，来提供一定的自动恢复能力、故障诊断分析能力，以支撑事后回顾、测试与发布、容量规划等功能。
图1-11
在SRE系统中，一个监控系统的输出应该只有3类，分别为紧急警报、工单和日志。由输出的定义可以看出传统监控工具的局限性，即只能感知系统的状态，需要人工介入来处理问题。
（2）阶段二：追踪问题位置
追踪问题位置阶段的核心技术就是链路追踪，只有实现了全链路追踪，才能对每个数据在系统中的流向进行还原。当前的大多数链路追踪系统都受到了2010年Google发表的论文Dapper，aLarge-Scale Distributed Systems Tracing Infrastructure的影响。
近几年链路追踪技术在社区百花齐放：在应用层面有Zipkin、SkyWalking和Jaeger等优秀且成熟的框架，可以用来实现业务应用的可观测性；在内核层面，eBPF技术快速发展，通过在内核埋点可以实现内核的可观测性。2019年，OpenTelemetry成为CNCF的孵化项目，并一举成为当前可观测领域非常热门的项目。该项目旨在提供可观测领域的标准化采集方案。
链路系统中组件覆盖的完整性能够让用户在仅依赖采集数据的情况下快速定位问题发生的位置，从而快速进行系统恢复和根因分析。
（3）阶段三：定位问题根因
定位问题根因是当前可观测性技术发展的第三个阶段。2017年的分布式追踪峰会之后，Peter Bourgon撰写的Metrics，Tracing，and Logging系统地阐述了指标数据、链路数据和日志数据的定义、特征，以及它们之间的关系与差异，受到了业界的广泛认可。在此之后，传统系统开始逐步向可观测系统转变，将原本割裂的指标数据、链路数据和日志数据进行关联，通过对关联的数据进行分析来快速定位问题根因。
可观测性数据具有关联性和连贯性，而传统的监控工具是垂直分层的，所以无法对数据进行关联和自动化分析。
传统的监控数据包括服务指标数据（如服务的请求量、请求耗时）、服务间的链路数据（如服务调用的链路）和日志数据（仅业务服务的日志数据）。但这些数据远远不够，可观测系统还需要采集云和基础设施的数据、系统和容器的数据、事件数据、业务数据，并将这些数据整合成指标、链路、日志，然后进行分析，如图1-12所示。
图1-12
只有将格式统一的标准数据上报到可观测系统中，系统才能对数据进行统一的分析。另外，还需要结合对业务架构的理解设置不同数据所属的业务特性，这样才能最大限度地发挥可观测系统的价值。
目前处于云原生时代，云原生带来的不仅仅是可以将应用部署到云上，可以说其定义了一套新的IT系统架构升级版本，包括开发模式、系统架构、部署模式、基础设施全套的演进和迭代。
如果没有有效的可观测性解决方案，就意味着无法深入了解业务系统、应用程序、中间件与基础设施的运行状态和过程。因此，可观测性是进行系统故障分析和保证系统稳定性的重要依据，也是推进业务连续性建设的基石。
2018年，在CNCF的云原生全景图中率先出现了可观测性的分组，自此，可观测性被正式引入IT领域。云原生全景图是CNCF的一个重要项目，旨在为云原生应用开发者提供资源地图，帮助企业和开发人员快速了解云原生体系的全貌。CNCF对云原生的定义中已经明确将可观测性列为一项必备要素。自此以后，可观测性逐渐取代监控，成为云原生技术领域最热门的技术之一。
图1-13所示是云原生全景图中关于可观测性的部分。综上可知，社区已经有了相当多的探索成果。
图1-13
图1-13（续）
除此之外，Elastic Stack推出了Elastic Observability，用来提供基于Elasticsearch的统一的可观测性解决方案。而国内的云厂商阿里云于2022年6月推出了阿里云可观测性套件（Alibaba Cloud Observability Suits，ACOS），旨在打造云原生时代的可观测性解决方案。
云原生时代的可观测性是通过检查其输出来衡量系统内部状态的。如果仅使用来自输出的信息即可估计系统当前状态，那么系统被认为是可观测的。可观测性的核心其实就是度量，度量系统中的基础设施、平台、应用和业务，通过度量获得的数据来了解它们是如何运行的，最终使系统内部的状态可以被衡量和理解。
可观测性从系统内部出发，基于白盒化的思路监测系统内部的运行情况。可观测性贯穿了应用开发的整个生命周期，通过分析应用的指标、日志和链路等数据，构建完整的观测模型，从而实现故障诊断、根因分析和快速恢复。
云原生时代的可观测系统需要满足以下要求。
（1）可观测性应全面
实现系统的可观测性需要全面采集系统的数据，否则无法发现和预测问题，也无法依赖可观测性数据分析和解决问题。但是全量可观测性数据对于系统来说体量过大，特别是在传输、计算和存储时对于可观测系统来说需要承受巨大的成本和压力。对于海量的可观测性数据，需要根据具体的业务模型对数据进行压缩，以降低系统的成本和压力。
可以说，可观测性的一切功能都建立在可观测性数据上，是数据驱动的典型系统。
（2）数据模型应统一
可观测系统有了全面的数据还不行，数据模型也必须是统一的。只有数据模型是统一的，才能将不同类型的数据进行关联，实现问题的精准定位，找到问题的根本原因。例如，当系统提示错误率升高时，可以通过指标和调用链的关联或根据时间范围找到异常的调用链，同时通过调用链和日志的关系找到具体的业务日志，从而获取系统报错的原因，如图1-14所示。如果数据间存在关联关系，那么系统可以自动探测并分析问题的原因，不需要人工介入查找关联数据。
图1-14
（3）可观测系统应统一
目前，一个运维团队维护多套监控系统来完成可观测性工作的情况并不少见，如一些人维护基础设施的监控系统，一些人维护业务服务的监控系统，还有一些人维护链路追踪系统或日志系统。这样会使数据之间相互割裂，无法进行统一的数据分析。
只有将统一数据模型中的数据连接到统一的系统，才能统一进行数据处理、数据分析、数据编排和数据展示，以及最大限度地发挥可观测系统的作用和价值。
当前的可观测系统还存在以下几点不足之处。
（1）可观测性数据覆盖不全
当前的云原生系统非常复杂，需要观测的对象包括云服务器、容器Kubernetes、DevOps、云存储、庞大的微服务集群等。由于云原生系统的架构非常复杂，以及可观测性的复杂度正在不断提升，因此可观测性数据覆盖不全。
（2）不同数据之间存在关联关系
不同的数据模型会导致数据之间存在语义差别，因此实际使用时比较困难。如果无法将不同类型的数据进行关联，那么系统将无法对其进行分析。例如，在日志中如果无法关联链路数据，那么在链路报错时便无法通过日志定位业务错误的根因，也无法通过日志报错的数据找到这条错误的链路是如何传递的。
（3）计算和分析海量数据的难度比较大
全面采集会导致可观测系统需要收集海量的数据，并且需要对海量的数据进行数据分析、数据编排和数据展示，这对于可观测系统的性能来说是一个巨大的挑战。
对于可观测系统来说，如何通过分析和处理数据来精确地发现系统中隐藏的问题和潜在的风险也是一个极大的挑战。因为不仅需要依赖对业务模型的理解和分析，还需要根据可观测性数据建立统一可关联的模型。
当前开源社区中诸如OpenTelemetry类的项目致力于解决采集端统一数据模型及数据覆盖的问题。OpenTelemetry项目已经获得了大部分云厂商的支持，期望能通过一个活跃的开源项目共同建设一个覆盖全面的统一采集方案。
在可观测平台上，开源社区也拥有Grafana生态的相关组件和Elastic生态的相关组件。通过对这些组件进行组合使用，开发人员可以快速搭建一套可观测系统。
本节介绍了可观测性的起源和可观测性技术的发展历程。通过当前开源社区中的项目，开发人员可以快速搭建可观测系统，也可以使用各大云厂商提供的功能。但是，可观测性数据的分析和处理更多依赖业务的实践进行优化。