📚 课程目录第3章安装与部署

3、安装与部署：二进制安装、Docker部署、Helm Chart部署Prometheus，配置文件详解（global、scrape_configs、rule_files）

Prometheus 的部署方式直接决定了后续运维的复杂度、扩展能力以及故障恢复速度。在生产环境中，我们通常不会只使用一种部署方式，而是根据监控对象的生命周期、资源限制和团队技术栈，在二进制、Docker 与 Kubernetes Helm Chart 之间做出权衡。本章将围绕这三种主流部署路径展开，深入剖析各自的适用场景、操作步骤与核心配置文件的解析逻辑，帮助你在实际项目中建立一套清晰、可维护的监控基础设施。

上图清晰地展示了三种部署方式与配置文件之间的逻辑关系。无论你选择哪种安装路径，最终都会汇聚到同一个核心：prometheus.yml 配置文件。理解这一点至关重要，因为部署方式的差异只是“如何把 Prometheus 跑起来”，而配置文件的编写质量才真正决定了监控系统的有效性。下面我们逐一深入。

3.1 二进制安装：传统环境下的精准控制

核心原理

二进制安装是 Prometheus 最原始的部署形态。官方将 Prometheus 编译为独立的可执行文件，不依赖任何运行时环境（如 JVM、Python 解释器）。这种方式的优势在于：资源占用极低（通常内存消耗在 200-500MB 左右，取决于采集目标数量）、启动速度极快、便于在物理机或虚拟机上直接以 systemd 服务形式托管。对于已有大量传统服务器、且未全面容器化的企业，二进制部署依然是首选。

操作流程

下载与解压：从 Prometheus 官方 GitHub Releases 页面下载对应操作系统架构的压缩包，例如 prometheus-2.53.0.linux-amd64.tar.gz，解压后得到可执行文件与默认配置文件。
目录规划：建议将 Prometheus 安装在 /opt/prometheus 下，数据目录独立为 /var/lib/prometheus，配置文件放在 /etc/prometheus，日志由 systemd 统一管理。
创建系统用户：出于安全考虑，使用专用用户 prometheus 运行，避免以 root 权限执行监控进程。
配置 systemd 服务：编写 /etc/systemd/system/prometheus.service 单元文件，定义启动命令、数据目录、配置目录以及重启策略。
启动与验证：执行 systemctl daemon-reload 后启动服务，通过 curl http://localhost:9090/-/healthy 检查健康状态。

# /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Monitoring System
Documentation=https://prometheus.io/docs/introduction/overview/
After=network.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/opt/prometheus/prometheus \
    --config.file=/etc/prometheus/prometheus.yml \
    --storage.tsdb.path=/var/lib/prometheus \
    --web.listen-address=0.0.0.0:9090
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

实战场景与案例拆解

某金融科技公司有 200 台虚拟机运行核心交易系统，由于安全合规要求，这些机器不能运行 Docker 守护进程。运维团队采用二进制方式部署 Prometheus，并使用 Ansible 批量推送二进制文件与配置。关键操作如下：

使用 Ansible 的 unarchive 模块解压 Prometheus 到目标机器。
通过 Jinja2 模板动态生成 prometheus.yml，将各业务组的 Target 列表从 CMDB 自动拉取。
配置 systemd 的 Restart=always 确保障碍后自动拉起。
数据目录挂载在独立的 SSD 磁盘上，避免与系统盘争抢 I/O。

部署完成后，监控系统在 10 分钟内即开始采集数据，内存占用稳定在 400MB 左右，CPU 使用率低于 1%。该方案的代价是后续升级需要重新走一遍 Ansible 流程，且无法享受容器化带来的弹性伸缩能力。

风险提示：二进制部署时务必注意 Prometheus 版本与配置文件的兼容性。例如，v2.40 之后移除了部分旧版 flag，直接替换二进制可能导致启动失败。建议在测试环境先行验证升级路径。

常见误区与复盘

