CentOS7下搭建Prometheus监控（二）——Prometheus监控端配置

(1).参考文献

　　Prometheus官网：https://prometheus.io/

　　Prometheus官方文档：https://prometheus.io/docs/introduction/overview/

　　官网下载地址：https://prometheus.io/download/

(2).实验环境

　　2核2G CentOS7.9.2009　　192.168.142.121　　Prometheus Server+Push Gateway

　　所有服务器均已设置阿里云yum源和epel-release源，关闭SELinubx和防火墙。

(3).安装Prometheus Server

　　Prometheus 基于Golang编写，编译后的软件包不依赖于任何第三方依赖，只需要下载对应平台的二进制包，解压并添加基本配置即可正常启动。

[root@localhost ~]# tar zxvf prometheus-3.13.1.linux-amd64.tar.gz -C /usr/local/
[root@localhost ~]# mv /usr/local/prometheus-3.13.1{.linux-amd64,}
[root@localhost ~]# cd /usr/local/prometheus-3.13.1/
[root@localhost prometheus-3.13.1]# cp prometheus.yml{,.bak}
[root@localhost prometheus-3.13.1]# vim prometheus.yml
# 全局配置
global:
  # scrape_interval 决定了 Prometheus 多久去目标拉取一次数据，默认值是每 1 分钟。
  # 15s 是生产环境中非常常用的配置，能在数据实时性和服务器负载之间取得平衡。
  scrape_interval: 15s
  # evaluation_interval 决定了 Prometheus 多久检查一次 rule_files 中的规则，默认值是每 1 分钟。
  # 建议与 scrape_interval 保持一致，或者设为其整数倍，以确保数据采样和规则评估的节奏同步。
  evaluation_interval: 15s
  # scrape_timeout 指的是 Prometheus 发起一次 HTTP 请求后，等待目标响应的最大时间，默认值是 10秒。
  # 如果目标在 10s 内没返回数据，这次抓取就会失败。默认 10s 通常足够，除非网络极差。

# 告警管理器配置
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          # Alertmanager 的目标地址，这里用于告诉 Prometheus 告警触发后，把数据发给哪个 Alertmanager，默认端口是 9093。
          # 如果不需要告警功能，可以保持注释；如果需要，去掉注释并填入实际 IP 或域名。
          # - alertmanager:9093

# 规则文件加载
# 加载规则文件，并根据全局的 'evaluation_interval' 定期评估它们。
rule_files:
  # 这里用于指定包含 Recording Rules（预聚合规则）或 Alerting Rules（告警规则）的 YAML 文件路径。
  # 支持通配符（如 "rules/*.yml"）。
  # - "first_rules.yml"
  # - "second_rules.yml"

# 抓取配置
scrape_configs:
  # 任务名称。这个名称会作为 `job=<job_name>` 标签附加到从该配置中抓取的所有时间序列上。
  # job 标签是 Prometheus 中最核心的标签之一，用于在 PromQL 中按服务分组查询数据。
  - job_name: "prometheus"

    # metrics_path默认为 '/metrics'，协议默认为 'http'。
    # Prometheus 默认会请求 http://<target>/metrics 来获取数据。如果你的应用暴露在其他路径，可以在这里修改 metrics_path。
    
    # 静态配置目标
    static_configs:
      # 指定监控目标
      - targets: ["localhost:9090"]
       # 自定义标签。这个标签名称和值也会附加到从该配置抓取的所有时间序列上。
       # 这里手动给 Prometheus 自身的数据打上了 `app="prometheus"` 的标签。
       # 在实际生产中，我们常通过 relabel_configs 自动打标签，但手动配置适用于这种固定的内部组件。
        labels:
          app: "prometheus"

  # 新增pushgateway监控目标
  - job_name: "pushgateway"
    static_configs:
      - targets: ["localhost:9091"]
        labels:
          instance: "pushgateway"

(4).安装Pushgateway

　　Prometheus 在正常情况下是采用拉模式从产生 metric 的作业或者 exporter（比如专门监控主机的 NodeExporter）拉取监控数据。

　　Pushgateway 是一种中间件服务，允许您将无法被抓取的作业中的指标推送过来。官方仅建议在少数特定场景下使用Pushgateway 。如果盲目使用 Pushgateway 来替代 Prometheus 常规的拉取（Pull）模式进行通用指标收集，会面临以下几个陷阱：

• 单点故障与性能瓶颈：当通过单个 Pushgateway 监控多个实例时，它本身就会成为单点故障源和潜在的性能瓶颈。
• 丧失健康状态监控：你将失去 Prometheus 通过 up 指标（每次抓取时自动生成）来自动监控实例健康状态的能力。
• 数据不会自动清理：Pushgateway 永远不会自动遗忘推送给它的数据。除非通过其 API 手动删除，否则这些数据会永远暴露给 Prometheus。

　　最后一点尤为重要。当同一个任务的多个实例通过 instance 等标签在 Pushgateway 中区分数据时，即使源实例被重命名或销毁，其对应的指标仍会残留在 Pushgateway 中。这是因为 Pushgateway 作为指标缓存的生命周期，与推送数据的进程生命周期是完全独立的。相比之下，在 Prometheus 常规的拉取模式下，当某个实例消失（无论是否有意为之），其指标也会随之自动消失。而在使用 Pushgateway 时则不然，你必须手动清理这些过期数据，或者自己编写逻辑来自动化这种生命周期的同步。

　　通常，Pushgateway 唯一合理的使用场景是用于捕获服务级别的批处理任务（Batch Job）的结果。所谓的“服务级别”批处理任务，是指在语义上不绑定于某台特定机器或特定任务实例的任务（例如：一个为整个服务批量删除用户的任务）。这类任务暴露的指标中不应包含 machine 或 instance 标签，从而将特定机器或实例的生命周期与推送的指标解耦。这能大幅降低在 Pushgateway 中管理过期数据的负担。

[root@localhost prometheus-3.13.1]# cd
[root@localhost ~]# tar zxvf pushgateway-1.11.3.linux-amd64.tar.gz -C /usr/local/
[root@localhost ~]# mv /usr/local/pushgateway-1.11.3{.linux-amd64,}

(5).启动Prometheus Server和Pushgateway

[root@localhost ~]# nohup /usr/local/prometheus-3.13.1/prometheus --config.file=/usr/local/prometheus-3.13.1/prometheus.yml > prometheus.log 2>&1 &
[1] 11950
[root@localhost ~]# nohup /usr/local/pushgateway-1.11.3/pushgateway --web.listen-address :9091 > pushgateway.log 2>&1 &
[2] 11958
[root@localhost ~]# ps -ef | grep -E '11950|11958'
root      11950  11916  1 14:54 pts/0    00:00:01 /usr/local/prometheus-3.13.1/prometheus --config.file=/usr/local/prometheus-3.13.1/prometheus.yml
root      11958  11916  0 14:55 pts/0    00:00:00 /usr/local/pushgateway-1.11.3/pushgateway --web.listen-address :9091
root      11968  11916  0 14:56 pts/0    00:00:00 grep --color=auto -E 11950|11958

(6).页面检查

　　如此，监控端算是初步搭建完成。