可观测性(Observability) – 监控和可观测性区别

监控

定义

监控（monitor）只是通过收集系统中预定义的指标集或日志集，告知并表明出了什么问题。
基于监控的运维方式是运用指标和仪表盘来对故障问题进行分类，这是软件行业的普遍做法。

如何使用监控

当我们系统要接入监控时：
1》第一步会使用各种各样的监控系统采集我们需要关注的指标和日志；
2》然后配置上对应的仪表盘进行展示或检索；
3》对于比较核心的指标还会设置告警，当系统产生告警时运维开发人员介入处理对应的异常。

• 范例

  一个简单的单体应用的架构如上图所示，这种架构服务之间的依赖关系非常简单，我们只需要关注后端服务的运行指标即可掌握整个系统的工作状态，后端服务出现超时或者不可用时，我们只需要查看后端服务负载指标基本上就能解决问题，就算后端服务没有异常，由于依赖的上下游非常简单，只需要稍微排查一些关联系统的负载情况问题基本上就能很好的解决了。

• 分析：
  在构建这个监控的过程中，我们系统会收集哪些指标，哪些指标能体现我们系统的状态，这些前提都是已知的。这意味着我们先有目标，然后再使用具体的监控系统。

监控的目标就是希望能够发现系统异常，我们要知道【采什么？看什么？告什么？】

监控的缺陷

在单体应用架构时代，由于系统交互比较简单，数据收集有限，依靠运维人员的经验和直觉来检测系统问题是有意义的。通过监控CPU、内存等资源消耗情况、数据库连接情况和网络传输质量，基本可以定位问题并进行修复。
现代应用程序底层系统的复杂性和规模：
1》分布式系统的交互组件数量众多，可能发生的故障数量和类型也更多；
2》敏捷化开发的需求，分布式系统不断更新迭代，每次更改都可能产生新的故障类型；

可观测性

可观测性（Observability）

管理学大师彼得德鲁克有一句话：“如果你无法衡量它，你就无法管理它”。
在企业中，无论是管理人，还是管理事，抑或是管理系统，首先都需要衡量。衡量的过程其实是搜集信息的过程，有了足够的信息才能做出正确的判断，有了正确的判断才能做出有效的管理和行动方案。

可观测性的背景

• 现代IT系统更加复杂
  现代IT系统的关键词是分布式、池化、大数据、零信任、弹性、容错、云原生等，越来越庞大，越来越精细，越来越动态，同时也越来越复杂。通过人去寻找各种信息的关联性，再根据经验判断和优化，显然是不可行的，耗时耗力还无法找到问题根因。
• 传统监控的数据无关联性
  传统的工具是垂直向的，引入一个新的组件的同时也会引入一个与之对应的观测工具，这样是保证了数据的全面性，但丢失了数据的关联性和分析排查的连贯性（换句话说，我们方方面面都监控到了，但遇到问题，还是不能很好地发现和定位）。
  此时我们很自然的想到做一个统一的数据平台，想象中把所有数据放在一个平台就能解决关联性的问题，但往往实际情况是我们只是把数据堆在一个地方，用的时候还是按传统的方式各看各的。我们只是把无数根柱子（工具），融合成了三根柱子：一个观测指标、日志、链路的统一平台，数据统一了，但关联性还得靠人的知识和经验。

可观测性的理解

• 可观测性描述的就是“观测-判断-优化-再观测”这个闭环的连续性、高效性。

  【图释：通过观测看到表象，通过判断定位问题，通过优化解决问题。】

如果只有观测而无法基于观测做出判断，则不能称其具备可观测性。
如果只有经验判断而没有数据支撑，也不能称其具备可观测性，这样会导致组织高度依赖个人能力而带来管理风险。
如果优化之后无法反馈到观测上，或者因优化引入新的技术而导致无法观测，则其可观测性不可持续。
如果在观测、判断、优化的闭环中需要付出很高的成本和承担很大风险，则其可观测性的价值为负。

