Agent 模式做什么
Agent 模式让 Prometheus 以纯采集器形态运行：加上 --enable-feature=agent 启动后不再提供本地查询界面、不评估告警与记录规则，只做抓取并 remote_write 到中心。它适合边缘集群、物联汇聚点这类只需上传数据、不需要本地查询的场景，也便于大规模分层汇聚时降低边缘资源占用。
启动方式
启动方式
prometheus --enable-feature=agent \
--config.file=prometheus.yml
# prometheus.yml 保留抓取与远程写
scrape_configs:
- job_name: node
static_configs:
- targets: ['localhost:9100']
remote_write:
- url: https://central.example.com/api/v1/write
queue_config:
max_samples_per_send: 500基本信息
| 本地能力 | 仅保留 WAL 用于远程写重试与断点续传，无查询与告警 |
|---|---|
| 典型场景 | 边缘集群、多机房分层汇聚到中心 Prometheus |
| 切换注意 | 依赖本地查询接口与本机告警的脚本、看板要迁到中心端 |
| 回退方式 | 去掉特性开关即回到常规模式，使用同一二进制文件 |
与常规模式差异
| 能力 | 常规模式 | Agent 模式 |
|---|---|---|
| 本地查询 API | 提供 | 不提供 |
| 规则评估 | 支持 | 不支持 |
| 远程写 | 可选 | 必需，否则数据无处可去 |
| 数据持久化 | 本地 TSDB 长期存储 | 仅 WAL 缓存用于重试 |
| 典型部署位置 | 中心或单体集群 | 边缘节点 |
使用注意
- 边缘数据量小、只需汇入中心统一存储与查询时收益最明显
- Grafana 数据源要指向中心端，直连 agent 会查询失败
- 网络不稳定环境要评估 WAL 容量与最长断网时长是否匹配
- 规则与告警统一在中心评估，边缘侧的角色定位要写进部署文档
断网时间超过 WAL 能容纳的量后，最早的数据会丢失；边缘网络稳定性要与 WAL 大小匹配，必要时缩短采集间隔以减少积压量。
上线检查项
- 确认远程写端点的鉴权方式（Basic、Bearer 或 mTLS）已在边缘配置
- 核对边缘与中心的时钟同步，时间漂移会造成远端拒收
- 压测一次断网恢复场景，观察重试队列与中心端写入压力
- 把 agent 的抓取配置纳入版本管理，边缘节点推倒重建时可快速还原