可观测性一词诞生于几十年前的控制理论。近年来，随着企业以微服务、⽆服务器和容器技术的形式迅速采⽤了AWS、阿里云等云原⽣基础设施服务。在这些分布式系统中追踪事件的起源需要在云上、本地或两者上运⾏的数千个进程。传统的监控技术和⼯具就很难跟踪这些分布式架构中的许多通信路径和相互依赖关系。更别提排查问题并定位根本原因了。
监控技术和工具革新迫在眉睫。
而可观测性一词近两年火起来的导火索是 CNCF 在云原生定义中提到 Observerbility，并声称这是云原生时代的必备能力。
于是从生产所需到概念发声，加之包括谷歌在内的众多大厂一拥而上，“可观测性”正式出道。
可观测性的定义
Observability是来自控制论的一个概念：
In control theory, observability is a measure for how well internal states of a system can be inferred by knowledge of its external outputs. The observability and controllability of a system are mathematical duals. The concept ofobservability was introduced by American-Hungarian scientist Rudolf E. Kalmanfor linear dynamic systems.
官方话语，感兴趣的读者可以自行翻译。
用相对严谨的话来说，可观测性指的是一种能力--是通过检查其输出来衡量系统内部状态的能⼒。这些输出体现内部系统状态的能力越强，可观测性也就越好。
简单来看，如果仅使⽤来⾃输出的信息（即传感器数据）可以估计当前状态，则系统被认为是“可观测的”。
可观测性的价值
谷歌给出可观测性的核心价值很简单：快速排障（troubleshooting）。
这个世界上没有不存在 Bug 的系统，而随着系统越来越精细，越来越复杂，越来越动态，越来越庞大，潜藏的问题和风险也就越来越多。
因此，任何一个软件的成功，不仅仅要依靠软件架构的合理设计，软件开发的代码质量，更要依靠软件系统的运行维护。而运行维护的基础，就是可观测性。
从银行的交易系统，互联网公司的业务平台，到运营商的云化核心网等运行在云上的各类软件系统，每时每刻都处在一定的风险之中。而保证这些系统能够风险可控，稳定运行，需要做的就是提前发现异常，快速定位根本原因，迅速排除或者规避故障。
因此，在 CNCF 对于云原生的定义中，已经明确将可观测性列为一项必备要素。
可观测性的三大支柱
业界对可观测性的共识，基于可观测性的三大支柱“metrics、logs、traces”。
1、logs（日志）
⽇志是在特定时间发⽣的事件的⽂本记录，包括说明事件发⽣时间的时间戳和提供上下⽂的有效负载。⽇志有三种格式：纯⽂本、结构化和⼆进制。纯⽂本是最常⻅的，但结构化⽇志⸺包括额外的数据和元数据并且更容易查询⸺正变得越来越流⾏。当系统出现问题时，⽇志通常也是您⾸先查看的地⽅。
2、metrics（指标）
指标是在⼀段时间内测量的数值，包括特定属性，例如时间戳、名称、KPI 和值。与⽇志不同，指标在默认情况下是结构化的，这使得查询和优化存储变得更加容易，让您能够将它们保留更⻓时间。
3、traces（跟踪）
跟踪表示请求通过分布式系统的端到端旅程。当请求通过主机系统时， 对其执⾏的每个操作（称为“跨度”）都使⽤与执⾏该操作的微服务相关的重要数据进⾏编码。通过查看跟踪，每个跟踪都包含⼀个或多个跨度，您可以通过分布式系统跟踪其进程并确定瓶颈或故障的原因。
从一个简单的“系统探查--日志搜集--日志统计”流程来看：三者之间的关系从 traces 开始，通过探查等手段采集众多信息，形成logs，logs详细记录了各种边界行为（如登陆，开启服务，关闭服务，退出系统，修改数据），而对于系统运行来说，更重要的是 特定事件发生的次数。这些信息可以从日志中提取，但是有一种更有效的方法：metrics。
至此，如果你的 metrics 与告警相关联，则可在系统关键节点设置阈值。如果指标超过了阈值，随叫随到的人员就会收到Slack或微软团队中的电子邮件、短信或消息。快速响应排出故障。
总结
可观测性简单来说就是通过检查其输出来衡量系统内部状态的能⼒。这些输出体现内部系统状态的能力越强，可观测性也就越好。
其价值在于快速排障（troubleshooting）。
当下，业界对可观测性的共识，基于三大支柱“metrics、logs、traces”。
那么，要构建一个优秀的可观测系统，仅有 metrics、logs、traces 是不是就够用了呢？我们下期再接着聊。
