可观测性与监控的区别和联系
什么是可观测性？可观测性（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.
传统监控的局限
从核心出发点来讲，传统的监控和可观测性，背后解决的是同样的问题，就是及时、准确的掌握系统的运行状况，提升对系统运行的控制能力。
1、侧重于依赖“经验主义”，应对“已知问题”
传统监控，要预先知晓采集哪些指标，添加什么样的告警策略，定制什么样的仪表盘，以便发现某种类型的故障后，采用什么样的 Runbook 来应对。比如技术团队根据过往经验，知道一台服务器上打开的文件句柄数量不能太多，超过某个上限就会影响到网络通信以及文件读写，因此我们会采集一个 node_filefd_allocated 的指标，然后配置一个告警策略：当 node_filefd_allocated > 1000k 则触发告警，同时我们会提前制作一个 Linux 主机 Dashboard，其中包含有 node_filefd_allocated 的趋势图。准备好这些工作之后，接下来就是守株待兔，等待告警的触发，值班的技术团队就可以按照 Runbook 中载明的排查步骤，检查是否有进程泄露文件句柄，或者是否有大量的网络链接建立等等。
经验主义，总是有限的，无法预知可能发生的各种未知的故障。因此在实际情况中，告警策略的完善往往靠“故障复盘”来驱动，每次故障复盘后，必定会有的一个改进项：继续完善监控、加更多的告警。技术团队总会处于一种对未知故障缺乏掌控的不安全的状态中，产生焦虑感，反过来又会促使技术团队添加更多的监控，久而久之，告警会越加越多，却又永远不够，告警风暴就这样产生了。
2、告警驱动的传统监控，缺乏对故障的全局感知
在传统监控中，告警充当着举足轻重的作用。当使用传统监控方式，发出某个告警之后，值班的技术团队看到的只是一个孤立的”技术问题“，这个技术问题的影响面有多大，重要程度如何，是否需要立即处理，是否需要上升和协同，很难快速的做出判断。某个”技术问题“是否重要，是否紧急，不取决于该技术问题本身的难易程度，也不取决于所涉及的服务器规模多寡，唯一的衡量标准是”对用户体验产生的影响有多大“。使用传统监控无法快速的评估某个告警事件和用户体验之间的必然联系，导致无法投入准确的应急处置资源，无法确定合理的应急响应时效，也无法和其他资源产生有效的联动协同，最终使得稳定性保障工作效率低下。
3、传统监控认为，系统的开发者和系统的维护者，职责是相对分割的
系统在设计之初，开发者的重心在于完成必备的业务逻辑，对于自身运行状态的暴露，并没有考虑的很完善甚至有时候都没有考虑。大家可能会经常遇到，做的好的开发者可能还会打印较为详细的日志，做的不好的，连日志也打的不全，更不必说提供主动暴露系统状态的 Metrics 接口或者为实现 Tracing 进行埋点了。一旦系统到了上线运行阶段，维护人员接手后，往往只能开启“外挂”模式，通过写各种各样的脚本，去探测进程是否存在、去分析匹配日志中是否有关键的错误字段。如果要进一步统计系统的访问量、访问延迟、资源消耗等等，就会更加被动。“外挂”往往是传统监控数据采集的特征。
4、传统监控面向的通常是基础设施，Metrics是传统监控的基础
基础设施的变化较慢，且变化带来的结果相对可预测。Metrics 类型的监控指标，具有采集存储成本低、简单直观、易于聚合计算的特点，因此在过去的二三十年里，基于 Metrics 为基础，出现了各种各样的采集器、时序数据库、可视化工具、告警工具等，基于前面提到的”经验主义“，尚能应付面向基础设施的稳定性保障工作。
传统监控工具发展的三个阶段
阶段1：Metrics监控0.1时代
互联网流行前，擅长于局部场景，部分产品到现在仍然被广泛使用：
[*]Cacti：2001年9月，一个名叫Lan Berry的高中生，当时他还在为一家小的ISP厂商工作，为了更好地监控网络质量，开发了Cacti的第一个版本，基于RRDtool，提供更友好的使用体验。
[*]Nagios：Nagios可谓是早期告警方向事实上的工业标准，可以用来监控主机和网络基础设施，以及各种应用服务。在监控对象出现问题时，及时发送邮件或者短信通知相关人员；当问题解决后，发送恢复信息。一段时间的主流，后来以难用闻名。
[*]Ganglia：UC Berkeley发起的一个开源集群监视项目，设计用于测量数以千计的节点。主要是用来监控系统性能，如：cpu 、mem、硬盘利用率， I/O负载、网络流量情况等。
[*]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监控1.0时代
互联网快速发展的时代，监控作为整体产品一体化的体验提升：
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监控2.0时代
云原生微服务时代：
Prometheus
由前 Google 工程师从 2012 年开始在 Soundcloud 以开源软件的形式进行研发的系统监控和告警工具包，产品设计源于Google的Borgmon。Prometheus 的开发者和用户社区非常活跃，Prometheus 于 2016 年 5 月加入 CNCF 基金会，成为继 Kubernetes 之后的第二个 CNCF 托管项目。
Nightingale
夜莺是一个 All-in-One 的云原生监控工具，集合了 Prometheus 和 Grafana 的优点，您可以在 UI 上管理和配置告警策略，也可以对分布在多个 Region 的指标、日志、链路追踪数据进行统一的可视化和分析。夜莺监控，由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。
高性能存储代表
[*]Prometheus：Prometheus自带的高性能单机存储数据库；
[*]InfluxDB：支持按标签存储查询，该领域最著名的存储之一；
[*]TDengine：国内最著名的开源时序数据存储之一，面向IoT领域，表结构存储，支持SQL查询；
[*]TimescaleDB：表结构存储的代表，支持SQL查询；
[*]VictoriaMetrics：被广泛应用的标签存储时序数据库，和prometheus做了无缝兼容；
[*]M3DB：高性能可扩展时序数据库，支持按标签存储查询，兼容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后，可观测的三要素日志、链路追踪、指标，将从过去的相互独立，变的关联性更强，方便我们进行更快速的问题定位：
OTelFlashcat
是一个兼容OpenTelemetry的可观测性平台，构建了一个数据、平台、场景打通的一体化可观测方案，具有以下四个特点：
[*]一体化：从业务到应用到基础实施，打通Metrics、Logging、Tracing、Event，是一个立体的监控产品体系和解决方案。
[*]统一管理：采集适配云原生、公有云、物理机/虚拟机、混合云等环境。产品层实现多环境、多集群的监控统一管理。
[*]集成融合：可集成企业内部已有的可观测配套系统，无需推倒重来，串联打通数据，发挥协同定位的价值。
[*]引导定位：结合服务稳定性保障的理论实践，从上往下引导用户按照最佳实践，层层下钻，加速故障处理。
你可以通过Flashcat平台，有效改善以下问题：
[*]希望整个公司统一用一个工具，就可以支持指标、日志、链路追踪数据的采集、可视化、告警，免去搭建和维护多套 Prometheus、Zabbix、Grafana、ELK、Jaeger 的工作量。
[*]如果有在用多云，并且在多个公有云监控控制台来回切换不方便，希望监控数据、监控视图都是统一的，有更一致的用户体验，同时降低给所有的工程师开通公有云控制台权限带来的安全隐患。
[*]告警太多，工作老被打断， 可以利用Flashcat提供的 OnCall 值班平台（类似于 PagerDuty），支持告警聚合、降噪、认领、升级、排班，可以在飞书、钉钉、企微中接收和处理告警。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]