做监控这块绕不开这套组合Prometheus Grafana。从最开始服务器上只有一份脚本定时跑df和free到后来容器化、微服务化之后指标铺天盖地涌过来我才真正理解为什么 Prometheus 成了云原生监控的事实标准也为什么大家偏偏选中 Grafana 来做展示层。这篇文章把这套环境从零搭建到告警联动的完整过程写下来包含我实操下来踩过的坑适合刚接触监控、准备在公司内网搭一套基础监控体系的运维和开发同学参考。这套组合能做的事很清楚Prometheus 负责拉取和存储时序指标Grafana 负责把指标变成看得懂的图表和看板再配上 Alertmanager 把异常变成电话、短信、钉钉、企业微信里的告警。整个链路开源、免费、组件少、文档多二三十台机器的小团队能用上万节点的集群也能通过联邦、分片和 Thanos 之类的方案撑住这也是它相比 Zabbix、Open-Falcon 这些老牌监控最大的优势。1. 监控选型为什么最终是 Prometheus Grafana 这套组合1.1 云原生时代Pull 模型才是主流Prometheus 核心的设计思路是 Pull 模型也就是由 Prometheus server 主动去各个目标机器的 HTTP 接口上抓取指标。刚开始用的时候我跟很多人一样有疑问Zabbix 那种 Agent 主动上报数据的 Push 模型不是更省事吗机器只要装个 Agent 就往服务端推数据服务端不用知道目标在哪里。实际跑起来才明白 Pull 模型的好处。第一服务端能准确知道目标是否存活up 0这个指标直接就是最天然的存活探针Push 模型下 Agent 挂了服务端根本不知道。第二 Pull 模型天然适合 Prometheus 配套的服务发现机制Kubernetes 里 Pod 的 IP 是动态变化的靠配置文件维护目标列表根本不可行Prometheus 可以直接从 Kubernetes API 里动态发现 Pod 和 Service自动开始抓取。第三抓取频率由服务端统一控制避免成千上万个 Agent 同时上报把服务端打爆。这套设计放到今天云原生的场景下依然合理只要能暴露一个符合 Prometheus 文本格式的 HTTP 接口就能被纳管进来新服务接入监控的成本几乎为零。1.2 时序数据模型与标签设计是灵魂Prometheus 的数据模型乍一看很简单一条时序数据由 metric 名称、一组 label 键值对和一个 float 数值组成比如http_requests_total{methodPOST, code500} 1024。但恰恰是这套标签机制让它的查询能力远超传统监控。我在教会团队用 PromQL 时总喜欢用一个比喻如果把每台机器的 CPU 使用率比作一本书metric 名称是书名标签就是目录索引。你要查所有机器的 CPU直接100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)一个表达式就能把几十台机器的 CPU 汇总曲线画出来。想在查询结果里按机器、按环境、按业务模块拆分全凭标签怎么设计。这也引出一个非常重要的经验标签命名一开始就要想清楚。我在生产环境吃过亏一开始没有规范标签不同 exporter 输出的 label 命名五花八门有的叫host有的叫node有的叫instance导致后面的 PromQL 表达式没法复用看板拆了又拆。建议在团队内约定好统一的标签规范比如env环境、app应用、instance实例地址所有接入监控的服务都必须遵守这会让你后续写告警规则和看板的时候省下大量时间。1.3 Grafana 为什么能脱颖而出Prometheus 自带的 UI 只适合做简单查询和调试离“可视化平台”还有不少距离。Grafana 的定位就是纯展示层它不关心数据从哪来只要数据源支持就能画图。一个 Grafana 实例可以同时接 Prometheus、MySQL、Elasticsearch、Loki、Zabbix 等多个数据源做统一的可视化入口。Grafana 的社区生态是它最大的护城河。官方和社区贡献了海量现成的 Dashboard 模板ID 一填、数据源一选几分钟就能复制一套专业看板。我到现在还记得第一次导入 node_exporter full 模板时的震撼相当于一个资深团队帮你把几百个常用指标都画好了图排列、单位、告警阈值全都调好了。这种“站在巨人肩膀上”的快感是自研监控系统永远给不了的。2. 二进制部署Prometheus server 与 Grafana 的落地全过程2.1 下载与版本选择部署方式我推荐先用二进制不急着上容器。二进制部署的整个链路清晰配置文件、数据目录、进程管理都是显式的出了问题好排查对理解 Prometheus 的运行机制更有帮助。等跑熟了再迁移到 Docker 或 Kubernetes 完全来得及。下载地址就是 Prometheus 官网的 download 页挑 amd64 的 linux 二进制包就行。版本选择上我的建议是不要追新也不要用太老的Prometheus 目前 2.x 系列的稳定版本都可用选最近半年的 release 足够。Grafana 同样从官网下载选 OSS 版本即可企业版的一些功能用不到。cd /opt wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz tar xvf prometheus-2.53.0.linux-amd64.tar.gz mv prometheus-2.53.0.linux-amd64 prometheusGrafana 用 RPM 包安装更省事一条命令搞定自带 systemd 服务文件wget https://dl.grafana.com/oss/release/grafana-11.1.0-1.x86_64.rpm yum localinstall -y grafana-11.1.0-1.x86_64.rpm systemctl enable --now grafana-server如果你手头网络环境下载 GitHub 资源很慢可以去国内的一些镜像站找 tar 包速度快很多。这是我实际部署时节省时间很重要的一步。2.2 Prometheus 核心配置与 systemd 管理Prometheus 的主配置文件叫prometheus.yml默认自带一份示例配置定义了抓取自身的 job。这是我搭建时用的最小可用配置global: scrape_interval: 15s # 多久抓取一次指标 evaluation_interval: 15s # 多久计算一次告警规则 alerting: alertmanagers: - static_configs: - targets: - localhost:9093 rule_files: - /etc/prometheus/rules/*.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: linux-node static_configs: - targets: [192.168.1.101:9100]这里有个新手容易忽略的点scrape_interval直接决定了数据精度和存储量。15 秒是推荐的默认值如果你对某些关键业务指标需要更精细的数据可以单独在 job 里覆盖这个参数但代价是存储占用上涨。我曾经把一批 job 统一改成 5 秒抓取一个月后磁盘差点被时序数据塞满后来用rate()函数时才意识到15 秒的数据对于绝大多数监控场景完全够用没必要为了“更精细”盲目提高采集频率。配置完成后用 systemd 托管cat /etc/systemd/system/prometheus.service EOF [Unit] DescriptionPrometheus Afternetwork.target [Service] Userprometheus Groupprometheus ExecStart/opt/prometheus/prometheus \ --config.file/opt/prometheus/prometheus.yml \ --storage.tsdb.path/data/prometheus \ --storage.tsdb.retention.time30d Restarton-failure [Install] WantedBymulti-user.target EOF注意--storage.tsdb.retention.time这个参数它决定数据保留多久。我之前遇到过一个诡异现象数据明明还在但查询时间范围一拉长就提示没有数据后来才发现是保留时间设置太短旧的时序数据已经被自动清理掉了。按 30 天来设是比较常规的选择。2.3 Prometheus 默认端口与首次验证装好之后 Prometheus 的默认端口是 9090Grafana 是 3000。启动后访问http://服务器IP:9090你会看到 Prometheus 自带的基础查询界面。在这里可以执行 PromQL 查询也可以到 Status - Targets 页面里查看所有抓取目标的状态是 UP 还是 DOWN抓取有没有报错。这一步是整个监控体系是否正常工作的第一道检查。如果 Targets 里某些目标显示 DOWN不要慌先看它的“Error”字段给出的提示。常见的无非就是网络不通、端口没开、exporter 没起来、抓取路径不对这么几类。排查顺序从下往上先 curl 一下目标的 /metrics 接口看看通不通通了再回 Prometheus 里看配置有没有写错基本都能快速定位。3. 数据采集理解指标抓取链路与关键配置细节3.1 用 node_exporter 采集主机指标Prometheus 本身只负责抓取和存储具体采集什么指标取决于目标机器上跑着什么样的 exporter。对 Linux 主机来说最常用的就是 node_exporter它暴露的/metrics接口里有 CPU、内存、磁盘、网络、文件系统等几百个指标。下载和启动 node_exporter 很简单运行后默认监听在 9100 端口wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xvf node_exporter-1.8.2.linux-amd64.tar.gz cd node_exporter-1.8.2.linux-amd64 nohup ./node_exporter --web.listen-address:9100 启动后浏览器直接访问http://机器IP:9100/metrics你会看到类似下面这种格式的输出# HELP node_cpu_seconds_total Seconds the cpus spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total{cpu0,modeidle} 2.467321e06 node_cpu_seconds_total{cpu0,modesystem} 1.234567e04这种格式就是 Prometheus 规定的文本暴露格式所有的 exporter 都是遵循这个标准在输出数据。理解了这个你以后看任何 exporter 的指标都不会发怵无非就是 HELP 解释指标含义、TYPE 声明指标类型、然后一行行的具体数据。在 9100 端口能 curl 通之后再去 Prometheus 配置文件里把该机器的 IP 加进 scrape_configs重启 Prometheus一个主机的监控就纳管进来了。3.2 Counter、Gauge、Histogram指标类型的实际意义Prometheus 的指标类型里有几个基础概念必须在动手前弄明白Counter、Gauge、Histogram 和 Summary。我在带新人时发现90% 的 PromQL 写不出来都是因为没理解这几种类型的差异。Counter 是累计计数器只增不减比如请求总数http_requests_total、开机时长node_boot_time_seconds。这类指标直接用没有意义因为它会一直涨必须配合rate()或increase()来看变化速率。Gauge 是仪表盘式的数值可增可减比如当前内存使用量、在线连接数这类指标直接查询就能反映当前状态。Histogram 和 Summary 用于统计分布比如请求延迟的百分位数在监控里常见的histogram_quantile(0.99, ...)就是从 Histogram 计算 P99 延迟。实际排障时Counter 配合rate()是最常用的组合比如排查某个 API 是否出现大量 5xx就查sum(rate(http_requests_total{code~5..}[5m])) by (service)。这里[5m]的意思是取过去 5 分钟的增量速率窗口大小选得合适曲线才会平滑且及时反映波动。3.3 Prometheus 如何从 otel-collector 收数两种路径都要懂这里分享一个最近社区问得很多的问题Prometheus 如何从 OpenTelemetry Collector 收取数据。很多公司已经在用 OTel 做统一的可观测性数据采集这时候就得清楚 Collector 跟 Prometheus 之间是怎么衔接的。第一种路径是把 Prometheus 的数据通过prometheusremotewriteexporter 发给远端 Prometheus也就是在 OTel Collector 的配置里配置 exporter 为prometheusremotewritePrometheus 这边启用--web.enable-remote-write-receiver参数接收。这么做的好处是可以把 OTel 收集到的指标统一汇到 Prometheus 里存储和查询。第二种路径更常见也更好理解OTel Collector 可以直接配置一个prometheus receiver让 Collector 自己主动抓取多个 Prometheus 格式的目标然后 Collector 再作为 Prometheus 的抓取目标这样 Prometheus 只需要面对 Collector 这一个目标也能实现指标中转和合并。这也是 k8s 环境里最常见的部署形态Collector 以 DaemonSet 方式跑在每台节点上Prometheus 统一抓 Collector 暴露的/metrics接口。如果你是在已有的 Prometheus 体系里引入 OTel我更推荐先把 OTel Collector 当转发层逐步把应用接入 OTel SDK而不是推倒重来。4. Grafana 可视化从数据源接入到自制监控面板4.1 添加 Prometheus 数据源Grafana 装好之后默认监听在 3000 端口首次访问会让你设置管理员账号密码。登录后第一步就是添加数据源路径是 Configuration - Data Sources - Add data source找到 Prometheus 那一项填上 Prometheus 的地址比如http://localhost:9090点击 Save Test 会提示连接成功。这里有一个容易忽略的细节Grafana 和 Prometheus 如果不在同一台机器上填写的地址一定得是 Grafana 服务器能访问到的地址。我有一次在容器里跑 GrafanaPrometheus 在宿主机上结果填localhost:9090连不上因为容器里的 localhost 指向容器自己。改成宿主机的内网 IP 之后问题就解决了。这种网络命名空间的问题在容器化部署里特别容易踩先确认网络可通再排查配置。4.2 导入现成 Dashboard 与理解 ID 用法Grafana 能这么快复制一套专业看板全靠 Dashboard 市场。在左侧菜单找到 Dashboards - Import输入模板 ID 就能加载。监控 Linux 主机最常用的模板 ID 是 1860对应 node_exporter full 模板里面包含了几百张图覆盖 CPU 各核心使用率、内存各区域使用率、磁盘 IO、网络流量、文件系统空间等。除了 1860还有 8919Node Exporter for Prometheus Dashboard和 11074Linux hosts等挑一个你看着顺眼的即可。导入时需要注意有的模板会要求你选数据源选对对应的 Prometheus 数据源就行。导入完成后你大概率会发现有些图是空的这通常是模板里查询语句用了跟你的环境不匹配的标签导致的比如模板里用了jobnode_exporter而你的 job 名是joblinux-node。解决办法不是改模板而是学会在 Grafana 面板里自己改 PromQL。4.3 自制一个面板PromQL 在 Grafana 中的实战我从不用现成模板一导入就完事更推荐在它的基础上改这样你能真正理解每个图背后的查询逻辑。以“CPU 使用率趋势图”为例在 Dashboard 里新建 Panel选择 Prometheus 数据源查询语句写100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)这个表达式的思路是CPU 空闲率取 5 分钟平均再用 100 减去它就得 CPU 使用率。avg后面不加by就是把所有 CPU 核心聚合到一起。如果你按核数查看去掉avg改成sum by (cpu)就能看到每个核的曲线。Grafana 里还有一个非常值得学的功能变量Variables。你可以定义一个变量叫instance值来自查询label_values(node_cpu_seconds_total, instance)这样面板顶部会多一个下拉框可以切换查看不同机器的 CPU 曲线。这个用法一旦掌握你的看板就从死板的固定查询变成了交互式工具团队里的其他同学用起来会非常顺手。顺带一提热搜词里有个“grafana sql”其实说的是 Grafana 还能接 MySQL、PostgreSQL 这类 SQL 数据源查询时可以直接写 SQL。但注意 Prometheus 是时序数据库查询语言是 PromQL 不是 SQL两者的使用场景完全不同不要试图在 Prometheus 上跑 SQL。Grafana 支持 SQL 数据源的主要意义是把你业务数据库里的指标跟监控指标放到同一张看板上做全局视野。4.4 Grafana 图表动态刷新与告警触达图表的刷新频率在 Dashboard 右上角的 refresh 选项里控制默认是关闭的需要手动刷新才能看到最新数据。我建议在内部监控大屏上设为 30 秒或 1 分钟自动刷新太频繁没有意义且增加 Prometheus 查询压力。另外每个 Panel 还可以设置阈值线比如把 CPU 使用率 80% 设为黄色阈值、90% 设为红色阈值这样告警发生时扫一眼大屏就能直观看到是哪个指标越界了。5. 告警体系告警规则、Alertmanager 与通知渠道的联动5.1 Prometheus 告警规则语法详解光有图表不叫监控指标异常时能主动通知到人这套系统才算闭环。Prometheus 的告警功能分两步第一步由 Prometheus 根据你配置的告警规则计算是否触发第二步由 Alertmanager 负责把触发的告警去重、分组、抑制之后发送到各个通知渠道。告警规则文件放在 Prometheus 的rule_files指向的目录里格式是 YAML。下面是一组非常基础但完整可用的规则groups: - name: host_alerts rules: - alert: InstanceDown expr: up 0 for: 1m labels: severity: critical annotations: summary: Instance {{ $labels.instance }} down description: {{ $labels.instance }} 已停止被 Prometheus 抓取超过 1 分钟 - alert: HighCPUUsage expr: 100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance) 85 for: 5m labels: severity: warning annotations: summary: {{ $labels.instance }} CPU 使用率过高 description: 实例 {{ $labels.instance }} CPU 使用率超过 85%持续 5 分钟这里expr是触发条件for是持续时间。for参数很多人会忽略它的价值但它在生产环境中是避免告警风暴的第一道过滤器。想象一下某个服务做发布瞬间 CPU 拉高一下又回落如果没有for: 5m每次波动都会触发告警值班的人会被垃圾告警淹没。5 分钟持续确认之后再告警噪音少得多。我落地告警时给团队定了个默认规范warning 级别至少持续 5 分钟critical 级别至少持续 1 分钟需要调整的方案走评审。5.2 Alertmanager 配置分组、抑制与路由分发Alertmanager 的配置文件alertmanager.yml主要包含 route路由、receivers接收者、inhibit_rules抑制规则三大部分。下面是一个可以用起来的配置route: group_by: [alertname, instance] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: default routes: - matchers: - severity critical receiver: critical-webhook receivers: - name: default webhook_configs: - url: http://localhost:8888/prometheus/notice send_resolved: true - name: critical-webhook webhook_configs: - url: http://localhost:8888/prometheus/critical send_resolved: true这里有几个参数要做说明。group_by决定哪些告警会被合并成一条通知比如同一台机器同时出现多个磁盘相关告警就会合并到一条消息里避免轰炸式通知。group_wait是组内第一条告警等待多久再发给后续相关告警时间聚进来。repeat_interval是同样的告警隔多久再发一次默认 4 小时合理不会因为一个问题反复打扰。很多团队上来就是默认配置结果线上一个问题把值班群刷爆后来限制 repeat_interval 才好起来。国内团队最常用的通知渠道一般是企业微信 webhook 和钉钉 webhook也有通过 PrometheusAlert 这类中间件把告警转发到飞书、短信、邮件的。webhook 的优势是接入成本低Alertmanager 只要配置一个 URL 即可不需要额外开发。告警恢复通知也很重要。Alertmanager 里每个 receiver 都可以开启send_resolved: true告警恢复时会收到一条“恢复”消息。这能让你确认问题已经闭环不用一直悬着心。很多人配了告警才发现恢复通知没开结果每次都要手动去 Prometheus 里确认当前是否还在告警这体验差太多了。5.3 告警规则自测与常见误报优化配置完告警规则后强烈建议在 Prometheus 的 Alerts 页面检查每条规则当前的状态Inactive未触发、Pending已超过条件还在等for时间、Firing已触发并发送通知。Pending 到 Firing 的转换过程是理解告警系统很有价值的一幕你可以在页面里看到规则已经满足条件但还在等待持续时间的确认。误报是告警系统最大的敌人。我遇到过的误报五花八门最典型的是磁盘空间告警明明临时文件清理之后空间已恢复但因为for时间设置太短清理动作稍慢就触发了告警。后面对这种临时性指标加了更长的for时间和更宽的阈值误报率降了一大截。优化告警没有一次性到位的方法只能靠业务实际情况不断调整阈值关键是在早期宁可漏报也不误报——误报多了值班的人会开始无视告警到真正出事的时候就没人看了。6. 升级与排错实战几个高频问题的根因与处理方法6.1 修复 Grafana 升级后数据源报错热搜词里有一条非常具体的报错信息grafana failed to upgrade legacy queries datasource im7_otuvz was not found。这个错误我身边已经有好几个同事遇到过了几乎都发生在 Grafana 大版本升级之后尤其从 8.x 升到 9.x、10.x 时高发。根因是 Grafana 的数据源引用机制在新版本里变严格了。老版本的 Dashboard JSON 里查询面板直接引用数据源名称升级后 Grafana 要求通过数据源 UID 来引用而旧 JSON 里的 uid 字段是空的或变成了类似im7_otuvz这种临时标识升级程序又找不到对应的新数据源就会报这个错。处理办法分两步。第一步打开报错所在的 Dashboard进入设置找到 JSON Model检查每个 Panel 的 datasource 字段。正常情况下应该是这个结构datasource: { type: prometheus, uid: 你的prometheus数据源uid }如果看到的是uid: im7_otuvz或者直接是字符串类型的老格式就需要改成实际存在的 uid。如何找到实际 uid进到 Connections - Data sources点开你的 Prometheus 数据源看地址栏 URL 里的参数或者在数据源设置页面里的“UID”字段直接复制。把 JSON Model 里所有错误的 uid 替换成正确的保存后验证一下。如果 Dashboard 太复杂 JSON 改起来容易出错更省力的方式是在 Grafana 里新建一个 Dashboard手动加一次面板并选择正确的数据源再对比看新旧 JSON 的差异基本就能定位。另一个更简单的预防手段升级 Grafana 大版本前先导出所有 Dashboard 的 JSON 备份升级后如果报错用备份 JSON 里的 uid 批量替换即可。经历过一次你就知道了版本升级前做备份永远是对的。6.2 Prometheus 内存与磁盘占用过高Prometheus 内存长期居高不下是新手最容易忽略的问题因为它默认就不是省内存的主。内存占用的核心来源是时序数据的 WAL预写日志和 Head Block还在内存里的最近数据快照。如果机器内存只有 2G 还要跑 Prometheus 和 Grafana我建议先加内存或者把 Prometheus 的--storage.tsdb.min-block-duration和--storage.tsdb.max-block-duration调大减少内存里未落盘的块数量。磁盘占用则主要取决于抓取指标的总量、抓取频率和保留时间。处理方案有几个方向减少采集频率、缩短保留时间、优化指标标签基数。标签基数过高是时序数据膨胀的元凶比如请求路径这种高基数标签放进指标里会产生成千上万条序列磁盘上很快就会堆出几十 G 的数据。在业务接入监控时就要约束 label 的设计不要把所有希望都寄托在“反正 Prometheus 能存”。6.3 容器环境与二进制环境如何做选型前面的部署讲解我全程用二进制演示但 Kafka、MySQL 等基础设施如果已经容器化了在 Kubernetes 里跑 Prometheus 就是最优选择。最成熟的方案是直接装 kube-prometheus-stack它把 Prometheus、Alertmanager、Grafana、各类 exporter 打包成 Helm chart一条命令就能拉起一整套监控体系。但即便在容器化环境理解二进制部署过程的价值依然存在。Helm chart 只是把配置包装成了模板排障时你依然需要知道values.yaml里的prometheus.yml配置段对应你手写配置的哪个部分告警规则的语法更是完全一致。先学会底层原理再上封装才是稳妥的学习路径。6.4 一次完整的告警排查链路复盘最后用一个我实际排查过的案例收尾展示告警系统是怎么帮你定位问题的。某天凌晨 2 点Alertmanager 推送了一条 NodeUnreachable 告警说某台业务机器已无法抓取。最初大家以为是网络抖动观察 10 分钟没有恢复登录那台机器发现 SSH 正常但curl localhost:9100/metrics没反应。我的排查顺序是先看 node_exporter 进程还在不在发现进程意外退出了。再看 systemd 日志journalctl -u node_exporter发现缺少权限无法读取某个磁盘的健康信息导致 panic。这个过程Prometheus 的告警只是起到了“提醒我出事了”的作用真正的定位靠的还是登录现场排查。但也正是告警让这台机器的问题在第一时间被发现否则可能要等业务方反馈接口超时才知道机器出了状况。这类基础组件进程意外退出的问题根因往往在系统更新、权限变更或磁盘故障上。处理完恢复进程后我给那台机器的 node_exporter 服务加了开机自启并设置了简单的进程守护之后就没再复现过。监控体系的建设从来不是一次部署就结束而是一轮一轮的完善。我个人实操下来最大的体会是监控系统的价值不在于装了多少组件、画了多少图而在于真的出问题时能不能第一时间发现、能不能快速定位、能不能避免同样的问题再次发生。Prometheus 和 Grafana 提供的是一套高效的工具链把指标采集、存储、可视化和告警串成一条完整的链路剩下的要靠运维同学在真实业务场景里慢慢打磨。这套组合你越用越会发现它的设计精髓每个组件都只做一件事但做得足够深、足够好组合在一起就成了云原生时代监控的基座。
