当前位置：文档库 › 故障预处理手册_ 爱立信

故障预处理手册_ 爱立信

V3.3

(省网维核心网络维护室编制)

第一部分监控派单说明 (2)

第二部分监控自处理部分 (3)

1、AP PROCESS REINITIATED (3)

2、AP REBOOT (4)

3、ILLEGAL LOGON ATTEMPTS (5)

4、AP FAULT (GENERAL ERROR) (5)

5、ALI FAULT (5)

6、BACKUP INFORMATION FAULT (6)

7、CP STATE NOT NORMAL (7)

8、DIGITAL PATH QUALITY SUPERVISION (7)

9、DISTURBANCE SUPERVISION OF TRUNK ROUTES (8)

10、DISTURBANCE SUPERVISION OF INDIVIDUAL DEVICES (8)

11、EVENT REPORTING THRESHOLD REACHED (9)

12、HLR SUBSCRIBERS WITH INCOMPATIBLE DATA SUPERVISION (9)

13、SEIZURE QUALITY SUPERVISION (9)

14、SEIZURE SUPERVISION OF DEVICES IN BSC (10)

15、SIGNALLING FAULT SUPERVISION (10)

16、SOFTWARE ERROR (11)

17、WNMS连接网元告警 (11)

第三部分监控预处理部分 (12)

1、AP DIAGNOSTIC FAULT (12)

2、AP PROCESS STOPPED (13)

3、AP SYSTEM ANALYSIS (13)

4、AP FILE PROCESSING FAULT (15)

5、AP SYSTEM CLOCK NOT SYNCHRONIZED (17)

6、ANALYSIS DATA FAULT (18)

7、AUDIT LOG DEACTIV ATED (19)

8、AUDIT FUNCTION THRESHOLD SUPERVISION (19)

9、BLOCKING SUPERVISION (20)

10、BLOCKING SUPERVISION OF DEVICE (21)

11、CCITT7 SIGNALLING LINK FAILURE (21)

12、CCITT7 LINK SET SUPERVISION (23)

13、CCITT7 DESTINATION INACCESSIBLE (23)

14、CONTINUITY CHECK FAILURE (24)

15、COMMAND LOG BLOCKED (24)

16、COMMAND LOG OUTPUT ERROR (25)

17、CP FAULT (25)

18、CHARGING DESTINATION FAULT (26)

19、DIGITAL PATH FAULT SUPERVISION (27)

20、DIGITAL PATH UNA V AILABLE STATE FAULT (28)

21、DISTRIBUTED GROUP SWITCH FAULT (28)

22、DISTRIBUTED GROUP SWITCH CLM CONTROL/ GROUP SWITCH CLM

CONTROL (30)

23、EM FAULT (30)

24、IO-FAULT FOR TRAFFIC DISPERSION MEASUREMENT (31)

25、IO STORAGE SPACE WARNING (31)

26、M3UA DESTINATION INACCESSIBLE (32)

27、MT ROAMING AND HANDOVER NUMBER, ALLOCATION, SUPERVISION (33)

28、NETWORK SYNCHRONIZATION FAULT (33)

29、RP FAULT (34)

30、SEMIPERMANENT CONNECTION FAULT (35)

31、SIZE ALTERATION OF DATA FILES FAULT (36)

32、SIZE ALTERATION OF DATA FILES SIZE CHANGE REQUIRED (36)

33、SIZE ALTERATION OF DATA FILES AUTOMATIC SIZE ALTERATION PASSIVE

(37)

34、SWITCHING NETWORK TERMINAL FAULT (37)

35、SYNCHRONOUS DIGITAL PATH FAULT SUPERVISION (39)

36、SYNCHRONOUS DIGITAL PATH UNA V AILABLE STATE FAULT (40)

37、VOLUME LIMIT EXCEEDED (40)

38、EXTERNAL ALARM RECEIVER FAULT (41)

39、PORT BLOCKED (41)

40、SP TRANSIENT FAULT SUPERVISION (42)

第四部分关于MGW退服故障处理的操作指引 (43)

1、查看MGW状态： (43)

2、查看告警： (43)

3、PING 操作： (44)

第一部分监控派单说明

随着核心网智能自动派单的全面启动运行，监控值班人员在接收到智能自动派单系统派发故障工单时，可参考以下的说明进行处理：

1、可以自处理的告警（详见第二部分），请监控值班人员参考操作手册进行自主处理或派市公司处理，无需派单核心网络维护室。

2、一般故障（详见第三部分），请监控值班人员在接到智能自动派单，包括集团公司派的一般故障工单，可参考本操作手册先进行预处理，如预处理不成功或预处理后过一段时间告警重新出现，请派往单核心室做后续处理，并在工单上填写所做的预处理操作及结果，以便专业室处理人可更好地了解故障处理过程的情况，提高故障工单的处理效率。

3、紧急故障和严重故障，如媒体网关退服，系统限呼、计费拥塞、系统重启/RELOAD 并影响业务的故障，请派单并电话通知核心网室值班人员（135********），也可先打电话再派单。

4、管理职责不在核心网室的相关告警（如涉及HLR用户数据、传输电路、关口局的IP专线故障和BSC侧告警等），请直接派单并联系市公司处理。

