Prometheus是做什么的_云原生监控工具原理解析

Prometheus是专为云原生设计的时间序列监控系统，专注指标采集与告警；采用Pull模型实现可控采集、动态适配与故障可视，短生命周期任务需Pushgateway中转；remote_write可将数据持久化至SLS MetricStore，但需严格配置URL、认证及队列参数；PromQL使用须遵循标签聚合规则、函数类型约束与时间窗口语义，避免标签爆炸。

Prometheus 是一个专为云原生环境设计的时间序列数据库+监控告警系统，核心作用是拉取、存储、查询和告警——不是日志系统，也不是全链路追踪工具，它只管「指标」（metrics）。

为什么用 Pull 模型而不是 Push？

绝大多数监控系统（如 Zabbix）靠客户端主动上报，但 Prometheus 反其道而行：它自己定时去 http://target:port/metrics 抓数据。这样做的好处很实在：

• 服务端完全掌控采集节奏，避免瞬时大量 Push 导致接收端雪崩
• 天然适配 Kubernetes 等动态环境——只要服务发现能列出 endpoint，Prometheus 就能自动跟进，不用每个 Pod 都配推送地址
• 抓取失败直接体现在 up{job="xxx"} 这个内置指标里，宕机、网络不通、exporter 崩溃一目了然

坏处也明显：如果目标实例生命周期极短（比如几秒的批处理任务），根本来不及被拉到，就得靠 Pushgateway 中转——但注意，Pushgateway 不是通用替代方案，滥用会导致指标陈旧、重复、难以关联实例标签。

remote_write 到日志服务，本质是“换存储”而非“换用途”

本地 TSDB 默认只存 15 天，且单机扩展性有限。把数据通过 remote_write 发往阿里云 SLS 的 MetricStore，其实是把 Prometheus 当成一个“采集+规则引擎”，把持久化和查询卸给后端。关键点在于：

• url 必须严格匹配格式：https://{project}.{sls-endpoint}/prometheus/{project}/{metricstore}/api/v1/write，少一个路径段或写错大小写都会返回 404 Not Found
• basic_auth 的 username 是阿里云 AccessKey ID，password 是 AccessKey Secret——不能填成 RAM 子账号的密钥，也不能误用 STS 临时 Token
• queue_config 参数直接影响稳定性：capacity: 20480 是内存队列上限，max_samples_per_send: 2048 控制每次发多少样本；若网络抖动频繁，max_backoff 设太小会导致重试风暴，设太大又会积压延迟

这不是“备份”，而是生产级长期存储方案。一旦启用，alert.rules 和 recording rules 仍由 Prometheus Server 执行，只是原始样本落盘位置变了。

PromQL 查询快，但别把它当 SQL 用

很多人第一次写 sum by (instance) (rate(http_requests_total[5m])) 觉得很酷，但很快会撞上两个现实：

• 所有聚合操作（sum、avg、count）必须带 by 或 without 显式声明标签保留逻辑，否则报错 many-to-many matching not allowed
• rate() 只接受计数器（Counter），对仪表盘（Gauge）用 rate() 会得到 0 或 NaN；想看内存使用率变化趋势，得用 delta(memory_usage_bytes[1h]) 或直接查原始值
• 时间范围选择器（如 [5m]）不是“过去 5 分钟”，而是“当前时刻往前推 5 分钟的数据窗口”，所以 irate() 更适合突刺类指标，rate() 更稳但有延迟

真正卡住人的，往往不是语法，而是标签爆炸（label explosion）：比如给每个 HTTP 请求加 trace_id 标签，几十万唯一值会让 T

SDB 内存暴涨、查询变慢甚至 OOM。Prometheus 的强大，始终建立在“合理打标”这个前提上。

它不解决日志检索，也不做分布式追踪，更不保证金融级精度。把它的能力边界划清楚，比堆功能更重要。