【参考】

• How Prometheus Monitoring works | Prometheus Architecture explained：https://www.youtube.com/watch?v=h4Sl21AKiDg --> 本文主要是对这个视频的内容的总结与学习
• Prometheus官网：https://prometheus.io/
• Prometheus配置学习，官网：https://prometheus.io/docs/prometheus/latest/configuration/configuration/
• PromQL学习，官网：https://prometheus.io/docs/prometheus/latest/querying/examples/

【本文主要内容】

• Prometheus是什么？使用案例？
• Prometheus监控的目标是谁？Prometheus监控的内容是什么？
• Prometheus收集Metrics的方式？Exporters的作用？
• prometheus.yml
• Alert Manager
• PromQL

1. Prometheus介绍

Prometheus是一款用来做监控和预警的开源的项目，最早是SoundCloud公司的项目，始于2012年。Prometheus不仅可以工作在传统的模式上（即部署在服务器），也可以工作在容器应用中，如Kubernetes。

过去几年，在容器端，Prometheus作为Monitoring工具尤其重要。原因是容器化的服务使得DevOps工作变得复杂，假设我们有很多很多个pod运行在多个Prod clusters上，那么这些pod的健康情况的监控就显得很重要，如：有没有出现响应延迟，负载过重，资源不足，出现了Error等等。

具体举例，如Prod上的某个pod的out of memory错误，间接的导致了数据库的两个pod出问题了，然后这两个db pod为用户登陆验证提供服务，那么从而使得用户在UI上无法登陆，在这种情况下，我们需要快速定位哪里出了问题？但问题的关键是如果我们有监控系统，那么就可以快速知道哪些pod是不健康的，甚至如果有某种预警系统，当某个pod快出现资源枯竭的问题时，就可以先发出警报（预警功能）。

2. Prometheus工作原理

Prometheus Server主要由三个部分组成：

• 存储（Storage）：主要用来存储metrics（指标相关）数据，是基于时间序列的数据库。
• 数据的拉取（Retrieval）：从应用中（或是其它目标服务器）拉取metrics数据，然后存入到它自己的数据库中。
• Http Server：使用PromQL，从它自己的数据库中检索数据，入口可以是Promethous Web UI或是其它的UI展示平台如Grafana。

2.1 Prometheus的监控目标

Prometheus的监控目标可以是我们的应用服务，也可以是其它对象如Linus或Windows服务器或Apache服务器，DB数据库等等。

2.2 Prometheus的监控内容

Prometheus的监控内容（即Metrics），针对不同的目标也不尽相同，针对服务器可以是CPU的状态，内存或磁盘的使用情况。或对于应用程序来说，监控的内容可以是服务请求的数据，请求的时间，异常的数量等。

以下是Prometheus的Metrics数据格式例子

通常由两部分组成：

• HELP：用来描述这个Metrics的内容
• TYPE：用来记录Metrics的内容，主要分三类：
  • 计数类的指标（Counter）：主要记录了某个事件发生的次数，如应用的异常发生次数。
  • 仪表盘（Gauge）：主要记录了某个目标目前的值是多少？如目前的CPU使用情况。
  • 直方图（Histogram）：在一段时间范围内对数据进行采样，并将其计入可配置的存储中。

2.3 Prometheus收集数据的方式

Prometheus通过HTTP的请求来收集数据，默认的地址为{目标应用地址}/metrics，换句话说我们的应用服务需要暴露出/metrics端点以供Prometheus来拉取数据。

并且这个端点的数据必须是Prometheus认可的数据格式（具体在#2.2中有介绍）。

3. Exporters

有些应用服务默认情况下就会暴露/metrics端点，而另外一些应用没有这样的功能，所以需要Exporter，来从目标应用服务中拉取数据，然后转化为Prometheus能接受的数据格式，然后暴露出/metrics端点。

地址：https://prometheus.io/docs/instrumenting/exporters/，上面列了很多第三方的Exporters，也有一些是官方提供的，如：

• DB相关：如MongoDB exporter, PostgreSQL exporter，MySQL server exporter等
• 硬件相关：Disk usage exporter等
• 消息中间件相关：IBM MQ exporter, RabbitMQ exporter等
• JAVA相关：Java GC exporter, JMS expoter等

这里只列了非常少的一部分，总之exporter种类繁多，有需要的去官网上查询。

3.1 监控Linux服务器

比如我们想要监控一台Linux服务器，那么可以：

• 下载Node exporter
• 解压并执行
• exporter会转化服务器上的数据为metrics
• 暴露/metrics端点
• 在Prometheus上配置该端点，用来拉取数据。

