CSDN

可观测性与传统监控的区别和联系

2024-01-16 15:51 由 SRETalk 发表于 #软件工程

什么是可观测性？

可观测性（Observability）是一种软件开发和系统构建的哲学，是对系统内部状态及行为的度量和推断能力，通常包括日志、指标、链路追踪等多个度量维度。也就是说，在软件开发和运维领域中，可观测性是指对于一个复杂的系统，能够通过监控、日志、指标、追踪等手段，快速地发现、诊断、解决问题的能力。

Observability 最早是起源于控制论的一个概念：

In 1960, Kálmán introduced a characterization he called observability to describe mathematical control systems in his paper. In control theory, observability is defined as a measure of how well internal states of a system can be inferred from knowledge of its external outputs.

传统监控的局限

从核心出发点来讲，传统的监控和可观测性，背后解决的是同样的问题，就是及时、准确的掌握系统的运行状况，提升对系统运行的控制能力。因此常有人讲可观测性之于监控是“新瓶装旧酒”，换汤不换药。实则不然，随着技术架构的演进，传统监控的局限愈发突出：

侧重于依赖“经验主义”，应对“已知问题”

传统监控，要预先知晓采集哪些指标，添加什么样的告警策略，定制什么样的仪表盘，以便发现某种类型的故障后，采用什么样的 Runbook 来应对。比如技术团队根据过往经验，知道一台服务器上打开的文件句柄数量不能太多，超过某个上限就会影响到网络通信以及文件读写，因此我们会采集一个 node_filefd_allocated 的指标，然后配置一个告警策略：当 node_filefd_allocated > 1000k 则触发告警，同时我们会提前制作一个 Linux 主机 Dashboard，其中包含有 node_filefd_allocated 的趋势图。准备好这些工作之后，接下来就是守株待兔，等待告警的触发，值班的技术团队就可以按照 Runbook 中载明的排查步骤，检查是否有进程泄露文件句柄，或者是否有大量的网络链接建立等等。

经验主义，总是有限的，无法预知可能发生的各种未知的故障。因此在实际情况中，告警策略的完善往往靠“故障复盘”来驱动，每次故障复盘后，必定会有的一个改进项：继续完善监控、加更多的告警。技术团队总会处于一种对未知故障缺乏掌控的不安全的状态中，产生焦虑感，反过来又会促使技术团队添加更多的监控，久而久之，告警会越加越多，却又永远不够，告警风暴就这样产生了。

告警驱动的传统监控，缺乏对故障的全局感知

在传统监控中，告警充当着举足轻重的作用。当使用传统监控方式，发出某个告警之后，值班的技术团队看到的只是一个孤立的”技术问题“，这个技术问题的影响面有多大，重要程度如何，是否需要立即处理，是否需要上升和协同，很难快速的做出判断。某个”技术问题“是否重要，是否紧急，不取决于该技术问题本身的难易程度，也不取决于所涉及的服务器规模多寡，唯一的衡量标准是”对用户体验产生的影响有多大“。使用传统监控无法快速的评估某个告警事件和用户体验之间的必然联系，导致无法投入准确的应急处置资源，无法确定合理的应急响应时效，也无法和其他资源产生有效的联动协同，最终使得稳定性保障工作效率低下。

传统监控认为，系统的开发者和系统的维护者，职责是相对分割的，导致监控以外挂形式为主

系统在设计之初，开发者的重心在于完成必备的业务逻辑，对于自身运行状态的暴露，并没有考虑的很完善甚至有时候都没有考虑。大家可能会经常遇到，做的好的开发者可能还会打印较为详细的日志，做的不好的，连日志也打的不全，更不必说提供主动暴露系统状态的 Metrics 接口或者为实现 Tracing 进行埋点了。一旦系统到了上线运行阶段，维护人员接手后，往往只能开启“外挂”模式，通过写各种各样的脚本，去探测进程是否存在、去分析匹配日志中是否有关键的错误字段。如果要进一步统计系统的访问量、访问延迟、资源消耗等等，就会更加被动。“外挂”往往是传统监控数据采集的特征。

传统监控面向的通常是基础设施，Metrics是传统监控的基础

传统监控面向基础设施，基础设施的变化较慢，且变化带来的结果相对可预测。Metrics 类型的监控指标，具有采集存储成本低、简单直观、易于聚合计算的特点，因此在过去的二三十年里，基于 Metrics 为基础，出现了各种各样的采集器、时序数据库、可视化工具、告警工具等，基于前面提到的”经验主义“，尚能应付面向基础设施的稳定性保障工作。

传统监控工具发展的三个阶段