误区一：将数据目录放在系统盘根分区，导致磁盘写满后系统崩溃。应独立挂载数据盘。
误区二：忘记设置 --storage.tsdb.retention.time，默认保留 15 天数据，对于需要长期趋势分析的场景可能不够。
误区三：直接使用 root 运行 Prometheus，一旦配置文件被篡改，攻击者将获得 root 权限。

3.2 Docker 部署：快速迭代与开发环境利器

核心原理

Docker 部署将 Prometheus 及其依赖封装在镜像中，通过容器运行时隔离。官方镜像 prom/prometheus 基于 Alpine Linux 构建，体积小（约 200MB），启动时间在秒级。Docker 部署的核心价值在于环境一致性——开发、测试、生产使用完全相同的镜像，避免“在我机器上能跑”的尴尬。同时，通过 Docker Compose 可以一键拉起 Prometheus、Grafana、Alertmanager 等全套监控栈。

操作流程

准备配置文件：在宿主机创建 /etc/prometheus/prometheus.yml，并通过数据卷挂载到容器内。
运行容器：使用 docker run 命令指定端口映射、数据卷和重启策略。
使用 Docker Compose：对于多服务编排，编写 docker-compose.yml 定义 Prometheus、Grafana、Alertmanager 等组件。
验证服务：访问 http://localhost:9090 查看 Prometheus UI。

# docker-compose.yml 示例
version: '3.8'
services:
  prometheus:
    image: prom/prometheus:v2.53.0
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=30d'
    ports:
      - "9090:9090"
    restart: unless-stopped
volumes:
  prometheus_data:
    driver: local

实战场景与案例拆解

一家互联网创业公司的开发环境需要频繁变更监控配置。团队使用 Docker 部署 Prometheus，并将 prometheus.yml 放在 Git 仓库中。每次修改配置后，只需执行 docker-compose restart prometheus 即可生效。他们还利用 Docker 的 --network host 模式让 Prometheus 直接访问宿主机网络，方便采集 localhost 上的 Node Exporter 指标。

在一次压测中，开发人员发现 Prometheus 容器频繁 OOM。通过 docker stats 观察内存占用，发现 scrape 的 Target 数量过多导致内存暴涨。解决方案是调整 scrape_interval 从 5s 改为 15s，并优化了采集指标的数量。这个案例说明，Docker 部署虽然便捷，但资源限制仍需关注。

经验提醒：Docker 部署时，务必使用命名数据卷（named volume）而非绑定挂载（bind mount）来存储 TSDB 数据。绑定挂载在 macOS 和 Windows 上存在 I/O 性能瓶颈，且文件权限容易混乱。

常见误区与复盘

误区一：容器内配置文件修改后不重启，Prometheus 不会自动加载新配置。需要发送 SIGHUP 信号或重启容器。
误区二：忘记映射端口，导致外部无法访问 UI。
误区三：将数据卷放在容器可写层，容器删除后数据丢失。

3.3 Helm Chart 部署：Kubernetes 云原生监控的标准答案

核心原理

在 Kubernetes 环境中，Helm Chart 是部署 Prometheus 的事实标准。最常用的 Chart 是 kube-prometheus-stack，它不仅仅部署 Prometheus，还集成了 Grafana、Alertmanager、各种 Exporter（如 node-exporter、kube-state-metrics）以及 Prometheus Operator。其核心价值在于：通过 Kubernetes CRD（Custom Resource Definition）如 ServiceMonitor 和 PrometheusRule 实现配置的动态管理。Prometheus Operator 会监听这些 CRD 的变化，自动更新 Prometheus 的采集配置和告警规则，无需手动编辑 prometheus.yml。

操作流程

添加 Helm 仓库：helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
更新仓库：helm repo update
创建命名空间：kubectl create namespace monitoring
安装 Chart：helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring
自定义 values.yaml：覆盖默认配置，如资源限制、持久化存储、告警规则等。

# values.yaml 关键配置片段
prometheus:
  prometheusSpec:
    retention: 15d
    resources:
      requests:
        memory: 2Gi
        cpu: 500m
      limits:
        memory: 4Gi
        cpu: 2
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: standard
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi
grafana:
  adminPassword: "your-strong-password"
  persistence:
    enabled: true
    size: 10Gi

