什么是可观测性
可观测性（Observability）是来自自动控制领域的一个术语。最初，它与可控制性（Controllability）一起，是由匈牙利数学家Rudolf E.Kalman针对线性动态控制系统提出的一组对偶属性，原本的含义是“可以由其外部输出，来推断其内部状态的程度”。
系统的可观测性越强，我们对系统的可控制性就越强。换句话说，可观测性是指仅通过复杂系统度量信息的输出就可了解其内部状态，而不必拆开系统才能暴露其内部状态。
Gartner将可观测性定义为软件和系统的一种特征，它允许管理员收集有关系统的外部和内部状态数据，以便他们回答有关行为的问题。然后，I&O、DevOps、SRE、Support等团队可以利用这些数据来调查异常情况，参与可观测性驱动的开发，并提高系统性能和正常运行时间。Gartner预测，预计2024年，30%的基于云架构的公司将采用可观测性技术。
IT领域的可观测性发展
虽然可观测性是从控制理论中借用的舶来概念，但其内容实际在IT领域中已有多年的实践积累。2017年的分布式追踪峰会（2017 Distributed Tracing Summit）结束后，德国工程师 Peter Bourgon 于当年2月在他篇著名的博文《Metrics, Tracing, and Logging》系统性的阐述了可观测性及三类观测数据的定义、特征以及他们之间的关系与差异，该文章（查看原文）被翻译为很多语言，影响很广，受到业界的广泛认可。
2017年 Pivotal 公司的 Matt Stine在接受InfoQ采访时（查看原文）对云原生定义做了修订，将原生架构定义为具有如下六大特质：模块化(Modularity) 、可观测性(Observability)、可部署性(Deployability)、可测试性(Testability)、可处理性(Disposability)以及可替换性(Replaceability)，明确了可观测性是云原生架构的标准特性。
2018年Oreilly出版了一本由Cindy Sridharan编写的《Distributed Systems Observability》电子书，该书系统性性的阐述了分布式系统的可观测性。
2018年CNCF将观测性概念正式引入了云原生领域，称其是云原生时代最重要的系统能力。自此，“可观测性“逐渐取代“监控”，成为了云原生技术领域最热门话题之一。
为推进业界可观测性技术理念的普及、填补可观测性理论与实践的鸿沟，在2021年开始，由中国信通院陆续了《可观测平台技术要求标准》、《可观测性技术发展白皮书》等，并对业界可观测性建设做出了深刻的剖析。
为什么需要可观测性
管理学大师彼得德鲁克有句名言“If you can’t measure it, you can’t manage it”（“如果你无法度量它，就无法管理它”）。要想有效管理，就难以绕开度量的问题。
从IT管理角度来看，这句话也同样适用。云原生时代，进行数字化转型的企业正在迅速采用现代开发实践——敏捷开发、持续集成和持续部署(CI/CD)、DevOps、多种编程语言以及云原生技术，如微服务、Docker容器、Kubernetes和无服务器技术。应用软件的部署更灵活，易于扩展和管理，大大加快了业务开发和上线的周期和效率，组织正在以前所未有的速度将更多应用软件软件推向市场。
然而任何事物都具有两面性，云原生架构下的分布式应用的管理和运维也面临新的问题。系统复杂度提升，系统之间的访问越来越复杂，服务的调用用传统的点对点和点对多点演变成网状，使用传统的监控技术和手段很难跟踪这些分布式架构中的数据流、调用链和相互依赖关系。 另一方面，从软件应用系统的全生命周期来看，系统的设计、构建、测试、部署、操作、监控、维护和发展都遵循着以下几点事实：
- 复杂系统没有一个是完全健康的
- 分布式系统从根本上是不可预测的
- 全部预测出系统的各个部分可能会出现的故障状态是不可能的
- 系统需要面向失败而设计，从系统的设计到实现、测试、部署最后到操作，每个阶段都要考虑到失败
- 易于调试是一个稳固的系统维护和发展的基石
对于这样一个复杂系统，可观测性在系统设计时就需要作为一种必备的特性纳入系统，以便有效的帮助运维团队实现对复杂系统的监测和控制，协助团队有效的从纷繁复杂的原始监控数据中找到问题主线路，追溯到故障原因，进行有效的根因分析。
因此，我们需要可观测性在系统运行的同时收集并分析系统内部运行的状态信息进行有效度量，尽可能保障应用系统的可靠性、稳定性。借用谷歌给出的可观测性的核心价值：快速排障（Troubleshooting）。
如何实现可观测性
实现可观测性的核心就是分布式应用系统可被度量，提供关于无法被监控或者测试的不可预测的故障和异常的信息，对系统实现深入可见性，快速准确地定位性能问题的其根本原因，以便更快且自动化地识别和解决问题。
CNCF将可观测性分解为三个具体的方向，分别是指标（Metric）、日志（Log）、追踪（Trace），也被称为可观测领域的三大支柱。采集三大支柱观测数据，结合CMDB、Profile等辅助数据进行融合关联分析，并辅助故障诊断定位排障，可以实现一个较为完备的的可观测性平台。
日志
日志记录了特定时间（带有时间戳）发生的各种离散事件的信息，用于检测系统中无法预知的行为。
日志通常有三种形式，Plaintext(明文)，Structured(结构化)和Binary(二进制)。但它们本质是相同的，都是时间戳和某些上下文的有效负载的组合。
-
Plaintext(明文)是指日志记录可以是任意格式的文本，也是最常见的日志格式
-
Structured(结构化)日志近几年被广泛使用，通常这种日志是JSON格式
-
Binary(二进制)日志始终采取二进制格式存储，而不是纯文本格式，例如用于复制和时间点回复的MySQL binlogs，systemd journal日志等等。
指标
指标是根据随时间变化的数据，是在⼀段时间内测量的数值。与⽇志不同，指标在默认情况下是结构化的，对存储，处理，压缩和检索进行了优化，指标能够更长地保存数据，也更容易进行查询。
追踪
跟踪可以帮助我们直观地看到请求(request)或操作在通过分布式系统的所有节点时的整个过程。因此，这里的跟踪实际上是分布式跟踪(Distributed Tracing)。
跟踪本质上是一种日志，它的数据结构和日志的数据结构非常相似。但相比日志，跟踪可以提供对请求所经过的路径和请求的结构的可见性。这可以帮助我们衡量整体系统运行状况，找到系统性能瓶颈或者故障。
综上，检测是依据是Metric，排障的依据Trace，分析的依据是Log，三大支柱密不可分。从发现指标异常，到指标关联分析，从逐层下钻到明细trace追踪和具体的错误日志，进而实现全链路自动化根因定位。
可观测性与监控的关系
可观测性经常被错误地描述为一个过度炒作的流行语，或者是一般系统监控，特别是应用程序性能监控 (APM) 的“品牌重塑”，新瓶装旧酒等。实际上，可观测性和监控是两个不同的概念，两者的目标也不同。
首先，可观测性和监控可以相互补充，可观测性是监控的超集和延展。监控是推动可观测性的一个过程，但可观测性不仅仅是监控。
其次，监控的目标是监控可预测的故障和异常并生成警报。而可观测性的目标则是提供关于无法被监控或者被测试的不可预测的故障和异常的信息，可观测性不仅提供了系统健康状况的高级概述，还提供了对系统内部不可预测的故障高粒度的洞察。
此外，一个可观测系统提供了关于其内部工作的上下文信息来实现主动学习，从而发现更深层次的系统性问题。
关于监控和可观测的区别，简单小结一下：
- 监控是观测的子集
- 一个系统只有在可观测的情况下才能被监控
- 监控围绕的是已知可预见的故障，而观测可以发现是未知的故障
比较通俗的说法就是：
“监控告诉我们系统哪些部分是工作的，可观测性告诉我们那里为什么不工作了。”
可观测性与AIOps的关系
AIOps（Artificial Intelligence for IT Operations），即智能运维。AIOps将人工智能应用于运维领域，基于已有的运维观测数据（指标、日志、链路）等运维大数据，通过机器学习的方式来进一步解决自动化运维没办法解决的问题。AIOps通过预防预测、个性化和动态分析，直接和简介增强IT业务的相关技术能力，实现产品和服务的更高质量、合理成本及高效支撑。
从落地来说，具备可观测性是实施AIOps的基础必要条件。基于可观测性提供全面、高质量的观测运维数据（不限于Metric、Trace、Log等三大支柱数据）供AIOps平台进行分析利用，落地异常监测、根因分析、告警收敛、故障自愈、容量预测、态势感知等诸多智能化运维场景。
同时，AIOps承诺了更强的可观测性和稳定性，贯穿了整个可观测环节和过程，是业务应用实现全面可观测性、智能观测的更高阶段能力的直接体现。