如果有人第一次看我搭Prometheus多半会问监控数据不都是采集器主动上报的吗为什么Prometheus要反着来自己跑到目标机器上去拉这几乎是每个监控初学者都会冒出来的疑问。其实拉取模式是Prometheus的立身之本也是它和Zabbix、Telegraf那类主动上报方案最核心的区别。可真正上生产之后你会发现拉取在小规模环境里很舒服一旦实例数量膨胀、集群地域分散、存储容量见底单纯靠拉就玩不转了。这篇文章我就把标准拉取、Pushgateway、服务发现、远程写入和Agent模式这条演进主线完整串一遍适合正在设计监控架构、准备把Prometheus从单机玩成集群的同学参考。1. 标准拉取模型Prometheus的“上门抄表”逻辑1.1 Pull模型到底在拉什么先别急着写配置。你得理解Pull模型的运作方式Prometheus server按照自己设定的周期定时对目标target发起HTTP请求默认访问/metrics端点拿到一份纯文本格式的指标数据然后解析入库。这个动作在监控里叫scrape对应的配置项就是scrape_configs。可以把它想象成自来水管网的查表员表不是由用户报的而是片区管理员定期上门抄表。好处是节奏统一谁抄、什么时候抄、抄哪个区域全部由监控中心控制。目标机器上如果本来没有暴露度量信息的程序你通常需要再装一个Exporter。比如Node Exporter把/proc、/sys等系统数据转换成指标MySQL Exporter把SHOW GLOBAL STATUS的查询结果转成指标。本质上Exporter就是一个“翻译器”把非Prometheus语言翻译成Prometheus听得懂的指标端点。核心关系不变Prometheus主动拉Exporter被动等。你身边运行的Prometheus可能已经到2.53.0甚至更新的版本但这套指标格式和拉取协议语义依然稳定。只要一个HTTP端点能以# HELP、# TYPE开头返回文本指标Prometheus就一定能采集。协议简单到这种程度才造就了今天庞大的Exporter生态。1.2 拉取频率与配置的耦合配置里最核心的三个字段是scrape_interval、scrape_timeout、metrics_path。scrape_interval决定多久拉一次生产环境常用15s或30s默认值相对保守。scrape_timeout必须小于scrape_interval否则上一次还没拉完、下一次又开始了目标会被标记为超时异常。你可能会觉得这个约束很基础但我见过不少新手把scrape_timeout设成和scrape_interval一样大然后目标状态一直在UP和TIMEOUT之间反复横跳。给一段最小配置global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: node static_configs: - targets: [192.168.1.10:9100, 192.168.1.11:9100] metrics_path: /metrics这段配置的意思是每15秒Prometheus对两个目标发起一次GET请求取回node_*等指标。两个目标都是静态写死适合机器数量少、地址不变的场景。targets列表越长Prometheus需要并行执行的拉取任务就越多这也是后续演进到服务发现和远程写入的重要背景。当一台机器要同时监控CPU、磁盘、网络、MySQL时target列表会迅速膨胀全写静态配置你很快就会想骂人。1.3 Pull模式相对于Push模式的三个明显优势我经常被问到“为什么不能让我写个脚本每分钟把数据POST给Prometheus”这里得说清楚拉和推的区别并不只是谁发数据而是谁决定采集目标和节奏。异常目标更容易被发现。Prometheus拉不到up变成0立刻就能知道目标挂了。如果靠目标自己上报“挂掉”这个状态本身也需要上报一旦宕机反而导致最后一条数据缺失。配置集中在监控端。想调整采集频率、加标签、做过滤改Prometheus配置即可不用挨个登录目标改agent。推模式改完agent还得重新部署维护成本高。暴露格式统一。无论Windows、Linux、K8s只要实现同一个Prometheus指标格式监控端就能识别。当然Pull模式不是没有缺点。最明显的是网络方向Prometheus必须能连到目标跨网络、跨云、防火墙严格的环境需要额外治理。另一个是短生命周期任务进程跑完直接退出Prometheus根本来不及拉。这两个缺陷正好逼迫架构向Pushgateway和远程写入演进。2. 先别急着“推”Pushgateway与服务发现2.1 Pushgateway只能算“暂存服务”不是真正的推送有一种比较常见的误解Prometheus不支持推送所以要用Pushgateway。这个说法方向对但理解不准确。Pushgateway本身仍然是被Prometheus拉取的。它的工作模式是任务运行结束时把指标POST到PushgatewayPushgateway把这些指标保存在内存中等Prometheus按固定间隔来拉取。你可以把Pushgateway看成“任务结果寄存处”任务先推Prometheus后拉整条链路还是以拉为主。什么场景适合批量数据加工、定时任务、CronJob、临时脚本。比如每天晚上跑一个批量任务凌晨2点完成Prometheus不可能一直等在旁边。脚本结束前把耗时、处理条数、错误码推给Pushgateway即使Prometheus在任务结束后第30秒才来拉取也能得到结果。我做工业设备采集时也碰到过类似场景注塑机数据采集联网项目里设备上位机只能按固定频率往外推数据监控平台又无法直接去连设备协议只能先把设备指标推到中间服务再通过远程写入接入统一监控。思路跟Pushgateway一致只是中间层变成协议转换网关。2.2 直接往Pushgateway推会有哪些坑我在生产环境见过最典型的问题是指标残留。任务失败或者重复执行同一个指标带不同的标签值被反复POSTPushgateway不会自动清理过期序列。结果Prometheus拉到的永远是历史任务数据告警会一直挂着直到你手动删除。另一个坑是标签冲突。如果任务名作为标签去聚合多实例多个实例同时推数据会互相覆盖如果不加常量标签Pushgateway又会在指标上额外加一个instance标签导致查询结果和预期不符。所以Pushgateway的正确用法限制很多尽量只放短时任务结果指标命名要避免冲突要么定期清理要么依赖外部机制做过期删除。实践里我还会在抓取配置里专门给Pushgateway的job加上honor_labels: true否则推数据时携带的标签会被Prometheus端配置覆盖掉。下面是一段往Pushgateway推送指标的脚本示例cat EOF | curl -XPOST --data-binary - http://pushgateway:9091/metrics/job/batch_cleanup batch_cleanup_last_run_seconds $(date %s) EOF然后Prometheus里照常配置一个job去抓Pushgatewayscrape_configs: - job_name: pushgateway honor_labels: true static_configs: - targets: [pushgateway:9091]2.3 服务发现让拉取自动找到“新目标”比Pushgateway更重要、也更常见的演进是服务发现。拉取如果只能手动写死IP遇到Kubernetes里Pod不断重建的场景就彻底完了。服务发现负责动态维护一个“目标清单”Prometheus定期询问Kubernetes API、Consul、DNS或者本地文件得到当前有哪些target存活再对它们执行拉取。最常见的Kubernetes发现片段大致这样scrape_configs: - job_name: k8s-pods kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true这个配置只做两件事发现所有Pod但只保留带prometheus.io/scrapetrue注释的Pod。中间那段relabel_configs非常重要——它既能过滤目标也能改写标签。可以说服务发现解决了“拉谁”的问题relabel则解决了“拉回来的数据长什么样”的问题。两者叠加才让拉取模型能在动态基础设施里存活下来。这也是后续remote_write架构里依然保留的能力无论存储层怎么变采集端这一套服务发现加relabel都不会被替代。3. 远程写入把Prometheus从“存储”变成“网关”3.1 单机拉取模型的瓶颈到底在哪先问一个问题Prometheus本地TSDB到底能撑多少数据量这取决于磁盘、内存和指标基数通常单机几百万时间序列已经会让查询变得很吃力。当监控对象发展到几十套集群、成千上万个实例时会有几个现实麻烦本地磁盘空间有限数据保留周期只能设7天或15天历史数据没法长期留多个Prometheus实例之间数据不互通统一查询需要跑到每个实例上拼结果抓取、查询、告警全在一个进程里谁都能把谁拖死联邦模式虽然能把上层指标汇总到根节点但它只适合“挑重点”不适合把所有原始序列都汇总。于是架构开始分化采集端要更轻存储端要更大查询端要统一。远程写入Remote Write就是为了让采集和存储解耦而生的。3.2 Remote Write到底在传什么Remote Write的原理并不神秘。Prometheus每次抓取到的样本会先写入本地WALWrite-Ahead Log然后Remote Write组件从WAL里读出来批量打包用Snappy压缩通过HTTP POST发送到远端存储。注意写入动作不是同步阻塞抓取流程的Prometheus本地TSDB照常写远端存储只是多了一份异步副本。这个设计在远端故障时特别有用——WAL会继续攒数据等远端恢复后重新发送避免数据丢失。一个基本配置长这样remote_write: - url: http://victoriametrics:8428/api/v1/write queue_config: capacity: 10000 min_shards: 1 max_shards: 32 max_samples_per_send: 2000 batch_send_deadline: 10s这些queue参数看着冷冰冰实际上一旦数据量增长它们就是生死线。简单说capacity每个分片队列能缓存多少样本队列满了之后会丢弃额外样本并增加错误计数max_shards并发发送分片数远端存储吞吐不足时调大它是常见手段max_samples_per_send每个HTTP请求携带的样本数量调太高可能让远端响应超时调太低则请求次数过多batch_send_deadline哪怕没攒到max_samples_per_send最多等多久就发一个包。生产环境里我通常从max_shards16起步观察远端CPU和Prometheus自身的remote_storage_*指标再动态调整。这个调参过程不是一蹴而就的监控架构里的“性能调优”本质上是数据流和系统资源之间的博弈。3.3 远程读一个“能用但别依赖”的接口与远程写入配套的还有一个Remote Read。它允许PromQL在有需要时直接查远端存储但实际体验一般。因为PromQL查询引擎默认还是以本地数据为主跨远端读数据往往要扫描大量标签性能波动大。更推荐的方案是把Grafana数据源直接指向远端存储例如VictoriaMetrics或Mimir本身的查询接口让远端存储承担查询职责。这样就更接近“Prometheus只是采集器统一查询入口在远端”的架构。3.4 谁是Remote Write的兼容存储Remote Write最开始只是对接官方推荐的远程存储但现在已经成了时序生态的事实标准。常用的兼容方案可以简单对比一下方案多租户存储后端适合规模运维成本VictoriaMetrics集群版支持本地磁盘/对象存储中到大规模低Thanos Receive支持对象存储大规模中高Mimir / Cortex支持对象存储企业级高它们都实现了同一个协议Prometheus remote write API。所以选型时不用太担心“Prometheus能不能写到这个后端”基本都能。真正要比的是查询能力、压缩率、高可用和运维成本。我见过不少团队一开始用VictoriaMetrics单机数据量涨上去后再平滑迁移到集群版采集端配置完全不用改这大概就是标准协议最大的红利。4. 轻量化采集端Agent模式与生态收敛4.1 当Prometheus自己成了“重组件”远程写入普及后很多团队发现问题如果所有数据都远程写了本地还要不要保留完整TSDB还要不要在本机做告警和查询在边缘节点、K8s DaemonSet等场景真正需要的其实只是“抓取发送”不需要本地查询不需要规则计算更不需要一整套UI。继续跑完整Prometheus等于为用不到的功能白白消耗内存和磁盘。官方给出的答案是Agent模式。你可以把它理解成一个“阉割版”Prometheus保留采集、服务发现、relabel、remote write去掉本地TSDB查询、告警规则、记录规则和本地压缩。以2.33之后的版本为例启动命令加一个flagprometheus --config.fileprometheus-agent.yml --enable-featureagent --web.listen-address:9090启动后/api/v1/query这类查询接口会直接回404但/metrics管理接口还在。这种模式特别适合大规模部署每个集群放一个DaemonSet Pod资源占用远低于完整Prometheus数据统一进远端Grafana连远端查询。4.2 Agent模式的取舍边界有人会问Agent模式这么好是不是所有场景都该换我个人不建议。如果只有一套Prometheus、数据量不大、也没有长期存储需求那全功能版本反而更省事。本地TSDB是一个低成本缓存Prometheus自己可以查询、告警、对接Alertmanager少了一层外部依赖。Agent模式的价值在于“规模化和集中化”不在于“替换掉所有单机”。举一个我实际见过的反面例子某团队把所有Prometheus都切到Agent模式然后Grafana直接查Mimir。结果网络抖动时Grafana查询会因为远端不可用而全部失败而同一时刻本地其实有一份最近几小时的数据却因为Agent模式没有查询能力而派不上用场。所以如果你坚持Agent模式就一定得给远端存储做好高可用。远端挂了监控就是全黑。4.3 Remote Write生态的进一步收敛除了Prometheus官方Agent这个生态里还有Grafana Agent/Alloy、OpenTelemetry Collector等组件它们都能抓取Prometheus格式指标然后以remote_write或OTLP协议发送。这里不展开讲但可以看到一个趋势采集端越来越薄存储端越来越厚中间用统一协议沟通。这也是“从标准拉取到远程写入”这条演进路线的自然结果。未来你再接触新组件时只要看到它支持remote_write就基本能确认它能接入这套监控体系。5. 实操实录三套K8s集群统一接入VictoriaMetrics5.1 拓扑设计看一张实践中的拓扑就更清楚了三套K8s集群每套集群内部部署一个Prometheus Agent负责抓取集群内Pod、Node、控制面组件指标三个Agent通过remote_write把数据发送到同一个VictoriaMetrics单节点Grafana连接VictoriaMetrics作为数据源所有集群的数据统一在一个地方查询。本地Prometheus不做告警只保留很小的本地WAL作为缓冲。这种设计的价值在于不用再登录每一套集群去执行PromQL所有集群的指标会自动带上一套集群标签比如clusterk8s-prod-1查询时按cluster维度聚合就能横向对比。后续如果换成本地存储之外的Mimir或Thanos只需要改remote_write地址采集端零改动。5.2 Agent配置示例主配置大致这样我加了生产环境常用的relabel规则可以直接参考global: scrape_interval: 30s external_labels: cluster: k8s-prod-1 scrape_configs: - job_name: node kubernetes_sd_configs: - role: node relabel_configs: - action: labelmap regex: __meta_kubernetes_node_label_(.) - job_name: kubelet kubernetes_sd_configs: - role: endpoints scheme: https tls_config: insecure_skip_verify: true relabel_configs: - source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] action: keep regex: kubelet;https-metrics remote_write: - url: http://victoriametrics:8428/api/v1/write queue_config: max_shards: 16 max_samples_per_send: 3000 batch_send_deadline: 5s这里有一行值得单独拿出来说external_labels并不是普通标签它会在remote_write发送时附加到每条样本上并且在多集群场景里充当“集群标识”。没有这层标识几套集群的数据混在一起后你根本没法区分。所以规划external_labels比你想的重要得多。取的时候要全局唯一最好提前列一张集群清单避免后面改来改去。5.3 启动与验证启动Agent只需要./prometheus --config.fileprometheus-agent.yml --enable-featureagent等待几分钟后登录VictoriaMetrics执行一个查询curl -G http://victoriametrics:8428/api/v1/query --data-urlencode querycount(up)如果返回结果大于0说明remote_write链路已经通了。想看更细的状态可以进Agent的/metrics查这些指标curl -s http://127.0.0.1:9090/metrics | grep prometheus_remote_storage重点关注prometheus_remote_storage_shards、prometheus_remote_storage_pending_samples、prometheus_remote_storage_sent_samples_total。pending_samples一直上涨说明远端存储跟不上优先看max_shards和网络sent_samples_total在增加说明数据确实在持续发出去。6. 常见问题与排查技巧实录6.1 明明配置了target却一直拉不到数据先把up指标查出来up 0说明Prometheus无法连接到目标端点。按顺序检查网络、端口、认证、路径、HTTP响应格式。一个容易忽略的点是目标暴露的路径不是/metrics比如Kubelet默认走HTTPS但需要证书某些Exporter的路径还带query参数。建议先用curl手动请求一遍看响应是不是以# HELP或# TYPE开头。不是这个格式Prometheus解析就直接失败。别让配置层面的小失误掩盖真正的问题。6.2 remote_write队列越堆越多怎么办我见过最典型的场景远端VictoriaMetrics在做大查询时CPU打满remote_write请求超时Prometheus这边开始重试队列越积越长。这时不要急着把max_shards调大因为更大的并发只会让远端更慢。我的处理顺序是看远端CPU和磁盘IO确认瓶颈在谁身上适当降低batch_send_deadline让请求更快失败把max_shards降下来减少对远端的冲击扩容远端节点或加缓存再逐步恢复max_shards。记住一个原则队列上涨是症状不是病因。只调采集端参数而不处理远端性能等于一边漏水一边加水。6.3 Pushgateway造成假告警残留指标是Pushgateway最大的坑。排查时经常发现轮值任务已经不跑了但某个指标还保留着旧值看起来任务一直成功。我通常会在Pushgateway的抓取配置里加honor_labels: true并在每个任务推完数据后主动清理curl -X DELETE http://pushgateway:9091/metrics/job/batch_cleanup而且推送时每个指标都要带上job和自定义标签避免不同批次互相覆盖。还有一点Pushgateway本身也会有up指标别把它和业务指标混在一起看。6.4 指标基数失控导致存储爆炸数据量翻倍通常不是采集频率导致的而是标签组合爆炸。比如一个接口用user_id、order_id做标签每个请求都产生一个新的时间序列再大的存储也扛不住。遇到这种情况拉取模型里的relabel正好派上用场。我建议业务指标只保留必要维度比如status、method、endpoint用户ID等高基数标签一律不留。已经存在的坏指标可以在采集端用metric_relabel_configs的labeldrop直接删掉metric_relabel_configs: - action: labeldrop regex: user_id|order_id这句话要记住宁可多写几条relabel规则也别让一个高基数标签毁掉整个监控集群的稳定性。最后聊一点个人经验。我最早觉得Prometheus就该一根筋拉取远程写入是“大型团队”才需要的东西。直到自己同时负责边缘机房和几套K8s环境的统一监控才发现设计良好的监控架构必须承认一个现实完全靠拉取网络会逼你妥协完全靠推送你又会失去统一调度和故障探测的能力。现在的监控架构本质上是“能拉则拉该推才推远端再来兜底”。Remote Write不是推翻拉取模型而是把拉取的优势保留在采集端把存储和查询责任转移到更专业的地方。如果你也在做类似改造我的建议是先从一台远端存储和一个Agent慢慢试观察队列指标和查询体验再逐步扩大范围。监控架构很少有一步到位的答案但演进的方向大体就是这条路。