5、因工程调试、割接和软件升级、补丁以及夜间因处理故障过程产生和告警等原因引起的告警，以EOMS公布信息为准进行匹配，均无需派单，请监控值班人员督促各项目实施操作人员及厂家操作操作人员，在确认上述操作所产生的告警消除后，方可同意操作人员离场。

6、为避免重复派单，对于一般告警，建议只采用自动派单，而不要自动派单和手动派单同时进行。

7、本手册在原先的基础上进行修订，同时增加媒体网关MGW发生退服故障的操作指引；

8、本手册的故障处理指引也适应集团工单的处理，请参照此手册处理集团工单；

9、本手册是核心网络室维护组与监控维护二线同事根据实际工作情况共同编写和审核，具有可操作性。

10、本手册的故障处理指引是针对爱立信网元上经常发生的故障，并非覆盖网元中所有的故障；

第二部分监控自处理部分

对于本部分所列告警，在没有伴随其它相关严重告警并且不是反复出现时，监控值班人员可参考以下处理步骤进行自主处理，无需派单核心网络维护室。

1、A P PROCESS REINITIATED

告警信息(举例)：

A2/APZ "GZSM7B1R12/ID/0" 548 070910 1447

AP PROCESS REINITIATED

AP APNAME NODE NODENAME

1 GZSM7B1AP1C A GZSM7B1AP1A

RESOURCE GROUP PROCESS

Disk Group stsprov

CAUSE DATE TIME

告警产生原因：APG中某个进程出现软件问题,APG系统自动对进程进行重新启动。

对于AP1告警处理方法：

1、

2、C:\> cluster res 检查所有process是否都为online.

3、C:\> cluster res|findstr –ive online检查存在OFFLINE的进程；

4、C:\>cluster res resource_name /on /wait对存在OFFLINE的进程进行重启

5、C:\> alist 得到该告警的Alarm Identifier(格式为xxxx:x，本例为6023:1)

6、C:\> acease 6023:1 删除告警(有时告警会过一两分钟才消除)

7、C:\> alist 确认告警消除；

对于AP2告警处理方法：

1、

2、C:\> ipconfig 检查AP1的IP地址（ETHERNET ADAPTER PUBLIC的IP 地址）

3、打开SUN TOOLS/TERMIAL。。。窗口

4、C:\> telnet AP1

5、C:\> telnet AP2（NODE_A:192.168.170.3;NODE_B:192.168.170.4）

6、C:\> cluster res|findstr –ive online检查存在OFFLINE的进程；

7、C：/>cluster res resource_name /on /wait对存在OFFLINE的进程进行重启

8、C:\> alist 得到该告警的Alarm Identifier(格式为xxxx:x，本例为6023:1)

9、C:\> acease 6023:1 删除告警(有时告警会过一两分钟才消除)

10、C:\> alist 确认告警消除；

2、AP REBOOT

告警信息(举例)：

A2/APZ "HDC1BSC10/GD/0/" 345 070731 0840

AP REBOOT

AP APNAME NODE NODENAME

1 HDG3B1AP1C A HDG3B1AP1A

CAUSE DATE TIME

Fault initiated 20070731 084035

END

告警产生原因：APG中某个node出现故障或可能存在故障，系统自动对其进行重启动或是人工对某个NODE进行重新启动。

告警处理方法:(与告警1的处理过程基本相同)

1、

2、C:\> cluster node 检查NODE 的状态(两个node都应为up)

3、C:\> cluster res 检查所有process是否都为online（如有offline参见2.1处理）.

4、C:\> alist 得到该告警的Alarm Identifier

5、C:\> acease xxxx:x 删除告警(有时告警会过一两分钟才消除)

6、C:\> alist 确认告警消除；

说明：对于AP2发生类似的告警，采用二次TELNET的方法登陆到告警的NODE上：（1）、打开OSS中的SUN TOOLS中的TERMAL。。窗口，用TELNET XXX登陆到AP1；（2）、在登陆到AP1的基础上，再次用TELNET 192.168.170.3(对应AP2的NODE_A),192.168.170.4(对应AP2的NODE_B);

（3）、参考AP1的处理方法；

3、ILLEGAL LOGON ATTEMPTS

告警信息(举例)：

A2/APZ "GZ33MSC63/JD/0/" 567 070910 1513

ILLEGAL LOGON ATTEMPTS

AP APNAME NODE NODENAME

1 GZG33MSCAP1C B GZG33MSCAP1B

SECURITY VIOLATION ATTEMPT

告警产生原因：此告警是一个安全提示，在短时间内，连续三次输错APG登陆帐户、密码。告警处理方法:(与告警1的处理过程基本相同)

1、

2、C:\> cluster res 检查所有process都为online状态.

3、C:\> alist 得到该告警的Alarm Identifier(格式为xxxx:x，本例为8799:0)

4、C:\> acease 8799:0 删除告警(有时告警会过一两分钟才消除)

5、C:\> alist

4、AP FAULT (GENERAL ERROR)

告警信息(举例)：

