简介
Prometheus是一种开源的监控和告警工具，最初由SoundCloud 开发并于2012年发布。
它被广泛应用于云原生环境中，特别是容器化的应用程序监控， Prometheus的核心设计理念是通过pull模型来收集度量数据。通过定期向目标系统发送HTTP请求，获取指定的监控数据。
官网地址：prometheus.io/
为什么学Prometheus
1.功能强大
Prometheus提供了广泛的监控功能，使我们能够全面了解系统的运行状况。比如下面的节点cpu数据监控，就非常的细致、全面
2.拓展性强
Prometheus具有丰富的生态系统和集成能力。它可以与各种工具和服务进行无缝集成，如Grafana、 Alertmanager, Kubernetes.
3.云原生
Prometheus是云原生环境中的首选监控方案。
随着云计算和容器化技术的普及，云原生架构已经成为现代应用程序开发和部署的趋势。
整体架构
Prometheus 是使用 Pull （抓取）的方式去搜集被监控对象的 Metrics 数据（监控指标数据），比如从 exporter 拉取数据，或者间接地通过网关 gateway 拉取数据（如果在 k8s 内部署，可以使用服务发现的方式），它默认本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，然后再把这些结果保存在一个 TSDB （时间序列数据库，比如 OpenTSDB、InfluxDB 等）当中，以便后续可以按照时间进行检索。有了这套核心监控机制， Prometheus 剩下的组件就是用来配合这套机制的运行。比如Pushgateway ，可以允许被监控对象以 Push 的方式向 Prometheus 推送 Metrics 数据。而 Alertmanager，则可以根据 Metrics 信息灵活地设置报警。当然， Prometheus 最受用户欢迎的功能，还是通过 Grafana 对外暴露出的、可以灵活配置的监控数据可视化界面。
组件内容
- Prometheus Server：Prometheus Server 是 Prometheus 组件中的核心部分，负责实现对监控数据的获取，存储以及查询。 Prometheus Server 可以通过静态配置管理监控目标，也可以配合使用 Service Discovery 的方式动态管理监控目标，并从这些监控目标中获取数据。其次 Prometheus Server 需要对采集到的监控数据进行存储，Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后 Prometheus Server 对外提供了自定义的 PromQL 语言，实现对数据的查询以及分析。
-
- Retrieval: 采样模块
- TSDB: 存储模块默认本地存储为tsdb
- HTTP Server: 提供http接口查询和面板，默认端口为9090
- Exporters/Jobs：负责收集目标对象（host, container…）的性能数据，并通过 HTTP 接口供 Prometheus Server 获取，Prometheus Server通过访问该 Exporter 提供的Endpoint端点，即可获取到需要采集的监控数据。支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等。只要符合接口格式，就可以被采集。
-
- 直接采集：这一类 Exporter 直接内置了对 Prometheus 监控的支持，比如 cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向 Prometheus 暴露监控数据的端点。
- 间接采集：间接采集，原有监控目标并不直接支持 Prometheus，因此我们需要通过 Prometheus 提供的 Client Library 编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。
- Short-lived jobs：瞬时任务的场景，无法通过pull方式拉取，需要使用push方式，与PushGateway搭配使用
- PushGateway：可选组件，主要用于短期的 jobs。由于 Prometheus 数据采集基于 Pull 模型进行设计，因此在网络环境的配置上必须要让 Prometheus Server 能够直接与 Exporter 进行通信。 当这种网络需求无法直接满足时，就可以利用 PushGateway 来进行中转。可以通过 PushGateway 将内部网络的监控数据主动 Push 到 Gateway 当中。而Prometheus Server则可以采用同样Pull 的方式从 PushGateway 中获取到监控数据。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。
- 客户端sdk：官方提供的客户端类库有go、java、scala、python、ruby，其他还有很多第三方开发的类库，支持nodejs、php、erlang等
- PromDash：使用 rails 开发的 dashboard，用于可视化指标数据，已废弃
- Alertmanager：在 Prometheus Server 中支持基于 PromQL 创建告警规则，如果满足 PromQL 定义的规则，则会产生一条告警，而告警的后续处理流程则由 AlertManager 进行管理。在 AlertManager 中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过 Webhook 自定义告警处理方式。AlertManager 即 Prometheus 体系中的告警处理中心。
- Service Discovery：服务发现，Prometheus 支持多种服务发现机制：文件，DNS，Consul,Kubernetes,OpenStack,EC2等等。基于服务发现的过程并不复杂，通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮训这些Target获取监控数据。
其大概的工作流程是：
- Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自 Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。
- Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报。
- Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。
- 在图形界面中，可视化采集数据。
与zabbix的比较
1.架构和数据模型：
Prometheus采用了pull模型，通过定期从被监控的系统主动拉取数据，将其存储在本地时间序列数据库中，而Zabbix使用push模型，被监控的系统将数据推送给Zabbix 服务器进行处理。从架构上来说，Prometheus的设计更为简单且易于扩展，而 Zabbix的架构相对复杂一些。
2.数据存储和查询语言：
Prometheus使用内置的时间序列数据库（TSDB）来存储和查询监控数据。它提供了强大的查询语言PromQL，用于分析和查询时间序列数据
相比之下，Zabbix采用关系型数据库存储监控数据，并使用 SQL查询语言进行数据检索。Prometheus的查询语言更为灵活和专注于时间序列的操作。
3.监控生态系统和集成能力：
Prometheus与Grafana、Alertmanager等工具有很好的集成能力，可创建漂亮的仪表板和灵活的告警规则。它还与 Kubernetes等云原生环境相关工具集成紧密，适合云原生应用的监控
Zabbix也提供了自己的仪表板和告警规则配置，但其集成能力相对较低，与其他开源工具的集成比较有限。
4.社区支持和发展活跃度：
Prometheus作为一个开源项目，拥有庞大而活跃的社区支持 。它得到了广泛的应用和推广， 并持续发展和更新 Zabbix也是一款历史悠久的监控工具，具有一定的用户基础和社区，但相对而言发展活跃度稍逊于Prometheus。
