从系统监控到系统可观测性，是技术趋势，更是一种文化

关于监控和可观测性的文章也很多了，不过有些内容有待商榷。比如网上有看到说可观测性是可靠性的一部分，这理解不太对。可观测性和可靠性是两个方面，系统可不可靠和具不具备可观测性没有必然联系。可观测性不是可靠性的一部分，不过系统可靠性可以通过可观测性来展现，比如说通过运行指标等展现系统的可靠性能力。

随着系统架构的演进，单体架构逐步分解为分布式服务化、云原生架构，从而也导致系统的组件和服务越来越多，彼此间的关系越来越复杂。传统监控手段已难以满足应对复杂分布式系统研发调试和运行监控的需要。比如说，微服务架构下难以用传统监控agent 的方式进行运行数据的采集和处理，从而也驱动轻量化sidecar 方式来代理流量技术的出现和应用；但面对复杂的跨云、跨集群、跨微服务和存量系统等复杂环境时，缺乏有效的一体化手段。不是不能采集各种监控数据，而是成本和代价太过高昂。因此可观测性的思想从另外一个视角提出了新的思路。

监控及其局限

监控通常采用外部的工具或手段来监测系统的运行状况，比如通过agent 采集系统运行数据、日志等，通过定义规则和阈值范围来监测系统运行。但在复杂的分布式系统中，整个链路层级可能非常深，分支也可能很多，特别如复杂事件处理（CEP）场景中，监控手段可能捉襟见肘。但无论规则多么复杂，都是封闭式监控：只观察系统的外部行为，而不试图观察系统内部发生的事情。因此封闭式监控有自身的局限：
1、它们只能监测可预测的故障（例如，请求超时、资源使用率高）。
2 、它们只检查系统中向外变形的部分的行为。
3、它们是被动的；他们只是在问题发生后才告诉你。
4、他们可以回答“什么坏了？”但不能回答更重要的问题“为什么？”
5、为了回答“为什么？”这个问题，我们需要超越传统的监控。

可观测性

在传统的监控中，难以从系统资源数据如 CPU负载、磁盘 使用 、网络数据包等等中推断出软件 应用程序 在做什么。要做到这一点，需要对软件本身进行 监控。不过软件通常是不透明的，它必须通过暴露生成数据、日志等以便提供它正在做什么的线索。可观测系统使人们能够回答“它是怎么工作的”。

