上述操作无效，则需派单给专业室做进一步的处理；
16、SOFTWARE ERROR
告警信息(举例)：
*** ALARM 723 A2/APZ \ SOFTWARE ERROR END
*** ALARM 376 A3/APZ \ APPLICATION DETECTED SOFTWARE ERROR END
告警产生原因：软件运行出错，有系统软件和应用软件。交换局任何时候都有大量的软件在运行，偶尔一两个运行出错很正常，在没有伴随SAE拥塞等告警时，可按下面方法处理。 告警处理方法：
1、 或SYRAE:RECTYPE=APPLERR; 用于application detected software error告警 3、 17、WNMS连接网元告警 告警信息(举例)： *** ALARM 8881 A1/APT \:网元: 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 \ 1652 :AP DIAGNOSTIC FAULT :AP APNAME NODE NODENAME : 1 SZSS34AP1C B SZSS34AP1B :ERROR IN ACS_USA_SyslogAnalyser :END 告警产生原因：一般APG系统本身存在某些硬件或软件故障，引起USA频繁地记录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 \ 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、 cluster node 检查两个NODE状态 3、C:\\>cluster res 检查cluster的Resource状态 4、C:\\>cluster res|findstr –ive online 列出状态异常的Resource(也可由上一步得到) 5、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 \ 1447 :AP SYSTEM ANALYSIS :AP APNAME NODE NODENAME : 1 SDMSC5AP1C A SDMSC5AP1A :OBJECT COUNTER INSTANCE LIMIT VALUE :Memory Available Bytes <104857600 91574272 :END 告警产生原因及原理分析： 一、对于内存告警，通常是软件问题，由于某些进程长时间占有内存而没有释放，如控制话统的进程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 \ 0218 :AP SYSTEM ANALYSIS :AP APNAME NODE NODENAME : 1 SZHLR2AP1C A SZHLR2AP1A :OBJECT COUNTER INSTANCE LIMIT VALUE :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； 2）、对于K:盘，一般是删除旧的ALOG文件；如K：/ACS/LOGS/ALOG/LOGFILE/下比较旧的ALOG文件（一个月前的文件）； 3）、对于L:盘，一般是删除旧的CP 备件文件，一般情况下，一个局只保存4个RELFSWn的文件如RELFSW0、RELFSW1、RELFESW2、RELFSW99，如其它备份文件可删除； DEL RELFSWn 4、AP FILE PROCESSING FAULT 告警信息(举例)： *** ALARM 102 A2/IO_DEV \: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升级引起的，通常大面积的出现该告警一般都是网管侧的问题。