A2/APZ "GZXMSC63/HD/0/0" 113 070901 1747

AP FAULT

AP APNAME NODE NODENAME

1 GZG24MAP1C A GZG24MAP1A

PROBLEM

GENERAL ERROR

END

告警产生原因：APG系统运行过程中出现的一般性告警信息。

告警处理方法:(与告警1的处理过程基本相同)

1、

2、C:\> cluster res 检查所有process都为online状态.

3、C:\> alist 得到该告警的Alarm Identifier(格式为xxxx:x，本例为8799:0)

4、C:\> acease 8799:0 删除告警(有时告警会过一两分钟才消除)

5、如上一步无法执行时用C:\> acease –o 8799:0

6、告警反复出现请派单。

5、ALI FAULT

告警信息(举例)：

*** ALARM 153 A2/APZ "GZEBSC1 R12/HB/0/1"U 080310 2352

ALI FAULT

MAG PCB ADDINFO

ALI-0 - NO CONTACT

END

告警分析：

产生此告警的原因是由于IOG中定义为告警输出接口终端AT-1/4被闭塞或吊死引起的。

告警处理：

1．确认没有其它相关告警

若有其它的相关告警，如IO BLOCKED、PORT BLOCKED、LINE UNIT BLOCKED告警，须先处理相关告警后再处理“ALI FAULT”告警。

2、闭解ALI

EXECUTED

查看告警，如果还不能消除告警的话就进行下一步骤；

3、闭解ALI的PORT(通常是AT-1)

:MCDVP;

:ILNPP:PORT=ALL;

:ILBLI:PORT=1-1-1-2;

:ILBLE:PORT=1-1-1-2;

:END;

4、检查SPG的两个NODE的状态均为WO：

INMCT：SPG=0；

IMCSP；

END；

5、若上述处理仍不能解决故障，则需要对SPG=0的执行NODE做一个小启动，相当于对SPG=0做倒边，此操作无风险，无须等到凌晨话务较低时做重启：

SYRSI：SPG=0，NODE=EX_NODE,RANK=SMALL;

6、BACKUP INFORMATION FAULT

告警信息(举例)：

*** ALARM 073 A1/APZ "ZSGMSC63/JD/0/0"U 070925 2144

BACKUP INFORMATION FAULT

FAULT CODE 41

END

告警产生原因：系统备份出错或有关信息异常，常见Fault Code有34、13、23、41、58等。

告警处理方法：

1、对于Fault Code 34，可以激活自动DUMP:

对于其它Fault Code：人工做一次系统备份(对于端局在实施备份的要求，在话务闲时，用PLLDP查询，CP负荷在40%以下；对于HLR的系统备份，安排在凌晨进行，避免影响BOSS侧在送修改用户数据时不成功的问题)；

流程如下：

7、CP STATE NOT NORMAL

告警信息(举例)：

*** ALARM 411 O1/APZ "STGMSC63/JD/0/0"U 080327 2017

:CP STATE NOT NORMAL

:END

告警分析：

产生CP40/50/55/60的CP-SB状态不正常的原因是由于修改CP的相关参数，如扩/缩SAE 或激活软件补丁引起的。

告警处理：

1、 DPWSP；

2、对系统做一个备份：(对于端局的备份要求，话务闲时，用PLLDP查询，负荷在40%以下，对于HLR的系统备份，为避免同BOSS修改用户数据冲突，要求安排在凌晨进行备份)；

SYBUE；

SYBUP：FILE；

SYTUC；

SYBUI；

3、DPWSP；

4、对CP完成备份后，CP还不正常的，需要对CP做一个并边处理：

DPPAI；

5、DPWSP；核查CP的状态；

8、DIGITAL PATH QUALITY SUPERVISION

告警信息(举例)：

*** ALARM 181 A2/APT "FSATR63/HB/0/0/"U 070312 0908

DIGITAL PATH QUALITY SUPERVISION

SESR

DIP DIPPART SESL QSV SECTION DATE TIME

1369UPE 15 15 070312 090817

END

告警产生原因：传输电路质量告警（存在误码问题），如ES、SF、DF等。

告警处理方法：

1、

2、

3、TPQSR:SDIP=xxxx,DEGR; 清除ET155质量告警；

4、在手动清除后，ES、ES2、SES还会产生，说明传输质量很差，需要派单给传送室进行彻底的处理。

9、DISTURBANCE SUPERVISION OF TRUNK ROUTES

告警信息(举例)：

*** ALARM 507 A2/APT "NHAGW63/HB/0/0/"U 070309 0746

DISTURBANCE SUPERVISION OF TRUNK ROUTES

R ADL

FSGM1O 20

END

告警产生原因：路由设备受到干扰(如电磁干扰等)引起。

告警处理过程：

1、

2、

3、告警反复出现请转派单给专业室进一步处理。

10、DISTURBANCE SUPERVISION OF INDIVIDUAL DEVICES

告警信息(举例)：

*** ALARM 0956 A2/APT "GZDS19CN65/KD/0"U 081217 1952

:DISTURBANCE SUPERVISION OF INDIVIDUAL DEVICES

:SGAL2O

:SGAL2I

:END

