概述
本文介绍NPM页面出现延迟或者没有数据的情况的排查步骤和可能问题的解决方法。
知识点
NPM的数据流向和各功能的数据来源如下图:
排查和解决方案
数据延迟或者无数据的排查方向:
pktminer→ dp→ worker→ exporter
首先要找到【延迟初始的时间点】,即DP最初堵满的时间或NPM最初延迟的时间
如果是无数据,请先确认npm/npmweb/smartprobe console是否有进程异常
pktimer:通常pktminer存包是不会出现延迟现象的,如果存包性能不够查看/opt/smartprobe/var/log/pktminer_v2_stderr.log会有IODrop,如果有IODrop参考【高性能版SmartProbe IODrop调优方案】
dp:smartprobe服务器上执行>spcd dplog,查看dp_default-cache.log,查看是卡在哪个环节
如果卡在exportPkts环节,那么是卡在输出到NPM,需要后续排查NPM是哪里卡,参考步骤#3和#4
如果是卡在前面ntrPkts和ntaPkts,那么是dp处理数据处理不过来,需要调整dp参数或者减小流量
卡在ntrPkts:减小/opt/smartprobe/etc/system/local/dp.xml中max_flow_count的值
卡在ntaPkts:减小/opt/smartprobe/etc/system/local/dp.xml中各nta.group中max_unit_count的值
worker:主要查看/opt/npm/var/log/vp_worker_ethx_stderr.log
查看当前处理的ts时间和系统时间是否有延迟,如果有延迟且top中各worker进程占用cpu接近100%,可能是worker处理不过来,需要增加worker数量(/opt/npm/etc/system/local/dataflow.xml)
lowcap表示链路视图和设备视图的数据,spv表示服务路径图的数据
判断是否为worker的问题可以结合#4中exporter的日志
exporter:主要查看/opt/npm/var/log/vp_exporter_ethx_stderr.log
查看elapsed时间是否很长,如果很长,则是插入mongo慢,插入mongo慢有两种可能:
mongo当前有大量慢操作,有长时间的查询
插入mongo的数据量过大导致exporter处理不过来:减小dp.xml中runtime.nta.group.target=worker的max_unit_count的值
exporter中可以看到收到worker的数据的ts,如果收到的ts时间和日志中系统时间相差很大,则worker处理很慢,参考#3
如果视图数据不延迟,仪表台数据延迟:vp_alert → vp_sink → vp_dashboarder
查看上述日志是否有延迟,增加有延迟的进程的进程数(/opt/npm/etc/system/local/dataflow.xml)