常见监控告警系统对比分析

目录

• 监控告警系统的总体介绍
• 常见的监控告警系统介绍
  • Prometheus
    • 架构
    • Prometheus Server
    • Metric Type
    • Prometheus Exporter
  • AlertManager
    • 架构
  • Open-Falcon
    • 架构
    • Data model
    • Data collection
    • Alert
    • Heartbeat server
  • Zabbix
    • Zabbix组件图
      • Zabbix Server
      • Zabbix Database
      • Zabbix Web
      • Proxy
      • Agent
  • InfluxData
    • TICK技术栈
    • InfluxDB metric type
    • Kapacitor
  • Bosun
  • Unisphere Unity300
• 对比分析
• References

---

监控告警系统的总体介绍

监控告警系统的实现各有不同，大致如下所述。

• 在数据采集方面，有的监控系统采用主动采集方式，有的监控系统采用被动上报方式，有的监控系统采用上述两者兼备的方式。
• 在数据传输方面，有的监控系统采用socket传输，有的监控系统采用HTTP传输。
• 在数据存储方面，有的监控系统将监控数据保存在MySQL中，有的监控系统将数据保存在MongoDB，OpenTSDB, InfluxDB等时序数据库中。

但是，所有的监控告警系统的核心都是采集和处理数据。

监控系统通常由指标采集子系统和数据处理子系统组成。

• 指标采集子系统主要负责信息采集，过滤，汇总和存储。

• 数据处理子系统主要负责数据分析，展现，预警，告警动作触发和告警等。

  
  

---

常见的监控告警系统介绍

常见的监控告警系统主要有Prometheus，Prometheus AlertManager，Zabbix，Open-Falcon， Bosun， InfluxData， Unity300等。下面分别进行简单的介绍和对比分析。

Prometheus

Prometheus是由SoundCloud公司开发的开源告警系统并且带时序数据库，基于Go语言开发。

架构

Prometheus的基本原理是通过HTTP周期性地抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。其架构图及其生态系统组件图如下所示。

Prometheus Server

Prometheus Server是Prometheus的核心，根据配置完成数据采集，服务发现以及数据存储 ，推送告警，以及提供PromQL查询语言的支持。

• Prometheus Server负责定时在目标上抓去Metrics数据，每个抓取目标都需要暴露一个HTTP服务接口用于Prometheus定时抓取。这种调用监控对象获取监控数据的方式成为Pull。Pull方式可以降低耦合，通过Pull方式，被采集端无须感知监控系统的存在，完全独立于监控系统之外，这样数据的采集完全由监控系统控制，增强了整个系统的稳定性。
• Prometheus Server通过如下两种方式获取监控对象。
  • 通过配置文件，文本文件等进行静态配置。
  • 支持Kubernetes，file_sd，Consul等方式进行动态发现。
• Storage通过一定的规则清理和整理数据，并把得到的结果存储到新的时间序列中，主要有两种存储方式。
  • 本地存储。通过Prometheus自带的时序数据库保存到本地磁盘。
  • 远端存储。通过中间层的适配器的转化，目前Prometheus支持OpenTSDB， InfluxDB，ElasticSearch等后端存储。
• Prometheus通过PromQL和其他API可视化地展示收集的数据。
• AlertManager是独立于Prometheus的一个组件，在触发了预先设置在Prometheus中的告警规则后，Prometheus便会push告警信息到AlertManager。

Metric Type

Prometheus的所有监控指标（Metric）被统一定义为：

{=, ...}

其中指标名称说明指标的含义，标签可以体现指标的维度特征，用于过滤和聚合。

Prometheus的Client Library提供度量的四种基本类型包括: Counter（计数器）, Gauge（仪表盘）, Histogram（柱状图）, Summary（概要）。

Prometheus Exporter

AlertManager

Alertmanager作为一个独立的组件，负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告警信息。Alertmanager可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且路由到正确的通知方，Prometheus内置了对邮件，Slack等多种通知方式的支持，同时还支持与Webhook的集成，以支持更多定制化的场景。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。

1. 客户端通过POST请求向AlertManager推送告警信息。
2. 每条告警信息中的labels可用于唯一识别告警信息并用于去重。

[
  {
    "labels": {
      "alertname": "",
      "": "",
      ...
    },
    "annotations": {
      "": "",
    },
    "startsAt": "",
    "endsAt": "",
    "generatorURL": ""
  },
  ...
]

架构

AlertManager主要分为两个部分，路由(router)和接收器(receiver)。告警消息先被经过路由树，然后被分配到对应的接收器中。路由树是由预先设定的路由规则生成的。其高可用架构如上图所示，具体流程如下：

1. Prometheus会通过调用AlertManager提供的告警接口将原始的告警消息发送到AlertManager。
2. AlertManager的API除了接收告警，还接收静默请求，将其分别保存到各自的provider里。
3. provider提供了一个订阅（subscribe）接口，这样Dispatcher组件便可以获取告警数据，并对数据进行分组，通过用户预先设置的规则进入告警抑制阶段或静默阶段。
4. 如果通过了上面的告警静默阶段，则进入路由分发阶段，最终发送通知。

Open-Falcon

Open-Falcon是小米公司开源的一款监控与告警系统，已被多家国内互联网公司所使用，基于Go语言开发。

架构

Data model

open-falcon采用和opentsdb相同的数据格式：metric、endpoint加多组key value tags。例如：

{
    metric: load.1min,
    endpoint: open-falcon-host,
    tags: srv=falcon,idc=aws-sgp,group=az1,
    value: 1.5,
    timestamp: `date +%s`,
    counterType: GAUGE,
    step: 60
}

Data collection

