PSI full>0 比 OOMKill 只早 3~10s，但 Prometheus 默认 15s 抓取——「采样粒度吃掉预警提前量」怎么破？有哪些不拉到 1s 全量的高频内存信号采集方案？

【背景】 做了 5 年运维。社区里"OOMKill 事前预警盯哪个信号"已经聊透了：#1905 把 working_set/request、working_set/limit 的比值和 page cache 误报讲清楚了，#1777 进一步论证 PSI memory.pressure full>0 是比 oom_kill 计数早 3~10s 的一等信号。我按这个结论去落地，结果在"选对了信号"之后撞上了一个大家似乎都没碰的卡点——信号本身的提前量只有秒级，而我的监控采样粒度是 15s，等于把提前量直接吃掉了，"预警"退化成了"事后通知"。

【现象（带数据）】

• 一次真实事故里实测：PSI memory.pressure full>0 的起点，到 oom_kill 计数 +1，间隔约 6s；
• 但我的链路是 Prometheus scrape interval=15s → 告警规则评估 → 通知，全链路 30s+；
• 结果：告警推到我手机的时候，进程早已经被内核杀了，kubectl describe pod 已经是 OOMKilled。所谓"提前 6s 预警"，在 15s 的采样面前约等于 0。

【已尝试与结果】

1. 把 scrape interval 从 15s 降到 5s：样本更密了，但 PSI 是瞬时压力值，full>0 窗口本身可能只有 3~6s，5s 采样仍可能整段错过；而且全集群 scrape 成本翻倍，100+ 节点我扛不住。
2. working_set 斜率做预测（predict_linear）：对"缓慢爬升型"内存泄漏很有效，能提前几分钟；但对"阶跃暴涨型"（一个大批量请求瞬间吃满堆外 / Direct buffer）几乎无效——斜率还没起来，进程已经没了。
3. 对 PSI 做 rate() 聚合：需要足够密的样本，又绕回粒度问题，等于没解决。

【我现在的卡点 & 期望得到的答案形态】

1. 有没有低成本拿到秒级甚至亚秒级内存信号的工程方案？我想到但没验证过的：eBPF 抓内存压力 / oom 前事件、cAdvisor 单独高频采、node-exporter textfile collector 高频写 PSI、内核 memory.oom.group + 用户态 pre-oom hook。这些哪个真在生产跑过？成本到底多少？
2. "缓慢爬升"和"阶跃暴涨"这两类内存事故，信号体系是不是得彻底分开？前者用斜率 / working_set 预测，后者只能靠 PSI full 或堆外池直接监控（如 Netty 的 MaxDirectMemorySize 水位）？有没有人真把两套体系并行跑的？
3. 采样粒度、信号提前量、采集成本这三者，你们实际是怎么权衡的？"1s 全量太贵、15s 太粗"之间有没有一个甜蜜点的落地做法（比如只对核心服务高频采、其余低频）？

我知道这类问题没有唯一标准答案，但每个被 OOMKilled 坑过的运维都该撞过这道坎，想听听大家生产上真实的取舍，尤其是"为了多提前几秒，到底愿意多付多少采集成本"。