一、概述
二、特点
三、核心组件
四、基础架构
4.1 Prometheus 的主要模块包含
4.2 运行逻辑
五、Prometheus 与 Zabbix 的对比
六、总结
一、概述
1. 什么是prometheus?
- 开源系统监控 和 警报工具包
- 受启发于Google的Brogmon监控系统(相似的Kubernetes是从Google的Brog系统演变而来)
2012年开始由前Google工程师在Soundcoud以开源软件的形式进行研发，并且于2015年期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNF基金会的项目，同年6月正式发布1.0版本，2017年底发布了基于全新存储层的2.0版本能更好地与容器平台、云平台配合。
二、特点
普罗米修斯的主要特点是:
- 支持多维数据模型由指标名称和键值对标识的时间序列数据
- 内置时间序列库 TSDB (Time Serices Database)
- 支持 PromQL (Promethues Query Language)，对数据的查询和分析、图形展示和监控告警
- 不依赖分布式存储;单个服务器节点是自治的
- 支持 HTTP 的拉取(pull)方式收集时间序列数据
- 通过中间网关 Push gateway 推送时间序列
- 通过 服务发现 或 静态配置 2种方式 发现目标
- 支持多种可视化和仪表盘，如: grafana
三、核心组件
-
Prometheus Server：用于抓取数据和存储时序数据，还提供查询和 Alert Rule 配置管理
-
client libraries：用于检测应用程序代码的客户端库
-
push gateway：用于批量，短期的监控数据的汇总节点，主要用于业务数据汇报等
-
exporters：收集监控样本数据，并以标准格式向 Prometheus 提供。例如: 收集服务器系统数的 node_exporter：收集 MySQL监控样本数据的是MySQLexporter 等等
-
alertmanager：用于告警通知管理
四、基础架构
4.1 Prometheus 的主要模块包含
- Server
- Exporters
- Pushgateway
- PromQL
- Alertmanager
- WebUl
4.2 运行逻辑
-
Prometheus server 定期从静态配置的 targets 或者服务发现的 targets 拉取数据(Targets Prometheus采集Agent需要抓取的采)
-
当新拉取的数据大于配置内存缓存区的时候，Prometheus 会将数据持久化到磁盘(如果使用 remote storage 将持化到云端)
-
Prometheus 可以配置 rules，然后定时查询数据，当条件触发的时候，会将 alerts 推送到配置的 Alertmanager.
-
Alertmanager 收到警告的时候，可以根据配置 (163，钉钉等)，聚合，去重，降噪，最后发送警告
-
可以使用APl， Prometheus Console 或者 Grafana 查询和聚合数据
五、Prometheus 与 Zabbix 的对比
| Zabbix | Prometheus（推荐） | |
| 定制化 | 难度很高 后端：C 界面：PHP | 难度较低 后端：golang 界面：Grafana |
| 集群规模 | 单节点10万+（6.0） | 支持更大的集群规模，速度也更快 |
| 适合环境 | 更适合监控物理机 (物理主机，交换机，网络等监控) | 更适合云环境 对OpenStack，Kubernetes有更好的集成 |
| 拓展性 | 难拓展 监控数据存储在关系型数据库内 如 MySQL很难从现有数据中扩展维度 | 难拓简单 监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合。十万级监控数据，Prometheus数据查询速率比Zabbix更快 |
| 安装 | 简单 zabbix-server 一个软件包中包括了所有的服务端功能 | 复杂 监控、告警和界面都分属于不同的组件 |
| 图形化界面 | 比较成熟，界面上基本上能完成全部的配置操作 | 界面相对较弱，很多配置需要修改配置文件 |
| 发展时间 | 更长 对于很多监控场景，都有现成的解决方案 | 2015年后开始快发展 发展时间短，但现在也非常的成熟 |
六、总结
-
prometheus，zabbix 都只是工具，监控思想才是最重要的
-
物理机、硬件设备的监控推荐使用 Zabbix
-
docker容器，Kubernetes监控推荐用 Prometheus
-
云服务器厂商自带有监控系统，有的监控不全面，也可以搭配zabbix和Prometheus来一起使用