• “可观测”不等于“可观测性”
  【图释：传统的观测工具是垂直的，观测者需要从多个工具中进行问题判断。】
  通常我们会基于自己想要的数据去搭建观测工具。
  1》当我们想了解掌握基础设施的健康状况的时候，我们会很自然的想到搭建一个仪表盘，实时监测各项指标。
  2》当我们想了解业务是如何出问题的，我们会很自然的想到搭建一个日志平台，随时过滤排查业务日志。
  3》当我们想了解事务为什么高延迟，我们会很自然的想到搭建一个链路监测平台，查询拓扑依赖和各节点的响应时间。
  这种模式很好，帮助我们解决了很多问题，以至于我们从不怀疑可观测性，我们信心满满。偶尔遇到大难题，把我们的仪表盘、日志平台、链路平台打开，所有的数据都在这里，我们坚信一定能找到问题的根因。即使花费了很长时间，我们也只是告诉自己要多学习，多了解掌握自己负责的系统，下一次我一定能更快找到根因。是的，当我们想要的数据都摆在面前的时候，我们还有什么理由怪罪观测工具。
  【图释：人脑像一把尺子，根据经验比对多个指标来发现它们的相关性。】
• 【图释：当发现指标有毛刺的时候，往往需要在大脑中构建复杂的日志查询条件，费时不说还容易出错。】
  我们会不辞劳苦地在各种指标数据中寻找可能的关联性，得到关键线索后，我们会在大脑中构造出一堆复杂的日志查询条件来验证自己的猜想。就这样比对、猜想、验证，同时还要在各种工具中切换。
  传统的系统相对简单，上述方式行之有效。现代IT系统的关键词是分布式、池化、大数据、零信任、弹性、容错、云原生等，越来越庞大，越来越精细，越来越动态，同时也越来越复杂。通过人去寻找各种信息的关联性，再根据经验判断和优化，显然是不可行的，耗时耗力还无法找到问题根因。

可观测性的意义

可观察性的最大益处是：系统更容易理解（笼统和细节层面均如此），更容易监控，更新新代码更简单、更安全，也更容易修复。 可观察性直接支持敏捷开发/DevOps/SRE 以更快速度交付更优质软件的目标。

• 发现和解决“不知道的未知问题”
  即您不知道存在的问题。 监控工具的一个主要限制是它们仅监测“知道的未知问题”- 即您已经知道要监测的意外条件。 可观察性会发现您可能从不知道或想过要监测的条件，然后跟踪它们与特定性能问题的关系，并提供背景信息以找出根本原因，加快解决问题。
• 在开发中尽早捕捉和解决问题
  可观察性在软件开发流程早期阶段就融入监控。 DevOps 团队可以及时识别和修复新代码中的问题，以免它们影响客户体验或 SLA。

使用场景

1》容量评估
评估单机、集群的容量；评估各个节点的容量。

2》对历史数据进行回溯分析
通过对监控数据的分析，得出业务在不同时间段对于各个应用/系统的资源占用情况。
通过对监控数据的分析，排除在出问题时刻的各个节点的状况。

2》排查问题：
2.1》快速得到问题节点：
监控数据和网络拓扑结构关联；

2.2》定位到问题节点后，定位具体的函数/热点：
应用内部的调用栈、各个指标

可观测性的要求

收集数据

能够具备采集Metric、Tracing、Logging、Profile数据；
根据 Metric 配置的告警策略发现问题，基于 Tracing 查看是哪个组件出问题，基于 Logging 查看组件的日志，Profiling 分析组件具体的故障或性能问题。

metric

指标数据，典型的指标有请求量、请求耗时、请求成功/失败统计（错误率）、业务自定义指标等等；
关于metric 主要关注4个方面的指标：

• 资源类: 分为计算、存储、网络资源三类。
  计算资源：比如CPU、load；存储资源比如内存；网络资源：比如连接数、并发连接数、活跃用户数。
