4、Prometheus部署：二进制部署、Docker部署、Prometheus配置文件详解

说到Prometheus的部署，其实就两种主流方式：二进制直接跑，或者用Docker容器化。我个人更倾向于二进制部署用于生产环境，Docker则适合快速验证和测试。今天咱们就把这两种方式都过一遍，顺便把配置文件里那些容易踩坑的地方讲清楚。

4.1 二进制部署：最传统，也最可控

二进制部署的好处是啥？说白了就是干净。没有容器层的开销，资源占用最小，排查问题也直接。我在项目中遇到过几次因为Docker网络模式导致Prometheus抓不到数据的情况，换成二进制部署就一切正常了。

步骤其实很简单：

1. 去Prometheus官网下载对应平台的压缩包
2. 解压后直接运行二进制文件
3. 配置好prometheus.yml就行

嗯，这里要注意版本选择。我建议用最新的稳定版，别追新。曾经有一次我手贱用了rc版本，结果有个指标格式变了，搞得告警规则全废了。

# 下载并解压
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
tar -xzf prometheus-2.45.0.linux-amd64.tar.gz
cd prometheus-2.45.0.linux-amd64

# 直接启动
./prometheus --config.file=prometheus.yml

启动后默认监听9090端口。你打开浏览器访问http://localhost:9090，就能看到Prometheus的Web界面了。我个人习惯用--web.enable-lifecycle参数，这样可以通过API热加载配置，不用重启服务。

4.2 Docker部署：快速上手，适合实验

Docker部署就一句话：docker run。但你真的以为就这么简单？我刚开始用Docker跑Prometheus时，就栽在数据持久化上。容器一删，所有监控数据全没了。

正确的做法是挂载数据卷和配置文件：

# 创建数据目录
mkdir -p /data/prometheus

# 启动容器
docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v /data/prometheus:/prometheus \
  -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus:v2.45.0

你想想看，如果不挂载/prometheus目录，重启容器后历史数据就丢了。这在生产环境可是大忌。我曾经帮一个团队排查问题，发现他们的Prometheus每次重启后指标都从零开始，就是因为没做持久化。

4.3 Prometheus配置文件详解：核心中的核心

配置文件prometheus.yml是Prometheus的灵魂。说白了，Prometheus就是个定时抓取数据的工具，而配置文件就是告诉它「去哪抓、抓什么、怎么处理」。

一个典型的配置文件长这样：

global:
  scrape_interval: 15s      # 默认抓取间隔
  evaluation_interval: 15s  # 规则评估间隔
  scrape_timeout: 10s       # 抓取超时时间

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['192.168.1.100:9100', '192.168.1.101:9100']

咱们拆开来看：

4.3.1 global 全局配置

这里定义的是全局默认值。每个抓取任务如果没有单独设置，就会继承这里的值。

• scrape_interval：多久抓一次数据。默认1分钟，我一般设15秒。太频繁会增加负载，太稀疏会丢失细节。
• evaluation_interval：多久评估一次告警规则。这个要和告警规则配合好。
• scrape_timeout：每次抓取超时时间。如果目标响应慢，可以适当调大。

我记得有一次线上告警频繁误报，查了半天发现是scrape_timeout设得太短，导致部分目标抓取失败，触发了up == 0的告警。调大超时时间后就正常了。

4.3.2 scrape_configs 抓取配置

这是最核心的部分。每个job_name代表一个抓取任务，可以包含多个目标。

常用的配置项：

配置项	说明	我的建议
job_name	任务名称，会作为标签job的值	命名要有意义，比如node_exporter、nginx
static_configs	静态目标列表	适合固定IP的场景
file_sd_configs	从文件读取目标列表	适合动态变化的场景，比如K8s
relabel_configs	标签重写规则	高级功能，可以过滤或修改标签

举个例子，如果你用file_sd_configs，可以这样写：

scrape_configs:
  - job_name: 'node_exporter'
    file_sd_configs:
      - files:
        - 'targets/node/*.json'
        refresh_interval: 5m

然后在targets/node/目录下放JSON文件，内容就是目标列表。这样你新增机器时，只需要改文件，Prometheus会自动加载。

4.3.3 其他常用配置

除了上面这些，还有几个配置值得注意：

• rule_files：指定告警规则文件路径。支持通配符，比如rules/*.yml。
• alerting：配置Alertmanager的地址。Prometheus只负责产生告警，发送通知是Alertmanager的事。
• remote_write/remote_read：远程读写配置。如果你用Thanos或VictoriaMetrics，这里就派上用场了。

我曾经犯过一个低级错误：在rule_files里写了个不存在的路径，结果Prometheus启动时直接报错退出。所以配置完一定要用./promtool check config prometheus.yml检查一下语法。

4.4 部署后的验证

部署完别急着走，先验证一下：

1. 访问http://localhost:9090/targets，看看所有目标是不是都是UP状态。
2. 在Graph页面随便查个指标，比如prometheus_http_requests_total，看能不能出数据。
3. 检查日志，有没有Error或Warning。

嗯，基本上做到这步，Prometheus就算跑起来了。接下来就是配置各种Exporter和告警规则，那是后面章节的内容了。