prometheus 是什么？

prometheus是一套开源的监控、报警、时间序列数据存储的监控告警解决方案，起初是有SoundCloud公司开发，随着发展很多公司与组织使用prometheus，社区也十分活跃，便独立成开源项目。

prometheus启发与Google的Brogmon监控系统，从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。

Prometheus作为新一代的云原生监控系统，现在常用与Kubernetes容器管理系统中，并且超过120+项的第三方集成。

监控目标

在《SRE: Google运维解密》一书中指出，监控系统需要能够有效的支持白盒监控和黑盒监控。通过白盒能够了解其内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。而黑盒监控，常见的如HTTP探针，TCP探针等，可以在系统或者服务在发生故障时能够快速通知相关的人员进行处理。通过建立完善的监控体系，从而达到以下目的：

• 长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。

• 对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过监控能够方便的对系统进行跟踪和比较。

• 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理或者提前预防问题的发生，避免出现对业务的影响。

• 故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控监控以及历史数据的分析，能够找到并解决根源问题。

• 数据可视化：通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信息。

prometheus 的优势？

• 无依赖，支持local和remote不同模型

• 强大的数据模型及查询语句PromQL

• 易于扩展、集成

• 设计思想是按照Google SRE理念构建的，具有实用性和前瞻性

• 分布式、微服务架构

• 社区活跃，基本在每月1个版本

prometheus 的特点

• 自定义多维度的数据模型（时序由metric名字和k/v的labels构成）
  

• 高效的存储，基于TSDB

• 多种统计数据模型，图形化友好（Grafana）

prometheus 的缺点

• 基于时序的float64的值，如果数据有更多类型则无法满足

• 会有少量采集数据丢失的情况

prometheus 核心组件

• Prometheus Server：用于抓取数据和存储时序数据，另外还提供查询和 Alert Rule 配置管理

• Client Libraries：用于对接 Prometheus Server, 可以查询和上报数据。

• Push Gateway ：用于批量，短期的监控数据的汇总节点，主要用于业务数据汇报等。

• Exporters（各种数据收集）：例如上报机器数据的 node_exporter, 上报 MongoDB 信息的 MongoDB exporter 等

• Alertmanager ：用于告警通知管理

prometheus 架构

从架构图，可以看出 Prometheus 的主要模块包含， Server, Exporters, Pushgateway, PromQL, Alertmanager, WebUI 等

流程逻辑：

1. Prometheus Server 定期从静态配置的 targets 或者服务发现的 targets 拉取数据

2. 当拉取到新的数据大于配置内存缓存区的时候，Prometheus 会将数据持久化到磁盘（如果使用 Remote Storage 将持久化到云端）

3. Prometheus 可以配置 rules，然后定时查询数据，当条件触发的时候，会将 Alert 推送到配置的 Alertmanager

4. Alertmanager 收到报警后，可以根据配置，聚合，去重，降噪，最后发送报警

5. 可以使用 API， Prometheus Console 或者 Grafana 查询或聚合数据

prometheus 与 zabbix 比较

分析

界面与配置文件 

   zabbix的界面配置毫无疑问比prometheus强大，但如果细想这也绝非是一大痛点，假设prometheus是为云原生环境，这种情况下环境动态变化，服务器随时增减，人工介入不太现实，那么即便界面强大也是比较繁琐。所以也需要看在什么样的环境下使用，在进行取舍。

TSDB与MySQL

  对于监控数据时序数据库会更方便聚合，在高并发下，读写性能也高于MySQL,另外时序数据库内置基于时间的处理函数，简化聚合的难度。对于MySQL并非不适合，而是时序数据库是专门应对监控场景存储优化的。

服务发现

  prometheus在收集数据是，主要采用pull模型，zabbix主要采用push模型（两种监控都支持pull和push）pull模型在云原生环境中比较有优势，可通过配置管理中心发现所有节点。push模型需要服务发现，但每个被监控端需要安装客户端程序，加大了部署难度。

总结

zabbix成熟稳定，上手快，webUI配置，但灵活性差，主机增多后查询性能慢，定制难度高。

prometheus上手难度大，但灵活性、整体性能高，也有更多数据聚合可能。

比较而言，如果是传统业务、新手、主机角色场景，或已经在用zabbix的话建议用zabbix。

如果是刚要上监控或是容器环境的话建议使用prometheus，虽然上手难度大，但Prometheus是未来的一个发展方向，值得去学习下。

参考文档

官方文档

What's the difference between Prometheus and Zabbix?

Zabbix vs Prometheus