一、先快速定位三层核心故障点
网络层:UIS 是否正常发送 Trap 到 IMC 服务器
IMC 接收层:IMC 是否收到 UIS 的 Trap 报文
解析匹配层:MIB、Trap 转告警规则、设备识别是否匹配失效
二、分步排查操作
1. 检查 UIS 侧 Trap 配置(源头)
1)登录 UIS 管理平台 → 系统管理 → 告警配置 → SNMP 陷阱
确认 SNMP 版本:IMC7.3 推荐 v2c,v3 容易出现加密 / 权限拦截
目标 IP 填写 IMC 服务器业务 IP,端口默认 162,防火墙放行 UDP 162
团体字和 IMC 设备 SNMP 团体字完全一致(区分大小写)
勾选全部告警级别(紧急 / 重要 / 次要 / 提示),不要只勾选部分级别
保存后点击「发送测试陷阱」,看 UIS 提示发送成功
2)UIS 主机防火墙放行 162 出站 UDP
plaintext
# 登录UIS后台节点执行
firewall-cmd --permanent --add-port=162/udp
firewall-cmd --reload
2. 网络抓包验证:UIS 有没有把 Trap 发出来(关键分界点)
方式 A:IMC 服务器抓包(Windows 用 Wireshark,Linux 用 tcpdump)
Linux IMC 服务器执行抓 162 端口 UDP:
bash
运行
tcpdump -i any udp port 162 host UIS管理IP
持续触发 UIS 告警,若抓不到报文:问题在 UIS / 防火墙 / 路由
排查:两端防火墙、安全组、中间交换机 ACL 是否拦截 UDP 162;IMC 与 UIS 跨网段检查路由可达
能抓到报文,但 IMC 无告警:问题在 IMC MIB 解析、告警转换规则
3. IMC 侧 Trap 接收基础校验
1)IMC 服务状态
登录 IMC 部署服务器,检查 2 个核心服务:
iMC Trap Receiver 服务必须运行
iMC UCenter APM 应用性能管理服务运行
Windows:服务面板直接查看;Linux:ps -ef | grep trap
2)IMC 本地防火墙放行 UDP 162
Windows:高级防火墙入站规则放行 UDP 162
Linux:
bash
运行
firewall-cmd --permanent --add-port=162/udp
firewall-cmd --reload
3)查看 IMC 原始 Trap 日志(区分收到 / 未解析)
路径:iMC/client/log/trap/trap.log
打开日志过滤 UIS 的 IP:
日志里持续出现 UIS 的 trap 报文 = IMC 收到报文,MIB 解析异常
日志完全无 UIS 报文 = 网络拦截,回到第二步排查
4. MIB 文件与 Trap 升级告警规则修复(你当前核心问题)
现象:导入 UIS MIB、开启全部 Trap 转告警,但只有 3 条静态告警不更新,典型 MIB 加载不全 / OID 不匹配
1)清理旧 MIB,重新导入完整 UIS MIB 包
路径:IMC → 资源 → SNMP 管理 → MIB 管理
删除原有 UIS 相关 MIB 文件
从对应 UIS 版本配套下载完整 MIB(不要截取部分 MIB,缺少子节点 OID 会丢告警)
批量上传全部 MIB,点击编译 MIB,确认编译无报错(报错会直接丢弃对应 Trap)
编译完成重启 iMC Trap Receiver 服务
2)Trap 升级告警规则重新生成
路径:资源 → 陷阱管理 → 陷阱升级告警配置
删除原有针对 UIS 设备的全部转换规则
点击「自动生成规则」,选中 UIS 设备类型,全选所有 Trap OID
所有规则状态改为启用,告警级别映射保持默认,不要自定义过滤
保存,重启 Trap 接收服务
3)设备 SNMP 参数一致性校验
进入 UIS 设备详情 → SNMP 参数:
SNMP 版本、团体字、超时、重试次数必须和 UIS 告警陷阱配置完全一致
勾选「接收该设备陷阱」,未勾选会直接丢弃所有 Trap
5. UCenter APM 应用纳管专属坑点(APM 纳管特有)
1)APM 纳管仅读取性能指标,Trap 告警由基础平台 Trap 模块处理,APM 本身不解析 Trap
不要只在 APM 页面排查,必须回到【资源 - 陷阱管理】配置
2)设备双纳管冲突:同时在资源平台 + APM 纳管同一台 UIS,容易出现 OID 缓存错乱
解决:删除 APM 内 UIS 纳管实例,重新同步纳管,刷新设备 SNMP 缓存
3)APM 同步周期缓存拦截旧告警
路径:UCenter APM → 系统配置 → 采集参数,缩短 SNMP 采集间隔,清理设备缓存
6. 数据库与缓存兜底修复(告警只 3 条不刷新)
1)清理 IMC Trap 缓存
停止 Trap 服务,删除路径:iMC/server/tmp/trap/* 下缓存文件,重启服务
2)检查 IMC 告警数据库是否溢出
进入系统监控 → 数据库管理,查看 trap、alarm 表数据量,历史告警过多会导致新告警入库缓慢
可配置自动归档历史告警,避免表过大阻塞写入
三、快速判断根因总结
抓包无 Trap 报文 → 网络 / 防火墙 / UIS SNMP 陷阱配置错误
抓包有报文、trap.log 有记录但无告警 → MIB 编译失败、Trap 转换规则缺失
仅固定 3 条告警永不更新 → MIB 不全、OID 匹配失败、Trap 缓存卡死
APM 纳管看不到告警,但资源平台能看到 → APM 页面告警过滤、纳管同步异常
四、标准修复操作顺序(推荐按顺序执行)
UIS 侧重新配置 SNMP 陷阱,发送测试陷阱验证发送成功
两端防火墙放行 UDP 162,抓包确认 IMC 收到 Trap
IMC 删除旧 UIS MIB,上传完整 MIB 并编译无报错,重启 Trap 服务
清空原有陷阱升级规则,自动生成全套转换规则并启用
核对 UIS 设备 SNMP 团体字、开启接收陷阱
清理 Trap 缓存,重启 Trap Receiver、UCenter APM 服务
重新同步 APM 纳管设备,触发 UIS 告警测试是否实时上报告警
暂无评论
UIS产生大量告警,但iMC上只收到3条且不更新,问题核心通常在于UIS侧告警上报配置、iMC侧Trap接收或升级为告警的规则上。
可以按照以下步骤,逐一排查,定位问题。
首先需要明确,UIS的告警可以通过以下两种方式上报给iMC:
SNMP Trap(推荐):UIS主动将告警作为Trap报文发送给iMC。这是实现实时告警的标准方式。
你提到配置了“Trap升级告警”,说明采用的是第一种方式。
请按照以下流程,从数据流的源头开始排查:
查看原始Trap:登录iMC,进入“告警” -> “Trap浏览”。这是最关键的一步。
如果能看到大量来自UIS的Trap:说明网络和UIS侧配置正常,问题在iMC内部。
如果只看到3条或看不到:说明Trap报文未能到达iMC或已被丢弃,问题在网络或UIS侧。
检查Trap过滤规则:iMC默认有过滤规则,可能丢弃了部分Trap。进入“告警设置” -> “Trap过滤规则”,检查是否有规则过滤了UIS的Trap。可以暂时禁用相关过滤规则进行测试。
检查“未加入本系统设备Trap过滤”:确保此功能未开启,否则来自未纳管设备的Trap会被丢弃。
你提到已配置“整个mib上传的trap都升级成告警”,但仍需确认:
检查规则完整性:如果只导入了部分MIB,可能只有部分Trap OID被定义了升级规则。确保已导入完整的UIS MIB库。同时,可检查是否所有Trap都成功升级为告警。
检查重复Trap过滤:如果UIS短时间内发送大量相同Trap,可能触发“闪断Trap”或“重复Trap”过滤规则,导致后续Trap无法升级为告警。
检查iMC进程:登录iMC服务器,确认 jserver 进程正常运行。
抓包分析:在iMC服务器上对UDP 162端口抓包,确认是否收到UIS的Trap报文。
查看iMC日志:检查iMC的imcapmedm等日志,查找错误信息。
暂无评论
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
抄袭了我的内容
×
原文链接或出处
诽谤我
×
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论