告警产生原因：路由上的个别设备受到干扰(如电磁干扰等)引起的告警。

告警处理过程：

1、DUIAR:R=SGAL2O&SGAL2I；

2、查看告警：ALLIP；

3、告警反复出现请转派单给专业室协助处理。

11、EVENT REPORTING THRESHOLD REACHED

告警信息(举例)：

*** ALARM 0086 A3/APT "GZS05/GD/0/"U 080321 0210

:EVENT REPORTING THRESHOLD REACHED

:ENUM THRESHOLD LEVEL

:115 TH 10

:END

告警分析：

产生此告警的原因是由于该局的某一局向的信令异常事件记录达到设定的范围值，如某一局向在做相关的链路调整而引起的事件记录，可作为排查故障参考，目前智能派单系统只针对MSC-SEVER局进行派单操作，其它类型的交换端局中此类告警只做为提示性告警，不做派单处理。

告警处理：

1、可用指令 ERESP：ENUM=XXX；查看相关告警；

2、可用指令EREAR:ENUM=XXXX; 释放此告警

3、在清除告警的5分钟后，用指令 ERESP：ENUM=XXX；系统还出现同一告警，可派单给专业室做后续处理；

12、HLR SUBSCRIBERS WITH INCOMPATIBLE DATA SUPERVISION

告警信息(举例)：

*** ALARM 012 A2/APT "SDAHLR63/HD/0/0"U 070611 1229

HLR SUBSCRIBERS WITH INCOMPATIBLE DATA SUPERVISION

INCDAT

159

END

告警产生原因：主备HLR中用户数据不一致，不一致数量达到告警门限值(100)，即产生告警。

告警处理方法：根据主用HLR用户数据更新备用HLR用户数据

1、

2、根据主用HLR用户数据更新备用HLR用户数据，由于不匹配数量较多，一般需要用OPS 脚本进行自动批处理。用户数据的维护职责在市公司，告警请派单市公司专业室处理。

13、SEIZURE QUALITY SUPERVISION

告警信息(举例)：

*** ALARM 246 A2/APT "SDAMSC63/HB/0/0"U 070607 1051

SEIZURE QUALITY SUPERVISION

SDD1O

END

告警产生原因：交换局的话务路由上设备占用异常。

告警处理方法：

1、

2、

3、查看告警是否消除：ALLIP；

14、SEIZURE SUPERVISION OF DEVICES IN BSC

告警信息(举例)：

*** ALARM 886 A3/APT "NHA1BSC10/GB/0/"A 070307 0109

SEIZURE SUPERVISION OF DEVICES IN BSC

DETY

RALT

END

告警产生原因：BSC到MSC的A接口路由上的设备占用异常。

告警处理方法：

1、

2、

3、ALLIP：ACL=A3；确认告警已消除；

15、SIGNALLING FAULT SUPERVISION

告警信息(举例)：

*** ALARM 0853 A2/APT "SGAMSC63/HB/0/0"U 080616 1108

:SIGNALLING FAULT SUPERVISION

:END

告警分析：

产生此告警的原因：是路由上的设备由于存在两个交换局之间的信令配合问题，需要双方交换局协调定位、处理。

告警处理：

1、FAIAP:R=ALL; 查询路由上有信令故障的DEVICE.

按照路由上DEVICE的状态为MBL,CBL,LIBL,SEAL对设备进行闭解等操作。

2、如果设备状态是MBL（人为关闭）的状态，确认后用指令解闭MBL状态的中继设备。

BLODE：DEV＝XXXX-XXXX；解闭中继设备。

3、若设备状态是ABL,需要进一步判断故障与传输电路是否相关

EXDEP：DEV= XXX-XXXX；根据DEV查找设备对应的SNT。

DTSTP：DIP=XXX；查看传输电路状态。

如果DIP为ABL，说明传输电路故障，需要派单传输协助处理。

若DIP为WO，对中继设备进行闭解

4、如果设备状态为AB/S，且分布无明显规律，并出现SEIZURE QUALITY SUPERVISON 的关联告警，可判断为设备的AB与路由设备占用时长监测功能相关。此功能会将占用时长过短的设备自动AB。转派专业室处理。

5、如果是LIBL（对端关闭）的状态，一般是对端局闭塞引起的，检查对端局相应路由上中继设备的状态。如果对端局是其他机型或其他运营商设备，与对端局联系处理。

6、如果是CBL（控制设备闭塞）,则说明控制中继设备的RP或EM故障，按照RP FAULT/EM FAULT的处理流程进行处理。

7、如果设备状态SEAL，所在传输正常，则需要判断故障点在本端还是对端。需要联系对端，查看对端显示的设备状态与本端是否一致。并在本端对设备进行闭解、重新激活测试。

BLODI：DEV=XXX-X；闭掉单个设备

EXDAE：DEV=XXX-X；去激活设备

EXDAI：DEV=XXX-X；重新激活设备

BLODE：DEV=XXX-X；解闭设备

上述操作无效，则需派单给专业室做进一步的处理；

16、SOFTWARE ERROR

告警信息(举例)：

*** ALARM 723 A2/APZ "SDGMSC63/JD/0/0" 070706 0912

