巡检机器人发现进程内存一路上涨，立即建议“存在泄漏”。如果同期请求量翻倍、缓存刚预热，这个结论可能太快。趋势检测应先帮助排除解释，而不是把斜率直接写成根因。

同时看负载和内存

下面是两个教学窗口，内存与完成请求数都由人工构造。程序先算每请求内存这个粗略比例，用来提示“负载也在变”，不把它当成泄漏判定。

windows = [
    {"rss_mib": 400, "completed": 1000},
    {"rss_mib": 600, "completed": 2000},
]
ratios = []
for w in windows:
    if w["completed"] <= 0:
        raise ValueError("cannot normalize by zero traffic")
    ratios.append(w["rss_mib"] / w["completed"])
assert windows[1]["rss_mib"] > windows[0]["rss_mib"]
assert ratios[1] < ratios[0]
print("memory rose while crude normalized ratio fell:", ratios)

概念曲线中，紫色表示RSS，青色表示GC后存活堆，金色表示负载。它们单位不同，高度不能直接比较，也不是实测数据；调查时须分别定义采样口径。

这个比值有明显局限：RSS是某时刻存量，请求数是窗口内流量，二者时间语义不同。它只能提醒我们补证，不能作为容量公式。真实系统还要区分堆、栈、映射、原生库和缓存，确认垃圾回收和采样时刻。

把机器人输出改成调查单

比“泄漏概率92%”更有用的输出是：增长从何时开始，是否跨过低负载窗口，GC后存活堆是否仍增长，最近是否发布新版本，哪些数据尚未拿到。每项附查询或采样位置，缺失就标缺失。

Trace可以帮助看某些调用是否滞留，但它不是内存剖析。反过来，一份堆剖析也不直接说明用户请求为什么慢。把不同信号放在同一时间轴上，才有机会形成可验证假设。

给自动化设停止条件

当数据不足时，机器人可以建议采集下一份剖析，不能自行重启所有实例“试试看”。如果允许自动重启，也应有实例范围、预算、冷却时间、健康检查和人工接手条件，否则会把潜在泄漏变成反复抖动。

本文没有连接真实进程，也没有检测泄漏；本地例子只验证归一化的算术和零分母拒绝原则。把趋势、解释和动作分开，巡检结果才不会因为一张向上曲线就显得过度自信。

参考

• OpenTelemetry：Trace的覆盖范围