内存异常预警：及时通知运维人员

内存异常预警：内存飙升为什么要及时通知运维

服务器内存被打满会触发OOM Killer杀掉关键进程，表现为接口超时、服务莫名重启，且事后排查难度大。相比CPU问题，内存异常往往隐蔽性更强——进程缓慢泄漏，直到某天突然崩溃才被发现。互亿无线预警通知支持在内存使用率超过阈值或出现OOM事件时，及时通过短信+语音通知运维人员，抢在进程被杀之前介入。

内存异常预警的两种触发方式

一种是基于指标的阈值告警：监控脚本定时读取/proc/meminfo，当可用内存低于阈值持续若干分钟即告警；另一种是基于事件的即时告警：系统出现OOM记录或进程被kill时，通过syslog转发立即触发通知。

接入内存异常预警的步骤

1. 部署Node Exporter或自定义脚本采集mem_available与oom_kill事件指标。
2. 配置告警规则：可用内存低于10%持续3分钟触发warning，出现oom_kill立即触发critical。
3. warning级别发短信提醒运维关注进程内存趋势，critical级别语音呼叫并通知应用负责人。
4. 在告警文案中附带TOP内存进程列表，帮助运维快速定位泄漏源。

with open("/proc/meminfo") as f:
    info = dict(l.split(":") for l in f)
total = int(info["MemTotal"].split()[0]); avail = int(info["MemAvailable"].split()[0])
if avail / total * 100 < 10:
    requests.post("https://api.ihuyi.com/voice/vm", data={
        "account": "APIID", "password": "APIKEY", "mobile": "13800000001",
        "content": "服务器可用内存不足，请检查内存泄漏"})

内存异常预警的注意事项

• 区分buff/cache与真正可用内存，使用MemAvailable而非MemFree判断，避免误报。
• OOM事件属于即时告警，应走语音通道，不能只发邮件。
• 告警文案中建议带上主机名与Top进程，缩短运维定位时间。
• 通话时长可查，确认值班工程师是否接听并响应。

进阶用法：内存泄漏定位与Top进程随告警下发

内存异常的难点在于定位：知道某台机器内存快满了，还得登录上去看是哪个进程在涨。建议在告警脚本里顺手采集Top内存进程列表，把进程名与占用百分比拼进短信，运维收到通知就知道该查哪个服务，省去登录排查的时间。

对于已经发生OOM的机器，syslog里会留下"Out of memory: Killed process"记录。可以把syslog转发到日志收集服务，用规则匹配oom_kill关键字，命中后立即触发语音呼叫应用负责人——这类事件已经发生进程被杀，属于事后补救，必须让人马上介入。

• 告警文案附带Top3内存进程，缩短定位时间。
• 用MemAvailable判断真实可用内存，排除buff/cache干扰。
• OOM事件走语音通道，普通水位告警走短信。

import subprocess
def top_mem(n=3):
    out = subprocess.check_output(
        ["ps", "aux", "--sort=-%mem"]).decode().splitlines()[1:1+n]
    return [f"{l.split()[0]} {l.split()[2]}%" for l in out]
# 拼入短信内容："内存不足，Top进程: nginx 22%, java 18%"

内存问题隐蔽性强、夜间突发概率高，互亿无线支持24小时发送，夜间OOM也能即时呼叫。语音接口约70字对应20秒播报，文案控制在这个长度内效果较好。

落地时建议把内存告警与自动重启策略配合使用：对无状态服务（如接口节点）检测到内存持续上涨可先自动重启释放，再发通知记录；对有状态服务（如数据库、缓存）则只告警不自动重启，交由人工判断。两种策略区分处理，既减少业务影响，又避免盲目重启丢数据。

内存异常预警把隐蔽的内存泄漏变成可感知的手机告警，避免业务在毫无征兆的情况下崩溃。互亿无线提供三网直连通道，开发者可注册免费试用。