SOFTWARE ERROR

END

*** ALARM 376 A3/APZ "SDBMSC63/HB/0/0"U 070308 0753

APPLICATION DETECTED SOFTWARE ERROR

END

告警产生原因：软件运行出错，有系统软件和应用软件。交换局任何时候都有大量的软件在运行，偶尔一两个运行出错很正常，在没有伴随SAE拥塞等告警时，可按下面方法处理。告警处理方法：

1、

2、

或SYRAE:RECTYPE=APPLERR; 用于application detected software error告警

3、

17、WNMS连接网元告警

告警信息(举例)：

*** ALARM 8881 A1/APT "GZS29" 080717 1906

:网元: GZS29 (oss_ip: 139.1.1.1)

:上次失败时间:

:本次失败时间: 2008-07-17 19:06:56

:故障原因: EAW网元连接失败!

:END

告警产生原因：此故障视断连的网元的个数来判断，有可能是网元侧的问题，也有可能是网管的问题。

告警分析：一般是话务网管通过定时去连接网元，目前是20分钟连接网元并下发命令进行数据采集，一当话务网管无法连接网元就产生告警，但是话务网管（WNMS）是先连接到OSS，OSS再连接到网元（NE）。产生网元断连告警的原因：

告警处理：

（1）、对于同一个市公司中同时有1至2个网元出现网元断连时，可直接在OSS上的CHA 手动连接网元，以确认是否真的断连，能正常连接网元，且告警还存在，先观察30分钟后，告警还没消失，则派单给网管支撑室；如果在OSS上也无法连接网元，可能是网元侧接口故障，则派单给核心室处理；对于对于是HLR网元断连时，除派工单外，同时电话通知核心室值班人员；

（2）对于同一个市公司中同时有3个网元出现网元断连时，可直接派单给网管支撑室确认处理，同时电话通知市公司启用本地监控。

第三部分监控预处理部分

出现本部分所列告警，请监控值班人员参考下述方法进行预处理，如预处理不能解决或告警虽可消除但反复出现请派单核心网室处理。

1、AP DIAGNOSTIC FAULT

告警信息(举例)：

*** ALARM 833 A2/APZ "SZSS34CN65/KD/0" 0833 080725 1652

:AP DIAGNOSTIC FAULT

:AP APNAME NODE NODENAME

: 1 SZSS34AP1C B SZSS34AP1B

:ERROR IN ACS_USA_SyslogAnalyser

:END

告警产生原因：一般APG系统本身存在某些硬件或软件故障，引起USA（Universal Systemlog Analyser）频繁地记录EVENT LOG，从而提示维护人员去分析旧的EVENT LOG；

告警处理：

（1）、APLOC；

（2）、ALIST检查是否其它有硬件告警存在，如磁盘镜像问题存在的，可派单给核心室协助处理；对于举例的告警，通常会列出告警8714:X，用指令ACEASE即可；或重启进程

ACS_USA_SyslogAnalyser：cluster res resource_name /on /wait 启动offline的资源后清除告警。

如果有查看有告警号为8701和告警参考数据为：C:\ACS\logs\USA\usa.temp. I/O error : Missing parameter，则进行如下的删除文件：

（3）、在ACTIVE NODE中，del C:\ACS\logs\USA\usa.tmp

（4）、ACEASE 8701

（5）、在PASSIVE NODE 中，执行PRCBOOT重启PASSIVE NODE，不影响APG的工作，此操作没有时间限制；

（6）、CLUSTER NODE 检查两个NODE的状态均处于UP时，对ACTIVE NODE也做PRCBOOT；

（7）、检查两个NODE及RES状态：CLUSTER NODE；CLUSTER RES；

（8）、ALLIP；检查告警是否消失；

2、AP PROCESS STOPPED

告警信息(举例)：

*** A2/APZ "GZ33MSC63/JD/0/" 576 070910 1535

AP PROCESS STOPPED

AP APNAME NODE NODENAME

1 GZG33MSCAP1C B GZG33MSCAP1B

RESOURCE GROUP PROCESS

Disk Group CPS_BUSRV

CAUSE DATE TIME

Unknown failure 20070910 153524

告警产生原因：APG中的某个进程停止工作。

告警预处理：进程所在的NODE状态正常的前提下有效。

1、

2、C:\>cluster node 检查两个NODE状态

3、C:\>cluster res 检查cluster的Resource状态

4、C:\>cluster res|findstr –ive online 列出状态异常的Resource(也可由上一步得到)

5、C:\>cluster res resource_name /on /wait 启动offline的资源。

(cluster res resource_name /off /wait 停闭online的资源)

6、C:\> acease xxxx:x 删除告警(Resource Online之后告警不会立即自动消除)

(Alarm Identifier xxxx:x 由C:\>alist 列出)

7、此操作也适应AP2及HLR；

3、AP SYSTEM ANALYSIS

告警信息(举例一)：

*** ALARM 937 A2/IO_DEV "SDEMSC63/JD/0/0" 0937 081210 1447

:AP SYSTEM ANALYSIS

:AP APNAME NODE NODENAME

