概述

通过对业界典型方案的竞品分析，以及深入了解监控的发展历史之后，对选型会有较大帮助。

Zabbix

zabbix是一个基于WEB界面的提供分布式系统监控以及网络监控功能的企业级的开源解决方案。zabbix能监控各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。
zabbix核心由2部分构成，zabbix server与可选组件zabbix agent。zabbix server可以通过SNMP，zabbix agent，ping，端口监控等方法提供对远程服务器/网络状态的监控，数据收集等功能。
zabbix还有一些配套组件，zabbix proxy、zabbix java gateway、zabbix get、zabbix web等，共同组成了zabbix整体架构。

zabbix整体架构

Zabbix的优点：

• 对各种设备的兼容性较好，Agentd不但可以在windows、linux上运行，也可以在aix上运行
• 架构简单，使用数据库做时序数据存储，易于维护，备份转储都较为容易
• 社区庞大，资料多，因为发展的时间比较久，大概12年开源，网上可以找到海量的资源
  Zabbix的缺点：
• 使用数据库做存储，无法水平扩展，容量有限，如果采集频率较高，比如10秒，上限大约可以监控600台设备
• Zabbix面向资产的管理逻辑，数据结构较为固化，没有灵活的标签设计，面对云原生架构下动态多变的环境，显得力不从心

Open-Falcon

Open-Falcon出现在Zabbix之后，Open-Falcon开发的初衷，就是解决Zabbix的容量问题，Open-Falcon最初来自小米公司，14年，小米有3套Zabbix，一套业务性能监控系统perfcounter，Open-Falcon初衷是想做一套大一统的方案，来解决这个乱局。

Open-Falcon

Open-Falcon基于rrdtool做了一个分布式时序存储组件graph，这种做法可以把多台机器组成一个集群，大幅提升整个集群的处理能力，前面负责转发的组件是transfer，transfer对监控数据求取一个唯一ID，再对ID做哈希，即可生成监控数据和graph组件的对应关系，这就是Open-Falcon架构中最核心的逻辑。

• 告警部分使用judge模块来做
• 发送告警事件的是alarm模块
• 采集数据的是agent
• 负责心跳的模块是hbs
• 负责聚合的模块是aggregator
• 负责处理数据缺失的模块是nodata
• 负责用户交互的portal/dashboard模块
  Open-Falcon把组件拆的比较散，组件就会比较多，部署起来略麻烦，不过每个组件的职能单一，二开会比较容易。
  Open-Falcon的优点：
• 可以处理大规模的监控场景，比Zabbix的容量要大的多，不止可以处理设备、中间件层面的监控问题，也可以处理应用层面的监控问题，最终替换掉了小米内部的perfcounter
• 组件拆分的比较散，大都是用go语言开发，web部分是用python，易于做二开，做魔改
  Open-Falcon的缺点：
• 生态不够庞大，是小米公司在主导，很多公司做了二开，但是都没有回馈社区，这个跟Open-Falcon的生态框架较差有关，有一些贡献者，也比较琐碎，相比Telegraf那样的方式，相差太大
• 开源软件的治理架构不够优秀，小米公司的核心开发人员离职，项目就停滞不前了，小米公司也没有后续大的治理投入，相比托管在基金会的项目，缺少了生命力

时序数据库异军突起

指标监控系统的架构中，最核心的部分是时序库，Zabbix直接使用DBMS，DBMS擅长处理的是事务场景，没有针对时序场景做优化，Open-Falcon就用rrdtool攒了一个，但是rrdtool本身的设计就有问题，对硬盘IO的要求太高，散文件太多，性能较差，Falcon-Graph是分布式的，可以通过堆机器来解决大规模的问题，但显然不是最优解。
于是，各种专门解决时序存储问题的数据库横空出世，比较有代表性的有：OpenTSDB、InfluxDB、TDEngine、M3DB、VictoriaMetrics、TimescaleDB 等。

OpenTSDB

OpenTSDB出来的挺早，2010年左右就有了，是基于HBase封装的，后来OpenTSDB持续发展，也有了基于Cassandra封装的版本。
OpenTSDB的数据模型很简单，包含四部分：metric（指标名称）、tags（维度标签）、timestamp（时间戳）、value（值），这种设计很灵活，后面很多时序库的数据结构都借鉴了这种设计，当然，会有小的优化，OpenTSDB确实是很好的先驱。
由于底层存储是基于HBase的，一般小公司都玩不转，所以OpenTSDB在国内的受众相对较小，当下2022年，再选型时序数据库，已经很少有人会选择OpenTSDB了。这里就不做过多介绍。

InfluxDB

InfluxDB来自InfluxData，19年D轮融资6000万美金，是一个创业公司做的项目，也拿到了不错的融资，所以开发人员不担心养家糊口的问题，做的产品还是非常不错的。
InfluxDB针对时序存储的场景做了专门的设计，专门设计了存储引擎、数据结构、存取接口，国内用的人挺多，而且InfluxDB可以和Grafana良好整合看图，组织社区开发了Telegraf采集器，整个生态是非常完备的。
不过InfluxDB开源版本是单机的，没有开源集群版本，毕竟是商业公司，需要赚钱实现良性发展，这个点是需要大家斟酌的。

TDEngine

