什么是可观测性？
可观测性（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“。随着云原生架构和微服务模型的普及，当代化的应用出现了一些新的特点：
- 相比单体应用，技术团队面临着更多的服务需要管理；
- 许多服务之间都是松耦合，而且像云数据库、云存储、第三方API等服务，都不处于你的掌控之下；
- 代码的发布和变更，频率越来越高，连续集成、连续发布成为主流；
- 底子办法动态化，容量也在动态的弹性伸缩；
- 当代化的系统架构下，大概出现故障的点位越来越多，”长尾问题“出现的频率也越来越高，难以定位和分析；
- 研发工程师更多的加入到系统的运行维护工作中来；
OpenTelemetry
也被称为 OTel。是一个供应商无关的开源可观测性框架，用于测量、生产、收集、导出可观测数据。可观测数据主要包含traces 链路、metrics 度量和 logs 日志。使用OpenTelemetry后，可观测的三要素日志、链路追踪、指标，将从过去的相互独立，变的关联性更强，方便我们进行更快速的问题定位：
Flashcat
Flashcat是一个兼容OpenTelemetry的可观测性平台，构建了一个数据、平台、场景打通的一体化可观测方案，具有以下四个特点：
- 一体化：从业务到应用到底子实施，打通Metrics、Logging、Tracing、Event，是一个立体的监控产品体系息争决方案。
- 同一管理：收罗适配云原生、公有云、物理机/虚拟机、混合云等环境。产品层实现多环境、多集群的监控同一管理。
- 集成融合：可集成企业内部已有的可观测配套系统，无需推倒重来，串联打通数据，发挥协同定位的价值。
- 引导定位：结合服务稳定性保障的理论实践，从上往下引导用户按照最佳实践，层层下钻，加快故障处置惩罚。
你可以通过Flashcat平台，有效改善以下问题：
- 盼望整个公司同一用一个工具，就可以支持指标、日志、链路追踪数据的收罗、可视化、告警，免去搭建和维护多套 Prometheus、Zabbix、Grafana、ELK、Jaeger 的工作量。
- 假如有在用多云，并且在多个公有云监控控制台来回切换不方便，盼望监控数据、监控视图都是同一的，有更同等的用户体验，同时降低给所有的工程师开通公有云控制台权限带来的安全隐患。
- 告警太多，工作老被打断， 可以利用我们提供的 OnCall 值班平台（类似于 PagerDuty），支持告警聚合、降噪、认领、升级、排班，可以在飞书、钉钉、企微中接收和处置惩罚告警。
最易被忽视的OnCall
在传统监控领域，OnCall是最容易被技术团队忽视的一个概念，运维和研发职员每每面临以下典范的困扰：
- 技术团队天天接收到大量的告警。
- 许多告警长时间无相应，恒久无人问津。
- 告警与告警之间缺乏关联性，处置惩罚效率低下。
- 告警处置惩罚缺乏协同，处置惩罚过程不透明，信息难以共享，知识难以沉淀。
- 许多告警并未准确反应实际情况，无谓的斲丧技术团队精力。
- 客户/用户每每先于技术团队发现故障，客户满足度连续走低。
- 无法量化的衡量应急相应的现状和效率，无法制定出改进和优化路线。
一个好的 OnCall 工具，可以大概大幅提拔运维和研发职员的效率和幸福感：
- 告警聚合收敛：办理告警风暴问题，按照业界的实践，压缩率为70%~80%。
- 告警全生命周期管理：告警认领、转派、升级，办理告警不能实时处置惩罚、告警漏处置惩罚、告警散落在各个监控系统的问题。
- 告警排班：引入值班表，以排班的形式高效的OnCall，镌汰疏忽和失误，镌汰告警对非值班team的打扰，让团队可连续发展。
- 故障管理：相关的告警聚合为故障，基于故障的告警处置惩罚协作模式，办理跨团队协同不畅的问题。
- ChatOps交互：在电话、短信之外，通过各种IM触达通知技术团队，在IM中交互式的相应和处置惩罚告警。
没有度量就没有改进，在实际工作中，运维负责人表面看到的是告警太多、团队成员疲于奔命，但苦于看不清告警处置惩罚的工作量，没法规划调和补充人力，更严峻的是看不清优化告警的方向，导致情况连续恶化，最终团队散了，故障频发。所以在告警处置惩罚的领域，尤其需要“可观测”，保举关注下面 5 个关键的OnCall度量指标：
- 降噪比：即告警的压缩比，通过算法、规则将众多相关的告警聚合后，再通知到值班职员。告警聚合能有效降低告警风暴，镌汰值班职员的工作量，进步信息处置惩罚的效率（该指标越高越好）。
- 相应比：被认领的告警占所有告警的比例。在告警管理领域，需要相应或者认领的告警，才是有效的告警，因此通过统计和观察“相应比“，能整体的评估告警是否足够有效和有效，并连续的推动提拔告警”相应比“（该指标越高越好）。
- 告警总量：一段时间窗口内产生的告警数量。过高的告警总量，意味着值班的压力越大，对技术团队注意力的干扰越多，埋伏的意味着告警的噪音大概也过大，因此过多的告警，会让整个系统处于不可运维的状态，应该该努力的降低告警总量，譬如采用基于SLO的告警，就可以回复降低该指标（该指标越低越好）。
- MTTA（平均相应或认领用时）：从告警发生到值班职员相应或者认领的时间间隔。越快的 MTTA，标志着越高的告警处置惩罚效率，埋伏的代表着越高的服务稳定性。通过MTTA我们可以有效的度量团队的工作压力，以便决议合适的资源投入，确保团队始终处于可连续发展的状态（该指标合适就好）。
- 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技术都为开辟职员和运维团队提供了更加全面、实时和深入的监控能力。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