3.2 以Pod的形式运行Exporters

Exporters也可以在Docker容器中，比如我们想要监控一台运行在Kubernetes上的mysql，那么我们可以另外运行exporter（也是一个pod），用来转化Mysql的监控数据并暴露端点。

4. 为什么Prometheus是以"拉取"的形式来收集数据？

有些监控系统是以应用主动推送的方式来收集Metrics数据，如Amazon Cloud Watch，New Relic。而这样的形式有时候会造成网络拥堵或是使得监控服务负载比较大。别外推送的方式需要在应用端额外安装工具以达到推送数据的功能。

Prometheus采取拉取的形式来收集数据，可以使用多个Prometheus实例来拉取数据，另外一个优势是Prometheus服务端可以很快速的感知应用端是否是运行状态。

但有些应用比如短时间短的job，可能Prometheus没办法定期的拉取数据（因为它跑的时间太短了），这时候Prometheus有个组件叫Pushgateway，以供应用可以主动推送数据到这个组件上，但这种方式不应该作为常规的数据收集方式。

5. Prometheus配置

Prometheus怎么知道什么时候需要拉取数据？以及拉取什么样的数据？需要在prometheus.yml中进行配置。

首先是global相关的配置，定义了一些全局的信息，如多久拉取一次Metrics数据（比如每隔15秒）？拉取数据时的超时时间为多少（如10秒）等等。这些值可以在具体配置的单个targets里进行覆盖重写：

global:
  scrape_interval:     15s # How frequently to scrape targets by default.
  evaluation_interval: 15s # How frequently to evaluate rules.
  scrape_timeout:      10s

rule_files，定义了一些规则的文件。如收集Metrics的规则，或者定义一些预警规则（如CPU到达70%后发出Alerts），这些规则多久执行依赖于上述global的定义：

rule_files:
  # - "first.rules"
  # - "second.rules"

scrape_configs：定义了Prometheus需要监控的数据源。如以下job_name=prometheus的，则是拉取prometheus服务本身的Metrics数据，这里配置的localhost:9090就是prometheus服务本身的地址，prometheus服务默认已经实现了/metrics端点。 也可以定义别的数据源，如job_name=node_exporter，每隔1分钟从localhost:9100/methics端点拉取一次数据。

scrape_configs:
  - job_name: prometheus
    static_configs:
    - targets: ['localhost:9090']
  - job_name: node_exporter
    scrape_interval: 1m
    scrape_timeout: 1m
    static_configs:
    - targets: ['localhost:9100']

本文介绍的比较简单，关于Prometheus到时候具体的配置，参考：

• 官方文档：https://prometheus.io/docs/prometheus/latest/configuration/configuration/
• 其它写的比较好的博文：https://blog.csdn.net/w2009211777/article/details/124005822

6. Alert Manager

Prometheus另外一个重要的组件是Alert Manager，可以用来收集Prometheus上的alerts。

具体来说，Prometheus服务端从prometheus.yml中读取alert规则的定义，然后如果发现满足了某个alert规则被触发，则会将alerts推送给Alert Manager，以便后续进行更具体的通知，如发邮件等。

7. Prometheus数据存储/查询

Prometheus的籹据存储，可以放本地磁盘，也可以放远程的存储中。数据存储的方式是时间序列型的。

数据的查询可以通过Prometheus的Web UI页面，通过PromQL（即Prometheus Query Langurage）进行查询。 也可以通过另外的可视化工具进行展示，如Grafana（其底层依旧使用了PromQL进行查询）。

PromQL示例：http_requests_total{status!~"4.."} --> 返回所有HTTP状态不等于4xx的http_requests_total metrics数据。

更多关于PromQL的示例，参考官网：https://prometheus.io/docs/prometheus/latest/querying/examples/

将Prometheus metrics数据展示在Grafana上：

8. Prometheus布署特点

作为监控系统，首先必要的是自已的服务必须是比较可靠的，基于此，Prometheus可以单机使用（stand-alone）或者叫独立的（self-containing），即就算是别的基础设施（如DB等）宕机了，作为监控系统的Prometheus依旧可以独立工作，并且不需要大量的设置。

正因为以上的特点，Prometheus很难作为集群进行部署。

建议：所以我们可以增加Prometheus的服务数据（单机部署），并且控制metrics的数量。

9. Prometheus可以很好的运行在Docker和Kubernetes上

关于Prometheus运行在Kubernetes上，可以做到不需要额外的配置，即可收集必要的metrics，是比较成熟的Prod监控解决方案。