• 流量类：更多的刻画的是系统的吞吐。比如一个应用的 bsp/pps/cps/qps。流量等于吞吐或者速率这样的指标。
• 时延类：刻画的是系统的访问是不是顺畅，耗费的时间是不是增加了。从四层的角度：有三次握手的时延，协议响应的时延；从7层/应用的角度看：http响应的时延，dns的响应时延。
• 错误类：服务返回的错误的总数量。错误可能发生在网络层：比如tcp的连接失败，tcp的重置（reset)，tcp的重传、tcp的零窗口；也可能发生在应用层：比如http的4xx 、5xx的错误，dns的解析错误。
• AutoMetrics

思路 ：部署agent
使用eBPF的kprobe、uprobe、tracepoints能力，与AF_PACKET、pcap等机制结合，实现面向任何操作系统、任意内核版本的全自动的数据采集。
也就是说，不管一个调用是发生在Application这一侧的客户端或服务端，不管这个调用流经的是Pod的虚拟网卡、VM的虚拟网卡、宿主机的物理网卡，还是中间的NFV虚拟网关，或者七层API网关，只需要在端上部署agent，都能自动的获取到它的每一个调用的事件详情及RED（Request、Error、Delay）性能指标。

通过eBPF/BPF技术从内核中获取到调用数据，并生成应用层面的RED指标、网络层面的吞吐、时延、异常、重传等指标。这样的指标采集是完全自动化的，它不需要我们的开发者手动做任何的埋点或插码。

log

日志数据，记录系统运行过程中的详细信息；对系统所做行为的一种记录，它是离散的，没有相关性，为了区分这种记录的重要程度，会分级别（DEBUG、INFO、WARN、ERROR、FATAL）。

对于日志，我们常用的是：Elastic-search 存储，Kibina展示。

trace

分布式追踪数据，用来跟踪用户请求行为，能够清晰的反映用户请求在我们分布式系统中的流转过程；

1> 用户发起请求到获取响应的整个链路（tracing）的追踪。包含：各个节点（dns/LB之四层、七层/firewall/NAT）、设备(物理网络、主机网络之宿主机、容器)、应用、多个微服务之间的调用栈 等等。
具体的手段：telemetry 、流量镜像、Erspan、netflow、sflow、traceroute 等等。

2> 对于某个具体的应用/节点，在这个应用内部的函数调用栈。
比如：是否是某个函数的耗时，导致整个应用的耗时增加；
是否是错误发生在某个函数内。

注：对于一个请求、一条流的追踪，在经过LB设备或者NAT设备，流的五元组发生更改，此时需要展示会话，将变化前的流和变化后的流关联起来。

• AutoTracing
  eBPF追踪的是每个Request相关的TCP/UDP通信函数，通过挂载到这些系统调用函数中实现自动追踪，高度完整的展示出微服务调用链。

profile

性能数据，一般叫做 Continuous Profiling，持续分析，它反映的是程序内部的运行状态，比如栈调用、执行时间等。可以把 Profiling 可视化成火焰图方面分析问题
；

接入简单/无侵入式

支持语言丰富，提供良好的接入指引，对于动态语言提供无侵入的接入方式.

关联数据

比如：
监控数据（metric）和 网络关系拓扑（tracing）的关联。
监控数据（metric）和日志（log）的关联；

关联哪些数据

指标需要链接到日志，以便生成的统计信息可以连接到它们正在监测的事务；
每个数据点都需要链接到底层系统资源（软件、基础设施和配置细节），以便所有事件都可以连接到整个系统的拓扑结构中；主动拨测体系需要具备实时探测的能力，达到发现故障、模拟故障和路径追踪的目的；关键配置信息与指标和日志关联分析帮助运维人员理解业务架构，最终结果是结构化的数据，它将为分析工具提供系统的完整视图。

关联数据的意义

把之前需要人去比对、过滤的事交给程序去处理。程序最擅长此类事同时也最可靠，人的时间更多的用在判断和决策上。这在复杂系统中，节省的时间会被放大很多倍，就这点小事就是可观测性看得见的未来。

纵向关联请求上下游链路和调用栈，横向关联请求和处理请求所消耗的应用资源。建立良好的可观测性数据模型，统一元数据，能够在一个平面上关联所有可观测性数据；

