序号 | | | | | |
1 | | | 华为告警出现比实际网管多告警的现象。 SG-TMS系统有这条告警,但是专业网管没有展现。 " alarmcause":"GNE_MGR_LIMIT_OVER" | 如果报文中出现此条告警可以询问厂家网管此条告警是否被屏蔽。 | |
2 | | | 华为告警出现比实际网管多告警的现象。 协议增加了告警描述导致网管上同样一条告警重复入库。 ![]() | | |
3 | | | NEC告警报文中没有站点名称和具体告警描述,无法核对告警。 | | |
4 | | | 报文和内存库比实际网管多告警。 此告警描述为“DCC连接失败”,厂家网管没有展示 | | |
5 | | | 当前重新采集,在系统当前告警中显示有比网管上多出来的告警,时间不是当前时间,并且当前状态为已确认 | 清除数据库中已确认的告警删除,更新配置同步中的jar包,修改采集协议。清楚缓存,重新打开当前告警查看告警数据。 | |
6 | | | 在当前告警中选中端口告警,然后定位该告警时无法显示 | 首先,内存库中验证是否有该告警;然后查看该端口的设备是否上架 | |
7 | | | 现象除西门子和华为外,其他厂家告警数量与设备网管均有出入,且报文拿回测试组重现,处理数量正常 | 华为协议发现设备网管接口重复上报告警(相同告警,仅时间不同),告警处理后台自动归并处理,所以呈现效果是,TMS系统告警少于设备网管告警,现象正常。 | |
8 | | | | 研发排查发现确定现场内存库服务中不应该出现commons-App.jar文件,清除该文件后问题解决,属于 配置问题 | |
9 | | | 当前告警列表,部分为端口类型的告警,其告警对象为null。用告警发生器查看内存库,字段DEV_TYPE_NAME、RES_NAME的值为null | 模拟现场发送告警报文。用告警发器查询内存库告警对象显示为空,且为端口告警,根据res_obj_id查看端口表,发现name为空,再根据EMS_NAME值查看报文,发现该端口的nativeemsname=””,确定是采集协议的问题。 | |
10 | | | 马可尼告警在由3.2版本更新到3.5版本的时候没有同步,导致告警无法采集 | | |
11 | | | 中兴网管 椿树园 严重告警 时间2078-01-11 告警对象NULL | 经和厂家网管告警信息对比,厂家网管不存在此告警。研发建议直接删除清掉该条数据,后期进一步观察; | |
12 | | | 运行告警发生器,查询内存库时,发现涉及到告警时间的字段如 ALARM_NE_TIME中内容为(1335613161000) | 经查看数据库表mw_app. T_RT_CUR_ALARM得知字段时间为数字型 ![]() 提供时间转换工具可以查看。 | |
13 | | | 右上角未确认告警数与告警列表中未确认告警数不符,刷新后也没有效果 | 查询内存库后发现数据与当前显示数据不符。清楚内存库告警,再次采集确认,是否存在该问题,然后做下一步问题定位 | |
14 | | | 告警确认完后,再后台采集程序开启的情况下,后台采集程序进行循环查询告警后,告警又变成全部未确认 | 修改 D:\SGTMS\DQF\Manager\probeweb_lib下该协议里面的config.xml文件,把‘是否激活同步’改成‘false’,防止十分钟同步一次告警 | |
15 | | | 告警接收、告警接口、7.pi3000&SGTMS&指标定义启动时报错如“无法定位RMI服务…” | 首先确保内存库启动完成,然后检查NETHOT下所有配置文件的IP是否全部统一和改对路径,其次排除JDK版本问题 | |
16 | | | 在当前告警列表里对某一条告警进行告警转运行处理,提示失败 | 在D:\SGTMS\pi3000\SGTMS\WEB-INF找到AlarmMonitor.properties;把 endpoint=http://127.0.0.1:7001/MWBusinessModel/ services/alarminsendoperation,ip改为:应用服务器地址,端口改为:7001 | |
17 | | | 告警无法确认,进行确认操作后,告警状态不变,仍显示为未确认告警 | 经排查是因为告警接收服务未正常开启,重启后问题得到解决。 | |
18 | | | | 根据日志上的网元名称到sys报文中找到对应的emsname,然后到数据库中查询是否存在日志中的资源。 分析: 数据库中存在ftp和ptp端口,入库的时候存在相同的唯一标示EMS_SN导致资源不能匹配,更新配置同步JAR包解决这个问题。 | |
19 | | | 内存库中的告警比网管告警少,但是报文中告警与网管一致。 | 如果报文中存在相同告警描述、告警等级、告警时间、告警对象的告警则会合并成一条告警。 | |
20 | | | 产生在端口上的告警进入系统后可能因为端口无法匹配,而匹配板卡,导致多条端口告警,变成1条板卡告警 | 检查内存库和物理中的端口,检查告警接收对端口的匹配情况。 | |
21 | | | 一块板卡下的多个端口告警,因为没有匹配到端口,匹配到了板卡,之后某个端口产生了一条165,就会导致此板卡的告警消失 | | |
22 | | | 网元上的告警在采集时丢失了网元信息,进入系统后成为一条系统告警 | | |
23 | | | | | |
24 | | | | | |
25 | | | | | |
26 | | | | | |