应直接监控内存增长曲线和分配源头，确认agent自身内存泄漏：通过ps/top观察rss上涨、停启验证、tracemalloc定位热点、检查日志轮转与配置累积行为，并可通过调大采集间隔、强制日志轮转、设置memorymax临时缓解。
直接盯住内存增长曲线和分配源头，别等 OOM 再动手。
确认是 Agent 而非业务代码在涨内存
先排除干扰：用 ps aux --sort=-%mem 或 top -p $(pgrep -f "agent-name") 确认目标进程 RSS（常驻内存）是否稳定上涨；同时对比同一台机器上其他业务进程的内存趋势。如果只有 Agent 进程每小时固定涨 50MB，而业务 JVM 堆内存（jstat -gc <pid></pid>）平稳、GC 频率正常，基本可锁定问题出在 Agent 自身。
补充验证：临时停掉该 Agent（如 systemctl stop az500-agent），观察 30 分钟内内存是否停止增长；再启起来，看是否恢复线性上涨节奏。
启用轻量级内存追踪定位热点
对 Python 类 Agent，立刻启用 tracemalloc 实时采样：
- 在 Agent 启动脚本中加入：
import tracemalloc; tracemalloc.start() - 每 10 分钟打一次快照：
snapshot = tracemalloc.take_snapshot() - 运行 2 小时后，对比首尾快照：
top_stats = snapshot2.compare_to(snapshot1, 'lineno')，重点看前 10 条中哪些文件、哪行代码分配了最多新增内存
常见泄漏点包括：未清理的回调引用、动态生成的工具对象未释放、日志缓冲区持续追加不刷盘、监控指标缓存无淘汰策略。
检查日志与配置中的隐性累积行为
很多 Agent 的“内存缓慢上涨”实际源于磁盘日志或内存映射间接引发：
- 查日志目录大小：
du -sh /var/log/agent-name/，若超过几 GB，说明日志轮转未生效，Agent 可能因 mmap 日志文件或缓冲区膨胀间接推高 RSS - 检查 Agent 配置中是否有
debug或verbose模式开启，尤其在高频采集场景下（如默认每 30 秒扫描系统状态），调试日志会大量创建字符串对象并长期驻留 - 确认是否启用了未限制大小的本地缓存，例如指标聚合 map、事件队列、对话历史 buffer —— 即使没显式 OOM，持续扩容也会吃掉内存
快速验证与临时缓解
不改代码也能压住增长：
- 调大采集间隔：如将
"collection_interval_sec": 30改为180，减少高频系统调用和中间对象生成频率 - 强制日志轮转：配好
logrotate并触发一次手动切割，观察内存增长是否变缓 - 加内存限制：用
systemd设置MemoryMax=512M，配合Restart=on-failure，让 Agent 在接近阈值时自动重启，避免拖垮整机
这类做法不能根治 Bug，但能争取排查时间，防止影响业务 SLA。