如何关联数据

标准化/结构化数据(metric/log/trace等)

在我们的统一数据平台上，由于数据是来自于各种观测工具的，虽然我们在数据格式上统一成了metric、log、trace，但不同工具的metric、log、trace的元数据截然不同，而如果我们在这个统一数据平台上去梳理和映射这些元数据的话，这将是庞杂、难维护、不可持续的。
只有将标准化、结构化的数据喂给观测平台，观测平台才能从中发现巨大价值。

空间上的关联

各个数据的上下文context信息，建立 context 空间信息的标准化。

时间上的关联

统一数据平台只是在数据格式上进行了标准化，而要想将trace、metric、log关联还必须建立context的标准化，context就是数据的空间信息，再叠加上时间信息的关联就可以发挥真正的观测价值。

设计模型

数据采集和关联、异常定义和分析、全链路错误寻根三方面统一的模型化设计。

仪表板展示

支持各类仪表板，服务拓扑图、火焰图等可视化能力；

场景覆盖全面

覆盖从客户端、服务端到基础设施所有场景；

可观测性构建的扩展

观测性分析平台

可观测性分析平台：将多元数据进行整合后，通过智能化分析能力识别整个数据中的相关性/关联性，可自动完成数多种运维场景、安全问题的状态解读，以及故障的根因分析。
【关键词：数据整合、数据关联、智能分析】

业务画像

通过应用拓扑来实现业务画像，业务画像真实反应用户访问的路径，并将关键指标关联到访问路径上，根据指标变化标记异常节点；最后通过平台的事件分析能力，实现故障自动化分析并输出结果和处置建议，从前繁琐的人工排障过程，比如数据回溯与疑点排查，现在通过大数据和智能算法，获得了分钟级的自动化解决方案。

【关键词：拓扑、访问路径上各个插件/节点的指标、异常节点】

这个是从广义上说的：查找异常节点：业务访问路径上的各个节点/插件的指标来找到异常节点。

智能化、定制化的告警

以往的告警模式会产生大量的信息，使运维人员淹没在海量告警中；
平台通过对黄金指标（延迟、流量、错误、饱和度）的长期学习形成符合用户场景特征的基线，并根据指标的异常变化告警，使运维人员可更加准确的感知业务异常。
【关键词：基于业务对软件的指标的长周期学习，形成基线】

这个是从狭义上说：如何定义异常节点：业务在这个节点的长时间学习，形成指标，异常时进行告警。
比如：

• 1》对于某个特定业务：
  业务基于拓扑、访问路径（含有一些插件/中间件）生成业务画像，在每个节点上都有一些指标数据（延迟、错误率、丢包、资源使用率等），业务访问有问题的时候，基于各个节点的指标数据，判断哪个节点出问题了。
• 2》对于LB而言：
  LB（专有的LB集群）只是其流量路径上的一个节点，可基于业务的历史流量在LB上对应的指标进行长期学习， 形成基线，一旦实际LB的指标远离了这个基线，就智能化告警。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
完善LB的可观测性：

1》业务粒度：

    1.1》业务粒度（vs以及vs下的rs）的丢包

        比如：访问某个vs，发生了丢包；

    1.2》业务粒度的流量统计

        比如：vs/rs的连接数、cps、pps、bps；

      更细粒度一点，可以是某个conn的bps、pps实时数据。

    1.3》业务在各个功能点的延迟

        比如：vs/rs在new_conn的延迟、在各个调度算法的延迟、查找conn的延迟、生成/查找neigh的延迟、插入uoa/toa的延迟、

             申请内存的延迟等等；

2》系统粒度：

    2.1》系统粒度的丢包

        比如：资源不足、队列满

    2.2》系统粒度的各个函数的耗时、函数返回错误、调用堆栈

        比如：uprobe/kprobe/tracepoint、perf、epbf

监控和可观测性的关系和区别

• 两者的关系：
  监控和可观测性都旨在辅助建设高可用的服务，缩短故障处理时长，两者往往是密切协作的，界限相对模糊。
• 两者的区别：