falcon-agent用于采集各项基础监控数据指标，主动上报，不需要用户在server做任何配置。falcon-agent还可以执行用户自定义的插件返回的数据。同时falcon-agent提供了一个proxy-gateway，用户可以方便的通过http接口，push数据到本机的gateway，gateway会帮忙高效率的转发到server端。

transfer接收客户端发送的数据，做一些数据规整，检查之后，转发到多个后端系统去处理。在转发到每个后端业务系统的时候，transfer会根据一致性hash算法，进行数据分片，来达到后端业务系统的水平扩展。transfer目前支持三种业务后端，分别为judge、graph、opentsdb。其中judge是告警判定组件，graph是数据存储、归档、查询组件，opentsdb是开源的时间序列数据存储服务。

Alert

Judge组件用户告警的判定。用户在web portal来配置相关的报警策略，存储在MySQL中。heartbeat server 会定期加载MySQL中的内容。judge也会定期和heartbeat server保持沟通，来获取相关的告警策略。

Heartbeat server

heartbeat sever从数据库中加载模板策略，根据模板继承、模板项覆盖、报警动作覆盖、模板和hostGroup绑定，计算出最终关联到每个endpoint的告警策略，提供给judge组件来使用。

Zabbix

Zabbix 是由 Alexei Vladishev 开发的一种网络监视、管理系统，支持多种采集方式和采集客户端，同时支持SNMP，IPMI，JMX，Telnet，SSH等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。

Zabbix组件图

Zabbix Server

Zabbix的核心组件，由C语言编写，主要负责接收Agent发送的监控信息，并进行汇总存储。Zabbix Server主要包括三个方面的工作。

1. 设备注册。
   • 手动配置Agent地址。
   • 自动发现机制。
2. 数据收集。采集到数据首先会被放置在内存中，然后被批量保存在数据库中。
   • 主动收集
   • 被动接收
3. 定期的数据清理和告警触发。

Zabbix Database

用于存储配置信息以及收集的监控数据。后端数据库支持MySQL，PostgreSQL，Oracle等，并提供Zabbix Web页面的数据查询方式。由于采用关系型数据库存储时序数据，所以Zabbix在监控大规模集群时常常在数据存储方面捉襟见肘。

Zabbix Web

Zabbix的GUI组件，由PHP编写。通常于Server运行在同一台主机上。提供监控数据的展现和系统配置，主要配置包括监控模板，告警等。

Proxy

主要解决两个问题。

• Server和Agent之间网络不通。
• 大规模部署时减轻Server的压力。

Agent

部署在被监控主机上，负责收集本地数据并发往Server端或Proxy端，Agent端会启动一个Agentd的守护进程。

• 主动
• 被动

InfluxData

TICK技术栈

TICK技术栈是InfluxData 平台提供的监控方案，代表了用于解决时序数据库问题的四个组件：Telegraf（数据收集器）、InfluxDB（时序数据库）、Chronograf（可视化 UI）和 Kapacitor（处理和监控服务）。

InfluxDB metric type

InfluxDB与传统数据库的比较

InfluxDB	MySQL
database	数据库
measurement	数据库中的表
points	表里面的一行数据

InfluxDB的数据类型

[,=...] =[,=...] [unix-nano-timestamp]

InfluxDB数据的构成：Point由时间戳（time）、数据（field）、标签（tags）组成。

Pointer属性	传统数据库中的概念
fields	各种记录值（没有索引的属性）也就是记录的值：温度， 湿度
tags	各种有索引的属性：地区，海拔
time	每个数据记录时间，是数据库中的主索引(会自动生成)

Kapacitor

Kapacitor 是TICK技术栈的告警服务，用户通过tickScript脚本来对时序数据库当中的数据进行过滤，筛选，批处理等进行告警，告警信息可以通过日志保存在本地，或回插到InfluxDB，还可以直接在告警产生后发起http请求到指定地址，kapacitor支持数据流（stream）和批处理（batch）数据。

kapacitor是一个脚本定义告警规则服务，与InfluxDB强相关，安装kapacitor后通过配置kapacitor.conf文件来配置和InfluxDB连接（通常是与InfluxDB开放的本地端口8086连接）

Example：

stream
  |from()
    .measurement('cpu')
    .where(lambda: "host" == 'serverA')
    .groupBy('host')
  |alert()
    .id('kapacitor/{{ index .Tags "service" }}')
    .message('{{ .ID }} is {{ .Level }} value:{{ index .Fields "value" }}')
    .info(lambda: "value" > 60)
    .warn(lambda: "value" > 70)
    .crit(lambda: "value" > 80)
    .post("http://example.com/api/alert")
    .post("http://another.example.com/api/alert")
    .tcp("exampleendpoint.com:5678")
    .email('[email protected]')

Bosun

Unisphere Unity300

对比分析

监控与告警系统	开发语言	成熟度	配置	可扩展性	故障域	性能	告警源	告警目标	社区活跃度	对容器的支持	企业使用度
Zabbix	C + PHP	高	基于模版	高	大，集成	低	多通道	多通道	中	低	高
Prometheus	Go	高	基于模版	高	小，单组件	高	多通道	多通道	高	高	高
Open-Falcon	Go + Python	中	树形结构	高	小，单组件	高	多通道	多通道	中	中	中 （主要是国内企业使用，包括美团，滴滴，360等）
InfluxDB	Go	高		高	小，单组件	高	多通道	多通道	高		高
Bosun	Go
Unity300											Dell EMC产品

References

• Prometheus overview
• alertmanager
• AlertManager
• open-falcon
• zabbix
• influxdata
• bosun
• Gossip算法
• AlertManager clients
• kapacitor 1.5 document
• 打造“云边一体化”，时序时空数据库TSDB技术原理深度解密