3. Prometheus 部署与配置：二进制部署、Docker部署、Prometheus Operator部署、配置文件详解
聊到 Prometheus 的部署，其实没有想象中那么复杂。但不同场景下，选择哪种方式，差别还挺大的。我个人习惯是：测试环境用 Docker，生产环境用 Operator。至于二进制部署？嗯，那是理解 Prometheus 内部机制的最好方式。
3.1 二进制部署：最原始，也最透彻
为什么我建议你至少手动部署一次二进制版本？说白了，就是让你知道 Prometheus 到底依赖什么、启动时加载了什么。我在项目中遇到过一位同事，用 Docker 用了一年，结果 Prometheus 挂了连日志在哪看都不知道——这就是对底层不了解的代价。
核心步骤：
- 从 Prometheus 官方下载页面 获取对应平台的压缩包
- 解压后，你会看到一个
prometheus可执行文件和一个prometheus.yml配置文件 - 直接运行
./prometheus --config.file=prometheus.yml
这里有个小细节：Prometheus 默认会监听 localhost:9090。如果你想让其他机器访问，记得加上 --web.listen-address=0.0.0.0:9090。我曾经因为忘记这个参数，在排查网络问题时浪费了半小时。
# 下载 Prometheus 2.45.0 版本（Linux amd64）
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
./prometheus --config.file=prometheus.yml --storage.tsdb.path=/data/prometheus
小技巧： 生产环境中，建议将 --storage.tsdb.retention.time 设置为 15d 或 30d，避免磁盘被历史数据撑爆。我一般设置为 30d，配合远程存储做长期归档。
3.2 Docker 部署：快速上手，适合测试
Docker 部署 Prometheus 其实就一行命令。但要注意的是，配置文件需要挂载进去。你想想看，如果不挂载，每次重启容器配置就丢了，那多尴尬。
# 创建配置目录
mkdir -p /etc/prometheus
# 运行 Prometheus 容器
docker run -d \
--name prometheus \
-p 9090:9090 \
-v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
-v /data/prometheus:/prometheus \
prom/prometheus:v2.45.0
这里我特别想提醒你：数据卷的权限问题。Prometheus 容器内默认以 nobody 用户运行，UID 是 65534。如果你挂载的宿主机目录权限不对，容器启动时会报 permission denied。我曾经在客户的 K8s 环境里踩过这个坑，排查了半天才发现是宿主机目录的 owner 没改。
避坑指南： 使用 Docker 部署时，务必先执行 chown 65534:65534 /data/prometheus，否则 Prometheus 无法写入数据。
3.3 Prometheus Operator 部署：生产环境的首选
如果你在 Kubernetes 上运行，Prometheus Operator 几乎是唯一的选择。为什么？因为它把 Prometheus 的部署、配置、服务发现全部抽象成了 Kubernetes 的 CRD（自定义资源）。说白了，你只需要定义 ServiceMonitor 和 PodMonitor，Operator 会自动帮你生成 Prometheus 的抓取配置。
我记得第一次用 Operator 时，最大的感受就是：再也不用手动修改 prometheus.yml 了。每次新增一个服务，只需要创建一个 ServiceMonitor 对象，Prometheus 就会自动发现并开始抓取。
# 使用 Helm 安装 Prometheus Operator
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
# 安装 kube-prometheus-stack（包含 Prometheus、Alertmanager、Grafana）
helm install prometheus prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--create-namespace
核心 CRD 资源：
| 资源名称 | 作用 |
|---|---|
Prometheus |
定义 Prometheus 实例的规格（副本数、资源限制、存储等） |
ServiceMonitor |
定义如何抓取 Service 暴露的指标 |
PodMonitor |
定义如何抓取 Pod 直接暴露的指标 |
Alertmanager |
定义告警管理器的配置 |
PrometheusRule |
定义告警规则 |
这里有个常见的误区：很多人以为安装了 Operator 就自动有了告警规则。其实不是的，你需要自己创建 PrometheusRule 资源。Operator 只是帮你管理 Prometheus 的生命周期，具体的告警逻辑还是要你自己写。
3.4 配置文件详解：prometheus.yml 的核心结构
不管用哪种方式部署，最终 Prometheus 读取的都是同一个结构的配置文件。我把它拆成几个核心块，你一看就明白了。
# 全局配置
global:
scrape_interval: 15s # 抓取间隔，默认1分钟
evaluation_interval: 15s # 评估告警规则的间隔
scrape_timeout: 10s # 抓取超时时间
# 告警配置
alerting:
alertmanagers:
- static_configs:
- targets:
- localhost:9093 # Alertmanager 地址
# 告警规则文件
rule_files:
- "rules/*.yml" # 可以写通配符
# 抓取配置
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node_exporter'
static_configs:
- targets: ['192.168.1.10:9100', '192.168.1.11:9100']
个人经验： scrape_interval 不要设置得太短。我见过有人设成 1s，结果 Prometheus 自己把自己抓挂了。一般 15s 到 30s 就足够了，除非你的业务对实时性要求极高。
再来说说 scrape_configs 里的几个关键字段：
- job_name：逻辑分组名称，在 Prometheus UI 里会显示为 job 标签
- static_configs：静态目标列表，适合固定 IP 的场景
- relabel_configs：标签重写，这是 Prometheus 最强大的功能之一。比如你可以把
__meta_kubernetes_pod_label_app重写成app标签 - metric_relabel_configs：对抓取到的指标进行标签操作，常用于丢弃不需要的指标
说到标签重写，我不得不提一个坑：标签冲突。如果你在 relabel 时不小心把两个不同的值映射到了同一个标签名，Prometheus 会报错。我曾经在生产环境里因为一个 relabel 规则写错了，导致整个 job 的指标都抓不回来。排查过程相当痛苦，最后发现是 target_label 写成了已有的标签名。
避坑指南： 在写 relabel 规则时，先用 --dry-run 模式测试一下。Prometheus 支持 promtool check config 命令来验证配置文件的正确性。
3.5 三种部署方式的对比总结
| 部署方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 二进制部署 | 学习、单机测试 | 无依赖、性能最好 | 手动管理、扩展困难 |
| Docker 部署 | 开发环境、小规模测试 | 部署快、环境隔离 | 持久化需手动处理 |
| Prometheus Operator | Kubernetes 生产环境 | 自动化运维、服务发现 | 学习曲线陡峭 |
最后说一句：没有最好的部署方式，只有最适合你的。如果你刚开始学，我建议从二进制部署入手，把 Prometheus 的启动流程、配置文件结构摸清楚。等你理解了这些，再切换到 Docker 或 Operator，你会发现一切都豁然开朗。