服务器多了以后，靠人工登录机器看CPU、内存和磁盘状态会越来越吃力，而且出问题时往往已经过去一段时间，很难回溯当时发生了什么。Prometheus就是为解决这类可观测性问题设计的开源监控与告警系统，它通过定时拉取目标服务的指标接口，把数据存入自己的时序数据库，并提供PromQL查询语言做分析和告警判断。对新手来说，先理解它由哪些组件组成、数据怎么流转，再动手配一套最基础的node_exporter监控，基本就能入门。
不过要注意，Prometheus默认采用拉取模式，也就是Server主动去各个target抓取指标接口，这和一些推送式监控系统不一样。这个机制的好处是监控端统一控制采集频率，目标端不用关心上报逻辑；坏处是目标必须暴露HTTP接口，短生命周期任务需要配合Pushgateway才能把数据送到Prometheus。
Prometheus核心组件与拉取模型
Prometheus不是单个进程包办所有事情，它由几个关键模块组成。核心的Prometheus Server负责服务发现、拉取指标、存储时序数据和执行告警规则。Exporter则是运行在目标机器或中间件旁边的采集代理，把MySQL、Redis、Nginx等应用的状态转换成Prometheus能识别的指标格式。最常用的node_exporter专门采集Linux主机的CPU、内存、磁盘、网络等基础指标。Alertmanager在告警触发后接管通知，支持邮件、企业微信、钉钉、Webhook等渠道，还能做去重、分组和静默。
拉取模型的工作流程可以这样理解：Server按照配置文件里的scrape_interval周期，向各个target请求/metrics接口，拿到文本格式的指标数据后解析并写入本地时序库。例如node_exporter默认监听9100端口，Server访问http://localhost:9100/metrics就能获取几百项系统指标。这种设计让目标服务保持简单，但也要求网络连通性从Server侧可达目标，如果中间有防火墙就需要放行对应端口。
除了拉取，Prometheus还支持通过Pushgateway接收短生命周期任务的指标。比如一个定时批处理任务跑完就退出，Server来不及拉取，任务可以在退出前把结果推送到Pushgateway，再由Server从Pushgateway统一拉取。不过Pushgateway只适合临时数据，不适合长期在线服务，因为推送的数据不会自动过期，一旦任务异常停止，旧值可能一直留着造成误判。
新手搭建：从安装到第一张监控图
初次使用可以先在单台Linux机器上跑通。下载Prometheus二进制包并解压后，不需要额外编译，直接运行prometheus可执行文件即可。默认配置文件名是prometheus.yml，里面已经包含Server自身监控的配置。启动命令大致是运行prometheus并指定--config.file参数指向配置文件，接着用浏览器打开http://localhost:9090就能看到Web界面。
要看到真实主机指标，还需要安装node_exporter。同样下载二进制包，解压后运行node_exporter，它会在9100端口暴露指标接口。然后回到prometheus.yml，在scrape_configs下面增加一个job，job_name可以填node，static_configs里的targets写成localhost:9100，scrape_interval设为15秒。保存后重启Prometheus，或者在Web界面执行热加载，新的target就会被自动发现并开始采集。
验证是否采集成功很简单。在Prometheus的Graph页面输入up，如果看到up{instance="localhost:9090"}和up{instance="localhost:9100"}的值都是1，说明两个目标都健康。再输入node_cpu_seconds_total，能看到多核CPU按模式拆分的累计秒数。虽然这些原始数值不太直观，但配合PromQL函数就能变成可读的百分比曲线。
指标类型与PromQL查询入门
Prometheus指标分为Counter、Gauge、Histogram和Summary四种类型。Counter只增不减，适合统计请求总数、错误次数、CPU累计时间等。Gauge可以任意上下波动，例如当前内存使用量、在线连接数。Histogram和Summary用于描述分布，比如请求延迟落在不同区间的次数，适合计算分位数。理解类型能帮助判断该用哪些函数处理数据，避免把累计值直接当成瞬时值使用。
PromQL是Prometheus的查询语言，新手掌握几个常用函数就能处理大部分场景。rate函数用来计算Counter的增长速率，例如rate(node_cpu_seconds_total{mode="idle"}[5m])表示过去5分钟内CPU空闲时间每秒的平均增长速率。再用1减去这个值，就能得到CPU使用率。内存类指标常用node_memory_MemAvailable_bytes除以node_memory_MemTotal_bytes得到可用内存占比。磁盘容量则比较node_filesystem_size_bytes和node_filesystem_avail_bytes。
查询时还可以用标签过滤和聚合。比如sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)可以按主机汇总非空闲CPU时间，算出一台机器整体使用率。PromQL支持算术运算、比较运算和逻辑运算，告警规则本质上也是PromQL表达式加上阈值判断。刚开始不要贪多，先跑通CPU、内存、磁盘、网络这四类基础指标，后续再按业务需要扩展。
告警规则与Alertmanager联动
监控只看图还不够，出问题需要及时通知。Prometheus的告警规则通常写在独立的rules文件里，然后在prometheus.yml中通过rule_files引用。每条规则包含expr表达式和for持续时间，例如当node_memory_MemAvailable_bytes除以node_memory_MemTotal_bytes小于0.1并持续5分钟时触发告警。for的作用是防止瞬时抖动造成误报，让指标确实异常一段时间后才通知。
告警触发后，Prometheus只会把状态标为firing，真正发通知的是Alertmanager。需要在Prometheus配置里指定Alertmanager地址，默认Alertmanager监听9093端口。Alertmanager路由可以根据标签把不同告警分发给不同渠道，还可以设置group_wait和group_interval控制通知频率，避免同一类问题反复轰炸。例如所有来自数据库实例的告警统一发给DBA组，来自Web节点的告警发给应用运维组。
Alertmanager还支持静默和抑制规则。静默是手动临时关闭某段时间的通知，常用于计划内维护。抑制规则用于避免级联告警，比如整台机器宕机时，CPU、磁盘、网络等多个告警可能同时触发，但只需要通知机器不可达这一条根因告警。合理配置抑制能显著降低告警噪音，让值班人员更容易抓住重点。
常见问题与注意事项
Prometheus默认在本地存储数据，保留时间由--storage.tsdb.retention.time参数控制，一般为15天。如果数据量增长快，需要提前评估磁盘空间，因为时序数据写入持续发生，磁盘满了会导致Prometheus无法正常工作。生产环境建议单独挂载数据盘，并配合监控自身存储使用率。高基数标签是一个容易被忽视的坑，如果把用户ID、请求路径等变化频繁的值作为标签，会导致时间序列数量爆炸，内存和查询性能都会急剧下降。
配置修改后不一定需要重启，Prometheus支持通过向进程发送SIGHUP信号或访问/-/reload接口实现热加载，但只对配置文件和规则文件有效，部分参数仍需重启。网络方面要留意Server到Exporter之间的防火墙端口，尤其是跨机房或云主机安全组。目标过多时还需要调整scrape_interval和scrape_timeout，避免采集超时堆积。
下面列出几个新手容易遇到的问题和处理方向，供快速排查参考。
| 问题现象 | 可能原因 | 处理建议 |
|---|---|---|
| Prometheus启动后可以访问，但targets页面显示DOWN | 目标端口未监听、防火墙拦截、配置的IP或端口错误 | 先在Prometheus所在机器用curl测试目标/metrics接口，再检查安全组和配置文件 |
| 查询某些指标为空 | 指标名拼写错误、标签过滤不匹配、Exporter未安装或未采集 | 用up确认目标健康，再在Graph页面搜索指标名，检查标签名和值是否一致 |
| 告警一直处于Pending状态 | for持续时间尚未满足或表达式一直为真但周期内未达到触发标准 | 检查规则文件的for设置，确认表达式在Prometheus里能返回结果 |
| Alertmanager没收到告警 | Prometheus未配置Alertmanager地址、路由规则不匹配、通知渠道参数错误 | 查看Alertmanager的alerts页面和日志，确认告警是否被接收以及路由去向 |
| 内存占用持续升高 | 高基数标签导致时间序列过多、查询负载过大、抓取目标过多 | 审查标签设计，减少变化频繁的标签，必要时使用recording rules预聚合 |
Prometheus虽然功能强大，但也不是所有场景都适合。长期历史数据存储通常需要接入Thanos或VictoriaMetrics等方案，联邦模式可以解决多集群聚合问题。刚开始使用不必追求一步到位，先把基础监控和告警跑顺，再根据实际规模逐步扩展。
整体来看，Prometheus的上手难度比很多人想象中要低。只要理解拉取模型、掌握几个核心PromQL表达式、配置好node_exporter和Alertmanager，就能搭建一套稳定的开源监控告警系统。遇到问题时优先从targets状态、指标是否存在、规则表达式是否返回结果这三个方向排查，大多数新手阶段的困惑都能很快定位。
Prometheus监控开源监控告警系统监控配置修改时间：2026-10-04 01:41:36