阶段1：Metrics监控之互联网大流行前

互联网大流行前，擅长于局部场景，部分工具到现在仍然被广泛使用

  • Cacti：最悠久的监控系统之一，2001年9月，一个名叫Lan Berry的高中生，当时他还在为一家小的ISP厂商工作，为了更好地监控网络质量，开发了Cacti的第一个版本，基于RRDtool，提供更友好的使用体验。
  • Nagios：Nagios可谓是早期告警方向事实上的工业标准，可以用来监控主机和网络基础设施，以及各种应用服务。在监控对象出现问题时，及时发送邮件或者短信通知相关人员；当问题解决后，发送恢复信息。一段时间的主流，后来以难用闻名。
  • Ganglia： UC Berkeley发起的一个开源集群监视项目，设计用于测量数以千计的节点。主要是用来监控系统性能，如：cpu 、mem、硬盘利用率， I/O负载、网络流量情况等，至今仍然在Hadoop监控领域流行。
  • RRDtool：在时间序列数据（time-series data）的存储、展示方面，其独创的round-robin database数据存储格式，曾经是事实上的时序数据存储工业标准。包括Cacti、MRTG、Collectd、Ganglia、Zenoss等系统，都是采用RRDtool的格式来存储数据，以及使用RRDtool的Graph工具来绘图。
  • Collectd：定位是收集和传输数据。在告警方面不是Collectd的设计初衷，不过它也支持一些简单的阈值判定，并发送告警信息。要支持更高级的一些告警需求，Collectd可以和Nagios配合使用。
  • StatsD：最早是 2008 年 Flickr 公司用 Perl 写的，StatsD 其实就是一个监听UDP（默认）或者TCP的守护程序，根据简单的协议收集statsd客户端发送来的数据，聚合之后，定时推送给后端，如graphite和influxdb等，再通过grafana等展示。
  • Graphite：一个开源实时的、显示时间序列度量数据的图形系统。Graphite并不收集度量数据本身，而是像一个数据库，通过其后端接收度量数据，然后以实时方式查询、转换、组合这些度量数据。Graphite支持内建的Web界面，它允许用户浏览度量数据和图。

阶段2：Metrics监控之互联网快速发展期

互联网快速发展的时代，监控往一体化方向发展，注重体验的提升

Zabbix

作为一款企业级分布式监控系统，功能齐全，用户体验良好，文档完善，API强大，存储可以对接主要的SQL接口数据库，适合于中小规模的公司或者团队使用。Zabbix 由 Alexei Vladishev (阿列克谢.弗拉迪谢夫、拉脱维亚人）创建，目前由其成立的公司 —— Zabbix SIA（一家总部位于拉脱维亚里加的软件公司） 积极的持续开发更新维护， 并为用户提供技术支持服务。

Open-Falcon

小米技术团队于2015年开源的一款互联网企业级监控系统，重在解决日益增长的监控数据量和监控系统的容量限制之间的矛盾。Open-Falcon在架构设计上，一个最关键的考量点就是“如何做到水平扩展”，底层存储采用的是RRDtool标准。

在Zabbix被广泛使用的时期，Open-Falcon为何能够在中国获得重要影响力：

  • Open-Falcon的初衷就是解决zabbix在大数据量情况下无法扩展伸缩的问题；
  • Open-Falcon引入了标签概念，该特性让监控数据的分析变得非常灵活而强大，是下一代监控主要特点之一；
  • Zabbix的用户体验在当时不太符合中国工程师的习惯；
  • Open-Falcon借助小米在互联网公司的影响获得快速推广；
  • Zabbix基于C语言开发，而Open-Falcon基于Go语言开发，在二开上更为友好；
  • Open-Falcon的中文文档和支持能力；

阶段3：Metrics监控之云原生时代

Prometheus 成为时代的王者

Prometheus

由前 Google 工程师从 2012 年开始在 Soundcloud 以开源软件的形式进行研发的系统监控和告警工具包，产品设计源于Google的Borgmon。Prometheus 的开发者和用户社区非常活跃，Prometheus 于 2016 年 5 月加入 CNCF 基金会，成为继 Kubernetes 之后的第二个 CNCF 托管项目。

Nightingale

夜莺 (Nightingale) 是一款开源云原生监控工具，是中国计算机学会接受捐赠并托管的第一个开源项目，在GitHub上有8000颗星，有数千家企业用户使用。夜莺集合了 Prometheus 和 Grafana 的优点，你可以在 UI 上管理和配置告警策略，也可以对分布在多个 Region 的指标、日志、链路追踪数据进行统一的可视化和分析。

高性能时序数据库代表

  • Prometheus：Prometheus自带的高性能单机存储数据库；
  • InfluxDB：支持按标签存储查询，该领域最著名的时序数据库之一；
  • TDengine：国内最著名的开源时序数据存储之一，面向IoT领域，表结构存储，支持SQL查询；
  • TimescaleDB：表结构存储的代表，支持SQL查询；
  • VictoriaMetrics：被广泛应用的标签存储时序数据库，和prometheus做了无缝兼容；
  • M3DB：Uber开发开源，高性能可扩展时序数据库，支持按标签存储查询，兼容prometheus，扩展性比VictoriaMetrics好，但运维更复杂；
  • Mimir：Grafana于2022年3月30日发布的时序数据存储，完全兼容prometheus生态；

可观测性的特点

可观测性认为，你的应用是如何运行的以及是否在正确的运行，应该主动地、默认地通过 Metrics、Logging、Tracing、Events 等多种数据维度实时的暴露出来，然后通过工具进行可视化、告警、分析和数据洞察。对应用内部状态和行为的暴露，是系统设计之初就要考虑的重要组成，是系统功能不可分割的一部分。在可观测体系下，“埋点”是一种文化，应用的开发者承担着主体责任，系统的维护者反而作为数据的使用方存在。

以终端用户发起对服务端的一次请求为例，在该请求的整个生命周期内，尽可能多的细节都应该被记录下来，以便在未来的某个时刻用于 troubleshooting，这些细节数据可能包括：请求ID（request_id）、请求头（headers）、请求参数（parameters）、请求执行的时间（duration_time）、对下游的rpc调用（rpc_calls)、执行rpc调用的耗时、rpc调用的结果、环境变量、元信息（metadata）等等。在可观测体系下，这些数据都应该被实时的记录下来，并以结构化的形式存储。

