目录
- 监控告警系统的总体介绍
- 常见的监控告警系统介绍
- 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
- Zabbix组件图
- InfluxData
- TICK技术栈
- InfluxDB metric type
- Kapacitor
- Bosun
- Unisphere Unity300
- Prometheus
- 对比分析
- 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）被统一定义为：
<metric_name>{<label_name>=<label_value>, ...}
其中指标名称说明指标的含义，标签可以体现指标的维度特征，用于过滤和聚合。
Prometheus的Client Library提供度量的四种基本类型包括: Counter（计数器）, Gauge（仪表盘）, Histogram（柱状图）, Summary（概要）。
Prometheus Exporter
AlertManager
Alertmanager作为一个独立的组件，负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告警信息。Alertmanager可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且路由到正确的通知方，Prometheus内置了对邮件，Slack等多种通知方式的支持，同时还支持与Webhook的集成，以支持更多定制化的场景。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。
- 客户端通过POST请求向AlertManager推送告警信息。
- 每条告警信息中的labels可用于唯一识别告警信息并用于去重。
[
{
"labels": {
"alertname": "<requiredAlertName>",
"<labelname>": "<labelvalue>",
...
},
"annotations": {
"<labelname>": "<labelvalue>",
},
"startsAt": "<rfc3339>",
"endsAt": "<rfc3339>",
"generatorURL": "<generator_url>"
},
...
]
架构
AlertManager主要分为两个部分，路由(router)和接收器(receiver)。告警消息先被经过路由树，然后被分配到对应的接收器中。路由树是由预先设定的路由规则生成的。其高可用架构如上图所示，具体流程如下：
- Prometheus会通过调用AlertManager提供的告警接口将原始的告警消息发送到AlertManager。
- AlertManager的API除了接收告警，还接收静默请求，将其分别保存到各自的provider里。
- provider提供了一个订阅（subscribe）接口，这样Dispatcher组件便可以获取告警数据，并对数据进行分组，通过用户预先设置的规则进入告警抑制阶段或静默阶段。
- 如果通过了上面的告警静默阶段，则进入路由分发阶段，最终发送通知。
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主要包括三个方面的工作。
- 设备注册。
- 手动配置Agent地址。
- 自动发现机制。
- 数据收集。采集到数据首先会被放置在内存中，然后被批量保存在数据库中。
- 主动收集
- 被动接收
- 定期的数据清理和告警触发。
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的数据类型
<measurement>[,<tag-key>=<tag-value>...] <field-key>=<field-value>[,<field2-key>=<field2-value>...] [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('oncall@example.com')
Bosun
Unisphere Unity300
对比分析
| 监控与告警系统 | 开发语言 | 成熟度 | 配置 | 可扩展性 | 故障域 | 性能 | 告警源 | 告警目标 | 社区活跃度 | 对容器的支持 | 企业使用度 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Zabbix | C + PHP | 高 | 基于模版 | 高 | 大，集成 | 低 | 多通道 | 多通道 | 中 | 低 | 高 |
| Prometheus | Go | 高 | 基于模版 | 高 | 小，单组件 | 高 | 多通道 | 多通道 | 高 | 高 | 高 |
| Open-Falcon | Go + Python | 中 | 树形结构 | 高 | 小，单组件 | 高 | 多通道 | 多通道 | 中 | 中 | 中 （主要是国内企业使用，包括美团，滴滴，360等） |
| InfluxDB | Go | 高 | 高 | 小，单组件 | 高 | 多通道 | 多通道 | 高 | 高 | ||
| Bosun | Go | ||||||||||
| Unity300 | Dell EMC产品 |
