我最早接触监控系统是从 Zabbix 开始的后来业务容器化之后机器数量上来了指标种类也多了Zabbix 那套维护成本越来越高。踩了不少坑之后我把整套监控栈迁到了 Prometheus Grafana 上面一直用到现在。今天这篇东西就是我把自己从零搭建这套系统、配置 Grafana 可视化界面的完整过程记下来里面有完整的 docker-compose 编排、prometheus.yml 的写法、告警规则接入 Alertmanager 的配置以及我在升级 Grafana 过程中遇到的一堆报错和排查方法。你不管是跑一个小集群还是已经上了 Kubernetes这套方案都可以直接照搬。1. 先想清楚监控要解决什么问题1.1 Prometheus 和传统监控的根本区别很多人一上来就问我Prometheus 到底比 Zabbix 强在哪我说一个最直观的差别Zabbix 是主机模型你得把每个设备、每个指标都“配”进去监控项是提前定义好的而 Prometheus 是拉取pull模型它定期去目标端点上抓数据数据里本身就带着标签天然就是多维度的。你在一台机器上跑一个 node_exporterPrometheus 每 15 秒来抓一次机器的 CPU、内存、磁盘、网络就全都进数据库了。不用像以前那样新建一台机器就得去 Zabbix 里手动关联模板、改分组、检查组名。容器衍生出来的实例多了之后这套模式会让运维压力小很多。再说存储Prometheus 用的是自定义的时序数据库不是 MySQL也不是 PostgreSQL。它的数据模型是一个指标名加一组 label比如node_cpu_seconds_total{cpu0,modeuser}这种结构让聚合查询非常方便。你写一句sum(rate(node_cpu_seconds_total[5m])) by (instance)就能直接出多台机器聚合之后的 CPU 使用率趋势图这在传统监控里几乎不可想象。1.2 整体架构拆解采集、存储、告警、可视化整套系统的角色划分特别清楚我习惯把它拆成四块采集端exporter也就是各种 agent常见的有 node_exporter主机指标、cadvisor容器指标、mysqld_exporter数据库指标、snmp_exporter交换机/网络设备等。它们负责把系统指标暴露成一个 HTTP 端口。存储与计算端Prometheus Server负责拉取指标、按规则聚合、存储数据同时会去评估告警规则。告警分发端Alertmanager接收 Prometheus 推送过来的告警做去重、分组、静默然后发到邮件、钉钉、企业微信等渠道。可视化端Grafana通过 PromQL 查询 Prometheus 里的数据画出面板和 Dashboard。这四层之间没有强耦合哪一块出问题就单独修哪一块。比如告警不想用了可以先把 Prometheus 里的告警规则停掉不影响数据采集和展示Grafana 崩了数据还是照常往 Prometheus 里写。这种松耦合的结构让我后面做升级、扩容量心里都有底。2. 部署前我做的那些准备2.1 机器规划与版本选择版本选择上我建议别一上来就追最新版。像 Prometheus 2.x 系列我长期用的是 2.45 左右的版本稳定社区踩坑文档多Grafana 的 9.x 和 10.x 差别不大9.x 更稳10.x 的新特性如果你用不上反而容易遇到升级问题。Alertmanager 用和 Prometheus 配套的 0.26 附近版本。你只有一台机器也没关系这套东西就是为单机起步设计的。我在一台 4 核 8G 的虚机上跑过完整的一套Prometheus、Grafana、Alertmanager、node_exporter、cadvisor用了一年多都没问题。目录规划上我比较执拗一定要先想清楚再动手/data/monitoring/prometheus/放 Prometheus 配置和数据/data/monitoring/grafana/放 Grafana 配置和数据/data/monitoring/alertmanager/放告警配置文件/data/monitoring/exporters/放需要挂载的采集器配置数据目录一定不要在系统盘里后面时序数据写起来会非常快别让日志跟监控数据抢磁盘 IO。2.2 Docker 镜像下载慢怎么破我早期用 docker pull prom/prometheus那个体验确实是折磨尤其在拉 Grafana 镜像的时候经常超时。我的做法是给 Docker 配置镜像加速器。这一步很简单编辑/etc/docker/daemon.json{ registry-mirrors: [https://docker.m.daocloud.io] }注意件名都不叫 daemon.json 的话就自己创建。配置完之后执行systemctl daemon-reload systemctl restart docker重启完用docker info看一下 Registry Mirrors 是不是已经生效。如果你公司内部有镜像仓库也可以直接把它当成上游同步源效果一样。这一块有个实际影响Prometheus、Grafana 这些容器镜像动辄两三百兆网络不稳的话很容易中途断掉。加速器配置好之后后面所有步骤都会顺畅很多。3. docker-compose 一键拉起整套监控栈3.1 编排文件怎么写我习惯把所有服务放到一个 docker-compose 里管好处是配置文件集中起来了之后就再也不用管了。下面是我现在生产环境下的一套精简版编排version: 3.7 networks: monitoring: driver: bridge volumes: prometheus_data: {} grafana_data: {} services: prometheus: image: prom/prometheus:v2.45.1 container_name: prometheus hostname: prometheus restart: always ports: - 9090:9090 volumes: - /data/monitoring/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml - /data/monitoring/prometheus/rules.yml:/etc/prometheus/rules.yml - prometheus_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.retention.time15d - --storage.tsdb.retention.size20GB networks: - monitoring node-exporter: image: prom/node-exporter:v1.6.1 container_name: node-exporter restart: always ports: - 9100:9100 networks: - monitoring alertmanager: image: prom/alertmanager:v0.26.0 container_name: alertmanager restart: always ports: - 9093:9093 volumes: - /data/monitoring/alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml command: - --config.file/etc/alertmanager/alertmanager.yml - --storage.path/alertmanager networks: - monitoring grafana: image: grafana/grafana:10.2.3 container_name: grafana restart: always ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_USERadmin - GF_SECURITY_ADMIN_PASSWORDadmin123 - GF_AUTH_ANONYMOUS_ENABLEDfalse volumes: - grafana_data:/var/lib/grafana - /data/monitoring/grafana/provisioning:/etc/grafana/provisioning depends_on: - prometheus networks: - monitoring这套里面有几个细节我特别说一下Prometheus 的--storage.tsdb.retention.time控制时间保留长度--storage.tsdb.retention.size控制大小上限。我设的是 15 天或 20GB哪个先到就算哪个。对于中小团队15 天足够排查问题了。别一开始就留 60 天数据文件膨胀起来单机根本扛不住。depends_on只保证容器启动顺序不保证服务已经就绪所以 Grafana 第一次起来可能有点慌但只要重启策略写的是always它会在 Prometheus 就绪后重新连接。数据卷一定用命名卷或者宿主机目录别写在容器可写层里容器一删数据全没这个教训我经历过。3.2 为什么要用 provisioning 而不是手动点界面很多新手装完 Grafana 之后都是打开网页手动填数据源这样当然也能用。但我强烈建议从一开始就用 provisioning 的方式自动配置数据源和面板。在宿主机/data/monitoring/grafana/provisioning/datasources/下建一个prometheus.ymlapiVersion: 1 datasources: - name: Prometheus type: prometheus access: proxy url: http://prometheus:9090 isDefault: true editable: true这里url直接用容器名http://prometheus:9090因为在同一个 docker-compose 网络里容器名就是可解析的域名。如果 Grafana 在宿主机上运行、Prometheus 在容器里就要写http://127.0.0.1:9090或者把防火墙端口放通。用了 provisioning 之后Grafana 重启后会自动加载数据源配置不用手动点。你以后批量部署环境复制一份配置就行比鼠标点半天快得多也方便代码审查。4. prometheus.yml 核心配置拆解4.1 全局配置从零讲起Prometheus 的所有采集行为都由这个 YAML 文件控制。我放一份最常用的基础配置global: scrape_interval: 15s evaluation_interval: 15s external_labels: cluster: my-lab rule_files: - /etc/prometheus/rules.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]几个关键点scrape_interval: 15s是采集间隔。间隔越小数据越细但磁盘和内存压力越大。一般监控系统 15 秒足够了线上核心业务可以单独设 5 秒。evaluation_interval: 15s是告警规则的评估间隔每 15 秒检查一次规则是否需要触发告警。external_labels是给所有指标打上的全局标签比如你以后要做联邦集群这个标签可以用来区分不同集群的数据。rule_files是告警规则文件路径Prometheus 启动时会加载并周期性评估这些规则。4.2 node_exporter 和 cadvisor 的采集配置采集主机指标在scrape_configs里加一段- job_name: node static_configs: - targets: - 192.168.1.10:9100 - 192.168.1.11:9100 labels: env: prodtargets里填的是 node_exporter 监听端口。我一般会在静态 target 里带上env标签结合后面的 Grafana 变量使用可以从界面上按环境筛选机器非常爽。如果你要监控 Docker 容器就再挂上一个 cadvisor 采集器- job_name: cadvisor static_configs: - targets: - 192.168.1.10:8080cadvisor 对磁盘、网络、CPU 容器维度的指标很全和 node_exporter 搭配起来一套监控体系基本齐了。4.3 怎么监控交换机和网络设备那会儿我负责的一套机房里有二十多台交换机Prometheus 本身不认识 SNMP 协议所以要用 snmp_exporter 来采集。部署方式一样在 docker-compose 里加一个prom/snmp-exporter服务配置好认证信息然后在 prometheus.yml 里这样写- job_name: network-devices scrape_interval: 60s static_configs: - targets: - 192.168.1.1 - 192.168.1.2 metrics_path: /snmp params: module: [if_mib] relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: snmp-exporter:9116这里的 relabel 逻辑其实是很多人的噩梦。它的作用是请求先访问 snmp-exporter:9116但要带上一个参数target192.168.1.1告诉 snmp-exporter 去采集哪台设备的指标。整个过程类似于“借道”采集。4.4 Prometheus 如何从 Otel Collector 收数据这个标题是很多从 OpenTelemetry 迁过来的人会问的。简单说OTel Collector 对外暴露的不是 Prometheus 那种拉取端口它得把你应用产生的 metric 通过 exporter 转发出去。你可以在 OTel Collector 配置里加一个prometheusexporter监听一个端口并把指标格式转成 Prometheus 能抓的格式exporters: prometheus: endpoint: 0.0.0.0:8889 namespace: otel service: pipelines: metrics: receivers: [otlp] exporters: [prometheus]然后在 prometheus.yml 的scrape_configs里把 OTel Collector 暴露出来的8889端口抓一遍- job_name: otel-collector static_configs: - targets: [otel-collector:8889]这样 Prometheus 就能当它的“消费者”把 OpenTelemetry 采集到的应用指标统一纳入监控体系。官方原话是“支持通过 Remote Write 推送”但在云原生场景下这个拉取方式用得最多。5. 告警规则和 Alertmanager 接入5.1 告警规则怎么写才不炸手机告警规则我踩过最大的坑是误报。一开始 CPU 超过 80% 就告警结果业务高峰天天收到几十条消息最后大家都麻木了真正出故障反而没人看。后来我学乖了加了两套机制持续时间和多条件。rules.yml里一个典型的规则groups: - name: host_alerts rules: - alert: HostCpuHigh expr: | 100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance) 90 for: 5m labels: severity: critical annotations: summary: {{ $labels.instance }} CPU 使用率过高 description: {{ $labels.instance }} 的 CPU 使用率已超过 90%持续 5 分钟以上。for: 5m表示指标需要持续 5 分钟满足条件才会触发这一下就能过滤掉大部分瞬时抖动。expr里的 PromQL 是关键rate(node_cpu_seconds_total{modeidle}[5m])算出过去 5 分钟内空闲 CPU 的平均占比再用 100 减掉它得到使用率。除以集群里 CPU 核数之类的操作需要根据实际需求调整。5.2 Alertmanager 收告警和发送通知Alertmanager 的配置文件如下route: group_by: [alertname] group_wait: 10s group_interval: 5m repeat_interval: 4h receiver: default receivers: - name: default webhook_configs: - url: http://your-webhook-server/hooks/alert send_resolved: true几个参数含义group_wait: 同一组告警首次通知前的等待时间我设 10 秒让同类告警凑一凑再发。group_interval: 同组告警再次通知的间隔。repeat_interval: 一个告警如果没有解决需要重新通知的间隔。这个我设 4 小时避免轰炸。send_resolved: true会让 Alertmanager 在告警恢复时也发一条通知我个人建议打开不然界面上的告警有没有恢复你根本不知道。现在很多团队直接接的是 Grafana 的 Alerting 模块其实它是可以把 Prometheus 的数据源拿来做规则的。Grafana Alerting 对可视化更友好Prometheus 原生的 Alertmanager 则更轻量。我的方案是“Prometheus 规则 Alertmanager 通知 Grafana 展示”这样告警链路少、灵活、不用在 Grafana 里重复配置规则。6. Grafana 数据源与面板配置的全过程6.1 添加数据源的基本操作打开浏览器访问http://ip:3000默认账号 admin/admin。第一次登录会强制改密码如果忘了就在 Docker 环境变量里重新指定GF_SECURITY_ADMIN_PASSWORD。进去之后先不要急着建面板先把数据源配上。点左上角菜单依次找到“Connections - Data sources”点 Add data source选择 Prometheus。注意这几个字段Name随便填我用 PrometheusURL如果你用了 provisioning 就不用填如果是手动配置容器部署就填http://prometheus:9090本机部署填http://127.0.0.1:9090Access选 Server默认就是 Server表示请求由 Grafana 服务端转发可以避免浏览器跨域安全策略填完点 Save test看到绿色的 Data source is working 就说明通了。6.2 从零手搓一个面板数据源配好后点 Dashboards - New dashboard - Add visualization添加查询。这里最常用的指标就是 CPU 使用率。在 Query 编辑器里输入100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance))右上角把时间范围选到 last 15 minutes立刻就能看到多条曲线一条对应一台机器。面板配置里我重点说几个Unit选择 Percent (0-100)否则数值就是个裸数字很难看。Legend可以改成{{instance}}图例上直接显示 IP方便识别。Thresholds把阈值线设成 90颜色选红色。面板上出现一个水平红线超过就有告警氛围了。同样的方式你可以加内存面板(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100磁盘空间100 - (node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay} * 100)注意磁盘查询一定要过滤虚拟文件系统不然 tmpfs、overlay 这些会干扰结果。6.3 面板模板导入与整体拷贝手搓面板当然可以但官方社区有成型的 Dashboard直接用比自己画快太多。在 Grafana 里Dashboards - Import填一个 Dashboard IDNode Exporter Full1860容器监控大盘14282Spring Boot 监控19004导入之后会要求选择数据源选你刚才配的 Prometheus 就行。这里插一句很多人不知道“拷贝整个面板”的操作。如果你想把这个 Dashboard 复制到另一个 Grafana 实例不用重新一个面板一个面板地画直接在 Dashboard 设置里找到 JSON Model全选复制。然后到新环境的 Import 里选择“Import via panel json”粘贴进去就能完整还原。我们团队现在就是运维手上一份标准的 Dashboard JSON新环境交付时直接导入五分钟搞定不用重新配。6.4 用变量让面板活起来固定写死查询条件的面板可复用性很差。我建议给 Dashboard 加变量比如按env标签筛选环境按instance筛选主机。添加变量的路径Dashboard settings - Variables - Add variable。类型选 Query查询语句里填label_values(node_cpu_seconds_total, instance)这样下拉框里就会自动列出所有监控主机的 IP。然后在查询语句里引用100 - (avg(rate(node_cpu_seconds_total{instance~$instance}[5m])) by (instance))用户在上方选择了哪台机器面板就展示哪台机器的数据。变量系统是 Grafana 最实用的功能一定要学会。7. 常见问题与排查实录7.1 升级后报错failed to upgrade legacy queries datasource ... was not found这个报错出现的原因很典型Grafana 面板里保存的查询是旧版本格式legacy query升级到新版本后面板里的数据源名称与当前数据源 ID 对不上了于是 Grafana 找不到那个 datasource。遇到这个报错我的排查顺序是先到 Connections - Data sources 里确认 Prometheus 数据源还在不在名称是否还叫 Prometheus。然后打开面板的 JSON Model搜索datasource字段看看里面引用的是uid: xxx还是旧的 datasource name。如果是旧格式直接手动把datasource.uid替换成当前数据源的 UIDdatasource.type改成prometheus。最省事的办法就是把面板 JSON 里所有查询重新选一遍数据源保存后再刷新。要是实在懒得改还有一个更粗暴的解法删掉这个面板到 Import 里重新导入原始 JSON这种方式对旧面板来说比修数据源快得多。7.2 Grafana 数据源连接被拒点 Save test 时如果出现 Network Error: Bad Gateway 或 dial tcp: lookup prometheus on 0.0.0.0:53 no such host大概率是 Grafana 容器和 Prometheus 容器不在同一个 Docker 网络里。我解决方法是进到 Grafana 容器里面试一下docker exec -it grafana sh curl http://prometheus:9090如果 curl 不通说明容器间网络有问题。这时候回到 docker-compose.yml确认两个服务都在同一个networks下然后重新docker-compose up -d。本地访问的情况Grafana 在容器里要访问宿主机上的 Prometheus就要把 URL 写成http://host.docker.internal:9090并且在启动参数里加上extra_hosts: [host.docker.internal:host-gateway]。7.3 指标总不显示十有八九是时区问题Grafana 默认显示的是 UTC 时间国内用户会看到时间差 8 小时。这个不算数据传输问题改一下时区就好。在 Grafana 的 User preferences 里把 Timezone 改成Local browser time或者直接在面板右侧的 Time range 设置里选择浏览器本地时间。如果想全局统一可以在环境变量里加- GF_DEFAULT_HOME_DASHBOARD_TIMEZONEbrowser另外 Prometheus 存储的时间戳本身是 UTC 的这个是时序数据库的正常行为不用改。7.4 时序数据占满磁盘Prometheus 的 TSDB 写起数据来是真的猛尤其是我一开始把 retention 设成 90 天结果一块 80G 的数据盘三个月就见底了。后来我改成按大小限制就是前面配置文件里的--storage.tsdb.retention.size20GB。注意这个参数在启动命令行里配在 yml 里不生效。如果磁盘已经满了临时清理可以先停掉 Prometheus 容器删掉/prometheus/wal和data目录里部分数据再启动。但这个是下策最好还是提前配置好 retention别等到满了再处理。7.5 Prometheus 的 alert 页面里看不到规则经常有人配置好rules.yml之后在 Prometheus 的 Alerts 页面后怎么都看不到规则。检查一下你的rule_files路径是不是写对了。如果你用 docker-compose 挂载文件注意容器里的路径和宿主机路径是两码事。我见过好多次把宿主机路径写进 rule_files 容器里结果永远加载不到配置。我建议启动后进容器看一眼docker exec -it prometheus sh cat /etc/prometheus/rules.yml确认文件确实挂载进去了。然后看 Prometheus 日志里有没有Error loading rules的提示。正常加载会有一行Starting rule manager...。8. 实际操作中我的一些心得这套监控栈我前前后后部署过几十套从单机环境到多机房集群都用过。最后分享几条经验希望你真能省下一些时间。第一监控不是为了“有图看”而是为了“能发现自己不知道的事”。所以我建议部署完成后先花一整天时间把 PromQL 练熟练重点掌握rate、irate、sum、avg、by这几个算子。面板着不着急不重要查询会写了任何指标都能随手出图。第二告警规则一定要“从宽发现、从严通知”。意思是采集的指标可以多采但告警条件要反复调优宁可后置也不要先轰炸告警。先把for: 5m这一类持续时间参数设上运行两周之后再根据实际情况收紧。第三把配置文件和 Dashboard JSON 纳入版本管理。我见过太多人晚上改完 prometheus.yml第二天忘记改了什么又不敢乱动。你用 Git 管起来每次变更都有记录出了问题直接回滚这对运维来说比什么都重要。这个项目后续还能扩展的方向其实不少比如给 Grafana 加上 LDAP 登录、用 Thanos 做多集群联邦与长期存储、给 Alertmanager 配置静默维护窗口。但不管是哪一步基础都是今天这套部署和配置流程。你把这一套走通、跑稳后面再复杂的功能都能在这个底子上长出来。