传统监控的局限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 为基础,出现了各种各样的采集器、时序数据库、可视化工具、告警工具等,基于前面提到的”经验主义“,尚能应付面向基础设施的稳定性保障工作。
阶段2:Metrics监控1.0时代
- 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界面,它允许用户浏览度量数据和图。
阶段3:Metrics监控2.0时代
- Open-Falcon的初衷就是解决zabbix在大数据量情况下无法扩展伸缩的问题;
- Open-Falcon引入了标签概念,这个特性让监控数据的分析变得非常灵活而强大,是下一代监控的主要特点之一;
- Zabbix的用户体验在当时不太符合中国工程师的习惯;
- Open-Falcon借助小米互联网公司的影响获得快速推广;
- Zabbix基于C语言开发,而Open-Falcon基于Go语言开发,在二开上更为友好;
- Open-Falcon的中文文档和支持能力;
可观测性的特点
- Prometheus:Prometheus自带的高性能单机存储数据库;
- InfluxDB:支持按标签存储查询,该领域最著名的存储之一;
- TDengine:国内最著名的开源时序数据存储之一,面向IoT领域,表结构存储,支持SQL查询;
- TimescaleDB:表结构存储的代表,支持SQL查询;
- VictoriaMetrics:被广泛应用的标签存储时序数据库,和prometheus做了无缝兼容;
- M3DB:高性能可扩展时序数据库,支持按标签存储查询,兼容prometheus,扩展性比VictoriaMetrics好,但运维更复杂;
- Mimir:Grafana于2022年3月30日发布的时序数据存储,完全兼容prometheus生态;
OpenTelemetry
- 相比单体应用,技术团队面临着更多的服务需要管理;
- 很多服务之间都是松耦合,而且像云数据库、云存储、第三方API等服务,都不处于你的掌控之下;
- 代码的发布和变更,频率越来越高,持续集成、持续发布成为主流;
- 基础设施动态化,容量也在动态的弹性伸缩;
- 现代化的系统架构下,可能出现故障的点位越来越多,”长尾问题“出现的频率也越来越高,难以定位和分析;
- 研发工程师更多的参与到系统的运行维护工作中来;
欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) | Powered by Discuz! X3.4 |