实战场景与案例拆解

某大型电商平台的 Kubernetes 集群有 50 个节点、500 个 Pod。运维团队使用 kube-prometheus-stack 部署监控系统。他们遇到的核心问题是：默认的 ServiceMonitor 无法自动发现自定义应用的监控端点。解决方案是创建一个自定义的 ServiceMonitor 资源，通过 label selector 匹配应用服务的标签。

# 自定义 ServiceMonitor 示例
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

创建后，Prometheus Operator 在 30 秒内自动更新了 Prometheus 的采集配置，无需人工干预。这个案例展示了 Helm Chart 部署在云原生环境中的巨大优势——配置即代码，声明式管理。

风险提示：Helm Chart 部署虽然强大，但升级时需谨慎。直接 helm upgrade 可能导致 CRD 版本不兼容。建议先备份 etcd 中的 CRD 资源，并在测试环境验证升级路径。

常见误区与复盘

误区一：不设置资源 requests/limits，Prometheus 在 Pod 数量增长时可能 OOMKilled。
误区二：忽略持久化存储配置，Pod 重启后监控数据全部丢失。
误区三：直接修改 Prometheus 的 ConfigMap 而不是通过 ServiceMonitor 管理，导致 Operator 覆盖自定义配置。

3.4 配置文件详解：global、scrape_configs、rule_files

核心原理

无论使用哪种部署方式，prometheus.yml 都是 Prometheus 的“大脑”。它由三个核心顶级配置块组成：global 定义全局默认行为，scrape_configs 定义采集目标与采集方式，rule_files 引用告警和记录规则文件。理解这三者的关系是配置 Prometheus 的基础。

配置块深度解析

配置块	关键参数	作用与说明	典型值
`global`	`scrape_interval`	全局采集频率，所有 job 的默认值	15s
	`evaluation_interval`	告警规则评估频率	15s
	`external_labels`	外部标签，用于全局唯一标识	cluster: "prod"
`scrape_configs`	`job_name`	采集任务名称，唯一标识	node-exporter
	`static_configs`	静态目标列表	targets: ['10.0.0.1:9100']
	`relabel_configs`	采集前标签重写	drop/replace/keep
`rule_files`	文件路径列表	加载告警规则与记录规则	rules/*.yml

实战场景与案例拆解

假设我们需要监控一组 Web 服务器，并设置 CPU 使用率超过 80% 时告警。配置文件如下：

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    cluster: "production"

scrape_configs:
- job_name: 'web-servers'
  static_configs:
  - targets: ['192.168.1.10:9100', '192.168.1.11:9100']
    labels:
      role: 'web'

rule_files:
- 'rules/*.yml'

在 rules/ 目录下创建 cpu_alert.yml：

groups:
- name: cpu_alerts
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }} CPU usage high"
      description: "CPU usage is above 80% for 10 minutes."

这个案例展示了三个配置块的协同工作：global 设置基础频率，scrape_configs 定义采集目标，rule_files 加载告警规则。当 CPU 持续 10 分钟超过 80% 时，Prometheus 会触发告警并发送给 Alertmanager。

经验提醒：在 scrape_configs 中，relabel_configs 是高级用法。例如，可以使用 __meta_kubernetes_pod_label_app 等元标签动态生成目标标签，实现 Kubernetes 服务发现的精细化控制。

常见误区与复盘

误区一：在 global 中设置过短的 scrape_interval（如 1s），导致 Prometheus 负载过高。
误区二：忘记在 rule_files 中引用规则文件，导致告警规则不生效。
误区三：在 scrape_configs 中重复定义相同 job_name，Prometheus 会报错并拒绝启动。

总结而言，三种部署方式各有千秋：二进制适合传统环境，Docker 适合快速迭代，Helm Chart 是云原生首选。而无论哪种方式，深入理解 prometheus.yml 的三大核心配置块，都是构建可靠监控系统的基石。建议读者在实际项目中，先从二进制或 Docker 开始熟悉配置语法，再逐步迁移到 Helm Chart 以享受自动化运维的便利。