1. 从裸安装到容器化Prometheus部署方式背后的技术选择1.1 Docker到底帮我们解决了什么问题初次接触Prometheus的时候我走的是传统的二进制部署路线下载压缩包、解压、写systemd服务、设置开机自启一套流程下来少说也要十分钟。如果还要部署node_exporter和Alertmanager那每台机器都得重复一遍版本差异、目录不一致、配置文件散落各处的问题很快就暴露出来。换成Docker部署之后大部分困扰直接消失了。镜像自带prometheus二进制文件运行环境是固定的只需要指定配置文件和数据目录剩下的交给容器运行管理器。升级的时候拉一个新标签、重新创建容器回滚也只需要把镜像tag切回去几秒钟就能完成。对监控这种“平时不太关注、出了问题又必须马上能查”的基础设施来说这种可复现、可回滚的部署方式价值远远大于省下的那几分钟。另一个容易被忽略的点是隔离。Prometheus本身是单二进程应用但它依赖的配置文件、规则文件、数据目录如果直接铺在宿主机上难免和其他应用产生交集。容器化之后文件通过挂载卷传入数据通过命名卷保存宿主机上只保留一份干净的外部配置目录整个生命周期完全可控。1.2 镜像版本标签怎么选不是latest就完事官方镜像prom/prometheus的发布节奏很规律每个版本都有对应的文档和特性说明。实际使用中我不建议用latest原因是Prometheus大版本迭代时有行为变化比如v2到v3在部分参数和默认行为上做了调整如果哪天latest指到了新大版本你的启动参数可能就不兼容了。比较稳妥的做法是在docker run或者docker-compose里直接锁定一个具体的v2小版本例如docker pull prom/prometheus:v2.53.0同时重要的一步是把镜像版本和官方文档对应起来。不同版本的prometheus.yml字段差异不大但命令行参数、TSDB存储行为、API接口路径都会有细微差别。锁定版本后查询文档时也要切到同版本页面这样排查问题才不会被过时信息带偏。1.3 资源预估内存和磁盘要提前想好Prometheus的时序数据库TSDB是内存友好的但并非不加限制地占用资源。它的内存使用量主要取决于时序数量、标签基数、抓取频率和查询负载。简单估算时可以按“大约每条时序占用300字节到1KB内存”来粗算。如果你只监控几台服务器、每台采集几百个指标2GB内存就非常宽裕但如果你把业务接口的自定义指标也接进来指标量到了十几万甚至上百万条时序内存就可能需要16GB以上。磁盘方面TSDB的压缩做得很好实际占用取决于数据量、抓取间隔、标签数量。建议在启动参数里同时设置保留时间和保留大小两者可以配合使用--storage.tsdb.retention.time15d --storage.tsdb.retention.size20GB这样一组参数的含义是按时间保留15天同时磁盘占用超过20GB时会优先删除最老的区块。我建议都设上只按时间保留的话遇到指标暴涨容易出现磁盘写满只按大小保留的话又可能比预期删得快。2. 先读懂prometheus.yml抓取、评估与告警三条管线怎么协同2.1 global配置中的几个interval各管各的事刚上手时我把prometheus.yml里的三个时间参数搞混过scrape_interval是抓取采集目标的周期evaluation_interval是规则评估周期两者默认都是15s但职责完全不同。scrape_interval影响数据采集频率evaluation_interval影响告警规则多久被评估一次。如果你的告警延迟很高先检查是不是evaluation_interval被调大到了几分钟。另外一个容易被忽略的参数是scrape_timeout它控制单次抓取的超时时间默认10s理论上不能大于scrape_interval。如果遇到某个目标响应很慢把抓取间隔调大不如先分析目标为什么慢超时时间调过头反而会掩盖问题。2.2 scrape_configs一个job是如何变成targets的配置里最核心的部分是scrape_configs。我习惯这样理解一个job代表一类采集任务比如node_exporter、cadvisor、prometheus各是一个job每个job下面通过static_configs或服务发现机制定义一组targets每个target就是一个具体的HTTP拉取端点。当Prometheus开始抓取一个target时它会自动附带一些标签job来自job_name配置instance默认取__address__的值。这些自动标签会出现在所有查询结果里后续在告警模板里会频繁用到。一个最小可用的抓取配置如下scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]如果只是想把监控跑起来这段配置就够了。但实际使用中我强烈建议从一开始就给目标打上更有语义的标签因为默认的instance是IP加端口时间长了根本看不出是哪台机器。- job_name: node_exporter static_configs: - targets: - 10.0.0.11:9100 - 10.0.0.12:9100 labels: env: production role: web这些标签会直接进入每条时序数据的label集合查询和告警时都能用。标签不宜过多否则会推高基数但要保证一眼能看出“这是什么环境、什么角色”。2.3 rule_files与alerting规则谁执行告警发给谁Prometheus的告警体系分成两层规则评估和告警发送。规则文件的写入路径由rule_files指定Prometheus会按照evaluation_interval周期检查规则。一旦规则表达式持续满足条件就生成一条告警并进入激活状态。告警并不由Prometheus直接推送到钉钉或邮件而是先发给一个独立的组件Alertmanager由它负责分组、去重、路由和通知。配置上需要告诉Prometheus去哪找Alertmanageralerting: alertmanagers: - static_configs: - targets: - alertmanager:9093 rule_files: - /etc/prometheus/rules/*.yml规则文件里定义的是一条条告警规则例如groups: - name: node_alerts rules: - alert: HighCpuUsage expr: 100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100 80 for: 10m labels: severity: warning annotations: summary: CPU usage on {{ $labels.instance }} is above 80%这里的for: 10m非常关键它表示指标需要持续10分钟超过阈值才触发告警可以过滤掉瞬时尖峰。规则、抓取、告警发送这三条线在时序上互相配合抓取提供数据规则周期评估告警通过Alertmanager送出理解了这个链路后面排查告警丢失会轻松很多。2.4 TSDB数据如何落盘block、WAL与retentionPrometheus自带的时序数据库采用按区块组织的方式。每隔大约2小时内存中的最新数据会被写入一个新的block文件block包含指标数据、索引和元数据。写入过程中先有WAL预写日志做保障Prometheus崩溃重启后可以靠WAL恢复未落盘的数据。这解释了为什么数据目录里会有一堆时间戳命名的目录也解释了为什么必须把数据目录做成持久化卷容器一旦被删除留在容器层里的block会一起被清掉只有保存在卷里的数据才能活下来。--storage.tsdb.retention.time和--storage.tsdb.retention.size在这里生效。注意二者是“或”的关系任何一个条件先达到就会触发旧block的清理。理解了这个机制就知道为什么单节点Prometheus不适合承担超大规模指标存储它是为可靠、简洁的本地存储设计的长时间跨度查询和大规模历史回放并不擅长。3. 用docker-compose搭一套能监控Docker主机和容器的基础设施3.1 先用docker run验证最小可用环境如果你第一次接触Prometheus我不建议直接上compose。先跑一个最简容器把抓取链路跑通再逐步扩展这样出了问题容易定位。先创建一个配置文件prometheus.ymlglobal: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]然后执行docker run -d \ --name prometheus \ -p 9090:9090 \ -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml:ro \ -v prometheus-data:/prometheus \ prom/prometheus:v2.53.0 \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/prometheus \ --storage.tsdb.retention.time15d启动后用浏览器访问宿主机的9090端口进入Prometheus自带界面点击“Status”下的“Targets”如果看到prometheus这个job的状态是UP说明最小链路已经通了。这个自监控target通过localhost:9090抓取实际上抓取的是Prometheus容器自己。3.2 compose纳入node-exporter和cadvisor只监控Prometheus自身意义不大我们通常还要监控宿主机的CPU、内存、磁盘以及Docker容器本身的运行指标。这里会用到两个经典导出器node_exporter负责暴露主机指标cadvisor负责暴露容器指标。下面是一个推荐的三服务compose配置services: prometheus: image: prom/prometheus:v2.53.0 container_name: prometheus ports: - 9090:9090 volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro - ./rules:/etc/prometheus/rules:ro - prometheus-data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --storage.tsdb.retention.time15d - --storage.tsdb.retention.size20GB - --web.enable-lifecycle restart: always node-exporter: image: prom/node-exporter:v1.8.2 container_name: node-exporter ports: - 9100:9100 volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - --path.rootfs/host restart: always cadvisor: image: gcr.io/cadvisor/cadvisor:v0.49.1 container_name: cadvisor ports: - 8080:8080 volumes: - /:/rootfs:ro - /var/run:/var/run:ro - /sys:/sys:ro - /var/lib/docker/:/var/lib/docker:ro - /dev/disk/:/dev/disk:ro privileged: true restart: always volumes: prometheus-data:node-exporter需要挂载宿主机的/proc、/sys和根目录通过--path.rootfs/host让它在容器内正确读取主机信息。cadvisor需要读取Docker的运行目录所以也要挂载相关系统路径并加privileged权限。对应的抓取配置扩展为scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node_exporter static_configs: - targets: [node-exporter:9100] - job_name: cadvisor static_configs: - targets: [cadvisor:8080]这里的关键点是容器之间通过compose创建的内部网络互相访问所以Prometheus里填的target地址是服务名node-exporter:9100而不是localhost或宿主机的IP。3.3 数据卷与文件权限别让容器以nobody身份写不了目录用bind mount挂载配置文件和目录时经常会碰上一个隐性问题Prometheus容器默认不是以root运行的容器内部用户是nobody。如果你的宿主机目录权限是700且仅属于root容器进程可能就无法读取配置或写入数据目录。我自己的习惯是配置文件和规则文件所在目录设置为755或750并且确保文件本身至少是644。数据目录直接用命名卷不直接挂在宿主机的某个文件夹下面这样权限由容器运行时管理少踩很多坑。需要单独保存数据时可以挂载并预先chown调整属主。另外一个细节是挂载配置时加:ro只读。这不是必需的但能防止容器内部误改配置文件也提醒自己配置的源头只在宿主机那一侧。3.4 用promtool做配置自检Prometheus自带一个非常有用的命令行工具promtool不需要额外安装。修改配置后先跑一次校验再重启容器能省去大量兜圈子排查时间docker run --rm -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml:ro prom/prometheus:v2.53.0 promtool check config /etc/prometheus/prometheus.yml规则文件也可以校验docker run --rm -v $(pwd)/rules:/etc/prometheus/rules:ro prom/prometheus:v2.53.0 promtool check rules /etc/prometheus/rules/*.ymlpromtool还会提示一些常见问题比如规则表达式语法错误、配置字段拼写错误。上线前多花这几十秒后面能少折腾半小时。4. 让抓取目标从简单到复杂静态配置、标记与文件发现4.1 静态配置与标签设计监控几台固定服务器时静态配置最简单也最好维护。建议从第一天就养成打标签的习惯。比如把生产环境和测试环境区分开- job_name: node_exporter static_configs: - targets: [10.0.0.11:9100, 10.0.0.12:9100] labels: env: production - targets: [10.0.0.21:9100] labels: env: staging这些标签会在查询和告警路由里发挥很大作用。比如Alertmanager可以根据env标签把生产环境的高优告警和测试环境的低优告警分开处理。条目增多后每个文件维护几百个target会显得笨重。这时候就需要引入服务发现机制让Prometheus动态读取目标列表。4.2 基于文件的服务发现适合中小规模、好理解的动态方案文件服务发现file_sd是静态配置到全面服务发现之间最好的过渡方案。它允许外部脚本把目标列表写入JSON或YAML文件Prometheus按固定周期重新读取并自动更新target。Prometheus配置里这样写- job_name: node_exporter file_sd_configs: - files: - /etc/prometheus/targets/*.yml refresh_interval: 30s对应的targets文件targets/node1.yml内容如下- targets: - 10.0.0.11:9100 - 10.0.0.12:9100 labels: env: production这样运维脚本或配置管理工具只需要把新增主机的IP和标签追加到文件列表里30秒后Prometheus就会自动纳入采集不需要重启服务也不需要reload。我实际用的过程中最大的收益是每次加机器只需要在targets目录下放一个新文件既不影响现有配置又能单独查看每个文件的变更记录。如果以后要迁移到Consul之类的注册中心Prometheus配置文件的结构也不需要大改只换discovery类型即可。4.3 relabel在抓取前调整标签的常见玩法relabel_configs是Prometheus非常灵活、但是初学者最容易犯迷糊的模块。它的作用是在抓取前对目标标签进行增删改。最常见的需求是把默认的instance标签从“IP:9100”变成纯IP让显示更干净。例如- job_name: node_exporter static_configs: - targets: [10.0.0.11:9100] relabel_configs: - source_labels: [__address__] regex: ([^:]):9100 target_label: instance replacement: $1这段配置的含义是从__address__这个内部标签提取出冒号前的IP部分写入instance标签。__address__是Prometheus抓取时使用的一个内部标签normal方式下会通过instance透出但我们可以改掉它。更复杂的relabel场景包括从URL路径提取环境信息、过滤指定标签的目标、给不同job注入统一标签等。开始阶段不必贪多先把source_labels、regex、target_label三个字段练熟就已经能应对七八成的需求。5. 把指标接进Grafana把告警接进Alertmanager5.1 容器网络里Grafana为什么填prometheus:9090Grafana是Prometheus最常用的可视化面板。如果Grafana也用Docker部署并且和Prometheus在同一个compose环境里数据源地址就可以直接写http://prometheus:9090这是compose内部DNS解析的结果。如果你把Grafana单独跑在另一个容器网络或者直接跑在宿主机进程里那数据源地址就要填http://宿主机IP:9090。很多人在这一步卡住其实是没理清容器网络和宿主机网络的边界。一个简单的判断方法谁要访问谁就站在谁的视角看地址。Prometheus要抓node-exporter所以站在Prometheus容器视角node-exporter的地址是服务名Grafana要查询Prometheus API所以站在Grafana容器视角地址是prometheus:9090。宿主机浏览器要访问Grafana或Prometheus用的是宿主机IP加映射端口。Grafana里添加数据源时类型选PrometheusURL填对应地址保存后切到Dashboards页面导入ID为1860的Node Exporter Full模板就能看到一套完整的node指标面板。这套流程跑通后相当于Prometheus Grafana的可视化闭环已经完成。5.2 一条告警从触发到通知的完整链路如果把告警流程画成一条时间线可以这样理解Prometheus按evaluation_interval周期评估规则。规则表达式持续满足for设置的时间后告警进入Firing状态。Prometheus把激活的告警以HTTP请求发给Alertmanager。Alertmanager根据路由规则做分组、抑制后把通知发到对应接收端。这里特别要注意for的作用。如果阈值条件只持续了一分钟而for设置的是5分钟那么告警不会触发。反之如果不想收到任何短暂抖动引起的告警就把for设为一个合理区间比如5分钟或10分钟。Alertmanager的配置包含两个核心部分route和receivers。一个简化但常用的配置如下route: group_by: [alertname] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: default-webhook routes: - match: severity: critical receiver: critical-webhook receivers: - name: default-webhook webhook_configs: - url: http://10.0.0.30:9000/notify - name: critical-webhook webhook_configs: - url: http://10.0.0.30:9000/notify/critical这条路由配置的逻辑是所有告警先进入默认的webhook接收端但如果告警带有severitycritical标签就转到critical-webhook。group_by: [alertname]会把5分钟内相同告警名的告警合并成一组避免通知轰炸。5.3 通知落在钉钉或企业微信这类平台时需要自己写转发层Alertmanager原生接收端里没有钉钉或企业微信这类渠道通常的做法是配置一个webhook_configs指向一个自定义转发服务。这个转发服务接收Alertmanager的JSON告警体再格式化成目标平台的消息结构发出去。这里分享一个实践经验不要在一个receivers里同时配多种通知渠道初期只保留最稳定的一个等告警链路跑稳定了再加其他渠道。否则告警触发时多个渠道同时故障或重复反而会掩盖真正的问题。6. 运行阶段最值得记住的几类问题以及它们背后的原因6.1 容器启动后立刻退出怎么定位现象是docker run之后容器状态显示Exited这时第一反应不要反复重启先看日志docker logs prometheus常见的错误包括配置文件内字段拼写错误找不到规则文件路径数据目录没有写权限命令行参数写错。promtool check config已经能过滤掉大部分语法问题如果日志提示无法创建TSDB优先检查数据目录权限。6.2 挂载目录权限导致的TSDB写入失败这件事我踩过不止一次。把数据目录bind mount到宿主机某个目录后Prometheus启动时报错“mkdir /prometheus: permission denied”原因是容器内用户nobody对宿主机目录没有写权限。解决方式有两种一是在宿主机上执行chown -R 65534:65534 /data/prometheus65534是nobody用户的UID二是直接改用命名卷让容器运行时负责管理。考虑到数据可迁移性我推荐第一种方式时只给自己本机实验用生产环境用命名卷和工具链配合备份不要手工管理一堆主机目录。6.3 配置改了没生效不是文件错了而是没有reloadPrometheus默认不会监控配置文件变化。你可以通过两种方式触发热加载docker kill -s SIGHUP prometheus或者启用--web.enable-lifecycle后调用APIcurl -X POST http://localhost:9090/-/reload注意kill -s SIGHUP发到容器里的进程1也就是Prometheus主进程它会重新加载配置。API方式更直观尤其是你处在远程环境时。建议启动参数里直接加上--web.enable-lifecycle但要注意这个参数在生产公网环境不要随意暴露应在网关层做好防护。6.4 容器删掉重来监控数据全没了这是容器部署最容易踩的坑。如果启动时没有给/prometheus挂载持久化存储卷所有监控数据都写在容器可写层容器删除后数据随之消失。解决方式就是我一直强调的命名卷或挂载目录。另外升级Prometheus时也别直接docker rm -f老容器最稳妥的做法是先停容器确认数据卷还在再创建带相同卷引用的新容器。如果连卷名都变了数据自然也就不在了。6.5 时间不同步导致抓取周期不稳定Prometheus对时间敏感目标主机和Prometheus所在主机如果存在明显时钟漂移会导致数据点错位、查询结果异常。Docker容器默认和宿主机共享内核时钟但宿主机本身如果没做好时间同步容器内也一样漂。所以宿主机上一定配置好时间同步服务。不要只盯着容器底层的时钟源才是根因。这个问题的典型表现是Targets显示UP但图表里的数据断断续续改进时间同步后立马恢复正常。6.6 Target在Targets页面里长期DOWN别急着怀疑Prometheus当一个target在Prometheus的Targets页面上显示DOWN问题不一定在Prometheus本身。要按顺序排查目标端口监听是否正常在目标机器上执行curl http://localhost:9100/metrics。端口是否对外可达在Prometheus容器里执行wget -qO- http://目标IP:9100/metrics这一步验证容器网络到达目标主机的连通性。防火墙或安全组是否放行端口。如果页面显示连接拒绝或超时信息会直接写出来按提示逐项排查就行。还有一个小细节如果node-exporter配置了--web.listen-address绑定非9100端口target地址必须改成对应端口否则Prometheus会默认访问9100。这类“配置和实际不符”的问题比网络故障更常见。我在实际操作中最深的体会是Docker化并没有改变Prometheus本身的工作方式它只是把“运行环境绑在一起”这件事交给了容器但配置文件结构、数据持久化、网络连通性和告警链路这些基本功仍然需要自己搞清楚。每多懂一环出问题时的定位范围就缩小一大截。整套监控建好以后我建议顺手做一次演练把Prometheus数据目录彻底删掉再恢复新建一台机器通过文件发现自动加入监控然后手动触发一条告警验证通知链路。这套演练做完剩下的日常维护才会真正轻松。
