做监控这件事绕不开的一个名字就是 Prometheus。不管你是刚入行的运维新人还是已经在云原生环境里摸爬滚打多年的 SRE最后都会在某个时刻打开那个自带查询界面的 9090 端口或者在一堆告警规则里和它打交道。我最早接触 Prometheus 是在一个微服务拆分进入深水区的项目里当时还在用传统监控方案指标一多加一次图表要等半天改告警配置更是改一次想骂一次。后来全面切到 Prometheus 体系才算把监控从能看做到了能用。这篇内容不打算写成抄文档式的科普。我会按自己落地时的思路把这个监控系统拆开讲清楚它解决了什么问题、为什么这样设计、怎么搭起来、查询怎么写、告警怎么配以及生产环境里最容易翻车的几个坑。无论你是第一次听说它还是用了一阵子想补补底层逻辑应该都能有点收获。1. 先说清楚Prometheus 到底是个什么东西1.1 名字的来历和它在监控体系中的位置Prometheus 这个名字来自希腊神话里的泰坦神普罗米修斯他从神界盗取了火种送给人类让人类有了文明和力量。监控系统取这个名字寓意也差不多——从各台机器、各个服务里把运行状态的火焰采集出来让开发者能看见系统内部到底在发生什么。这个项目最早由一家知名音频平台的工程师为内部监控需求而发起2016 年加入云原生领域的顶级开源基金会后和 Kubernetes 一起成长为云原生时代的事实标准。现在几乎所有主流服务网格、容器平台都把 Prometheus 指标作为默认的监控输出格式。它本质上是一套抓取-存储-查询-告警的完整链路。注意这里的关键词是抓取不是推送。监控对象通过暴露一个 HTTP 接口把自身状态用特定格式的文本暴露出来Prometheus 定时去拉。这种设计在后面很多讨论里都会反复出现理解了它你就能理解为什么这个体系会成长成现在的样子。1.2 它能解决什么问题边界在哪里先讲一个实际场景。假设你有几十个微服务每个服务又有多个实例部署在几十台机器上。传统监控方案通常要求每台机器装一个 agentagent 再往中心服务器推数据中心服务器负责汇总、画图、告警。这套模式在小规模时没问题但服务一多、实例一变比如弹性伸缩频繁加减副本问题就来了中心服务器不知道有哪些实例存在需要手动维护清单agent 数量和版本一多运维本身又成了负担。Prometheus 把这些问题拆成几块解决服务发现不需要手工维护机器清单可以通过配置文件、接口或者直接对接容器平台动态发现要抓哪些目标。统一的指标暴露格式语言无关只要提供一个文本接口什么服务都能接接入门槛被压到最低。标准化的数据模型所有指标都是一条带标签的时间序列查询和告警都在这个模型上操作非常干净。它能做的是三件大事采集指标、处理告警、提供查询。它的可视化能力很弱自带一个极简的图表页主要用于调试真正做仪表盘通常用生态里最出名的伙伴 Grafana。这一点建议新手一开始就记住很多人把 Prometheus 和 Grafana 混为一谈其实分工完全不同一个是监控后端一个是仪表盘前端。2. 核心设计思路Pull 模型和时间序列数据模型2.1 为什么选 Pull 而不是 Push监控数据的采集方式业界长期有两大门派一种是 agent 把数据主动推给中心叫 Push一种是中心主动上门拉取叫 Pull。Prometheus 选择了 Pull这个选择刚出来时争议很大因为当时主流监控系统大多是 Push。Pull 的好处很实在。第一中心主动拉取目标实例的可用性一目了然——拉不到就是挂了不需要额外的心跳机制来判断存活。第二抓什么、多频繁抓由监控端说了算变更采集策略时不需要去动所有被监控机器。第三被监控端只需要暴露接口不关心数据送到哪里天然适合容器环境里实例频繁漂移的场景。但 Pull 也有天生短板如果监控端和被监控端之间有网络隔离或者目标是生命周期很短的批处理任务比如一个跑几十秒就退出的一次性脚本Prometheus 根本来不及去拉。所以生态里有一个叫 Pushgateway 的中间组件专门解决这种场景。我见过很多团队一上来就无脑用 Pushgateway结果把数据模型搞得一团糟后面会单独讲到底什么时候该用它。2.2 一切皆标签时间序列模型理解 Prometheus 的核心是学会用时间序列的思维方式看监控数据。一条时间序列由三部分构成指标名、标签集、采样值。举个例子http_requests_total{code200, methodGET, instance10.0.0.1:9090}描述的是某个实例上、GET 方法、返回码 200 的 HTTP 请求总数。标签的每一个组合都构成一条独立的时间序列。你可以把指标名理解为数据库里的表名标签理解为这张表上的索引维度采样值就是某一时刻这条记录的数值。这个模型最大的好处是维度灵活。同样一份请求量数据你可以随时按状态码聚合、按实例聚合、按接口聚合不需要提前设计好多维表结构。查询时用 PromQL 一句话就能算出所有实例的 P99 延迟或者按错误码分组的 QPS。坏处是维度一旦失控数据量会指数级膨胀这就是业内常说的高基数问题后面避坑章节专门展开。2.3 四种指标类型用错会算错账Prometheus 的指标在客户端库里分为四种类型存储层面其实不区分类型都是浮点数加时间戳但语义和使用方式必须分清楚否则写查询时很容易得出错误结论。类型特点典型场景PromQL 里怎么用Counter只增不减请求总数、累计错误数必须配 rate() 看速率不能直接看当前值Gauge可增可减CPU 使用率、内存、队列长度直接查当前值就有意义Histogram按桶统计观测值分布请求延迟、响应体大小配 histogram_quantile() 算分位数Summary客户端算好分位数延迟分位数的快速查看直接查 _quantile 后缀序列Counter 的值本身通常没意义关键是变化速率所以要配合 rate() 函数。Gauge 是状态的快照当前值就是答案。Histogram 和 Summary 都是处理延迟这类分布型数据的区别在于一个把原始桶数据暴露给服务端算一个在客户端就算好。业务指标上我建议优先用 Counter 和 Gauge延迟类先用 Histogram等分位数精度要求明确了再评估要不要换 Summary。3. 架构与组件全景哪些角色在干活3.1 组件分工与数据流向一个完整的使用体系通常由几块拼起来Prometheus Server核心负责抓取、存储、查询、告警规则评估。各类 Exporter被监控端的指标暴露器把第三方系统的内部状态翻译成标准指标格式。Pushgateway短生命周期任务的指标中转站。Alertmanager接收告警做去重、分组、静默、路由最终送到通知渠道。可视化层通常是 Grafana负责把数据画成仪表盘。数据流很简单Exporter 暴露接口Prometheus 定时抓取写入自带的时序数据库查询时用 PromQL 去取告警条件命中后推给 Alertmanager 分发。很多人会问为什么不像传统方案一样接一个外部分布式存储因为 Prometheus 默认把数据存在本地磁盘单体架构通过复制和远程存储协议解决高可用和持久化的扩展。对小团队来说单机完全能跑这也是它的一大优势不像很多监控系统一开始就要设计集群它可以先用最简单的方式跑起来数据量上去了再考虑扩展。3.2 Exporter被监控对象的翻译官Exporter 是很有意思的一层设计。被监控的对象往往自己不知道 Prometheus 的存在比如数据库、消息队列、Web 服务器它们各有各的状态接口但格式五花八门。Exporter 做的事情就是在这两者之间做翻译主动去读这些系统的状态接口转成标准文本格式然后开一个 HTTP 端口等待被抓取。常见的 Exporter 有监控宿主机系统指标的 Node ExporterCPU、内存、磁盘、网络针对数据库的连接数、慢查询等指标的数据库 Exporter还有一堆针对中间件的现成 Exporter。对于自研的应用一般不需要单独部署 Exporter直接在代码里引入 Prometheus 客户端库自己暴露/metrics接口就行。主流的 Java、Go、Python、Node.js 语言都有对应的库用法也不复杂就是在关键业务路径加指标埋点。我习惯的做法是每个微服务至少暴露三个基础设施——请求速率、错误率、延迟分布。这样无论哪个服务出问题都能第一时间通过仪表盘定位到大方向再顺着日志和链路追踪往下钻。3.3 Pushgateway用之前先想清楚Pushgateway 是用来接收 Push 的中转站但它是个争议组件。它解决的问题是 Pull 模型够不着的场景批量任务、跑几分钟的定时脚本、防火墙隔离的临时端口任务。这些任务太短命Prometheus 压根来不及抓于是脚本把结果推到 PushgatewayPrometheus 再从 Pushgateway 拉。但很多团队把 Pushgateway 当成一劳永逸的接入方案任何数据都想往它那里推。这几个隐患必须知道第一数据推过去后长期留在序列里即使任务早就不跑了序列也不会自己消失指标垃圾越积越多第二因为 Push 是单向的Prometheus 判断不了被监控对象是否真的活着——只要 Pushgateway 还活着Prometheus 就以为数据有效第三多个实例往同一个 metric 推送时容易互相覆盖数据一乱告警也跟着误报。我个人的经验是默认不用它。只有当任务是真正的短生命周期批处理且没有别的办法时才接入并且必须配合清理机制任务跑完后主动调用删除接口把自己的序列清掉或者定时清理过期数据。4. 从零搭一套监控环境部署与配置实操4.1 最小闭环启动一个 PrometheusPrometheus 非常轻解压即用。二进制包又一次体现了这个项目对易用性的偏执。以 Linux 为例下载官方 release 的压缩包解压之后目录里就是一个可执行文件和默认配置。先写一个最简的配置文件prometheus.ymlglobal: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]这里只有两个配置段。scrape_interval决定每隔多久抓一次目标evaluation_interval决定每隔多久计算一次告警规则。scrape_configs定义要抓哪些目标这里先用 Prometheus 自带的/metrics接口做自监控。启动命令很简单./prometheus --config.fileprometheus.yml --storage.tsdb.retention.time30d然后浏览器打开localhost:9090看到自带表达式浏览器后在查询框输入prometheus_http_requests_total点执行就能看到这个服务自身的请求计数。到这里最小环境已经起来。这个过程细节不多但有一个点值得琢磨为什么设计成解压即用因为它不想在部署环节引入外部依赖对新手友好也方便生产里用进程管理器或容器快速跑起来。4.2 配置文件里真正要精读的参数配置是 Prometheus 最需要精读的部分。除了上面的两个 interval还有几个关键参数要在真正部署前弄明白scrape_timeout单次抓取的超时时间必须小于scrape_interval否则会导致抓取排队和重叠。scrape_interval设多少合适我的经验是 15 秒是大多数场景的黄金值。小于 5 秒会明显增加存储和网络开销对于秒级波动很快的指标比如需要精确到秒的 QPS可以设 5 秒但存储开销至少翻三倍。rule_files存放告警规则的文件列表。alertingAlertmanager 的地址配置。storage.tsdb.retention.time数据保留时间默认 15 天。生产环境要根据磁盘容量和业务需求综合决定如果接了远程存储本地可以留短一些。每个scrape_config里可以配置多组任务。组内除了静态目标还有更常用的服务发现机制。一个典型是文件发现scrape_configs: - job_name: myapp file_sd_configs: - files: - /etc/prometheus/targets/*.json refresh_interval: 30s只要运维往这个目录里放目标文件Prometheus 每 30 秒自动刷新目标列表完全不用重启服务。这在机器做弹性伸缩、实例 IP 不固定的场景里特别省事。很多第一次用的人不理解为什么配置文件里看不到全部机器列表就是被这个机制卡过——记住动态环境里目标是活的不是写在配置文件里写到老的。4.3 接入第一个真实监控目标假设要监控一台 Linux 主机做法是下载 node_exporter 解压运行./node_exporter --web.listen-address:9100这个进程会暴露宿主机的大量指标比如 CPU、内存、磁盘、网络。然后在配置文件里加scrape_configs: - job_name: node static_configs: - targets: [192.168.1.10:9100]重启 Prometheus 后在界面里选到node_cpu_seconds_total就能看到该主机的 CPU 曲线。到这里你已经完整走通了暴露指标-抓取-查询的主链路。这个例子的意义在于从零到看到第一张曲线图整个过程没有任何绕路。这也是它能在团队里快速推广的原因——学习成本的天花板不在部署而在后面写查询和设计指标。5. PromQL 查询实战把数据变成答案5.1 选择序列和过滤标签PromQL 是 Prometheus 的查询语言也是新手最容易觉得有门槛的地方。我总结的经验是它不复杂只是大部分人一开始被函数和聚合的排列组合吓到了。先掌握最核心的三件事——选择序列、过滤标签、聚合。选择序列靠指标名加标签匹配大括号。比如http_requests_total{code200} http_requests_total{code~5..} http_requests_total{instance~10\\.0\\.0\\..*}第一行是精确匹配第二行用正则匹配所有 5 开头的状态码第三行用正则匹配一个网段内的实例。标签匹配规则就这么几种等于、不等于、正则匹配、正则不匹配。聚合操作负责把多序列合成一条。最常用的是sum、avg、min、max配合by或without指定保留的标签维度sum(rate(http_requests_total[5m])) by (code)这条查询的含义是按状态码分组计算最近 5 分钟的每秒请求增量也就是每个状态码对应的 QPS。注意这里的rate()是 Counter 类型指标专用的函数它会自动处理实例重启时计数器清零带来的跳变问题这是 PromQL 里比较精巧的设计——单看绝对计数经常被重启误导而 rate 能自动规避。5.2 高频函数与常用计算套路把工作中最常用的一批函数掌握住PromQL 就算过关了。除了rate还有这些出现频率极高irate()基于最后两个采样点计算瞬时速率适合快变化指标曲线锯齿更多但响应快。increase()计算一段时间内的总量增量比如increase(http_requests_total[1h])就是过去一小时的请求总数。histogram_quantile()从 Histogram 桶数据反推分位数。topk()和bottomk()取前几名和后几名排障时特别好用。,这类阈值比较通常配合告警。一个几乎必用的套路是计算服务错误率sum(rate(http_requests_total{code~5..}[5m])) / sum(rate(http_requests_total[5m]))分子是 5xx 的速率分母是所有请求的速率一除就是错误率。这个值超过阈值就触发告警。另一个套路是延迟分位数histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))histogram_quantile是把桶的累计计数反向处理再根据目标分位点做线性插值估算所以算出来是近似值。桶的边界划分越细估算越准但存储开销也越大。5.3 写查询的三个好习惯实际写查询时有几个习惯能帮你少走弯路一是永远先确认指标类型。Counter 直接看当前值会让人误判Gauge 用 rate 会得到无意义的波动。在查询框输入指标名后会自动显示类型和帮助描述先看一眼再写表达式。二是区间向量和时间范围别搞混。rate(xxx[5m])中括号里的时间范围决定了速率计算的窗口窗口太短抖动大窗口太长反应慢。日常排障用 5 分钟窗口看长期趋势用 1 小时窗口。三是正则匹配的转义很容易错。PromQL 的正则基于 RE2点号要写成\\.在 YAML 配置里写还要再转义一层新手经常在这里被折磨。一个建议能用精确匹配就少用正则正则用得越多查询越难维护。四是先在小范围验证再放开。调新的查询时先用一个已知实例比如instance具体IP:端口确认数据形态正确再逐步放宽标签条件。直接从全量数据开始调一旦出错很难判断是表达式问题还是数据本身问题。6. 告警与可视化的完整闭环6.1 告警规则与 Alertmanager 怎么配合采集了指标、能查了监控系统还差最后一步闭环出问题时得有人知道。Prometheus 的告警分成两段Prometheus Server 负责规则评估算出哪些表达式命中Alertmanager 负责把命中的告警送到对应的人手里。告警规则写在专门的规则文件里典型结构groups: - name: example rules: - alert: InstanceDown expr: up 0 for: 5m labels: severity: critical annotations: summary: 实例 {{ $labels.instance }} 不可用一个规则里最关键的是expr触发条件表达式、for持续时间条件、labels附加标签、annotations告警内容模板。for的作用是防止瞬时抖动误报——指标只在某一瞬间满足条件还没持续够时长就不算数。Alertmanager 的配置包含三块主要逻辑route路由规则决定告警来了走哪个分支发出去通常根据严重级别或团队标签分组receivers接收人定义通知渠道比如邮件、企业微信、钉钉、Webhookinhibit_rules抑制规则比如主机宕机时就不用再发一堆该主机上所有服务的关联告警。把告警理解为分诊台就对了Prometheus 负责喊有人出问题了Alertmanager 负责判断该喊谁、怎么喊、要不要合并喊。6.2 通知分组参数怎么调接一个 Webhook 通知为例Alertmanager 配置route: group_by: [alertname] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: webhook receivers: - name: webhook webhook_configs: - url: http://notification-service:8080/alert send_resolved: truegroup_by指定哪些标签相同的告警归为一组group_wait决定同组告警积压多久再一起发group_interval是组内新增告警的发送间隔repeat_interval是告警没恢复时多久重复发一次。这些参数直接决定告警的轰炸程度。经验值上group_wait30 秒左右、repeat_interval4 小时起步是大部分团队选用的节奏。重复间隔太短会把值班人的手机打成筛子太长则让持续问题错过提醒。send_resolved: true也很关键恢复通知能极大减少值班时的猜测成本。6.3 用 Grafana 搭仪表盘的提效技巧Grafana 和 Prometheus 是黄金搭档。Grafana 本身没有监控能力它从 Prometheus 查询数据专门负责画仪表盘。为什么推荐它而不是直接用 Prometheus 自带的界面因为成熟团队的仪表盘不是一张图而是一整套视图分层全局总览、服务列表、单服务的详细面板、单机的硬件状态每一层都要有对应的查询脚本和布局Grafana 的模板化和变量体系让这套东西可维护。实操中最常用的是 Grafana 的变量功能。比如做了一个服务 QPS面板可以加一个label_values(http_requests_total, job)变量下拉框里就能动态切换服务一张面板通吃所有服务的 QPS 查看。这个能力能极大减少重复建面板的工作量是我在团队推广时强调的第一个提效技巧。从告警到可视化监控才形成完整闭环指标暴露到系统、采集进 Prometheus、规则匹配触发告警、Alertmanager 分诊通知、值班人员在仪表盘里顺着视图定位根因。7. 生产环境避坑指南7.1 高基数最隐蔽的杀手生产环境里最坑的问题是下面要讲的高基数high cardinality。先明确概念高基数不是一个指标参数问题而是标签产生的序列组合数爆炸。举个例子有个业务指标http_request_duration_seconds如果加一个user_id标签每个用户都成为一条独立序列。假设用户量一万这个指标就是一 万条序列每个采集周期都会写入一万个新样本存储和查询压力立刻飙升。更恐怖的是如果配合每次请求的随机值这样的标签序列数量会看不到尽头。高基数的杀伤力是潜移默化的早期看不出问题等时间序列攒到几千万条时系统会变得很慢查询超时内存飙升甚至直接影响抓取和告警评估。规避手段有这几条标签值必须是低基数集合。状态码几十个、实例名几十个、接口名的聚合分组几百个上限都没问题。用户 ID、订单 ID、设备 ID 这些必须毫不犹豫地砍掉。如果确实需要按具体业务维度细分优先考虑用日志系统或链路追踪体系承担而不是把监控系统变成一把到处乱用的锤子。定期观察prometheus_tsdb_head_series这个内置指标它反映当前活跃的时间序列数。持续上涨就意味着高危得尽快找到是哪条指标在膨胀。7.2 存储与持久化的规划Prometheus 默认把数据存在本地磁盘单机模式下数据量大了之后备份和容灾都是要提前规划的事。建议从第一天就想清楚三个问题。第一个问题是磁盘容量估算。经验判断基准每个样本大约 1 到 2 字节按抓取间隔 15 秒算如果单实例有一百万条序列一天的数据量大约是 6 到 12 GB。按这个量级去配磁盘能覆盖绝大多数中等规模业务。第二个问题是保留时长。默认 15 天对于排查一个月前的问题这种需求远远不够。我习惯把本地保留时长按业务回溯需求设置成 30 天或者更长同时配合远程存储做冷数据归档。如果用了云平台托管方案则把本地留短一些省磁盘。第三个问题是重启和数据损坏。非正常关机或磁盘满时本地存储可能出现损坏。这时不能只靠一个节点硬扛要用多个副本或联邦架构分散风险。至少做到定期给数据目录做快照备份并且不要在磁盘快满时运行否则指标时间轴会直接断掉监控出现空窗期反而错过故障。7.3 常见问题与排查思路速查我在维护生产监控环境时沉淀了一张问题排查表分享给你们参考现象排查路径抓取目标显示 DOWN先查网络连通性再用curl http://IP:端口/metrics手动访问确认接口是否正常返回查询返回空结果先用最简单指标名确认序列存在再一步步加标签条件排除条件组合问题告警不触发检查规则文件是否被加载检查 Alertmanager 地址和路由配置确认for持续时间是否太长内存占用持续走高观察活跃序列数是否上涨判断是否打上了高基数标签抓取超时检查超时值是否小于间隔值再看目标接口本身的响应时间这套速查表解决的 90% 的现场问题剩下的基本都能从日志里找到线索。Prometheus 日志默认输出到标准输出排查时先看日志永远是对的。7.4 几条不写进文档的实践经验最后分享几条我的经验这几条不写在官方文档里但每一条都来自真实翻车现场。第一告警规则要小而准不要一上来就搞一个大而全的表达式。把每个告警拆成最小可验证单元比如up 0单独一条错误率阈值单独一条。这样触发时定位更快也不会因为依赖关系相互掩盖。太复杂的告警表达式出问题的时候没人能一眼看懂它为什么报反而增加值班压力。第二在搭建监控时就要把指标命名约定立好。命名统一成应用名_模块名_指标名的层级标签语义保持一致能用小写字符就绝不用大写。命名混乱的监控体系半年之后会变成一座没人敢动的粪山这是无数团队的真实写照。第三测试环境里一定要做告警演练。把节点直接杀掉、把服务停掉看告警链路从采集到通知是否顺畅看分组、抑制是否正确。很多配置只有在真实故障场景里才会暴露问题等线上出事再发现告警漏掉那才是最被动的局面。我个人的体会是Prometheus 这个项目最难得的地方不是单个功能有多惊艳而是把抓取-存储-查询-告警四件事的边界划得非常清楚。每个组件只干一件事每件事都可以独立扩展和替换。这种设计让它入门曲线可以做到极低同时上限又高到足以支撑整个云原生体系的监控底座。哪怕你只是打算自学监控的新人从它开始学起往后接触其他监控系统很多思路都是相通的。最后再留一个小建议别急着把文档里所有功能都部署一遍先用最小闭环跑通你的第一个业务指标再慢慢往体系里加东西复杂度会随着你的理解自然消化掉。