ZMC Heartbeat Error心跳告警排查

    ZMC心跳问题常见原因：
    1，网元所在ZMC客户端没有配置探针，每个客户端至少需要配置一个探针才能发送心跳。
    2，网元所在客户端进程zmcagent和zmc_daemon没有启动。
    3，告警网元的ZMC客户端机器时钟跟ZMC Server端时钟不一致。
    4，告警数量太大时服务端心跳会丢失，JMS服务出现异常，导致客户端收不到心跳。
    5，ZMC版本太老，版本缺陷没有修补，需要升级到最新版本。
    6，检查这个网元agent2client下面的NM_HEART    文件内容否正常更新，这个文件记录了client和server心跳交互的时间，如果这个时间一直没有更新，那是客户端上传有问题。
    7，检查客户端日志（zmcagent/control/agent_probe_app.log），是否正常处理这个NM_HEART    文件，可以通过client日志查看。
    8，数据库出现性能问题，告警入库慢导致JMS消息积压，客户端正常，但是依然大面积心跳丢失。
    9，卸载了客户端以后，页面上还是会显示没有心跳告警，这种情况是因为缓存的原因，可以忽略。
    10，重启ZMC服务后需要重启客户端agent，否则也可能会导致心跳丢失，这个部分需要考虑产品提升。
    11，License和Project ID不一致会导致无法生成正常的agent.xml文件，所有客户端zmcAgent进程无法启动运行，导致类似心跳丢失的结果（Probe task running error）。
    12，客户端出现打开文件问题，使用lsof命令查看到太多的打开文件，重启agent后解决。
    13，ZMC服务器没有安装客户端，或者zmcAgent进程没有启动，会导致大面积心跳异常。
    14，ZMC服务器到客户端的心跳丢失，会导致大面积心跳异常。
    15，卸载删除客户端之前没有清理数据，这种情况可以忽略。

    ZMC心跳问题排查过程：
    1，检查NM_NE_HEART表的Update时间是否正常更新（select sysdate,h.* from nm_ne_heart h where h.app_name in(&appenvid);）；如果有记录并且在更新，那检查时钟同步，或检查探针处理性能。

    2，检查客户端日志有没有生成心跳信息，zmcagent/control/logs/agent_probe_app.log 查找 DEBUG c.z.z.z.a.p.b.MessageSender—> Parsing file[/tt/zmc_agent/control/probedata/swap/NM_HEART

    3，检查客户端日志有没有发送心跳信息， zmc_agent/control/logs/agent_app.log 查找 DEBUG c.z.z.z.c.a.JMSClient—> Send [Event = [HEARTBEAT_AGENT_REPORT],

    4，有可能是采集太多的KPI数据，系统来不急处理，检查zmc_agent/control/logs/agent_probe_app.log日志，两次NM_HEART之间是不是有太多的探针，这种情况下建议分散一些探针。

    5，尝试重启客户端进程，客户端机器上$HOME/zmc_agent/daemon/执行 ./daemonadmin.sh restart重启后观察是否恢复正常，这种方法适用于客户端zmcagent进程异常挂起的场景。

    6，检查配置的探针没有Apply，客户端没有找到 zmc_agent/control/probedata/agent.xml文件，或者比较客户端和服务器端的agent.xml是不是最新同步的。

    7，重启客户端zmcAgent进程：停客户端zmcAgent，然后删除 zmc_agent/control/agent.id，再启动zmcAgent进程，让程序自动注册。

    8，检查客户端和服务端的时钟是否同步，相差超过5分钟会导致程序判断超时。

    9，检查 客户端日志记录，搜索LONG TIME字样，是否存在探针执行慢导致客户端任务卡死的情况，针对执行效率低的探针做具体分析。

    10，检查agent_probe_app.log日志中有没有Pending Message Number of Queue [ZMC.KPI] Over，这个队列太大会导致服务端不发心跳，然后客户端就暂停发数据，心跳就异常。数据库里 所有alarm code 为 31038 是 nm_alarm_cdr记录，日志中存在Pending Message Number of Queue [ZMC.KPI] Over 1000，服务端发心跳是5分钟发一次，我们现在只要队列的数量超过1000 服务端就不发心跳。

    11，因为KPI数据量太大导致心跳超时的，KPI可以考虑Summary功能减少上传数据量，分析下哪个KPI送得多，把该KPI Summary设置成Y，每次采集会按照这个合并。

    12，关闭Agent/Server的日志级别，打印日志太多 影响性能。

    13，检查一个机器用户下是不是安装了多个客户端，检查 ps -fu pcrf|grep zmcDaemon，或者执行命令find ./ -name agent.id查找是否存在两个agent.id。不可以在一台机器的同一个用户上部署两个及以上的客户端，否则会产生冲突并导致心跳丢失。

    14，检查ZMC的版本号，是否升级到最新版本，修补了以前版本的缺陷。

    15，检查服务端日志server_app.log，搜索“[ServiceName]:InsertKPIData”，通常入库不应该超过100ms，如果发现其中出现了类似“[ServiceName]:InsertKPIData [Time]:2017-06-15 22:38:19 [Cost]:1387ms”这样高Cost的日志，说明数据库存在性能问题，可能会导致消息积压，最终导致服务端心跳异常。

    16，ZMC客户端都已经卸载了，页面上还是会显示，信息保留2小时，2小时后会消失，卸载了客户端就行了，数据库表里面不要手工去删数据，可以忽略。

    17，客户端探针出现打开文件问题，使用lsof|grep “KPI”等命令查看到太多的打开文件，不同进程和线程处理相同的文件导致异常（比如probedata/temp/KPI_History.ConnInfo.dat文件），重启agent后即可解决，重启命令为进入control目录后执行./agentadmin.sh restart。

    18，重启ZMC Server服务，对于无法排查和定位的问题，可以尝试先重启ZMC服务进程。