姑且可以看做是国产版InfluxDB，Github的Star数上万，针对物联网设备的场景做了优化，性能很好，相比InfluxDB，生态上差一些，适合有自研能力的团队，使用TDEngine处理偏设备监控的场景。
TDEngine的集群版也是开源的，也可以兼容Telegraf采集器，创始人陶建辉也有非常高的技术热情，TDEngine也拿到了很高的融资，有粮草，未来可期。

M3DB

这是来自Uber的时序数据库，声称在Uber抗住了66亿Series，这个量是非常庞大的，M3DB是全开源的，包括集群版，不过架构原理上比较复杂，CPU和内存占用较高，在国内没有大规模推广起来。M3DB的架构代码中包含很多分布式系统设计的知识，是个可以拿来学习的好项目。

VictoriaMetrics

VictoriaMetrics，简称VM，架构上非常简单清晰，采用merge read方式，避免了数据迁移问题，搞一批云上虚拟机，挂上云硬盘，部署VM集群，使用单副本，是非常轻量可靠的集群方式。
VM实现了Prometheus的Querier接口，即 /api/v1/query
/api/v1/query_range
/api/v1/label/<label-key>/values
相关的接口，是Prometheus的一个非常好的Backend。

TimescaleDB

Timescaledb是 timescale.inc开发的一款兼容sql的时序数据库， 底层存储架构在postgresql上。作为一个postgresql的扩展提供服务。
因为是基于postgres的，所以，postgres生态四十年的积累，就是巨人的肩膀。比如对于保障数据安全，因为程序可能随时会崩溃，服务器可能会遇到电源问题或硬件故障，磁盘可能损坏或者夯住，这些极端场景都需要完善的解决方案来处理。postgres社区已经有了现成的高可用特性，包括完善的流复制和只读副本，数据库快照功能，增量备份和任意时间点恢复，wal支持，快速导入导出工具等。而其他时序库，这些问题都要从头解决。
但是传统数据库是基于btree做索引的，数据量到百亿或者千亿行，btree会大到内存都存不下，产生频繁的磁盘交换，数据库性能会显著下降。另外，时序数据的场景是写入量特别大，postgres面对大量的插入性能也不理想。那 TimescaleDB 就要解决这些问题。

新一代整体方案代表 Prometheus

Prometheus的思路来自Google的Borgmon，师出名门，就像Borgmon是为Borg而生，Prometheus就是为Kubernetes而生。Prometheus针对Kubernetes做了直接的支持，提供了Kubernetes的服务发现机制，大幅简化了Kubernetes的监控。
在Kubernetes环境下，POD创建和销毁非常频繁，Series生命周期大幅缩短，这导致类似Zabbix这种面向资产的监控系统力不从心，而且云原生环境下大都是微服务设计，服务数量变多，指标量也成爆炸态势，这就对时序数据存储提出了非常高的要求。
Prometheus1.0的版本设计较差，从2.0开始，对时序库做了重新设计，性能、可靠性都要好很多，另外社区涌现了越来越多的Exporter采集器，非常繁荣。Prometheus的架构如下：

Prometheus

Prometheus的优点：

• 对Kubernetes支持得好，目前来看，Kubernetes监控，基本Prometheus就是标配
• 生态庞大，有各种各样的Exporter，也有良好的SDK供业务代码嵌入埋点
  Prometheus的缺点：
• 易用性差一些，比如告警策略需要修改配置文件，协同起来较为麻烦，当然了，对于IaC落地较好的公司，反而认为这样更好，不过国内的当下环境来看，还无法走得这么靠前
• Exporter参差不齐，通常是一个监控目标一个Exporter，管理起来略麻烦
• 容量问题，Prometheus默认只提供单机时序库，集群方案需要依赖其他的时序库

新一代国产代表 Nightingale

Nightingale 可以看做是 Open-Falcon 的一个延续，因为开发人员是一拨人，不过两个软件的定位截然不同，Open-Falcon 类似 Zabbix，更多的是面向机器设备的，Nightingale 则不止是解决设备和中间件的监控，也希望能一并解决云原生环境下的监控问题。
但是在 Kubernetes 环境下，Prometheus 已经大行其道，再重复造轮子意义不大，所以 Nightingale 的做法是可以和 Prometheus 做良好整合，打造一个更完备的方案。当下的架构，可以把 Prometheus 作为一个时序库，作为 Nightingale 的一个数据源，如果不使用 Prometheus 也没问题，比如使用 VictoriaMetrics 作为时序库，也是很多公司的选择。
采集层面，Nightingale支持多种采集器，比如 Telegraf、Datadog-Agent、Grafana-Agent、Prometheus Exporters、Categraf 等。同时，Nightingale 也实现了 Prometheus 的 remote write 协议接口，可以作为 Prometheus 的 backend，即：可以把 Prometheus 作为一个采集器，采集数据推给 Nightingale，新版本的 Prometheus 支持 agent mode，是一个挺好的落地方式。
Nightingale的优点：

• 兼容并包，生态开放，可以和 Grafana、Telegraf、Prometheus、Thanos 等良好整合
• 提供了一套UI，便于协同，特别是那些想要把 Prometheus 的能力开放给全公司的场景非常合适
• Nightingale之于Prometheus，就像OpenShift之于Kubernetes，提供了很多扩展能力，比如告警自愈贯通、快捷视图、历史告警存档检索、活跃告警聚合视图、权限体系等等
  Nightingale的缺点：
• 服务比较多，部署起来会比较费劲

• 比较专业，小白使用有比较大的成本

  
  Nightingale

参考

龙渊秦五专栏连载：《说透运维监控系统》