: 1 SDMSC5AP1C A SDMSC5AP1A

:OBJECT COUNTER INSTANCE LIMIT V ALUE

:Memory Available Bytes <104857600 91574272

:END

告警产生原因及原理分析：

一、对于内存告警，通常是软件问题，由于某些进程长时间占用APG内存而没有释放，如控制话统的进程STSPROV、STSCONV、STSOPCF长时间占用了虚拟内存。可以采取重启进程的方法来恢复，但是对于AP2告警都需要在晚上闲时处理。

告警处理方法（一）：

1) aploc; 进入ap模式下

2) cluster res 检查所有process是否都为online

3) cluster res stsmain /off 停掉stamain进程

4) cluster res |findstr –ive online 查看有哪些进程是offline(正常情况应该是有stsmain、stsprov、stsconv、stsopcf四个进程是offline的)

5) cluster res stsmain /on/wait 启动stamain进程

6) cluster res |findstr –ive online 查看有哪些进程是offline（stsprov、stsconv、stsopcf四个进程是offline的）

7) cluster res stsmain /on/wait 启动stsmain进程

cluster res stsprov /on/wait 启动stsprov进程

cluster res stsconv /on/wait 启动stsconv进程

cluster res stsopcf /on/wait 启动stsopcf进程

8) cluster res |findstr –ive online 查看有哪些进程是offline（正常情况没有进程offline，如果有offline的进程则参照上一步启动该进程）

9) cluster res 检查所有process是否都为online

10) exit

11) allip:acl=; 确认告警是否消除。

告警处理方法（二）：

上述操作后，几个进程的状态又没有恢复是ONLINE状态，可以采用对APG进行倒边重启的方法（过程需要5分钟左右），但为了保证APG的正常工作，在对APG进行倒边前先检查APG的备用边（PASSIVE NODE）能否正常完成重启，检验方式是：telnet到PASSIVE NODE，执行PRCBOOT指令重启备用边，重启完成后检查PASSIVE NODE的状态时候是否为up，所有process的状态是否都为online。如果一切正常，则可以在ACTIVE NODE执行PRCBOOT指令进行倒边，倒边后检查两个NODE是否都正常，检查告警是否已经消除。1）、APLOC；

2）、telnet IP（PASSIVE NODE）

3）、PRCBOOT

4）、CLUSTER NODE检查两个NODE都为up状态

5）、CLUSTER RES检查所有process都为online

6）、telnet IP（ACTIVE NODE）

7）、PRCBOOT

8）、CLUSTER NODE检查两个NODE都为up状态

9）、CLUSTER RES 检查所有process是否都为online

10）、Exit

11）、ALLIP:ACL=; 确认告警是否消除。

告警信息(举例二)：

*** ALARM 644 A1/IO_DEV "SZBHLR65/HD/00/" 081210 0218

:AP SYSTEM ANALYSIS

:AP APNAME NODE NODENAME

: 1 SZHLR2AP1C A SZHLR2AP1A

:OBJECT COUNTER INSTANCE LIMIT V ALUE

:LogicalDisk % Free Space L

: <4 3.83

:END

告警产生原因及原理分析：

一、产生此类告警的原因是由于某个磁盘的空间达到预设的门限值时而产生。

APG40的硬盘有两类。一类是系统盘，每边（A边和B边）各一块，分为四个分区C: D: E: F:。另一类是数据盘，是三对硬盘作RAID1镜像。只有执行侧（ACTIVE）可以接入数据盘。数据盘的分区分为J: K: L: M: G: Q: Y: R: S: 。

APG40有一个内部监控磁盘空间使用的程序，根据目前的缺省配置，当所剩磁盘空间小于总分配空间的16％时，即会生成A2级告警。而小于4％时，即会产生A1告警。当剩余空间重新回到6％时，A1告警消除。而剩余空间回到18％时，A2告警消除。这个告警门限的设定没有特别的原因而且不对某一个磁盘分区有针对性。

随着APG40软件版本的不断升级，正常的系统文件对C:盘（共2GB）的占用会不断增加，从而导致会比较频繁地出现C:盘使用空间不足的告警。就目前软件版本的情况，需定期检查和删除一些不必要的系统日志文件，应该可以使C:盘的剩余可使用空间控制在360MB到400MB之间。从而可以达到消除告警的威胁。

从日常告警的频次统计，C: 盘，K:盘和HLR的L:盘会经常有空间告警现象的出现。

告警告警处理方法：

1）、对于C: 盘，一般只确认和删除一些临时的文件，如目录为：①、C：/TEMP下所有文件，②、C：/TEST下的所有文件；③、C:\acs\data\ftp\ mktrbuild下的所有文件；

2）、对于K:盘，一般是删除旧的ALOG文件；如K：/ACS/LOGS/ALOG/LOGFILE/下比较旧的ALOG文件（一个月前的文件）；

3）、对于L:盘，一般是删除旧的CP 备件文件，一般情况下，一个局只保存4个RELFSWn 的文件如RELFSW0、RELFSW1、RELFESW2、RELFSW99，如其它备份文件可删除；DEL RELFSWn

