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

什么是可观测性？

可观测性（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 的指标、日志、链路追踪数据进行统一的可视化和分析。

高性能时序数据库代表