• 监控：
  监控往往关注告警触发的瞬时状态，一般围绕告警事件展开，涉及从告警事件的产生到应急响应等一系列动作。关注的视角一般是局部可用性，关注每个具体的监控项，如CPU负载、剩余内存等。监控最常见的场景是系统资源监控、进程或服务状态的粗粒度监控。对定制化的业务指标，监控不太友好，另外传统的监控体系对云原生的支持、对微服务体系监控的支持也不太友好。
• 可观测性:
  可观测性可以看作是监控的一种延续，涉及面较广，包括全链路分析（APM）、业务服务质量（SLA）、业务容量等，聚焦服务的整体可用性。关注的视角一般是全局可用性，会忽略不影响服务质量的一些指标，如CPU负载高，服务整体时延波动不大就会忽略这个CPU负载指标。
  可观测性的应用场景一般与业务能力相绑定，通过可视化聚合展示影响SLA的相关指标（SLI），再配合监控告警，通过可观测性看板下钻分析异常根因。另外可观测性打通Metrics/Traces/Logs后可主动识别出服务的潜在风险，能先于用户发现问题。

传统的监控，无法适应现代软件系统，其技术和工具很难跟踪当前的分布式架构中的许多通信路径和相互依赖关系。
现代的可观测性，可以更好地控制复杂系统。随着微服务架构的普及，稳定性职责将分布在整个软件生命周期涉及的多团队之间。

---

因此可以说可观测性是在监控的基础上做了更深、更广的发展。以众所周知的冰山模型为例，监控和可观测性也同样适用，冰山之上是外在，易于被测量和了解，这就是监控，而冰山之下不会受外界影响，内在为主，指代的就是可观测性。

• 以故障管理为例:
  “监控”的重点在于监视特定的指标，有助于我们回答“何时何地正在发生什么”这个问题；而可观测性的重点在于能够帮助团队在多云环境中了解上下文发生的事情，以检测和解决问题的根本原因，有助于我们回答“何时何地正在发生什么”以及“为什么会发生该事件”这两个问题。因此，可以说，在故障管理角度，相比较于监控，可观测性的价值在于快速排障。

• 监控是可观测性能力的一部分:
  监控能够检测到系统中的错误，而可观测性能够理解问题发生的原因；从某个意义上来说，监控是可观测性的子集和功能，可观测性是监控的超集和延展。

监控只是通过收集系统中预定义的指标集或日志集，告知并表明出了什么问题；
可观测性使用数据收集来告知出了什么问题、为什么会出问题，以便SRE（系统可靠性工程师）或DevOps团队可以轻松调试系统，因此它可以探究可能事先未定义的指标和模式。

• 可观测性 发现&解决未知的未知问题。监控发现已知的问题。
• 监控为你提供有关系统中的问题或故障的信息，而可观测性让你了解导致故障的原因。

可监控性对开发、运维、架构的要求

• 从被动监控向主动发现与定位问题的转变
  除了要知道“正在发生什么”，还要尝试解释“为什么会这样”。我们需要把可观测性的理念贯穿到架构和程序设计中，而不是到事发或事后再来补救。认为最大的变化是应用系统自身角色的转变，从被动监控转向主动发现与定位问题，在设计应用系统架构之初就需要考虑到系统自身的可观测性建设。运维、开发、架构师都是各环节设计的参与者，在协作方式也有一定的改变：

• 运维：深入熟悉产品业务和应用服务，定义并关联业务指标、应用服务指标、系统资源指标等。
• 开发：在框架层设计和实现对分布式应用服务运行时的Metric、Trace、Log数据采集。
• 架构：业务应用系统和可观测性系统的整体架构设计，需要关注无侵入式采集上报、多维度量聚合、错误寻根分析、整体海量数据处理和存储等。

• 职责分工、认知意识、排障效率的转变和升级

• 职责分工的转变，研发关注服务质量后，部分职责从运维侧开始迁移到研发侧。研发上线后不再当甩手掌柜，开始对自己的服务负责。
• 认知意识的提高，从被动响应告警到主动提升服务质量。
• 排障效率的提升，从原先的黑盒排障模式逐渐朝可视化发展。