4）、在清理完临时文件后，C:盘的剩余可使用空间控制在360MB到400MB之间，但告警仍未能消除，可对产生告警的NODE 做一个REBOOT的操作；

5）、ALLIP：ACL=A2；核查告警是否已消除；

4、AP FILE PROCESSING FAULT

告警信息(举例)：

*** ALARM 102 A2/IO_DEV "PYFMSC63/JD/0/0" 0102 081208 0000

:AP FILE PROCESSING FAULT

:AP APNAME NODE NODENAME

: 1 PYG6MAP1C A PYG6MAP1A

:CAUSE

:FILE TRANSFER FAILED

:TRANSFER QUEUE

:ALOG

:DESTINATION SET

:OSSDESTALOG

:END

告警产生原因及原理分析：

统计文件、计费文件、ALOG文件（事件记录文件）的传送方式不同，其中统计文件、计费文件是被动地传送，不同的是计费文件是由计费中心通过FTP方式来取，统计文件则是在生成后通知OSS，OSS再通过FTP方式来取；ALOG文件是主动传送，直接FTP到OSS。

ALOG文件传送失败，APG40系统中的文件无法传到远端计算机服务器；一般有三种情况：1、网络临时故障（此类情况最多）；2、本地设置和定义的参数不正确；3、对端的参数设置及网络问题。

此类告警通常在OSS因故障连不上机后一般都会出现；在网络故障恢复后，通常使用指令人工重传文件后告警即会消除；如广州该故障告警比较多，经咨询是广州的OSS升级引起的，通常大面积的出现该告警一般都是网管侧的问题。

生成的ALOG文件先放入K:\ACS\LOGS\ALOG\LOGFILE（afpls -l ALOG可以查看其实际路径的源目录），ALOG文件满1M后自动传送到OSS对应目录，指令“afpls –ls ALOG”查看文件的传送情况， DELETE状态是已经成功传送并10080分钟后删除了（TIMER表示即将在多少分钟后删除）；FAILED状态是传送失败。告警发生后，不会自动消除，需要通过人工手动传送，alogfind –s afpfti可以查看人工重传的记录。

告警处理方法：

1)APLOC; 进入AP模式下

2)afpls –ls ALOG 查看ALOG文件传送情况，状态为failed的为传送失败文件。

3)afpfti –f ALOG 将传送失败的ALOG文件重传一次，传送成功故障将会消除。

4)afpls –ls alog 查看状态（STATUS）由FAILED变为SEND或READY，表示已经开始

重传

5)alist 需要等待几分钟后，确认文件是否传送成功告警消失。

6)exit

7)ALLIP:ACL=; 确认告警是否消除。

如果手工传送失败，可以尝试以下操作并派单专业室或地市公司处理：

8)cdhver OSSDESTALOG 看目的点状态，结果显示是否STATUS OK。

9)cdhls -l OSSDESTALOG 查看此路径的所有传输参数是否正确，同时可获得对应的对应

的IP。

确认本地交换机的设置没有问题，怀疑是到OSS的网络不通

10)ping x.x.x.x 检查网络是否通

案例：ping 对端的IP, 显示网络路径完全正常；后来注意到A3级的一个告警，是由于刚才那个A2级告警AP FILE PROCESSING FAULT引起的：

DATA OUTPUT, AP COMMON DESTINATION HANDLING, DESTINATION FAULT

DESTINATION

OSSDESTALOG

CAUSE

WRITE FAILURE

Problem Data

The connection to the remote host lost or write access denied

再分析上面的告警，确认了是因为AP 文件没有写到OSS的权限。综上分析可以确定是对端网管的设置问题，导致ALOG文件无法正常传送。所以应及时联系对端人员(网管组)协助处理。

备注：1、在检查本端问题时，可以尝试删除ALOG队列、重新定义ALOG队列，再用指令“cdhver OSSDESTALOG”检查状态是否OK，但是本端通常是没有问题的，此步操作不列出，不建议操作。

2、上述操作也包括AP2

5、AP SYSTEM CLOCK NOT SYNCHRONIZED

告警信息(举例)：

*** ALARM 263 A2/ IO_DEV "MMSM4B1R12/HD/0"U 080621 0710

:AP SYSTEM CLOCK NOT SYNCHRONIZED

:AP APNAME NODE NODENAME

: 1 MMSM4B1AP1C A MMSM4B1AP1A

:REASON

:DIFFERENCE BETWEEN CP AND AP TIME EXCEEDS 600 S.

:END

告警产生原因：

在APG出现此类告警的原因，一般是由于AP 系统同CP之间的时间不同步，两个系统之间的差值大于600S（10分钟）引起的，需要对AP的时间进行手动较对。

告警预处理：

1、检查CP 的时间

CACLP；

2、telnet到该网元，检查APG的时间, 确认与CP时间差值是否过大；

date /t

time /t

3、若确认是时间相差600秒，则登陆到网元的passive边，修改APG时间与CP 一致

date （修改的日期）

time （修改的时间）

4、在PASSIVE 边做完时间修改后，做一个PRCBOOT；

5、检查PASSIVE边状态为UP后，对ACTIVE 边倒边，使得ACTIVE边变为passive边，再进行一次时间修改，使得时间与CP同步