相较于传统监控关注基础设施，可观测性强调面向”Application“。随着云原生架构和微服务模型的普及，现代化的应用出现了一些新的特点：

  1. 相比单体应用，技术团队面临着更多的服务需要管理；
  2. 很多服务之间都是松耦合，而且像云数据库、云存储、第三方API等服务，都不处于你的掌控之下；
  3. 代码的发布和变更，频率越来越高，持续集成、持续发布成为主流；
  4. 基础设施动态化，容量也在动态的弹性伸缩；
  5. 现代化的系统架构下，可能出现故障的点位越来越多，”长尾问题“出现的频率也越来越高，难以定位和分析；
  6. 研发工程师更多的参与到系统的运行维护工作中来；

OpenTelemetry

也被称为 OTel。是一个供应商无关的开源可观测性框架，用于测量、生产、收集、导出可观测数据。可观测数据主要包含traces 链路、metrics 度量和 logs 日志。使用OpenTelemetry后，可观测的三要素日志、链路追踪、指标，将从过去的相互独立，变的关联性更强，方便我们进行更快速的问题定位：

Flashcat

Flashcat是一个兼容OpenTelemetry的可观测性平台，构建了一个数据、平台、场景打通的一体化可观测方案，具有以下四个特点：

  • 一体化：从业务到应用到基础实施，打通Metrics、Logging、Tracing、Event，是一个立体的监控产品体系和解决方案。
  • 统一管理：采集适配云原生、公有云、物理机/虚拟机、混合云等环境。产品层实现多环境、多集群的监控统一管理。
  • 集成融合：可集成企业内部已有的可观测配套系统，无需推倒重来，串联打通数据，发挥协同定位的价值。
  • 引导定位：结合服务稳定性保障的理论实践，从上往下引导用户按照最佳实践，层层下钻，加速故障处理。

你可以通过Flashcat平台，有效改善以下问题：

  • 希望整个公司统一用一个工具，就可以支持指标、日志、链路追踪数据的采集、可视化、告警，免去搭建和维护多套 Prometheus、Zabbix、Grafana、ELK、Jaeger 的工作量。
  • 如果有在用多云，并且在多个公有云监控控制台来回切换不方便，希望监控数据、监控视图都是统一的，有更一致的用户体验，同时降低给所有的工程师开通公有云控制台权限带来的安全隐患。
  • 告警太多，工作老被打断， 可以利用我们提供的 OnCall 值班平台（类似于 PagerDuty），支持告警聚合、降噪、认领、升级、排班，可以在飞书、钉钉、企微中接收和处理告警。

最易被忽视的OnCall