https://blog.csdn.net/legend050709/article/details/129111941

监控是可观测性能力的一部分，初期监控主要是外部对业务应用系统的主动行为，运维是传统监控的使用主体，如：通过业务进程状态、系统资源等监控数据的分析和告警来发现问题。而现在可观测性更多是对业务应用系统自身的要求，如何设计去暴露出更多可被观测的应用运行时的数据，并为这些数据之间建立关联，如：微服务框架在请求处理和RPC调用时提供一些AOP扩展的设计，可以更方便地对请求进行Metric度量和Trace追踪，以及异常情况的上下文关联。

三者打通最大的价值是能做到全链路错误寻根，即从发现请求Metric指标异常，通过指标关联分析，并逐层下钻到明细Trace追踪和具体Error Log，全流程自动化从宏观到明细的错误发现和根因定位。

虎牙为三者统一设计了应用监控模型，包括应用服务的透明零成本SDK接入，三者数据自动采集和关联，以及在虎牙大型分布式系统充分实践的全链路错误寻根算法。就整体实践经验来说，最终业务价值在于帮助研发和运维提高了应用服务的排障和治理效率。

“打通后可立体、全息分析整个服务的可用性”

从投入成本（CapEx）、运维成本（OpEx）、响应能力（Reaction）、查问题的有效程度（Investigation）几个方面分析。Metrics、Logs、Traces具有以下特征：

Logs和Traces一般采用trace_id打通，trace_id一般在端入口生成，贯穿整个请求的生命周期，业务记录Logs的时候可记录当前的trace_id，这样Logs和Traces就能打通了。

与Metrics打通一般是采用标签Tags模式，如某个服务servername产生的metrics可与Traces中的servername关联。

打通后可以服务名的维度，立体、全息分析整个服务的可用性。

“高可用、可伸缩、降成本、易运维”

我们关注可观测工具系统的这些特性：

高可用：可观测系统作为稳定性的守卫者，本身要求更高的可靠性。

可伸缩：我们关注存储写入和查询能力的可拓展性，以支持更大的数据量级。

降成本：观测类数据会随着时间的推移逐渐失去价值，历史数据最好能低成本地失效或能对存储介质进行降级。

易运维：拥有一定的自动化能力或者本身架构足够简单。

虎牙主要是基于OpenTracing标准进行的深度自研和扩展，通过业界标准来做会有充分的开源代码和社区支持，可以节省很多基础代码的工作，让我们更关注自身的业务系统特性和模型设计。现在OpenTelemetry对Metrics、Traces、Logs三者提供了统一标准，开源社区热度也比较大，是个值得去研究和实践的方向。

可观测性工具选型建议可考虑两个方面：

1. 是否基于业界标准，有更多社区和厂商支持。
2. 是否方便扩展，更容易把共性和个性结合，最终在此基础上建设符合自身业务特性的可观测性系统。

“根据已有技术栈按需选择，不必盲从主流”

可观测性分析整个技术栈可参考如下图：

工具选型：

Metrics：常用Zabbix、Nagios、Prometheus，及相关高可用部署方案如Prometheus-operator、Thanos。

Logging：ELK Stack、Fluentd、Loki等。

Traceing：常用Jaeger、SkyWalking、Pinpoint、Zipkin、Spring Cloud Sleuth等。

可视化：Grafana。

其实技术选型没什么特定的标准，每个企业不同阶段可能有不同的选择，适合自己的才是最好的，这里总结几点心得：

控制成本预算，企业一般需要从自身的发展阶段实际情况考虑，不必一上来就整全链路可观测性，也许初期只用传统的Zabbix就满足需求了。理性按需选择，大可不必盲从主流。

拥抱开源，初期一般采用开源产品，开箱即用，搭顺风车。另外，选型时还需要考虑周边生态的丰富度。

根据团队技术栈选择，中间件、业务服务、云原生、物理机监控等选型都要贴合团队已有的技术栈。