在软件应用程序的上下文中，可观测性是指在不部署任何新代码的情况下理解和解释系统状态的能力。这对于故障排除、记录业务事务、识别异常、识别业务模式、生成见解等至关重要。包括日志记录、指标、链路跟踪和服务可视化( Kasun Indrasiri, etc, Design Patterns for Cloud Native Applications, O'Reilly Media, Inc., May 2021) 。可观测性是主动暴露系统状态和逻辑的能力，和传统监控通过采集、汇总、分析指标的被动方式是不同的。（ Charity Majors, etc.，Observability Enginerring， O'Reilly Media Inc. 2022 ）

可观测性是关于理解的，理解系统做了什么以及它是如何做的。例如，如果你提交了一个代码更改，旨在将特定功能的性能提高10%，那么可观测性可以告诉你它是否有效。如果性能只上升了一点点，或者更糟，略有下降，那么你需要重新修改代码。另一方面，如果性能增长了20%，这一变化超出了你的预期，也许你需要思考为什么你的预测没有达到预期。可观察性可以帮助建立和完善心理模型，了解系统的不同部分是如何相互作用的。可观测性与数据有关。我们需要知道系统生成了什么数据、如何生成这些数据的，如何聚合和计算数据的，期望和关注什么结果，以及如何查询和显示这些结果。它和传统监控方式是不一样的，监视告诉系统是否工作，而可观察性则提示为什么它工作和不工作，同时考虑它的执行情况。监控通常是通过自动化的手段实现，自动监控是以某种程序化的方式检查系统的可用性或行为，比如监控agent ，通常是定期进行的，如果出现问题，通常会以某种自动化的方式提醒人工工程师。

可观测性是用户体验的重要部分

一个系统，无论简单系统还是复杂系统，离不开：系统资产、资源和运行状况。系统资产是系统中定义和使用的各种组件、数据等对象，资源是运行系统所需的计算、存储、网络等设施，资产和资源是系统的软硬件设施；运行状况则是系统持续运行的指标、日志、状态、调用链路、异常信息和处理等。

用户在使用系统的过程中，除了要满足自己业务的功能需求，也会对系统的可观测性有、可靠性等有需求。可观测性强则有助于对系统的理解，有助于提升对系统的信任，有助于提供用户的满意度。如果系统总是莫名其妙、难以理解，无论定义什么样的指标，都不会让用户满意的。服务有很多方式会让用户不高兴，即使它是名义上是运行着的。好的用户体验除了良好、平滑的操作，也需要良好的可理解性和可观测性。因此可以说，监控是让用户知其然，而可观测性则是让用户知其所以然，可观测性是用户体验的重要组成部分。

日志、指标和链路跟踪

日志、指标和跟踪被称为可观测性的三大技术支柱，它们同样是监控工具箱里面的技术，区别在实现的方式。监控是通过部署外部采集工具如agent 等采集日志、指标数据、链路数据等实现应用系统运行信息的可见，而可观测性则依赖于应用系统自身的能力实现系统运行信息的可见，不需要额外的工具，从而也简化了系统的架构和降低了运维复杂度。

日志

日志是记录系统或应用等运行状况、以某种格式带有时间戳的一系列信息。比如http请求日志可能包括请求的 URI 、客户端的IP地址 、请求参数等。如果应用程序运行遇到异常，则需要记录异常信息等帮助运维人员找到根因。日志通常被汇聚到日志中心，然后对日志进行分析和处理，以支持应用程序调试、业务分析、故障分析等。日志非常有用，但也有其局限性。研发人员在编写应用程序时决定记录什么或不记录什么。因此日志只能回答问题或检测可以提前预测的问题。另外，日志也不能很好地随流量扩展，日志的量也是一个不得不面对的问题，日志少则在面对异常时难以定位问题，日志量大则查询分析困难，也会对磁盘或网络产生影响，特别在云原生环境，多集群、多服务、多实例日志聚合是一个额外的工作，日志文件的大小、数量、保存时间、合规要求等都是需要认真考虑的事项。日志存储的数据越多，成本越高，也因此需要相应的日志规范和日志平台工具。

日志记录的是系统历史运行状况，其并不能为我们提供所有真正可观测性所需的信息。为此，引入了指标。

指标

收集有关服务信息的一种更复杂的方法是使用指标（SLI）。指标是对事物的数字度量，例如请求数、响应时间、错误率、资源使用率等。应用程序不同、业务场景不同，关注的指标也不一样。指标是一个新的监控维度，给出关于正在发生的事情的数字信息。与日志不同，指标可以通过各种有用的方式轻松处理：绘制图形、进行统计或对预定义阈值发出告警。例如，如果应用程序的错误率在单位时间段内超过 10%，监控系统可能 生成告警 。

某个时点的指标数据是点数据，随之间推移，指标点数据形成时序线数据，从而为系统的分析和预测提供线性依据。指标从不同的点监控实时监控系统运行，从而构筑全面或立体的指标体系，每个指标通常都有其合理区间范围，有其合理服务目标（SLO ）。系统服务对外提供相应的服务依赖于该服务的自身设计架构和部署架构、可扩展性能力等，从而也可以计算或估算出该服务的该项指标的服务能力（ SLA ），比如最大并发数、最大请求体、最大单位请求量等。SLI 、SLO、SLA是系统指标的不同方面，有助于回答系统问题的“为什么？”。指标允许应用程序开发人员根据他们对系统实际工作方式（以及失败方式）的了解，推导出有关系统隐藏方面的关键信息 。

链路跟踪

跟踪在分布式系统中尤为重要。指标和日志会告诉您系统中每个单独组件的情况，跟踪会在整个生命周期中跟踪单个用户请求，从而可以直观地将单个请求的整个链路关系和这个链路上每个节点的输入输出、资源的瞬时使用量、异常信息等展示出来。

ESB 曾经尝试解决服务之间繁杂的调用关系，不过微服务架构又将服务之间的这种繁杂的调用关系用了回来；微服务量的增多，使服务调用链路更为复杂；加上容器化封装等使异常处理、故障定位往往异常困难。通过链路跟踪技术，使整个请求路由路径可视化和可检查，从而可以快速看到并定位异常，及时采取措施对异常进行处理。

链路跟踪提供整个请求链路上有关错误发生位置的信息，配合使用日志记录来查找错误的根本原因。因此日志中往往有每个参与的微服务关联 ID的事件和错误，并通过使用日志聚合系统（如Fluentd、Logstash等）找到这些错误背后的原因。

从监控到可观测性

“可观测性”一词对不同的人可能理解不一样。有人说可观测性是监控的超集，也有人说可观测性反映了与传统监控完全不同的心态。从简单监控到指标、日志记录和跟踪的组合使用可观测性作为涵盖所有这些技术的包罗万象的术语变得越来越普遍。系统的可观察性是衡量系统内部逻辑和运行状况的可视化程度，以及能多容易地发现它内部发生了什么。系统可观测性仍然需要借助传统监控的技术和工具，因此往往将监控和可观测性混为一谈。不过监控和可观测性的数据的来源方式是不同的，监控是借助工具从系统采集数据，也因此往往对系统会或大或小的产生影响，可观测性是系统主动对外暴露或发布数据，比如说发布到kafka等消息总线上，无论谁需要这些数据，都可以从消息总线上订阅，对原系统无影响。但不管监控或可观测性，都需要可视化的UI对数据进行展示和交互。

可观测性文化

具备可观测性是实现自服务敏捷的前提。自服务敏捷能力的实现离不开研发人员具备良好的习惯和方法。认识到可观测性的价值和必要性，在服务研发过程中就会主动的实现可观测性能力，从而无需额外的监控工具和组件。因此也有人说可观测性是关于文化的。研发人员往往不愿意去做运维，或不屑于去做运维，而系统的可观测性是衡量一个研发人员是否具备系统设计思想的关键指标，也是实现DevOps 方法论的重要一环。