在传统监控领域，OnCall是最容易被技术团队忽视的一个概念，运维和研发人员往往面临以下典型的困扰：

  • 技术团队每天接收到大量的告警。
  • 很多告警长时间无响应，长期无人问津。
  • 告警与告警之间缺乏关联性，处理效率低下。
  • 告警处理缺乏协同，处理过程不透明，信息难以共享，知识难以沉淀。
  • 很多告警并未准确反应实际情况，无谓的消耗技术团队精力。
  • 客户/用户往往先于技术团队发现故障，客户满意度持续走低。
  • 无法量化的衡量应急响应的现状和效率，无法制定出改进和优化路线。

一个好的 OnCall 工具，能够大幅提升运维和研发人员的效率和幸福感：

  1. 告警聚合收敛：解决告警风暴问题，按照业界的实践，压缩率为70%~80%。
  2. 告警全生命周期管理：告警认领、转派、升级，解决告警不能及时处理、告警漏处理、告警散落在各个监控系统的问题。
  3. 告警排班：引入值班表，以排班的形式高效的OnCall，减少疏忽和失误，减少告警对非值班team的打扰，让团队可持续发展。
  4. 故障管理：相关的告警聚合为故障，基于故障的告警处理协作模式，解决跨团队协同不畅的问题。
  5. ChatOps交互：在电话、短信之外，通过各种IM触达通知技术团队，在IM中交互式的响应和处理告警。

没有度量就没有改进，在实际工作中，运维负责人表面看到的是告警太多、团队成员疲于奔命，但苦于看不清告警处理的工作量，没法规划协调补充人力，更严重的是看不清优化告警的方向，导致情况持续恶化，最终团队散了，故障频发。所以在告警处理的领域，尤其需要“可观测”，推荐关注下面 5 个关键的OnCall度量指标：

  1. 降噪比：即告警的压缩比，通过算法、规则将众多相关的告警聚合后，再通知到值班人员。告警聚合能有效降低告警风暴，减少值班人员的工作量，提高信息处理的效率（该指标越高越好）。
  2. 响应比：被认领的告警占所有告警的比例。在告警管理领域，需要响应或者认领的告警，才是有用的告警，因此通过统计和观察“响应比“，能整体的评估告警是否足够有效和有用，并持续的推动提升告警”响应比“（该指标越高越好）。
  3. 告警总量：一段时间窗口内产生的告警数量。过高的告警总量，意味着值班的压力越大，对技术团队注意力的干扰越多，潜在的意味着告警的噪音可能也过大，因此过多的告警，会让整个系统处于不可运维的状态，应该该尽力的降低告警总量，譬如采用基于SLO的告警，就可以答复降低该指标（该指标越低越好）。
  4. MTTA（平均响应或认领用时）：从告警发生到值班人员响应或者认领的时间间隔。越快的 MTTA，标志着越高的告警处理效率，潜在的代表着越高的服务稳定性。通过MTTA我们可以有效的度量团队的工作压力，以便决策合适的资源投入，确保团队始终处于可持续发展的状态（该指标合适就好）。
  5. MTTR（平均恢复或解决用时）：从告警发生到问题解决的时间间隔。越快的 MTTR，往往意味着团队拥有更先进的观测技术、更强大的基础设施平台、更熟练的工作技能、以及对业务系统有更深入的理解（该指标越快越好）。

兵器推荐：

  • 国外推荐采用PagerDuty，PagerDuty是全球范围内OnCall产品的领导者。
  • 国内推荐采用FlashDuty，FlashDuty是开源监控工具夜莺背后的开发者团队推出的OnCall产品，相比PagerDuty对国内的各种监控工具、IM工具适配性更好，产品体验也更简洁。

可观测性的技术趋势

在可观测性三大支柱在外，Continuous Profiling作为一种持续性能分析技术，应用也越来越广泛。Continuous Profiling 用于实时监测和分析应用程序的性能特征。它通过不间断地采集应用程序的性能数据，例如函数调用、内存使用情况、CPU利用率等，以实现对应用程序性能的全面了解。

eBPF（Extended Berkeley Packet Filter）是Linux内核的扩展功能，用于在内核层面执行安全、性能和观测等任务。eBPF技术允许用户在不修改内核代码的情况下，通过安全的、可编程的虚拟机在内核中注入代码。它能够捕获和处理系统的事件，例如网络数据包、系统调用、文件访问等，并进行实时分析或转发，从而实现更高级的网络分析、安全监控和性能优化等功能。

在可观测性领域，Continuous Profiling和eBPF技术都为开发人员和运维团队提供了更加全面、实时和深入的监控能力。

热门相关：唐土万里   少林武僧在异界   重生隐婚：Hi，高冷权少！   天河大帝   盛世娇宠之名门闺香