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 标签，几十万唯一值会让 TSDB 内存暴涨、查询变慢甚至 OOM。Prometheus 的强大，始终建立在“合理打标”这个前提上。
它不解决日志检索，也不做分布式追踪，更不保证金融级精度。把它的能力边界划清楚，比堆功能更重要。