prcboot

date （修改的日期）

time （修改的时间）

6、检查、确认告警是否已消除

Allip：acl=；

6、ANALYSIS DATA FAULT

告警信息(举例)：

*** ALARM 695 A2/APT "GZSS16CN65/KD/0" 0695 080226 1125

:ANALYSIS DATA FAULT

:FCODE REASON

:4 LOOP IN ROUTE ANALYSIS AT RESTART OF ANALYSIS

:BNBR BO BO1

:8613900301769 58 58

:BNBC BNT BNT1

:139******** 1 4

:BSNB NAPIB NAPIB1

: 1 1

:ANBR AO AO1

:139******** 1 1

:ASNB ANT ANT1

: 4 4

: NAPIA NAPIA1

: 1 1

:RC RO INCROUTE OUTROUTE

:372 1 CTPPSI GZSA1AO

:REROUTING TONE EOS EO

:YES 1 1658

:TEST TCL EA PR LOD

: 8 0 0 0

:ISAT OSAT AL TMR WSIG

:0 0 0 0

:NA NRA RA ISTI ST

:1 0 0 0

:MST PLMN IWE SW ISK-TYPE :1 0 0 0

:TN ODR IGWT NS NAR

:0 0 0 0 0

:END

告警分析：产生此告警一般是由于做测试或系统发生重启后, 路由重选时所有备用路由电路拥塞，导致产生路由循环。

告警处理:

1) 对于此类告警,可参考ALEX中的OPI进行预处理，首先查看其中的FCODE和REASON，按照FC的不同，处理流程也不同。以下根据FC出现频率,由高到低叙述处理流程。

　FC=4,REASON=” (loop in routing analysis at restart of analysis)

　路由重选时所有备用路由电路拥塞，导致产生路由循环，可用命令ANFAR消除告警，若告警重复出现，则派单给资源配置室检查有无数据问题，数据无误由资源配置室转核心室检查是否硬件问题导致全局电路不可用或电路资源不足，需申请电路资源。

　FC=3 ,REASON=”(loop in B-Number analysis with analysis restart)

　B号码分析循环，可直接派单给资源配置室处理

　FC=5 ,REASON=”(loop in EOS analysis at restart of analysis)

　用命令ANFAR消除告警，若告警重复出现-，则派单给资源配置室处理。

　对于其他FC的，可用命令清除告警后，若告警重复出现，再派单给核心室处理。7、AUDIT LOG DEACTIVATED

告警信息(举例)：无

告警产生原因：主要是由于APG进行软件升级或是APG进行硬件更换的过程中，人工关闭ALOG功能；

告警预处理：

1、ALOGACT激活即可；

2、ALOGDEACT去激活

3、ALLIP；

8、AUDIT FUNCTION THRESHOLD SUPERVISION

告警信息(举例)：

*** ALARM 0098 A2/APZ "SZSS24CN65/KD/0"U 080715 1650

:AUDIT FUNCTION THRESHOLD SUPERVISION

:TEST 101

:END

*** ALARM 0098 A2/APZ "SZSS24CN65/KD/0"U 080715 1650

:AUDIT FUNCTION THRESHOLD SUPERVISION

:TEST 102

:END

*** ALARM 0098 A2/APZ "SZSS24CN65/KD/0"U 080715 1650

:AUDIT FUNCTION THRESHOLD SUPERVISION

:TEST 104

:END

*** ALARM 0098 A2/APZ "SZSS24CN65/KD/0"U 080715 1650

:AUDIT FUNCTION THRESHOLD SUPERVISION

:TEST 110

:END

告警产生原因：

此告警是PS、RS、DS以及有定义监视的SAE占用已达到事先定义的告警门限；

告警预处理：

对于TEST 101 是指PS空间告警；TEST 102 是RS空间告警；TEST 104 是指DS空间告警；TEST 110 是指SAE空间告警；这几种告警的处理方法、思路是一样的，下面以TEST 110的告警进行说明：

1、查询是哪一个SAE引起告警的；

AFTSP：TEST=110，LOG；

2、按扩SAE的步骤扩相应的SAE；（对于TEST XX提示SAE告警，用SAALI无效

果）

SAAII：SAE=XX，NI=YY；

3、检查告警情况：

ALLIP；

4、扩完SAE后，告警仍然存在或手工无法进行扩SAE，则电话专业室值班人员协助处

理；

5、对于CP40/50/55/60来说，做完扩SAE后，会引起CP STATE NOT NORMAL告警，

需要在话务闲时做一次人工备份。

9、BLOCKING SUPERVISION

告警信息(举例)：

*** ALARM 684 A3/APT "FSATR63/HB/0/0/"U 070510 1934

BLOCKING SUPERVISION

R LVB NDV BLO

ZSD2O 55 1114 55

END

*** ALARM 527 A1/APT "NHBMSC63/HB/0/0"U 070428 0930

BLOCKING SUPERVISION

R LVB NDV BLO

1MAIN0 32 64 64

END

告警产生原因：

中继闭塞监测告警，当路由中设备闭塞数达到告警门限值时产生该告警。

告警预处理：