监控系统对比
监控系统对比
开源监控系统也经历了非常多的迭代：
- 老牌监控系统：Zabbix, Nagios, Cacti, Ganglia, Garafana
- 新型监控系统：Open-Falcon, Prometheus
Zabbix
- **Zabbix Server：
** 核心组件，C 语言编写，负责接收Agent 、Proxy 发送的监控数据，也支持JMX 、SNMP 等多种协议直接采集数据。同时，它还负责数据的汇总存储以及告警触发等。 - **Zabbix Proxy：
** 可选组件，对于被监控机器较多的情况下，可使用Proxy 进行分布式监控，它能代理Server 收集部分监控数据，以减轻Server 的压力。 - **Zabbix Agentd：
** 部署在被监控主机上，用于采集本机的数据并发送给Proxy 或者Server ，它的插件机制支持用户自定义数据采集脚本。Agent 可在Server 端手动配置，也可以通过自动发现机制被识别。数据收集方式同时支持主动Push 和被动Pull 两种模式。 - **Database：
** 用于存储配置信息以及采集到的数据，支持MySQL 、Oracle 等关系型数据库。同时，最新版本的Zabbix 已经开始支持时序数据库，不过成熟度还不高。 - **Web Server：
**Zabbix 的GUI 组件，PHP 编写，提供监控数据的展现和告警配置。
优势
** 产品成熟：** 由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景。** 采集方式丰富：** 支持Agent 、SNMP、JMX、SSH 等多种采集方式，以及主动和被动的数据传输方式。- 较强的扩展性：支持
Proxy 分布式监控，有agent 自动发现功能，插件式架构支持用户自定义数据采集脚本。 - 配置管理方便：能通过
Web 界面进行监控和告警配置，操作方便，上手简单。
缺陷
- 性能瓶颈：机器量或者业务量大了后，关系型数据库的写入一定是瓶颈，官方给出的单机上限是
5000 台，个人感觉达不到，尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库，不过成熟度还不高。 ** 应用层监控支持有限：** 如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能） ，zabbix 没有提供对应的sdk ，通过插件式的脚本也能曲线实现此功能，个人感觉zabbix 就不是做这个事的。- 数据模型不强大：不支持
tag ，因此没法按多维度进行聚合统计和告警配置，使用起来不灵活。 - 方便二次开发难度大：
Zabbix 采用的是C 语言，二次开发往往需要熟悉它的数据表结构，基于它提供的API 更多只能做展示层的定制。
ELK 监控生态
下图是
下图是服务器的
Open-Falcon
-
Falcon-agent：用
Go 语言开发的Daemon 程序，运行在每台Linux 服务器上，用于采集主机上的各种指标数据，主要包括CPU 、内存、磁盘、文件系统、内核参数、Socket 连接等，目前已经支持200 多项监控指标。并且，Agent 支持用户自定义的监控脚本。 -
Hearthbeat server：简称
HBS 心跳服务，每个Agent 都会周期性地通过RPC 方式将自己的状态上报给HBS ，主要包括主机名、主机IP 、Agent 版本和插件版本，Agent 还会从HBS 获取自己需要执行的采集任务和自定义插件。 -
Transfer：负责接收
Agent 发送的监控数据，并对数据进行整理，在过滤后通过一致性Hash 算法发送到Judge 或者Graph 。 -
Graph：
RRD 数据上报、归档、存储的组件。Graph 在收到数据以后，会以RRDtool 的数据归档方式来存储，同时提供RPC 方式的监控查询接口。 -
Judge：告警模块，
Transfer 转发到Judge 的数据会触发用户设定的告警规则，如果满足，则会触发邮件、微信或者回调接口。这里为了避免重复告警引入了Redis 暂存告警，从而完成告警的合并和抑制。 -
Dashboard：面向用户的监控数据查询和告警配置界面。
优势
- 自动采集能力：
Falcon-agent 能自动采集服务器的200 多个基础指标（比如CPU 、内存等） ，无需在server 上做任何配置，这一点可以秒杀Zabbix. - 强大的存储能力：底层采用
RRDTool ，并且通过一致性hash 进行数据分片，构建了一个分布式的时序数据存储系统，可扩展性强。 ** 灵活的数据模型：** 借鉴OpenTSDB ，数据模型中引入了tag ，这样能支持多维度的聚合统计以及告警规则设置，大大提高了使用效率。** 插件统一管理：**Open-Falcon 的插件机制实现了对用户自定义脚本的统一化管理，可通过HeartBeat Server 分发给agent ，减轻了使用者自主维护脚本的成本。- 个性化监控支持：基于
Proxy-gateway ，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求，集成方便。
缺陷
** 整体发展一般：** 社区活跃度不算高，同时版本更新慢，有些大厂是基于它的稳定版本直接做二次开发的，关于以后的前景其实有点担忧。UI 不够友好：对于业务线的研发来说，可能只想便捷地完成告警配置和业务监控，但是它把机器分组、策略模板、模板继承等概念全部暴露在UI 上，感觉在围绕这几个概念设计UI ，理解有点费劲。** 安装比较复杂：** 个人的亲身感受，由于它是从小米内部衍生出来的，虽然去掉了对小米内部系统的依赖，但是组件还是比较多，如果对整个架构不熟悉，安装很难一蹴而就。
Prometheus
- **Prometheus Server：
** 核心组件，用于收集、存储监控数据。它同时支持静态配置和通过Service Discovery 动态发现来管理监控目标，并从监控目标中获取数据。此外，Prometheus Server 也是一个时序数据库，它将监控数据保存在本地磁盘中，并对外提供自定义的PromQL 语言实现对数据的查询和分析。 - **Exporter：
** 用来采集数据，作用类似于agent ，区别在于Prometheus 是基于Pull 方式拉取采集数据的，因此，Exporter 通过HTTP 服务的形式将监控数据按照标准格式暴露给Prometheus Server ，社区中已经有大量现成的Exporter 可以直接使用，用户也可以使用各种语言的client library 自定义实现。 - **Push gateway：
** 主要用于瞬时任务的场景，防止Prometheus Server 来pull 数据之前此类Short-lived jobs 就已经执行完毕了，因此job 可以采用push 的方式将监控数据主动汇报给Push gateway 缓存起来进行中转。 - **Alert Manager：
** 当告警产生时，Prometheus Server 将告警信息推送给Alert Manager ，由它发送告警信息给接收方。 - **Web UI：
**Prometheus 内置了一个简单的web 控制台，可以查询配置信息和指标等，而实际应用中我们通常会将Prometheus 作为Grafana 的数据源，创建仪表盘以及查看指标。
优势
** 轻量管理：** 架构简单，不依赖外部存储，单个服务器节点可直接工作，二进制文件启动即可，属于轻量级的Server ，便于迁移和维护。- 较强的处理能力：监控数据直接存储在
Prometheus Server 本地的时序数据库中，单个实例可以处理数百万的metrics 。 ** 灵活的数据模型：** 同Open-Falcon ，引入了tag ，属于多维数据模型，聚合统计更方便。** 强大的查询语句：**PromQL 允许在同一个查询语句中，对多个metrics 进行加法、连接和取分位值等操作。- 很好地支持云环境：能自动发现容器，同时
K8s 和etcd 等项目都提供了对Prometheus 的原生支持，是目前容器监控最流行的方案。
缺陷
** 功能不够完善：**Prometheus 从一开始的架构设计就是要做到简单，不提供集群化方案，长期的持久化存储和用户管理，而这些是企业变大后所必须的特性，目前要做到这些只能在Prometheus 之上进行扩展。- 网络规划变复杂：由于
Prometheus 采用的是Pull 模型拉取数据，意味着所有被监控的endpoint 必须是可达的，需要合理规划网络的安全配置。
综合对比
从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从
从系统成熟度上看，
从系统扩展性方面看，
从数据存储方面来看，
从配置和维护的复杂度上看，
从社区活跃度上看，目前
从容器支持角度看，由于