- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
手册下载
故障处理手册
资料版本：5W103-20260122
Copyright © 2026 新华三技术有限公司 版权所有，保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
除新华三技术有限公司的商标外，本手册中出现的其它公司的商标、产品标识及商品名称，由各自权利人拥有。
本文档中的信息可能变动，恕不另行通知。
目 录
2.1 集群单个节点服务器硬件故障无法恢复，必须更换节点服务器
11.3 采用南向网络部署时，为什么有时被动采集接收不到数据？
11.4 为什么采集组件先安装，再安装itoa-syslog组件会失败？
11.5 为什么Matrix节点重建后部分分析业务功能不可用？
11.8 为什么网络正常，但网络设备详情页面接口指标有丢包现象？
11.13 为什么设备侧有对应指标数据，但是分析组件上对应指标展示数据为0？
11.15 为什么E6312之前及E6312版本升级到E6312之后的版本，网络健康度最低分指标个数有变化？
11.16 为什么变更分析中，有时会出现设备对比统计与对比详情信息不一致？
11.17 iFIT在端到端探测切换成逐跳探测时，为什么会出现部分周期数据丢包？
11.18 为什么健康度趋势图最新数据可能和网络健康数据可能不一致？
11.19 分析组件集群部署时，当发生节点下电或节点恢复时，为什么健康度等趋势图可能出现断点现象？
11.20 分析组件“无线用户详情-连接信息”中，当时间选择24小时内跨天时（比如前一天的14:00到当天的14:00及之前），为什么只返回前一天的数据？
11.21 为什么无线终端上线事件和深度解析的数据在个别情况下会关联不准确？
11.22 在iFIT全局配置中已删除的配置，为什么依旧会同步到全局配置列表中？
11.23 为什么在音视频分析详情页面中，当趋势图数据中有一段y值相等时，设置相同的阈值会导致线条同时显示两种颜色？
11.24 部署异地容灾，当容灾间长时间网络故障时，会有什么影响？
11.26 采用北向网络部署时，为什么SNMP Trap告警不影响网络健康度？
11.28 为什么同一个无线终端上线事件和协议回放的数据在个别情况下会关联不准确？
11.31 在配置了ERSPAN之后，为什么TCP流分析会话的SYN事件路径显示有n跳，但接口页面只统计了前n-1跳的端口信息？
11.32 在异常分析中，为什么功率异常的光模块在关机一段时间后重新启动时，会同时报告光链路亚健康故障和接入侧光模块故障？
本文档介绍了H3C SeerAnalyzer常见故障的诊断方法及处理措施。除非特别注明适用版本，否则文中命令行以E71XX及之后版本为基准。早期版本可能存在差异，建议在使用前先咨询技术支持人员。
当出现故障时，请尽可能全面、详细地记录现场信息（包括但不限于以下内容），收集信息越全面、越详细，越有利于故障的快速定位。
· 记录您所使用的H3C SeerAnalyzer版本、统一数字底盘版本、Matrix版本。
· 记录具体的故障现象、故障时间、配置信息。
· 记录完整的网络拓扑，包括组网图、端口连接关系、故障位置。
· 收集日志信息和运行信息（收集方法见收集故障运行信息）。
· 记录现场采取的故障处理措施及实施后的现象效果。
您可以通过如下步骤，收集SeerAnalyzer的运行信息。
(1) 在浏览器中输入统一数字底盘GUI的登录地址（格式为：http://ip_address:30000/central/index.html），回车后打开统一数字底盘GUI的登录界面。输入用户名和密码后，单击<登录>按钮进入统一数字底盘GUI首页。
(2) 在统一数字底盘GUI界面中，单击[系统>日志管理>运行日志列表]菜单项，进入运行日志列表页面，可进行如下操作：
¡ 通过“所在目录（相对路径）、“日期（起）”和“日期（止）”可查看指定目录和日期区间的全局日志或节点日志文件信息。
¡ 在搜索栏输入指定的文件或者目录名称，可搜索相应的日志。
¡ 勾选指定日志或勾选“全选”复选框，单击<导出>按钮，将导出的全局或节点运行日志信息保存到本地。
当故障无法自行解决时，请准备好设备运行信息、故障现象等材料，发送给H3C技术支持人员进行故障定位分析。
用户支持邮箱：[email protected]
技术支持热线电话：400-810-0504（手机、固话均可拨打）
集群中的某个节点因为硬件故障无法恢复，需要更换新的节点服务器。
造成故障的原因：集群节点服务器的硬件出现故障，导致节点服务器运行异常，且无法恢复。
故障处理步骤如下：
(1) 更换新节点服务器，并确保新节点服务器的主机名、用户名及密码与故障节点相同。
(2) 在新节点服务器中安装Matrix，具体请参见《H3C统一数字底盘部署指导》。
(3) 登录Matrix界面，在[部署>集群]页面下，单击故障节点右上角的
按钮，选择[重建]菜单项重建该节点，在弹出窗口中选择方式二进行重建：
¡ 方式一：单击上传与当前节点相同版本的软件包进行节点重建，并上传重建文件，单击<应用>按钮。
¡ 方式二：单击使用系统中原有的节点部署文件进行重建，单击<应用>按钮。
(4) 节点重建完成后，查看节点状态和所有Pod状态是否恢复正常，节点和Pod状态都正常表示集群数据和统一数字底盘数据都已恢复。
(5) 对于E71XX之前版本（包括E65XX、E63XX），需要在重装Master节点并重建之后在其他不需要重装的任意一个Master节点执行如下两个脚本。其中，$IP为新建节点的管理IP，否则itoa-collect-multi容器将无限重启
¡ 进入/opt/matrix/app/install/metadata/UCENTER/collection/scripts/fault_migration，执行sh -x faultMigration.sh $IP
¡ 进入/opt/matrix/app/install/metadata/SA/scripts/fault_migration/，执行./faultMigration.sh $IP
在[分析>分析设置>资源管理>资产管理>资产列表]页面，为资产绑定NETCONF协议模板后，NETCONF连通性状态仍显示为“否”。
造成故障的原因可能有如下几种：
· 设备与分析组件的南向主动采集地址不通。
· 设备侧SSH新增ACL访问控制策略时，未放通南向主动采集节点的地址。
· 设备侧带外或带内管理网络与分析组件南向采集网络之间存在防火墙（FW），FW未放行南向采集网络的地址、协议（TCP）及端口（默认830），同时需放通对应地址的ICMP协议。
· 设备侧与分析组件侧的NECONF账号密码不一致。
· 设备侧NETCONF连接账号携带ISP域信息，分析组件创建NETCONF协议模板未携带ISP信息
故障处理步骤如下：
(1) 检查分析组件主动采集Pod和设备之间的网络是否正常。
在南向单协议或南向双协议部署场景下，可在Matrix页面查看南向采集IP。
图2 单击Analyzer-Collector的详情图标
图3 查看南向采集IP
(2) 进入主动采集Pod内，ping纳管设备的管理IP。注意，E71xx及以上版本，执行ping时需通过busybox调用。
[root@sa003 ~]# kubectl get pods -n common-collect | grep init
itoa-collect-multi-initiative1-6f55df5cc6-tkc8v 2/2 Running 0 37d
kubectl exec -it itoa-collect-multi-initiative1-6f55df5cc6-tkc8v -n common-collect bash -c itoa-netconf
[root@itoa-collect-multi-initiative1-6f55df5cc6-tkc8v /]# busybox ping 65.1.1.2
(3) 如果ping不通，检查设备侧SSH Server配置中所引用的ACL是否已增加放通南向主动采集地址的规则；在集群环境中，需要放通3个主动采集Pod的地址。
(4) 检查设备与分析组件之间防火墙（FW）上的策略。建议先根据端口矩阵列表（发布版本配套资料），确认NETCONF主动采集需要放通的地址、协议和端口，同时放通对应地址的ICMP协议；在NETCONF协议连通前，会先发送ICMP探测报文。
(5) 检查分析组件统一采集的NETCONF协议模板账号和密码，是否与设备侧local-user下配置的SSH服务类型账号和密码保持一致。对“前期采集正常、运行一段时间后出现异常”的情况，需要重点核查设备侧是否存在定期修改密码的策略或运维习惯，并确认修改后是否及时同步更新到分析组件的NETCONF模板配置中。
(6) 进入[分析>分析设置>采集管理>统一采集>NETCONF]页面，查看NETCONF协议模板的配置详情。
图4 查看NETCONF协议模板
(7) 检查设备侧用于NETCONF连接的账号是否关联到正确的ISP域信息。在设备侧确认已创建相应的domain，并在该域下明确指定本地登录认证及本地命令授权方式。
图5 检查设备侧信息
(8) 如果上一步骤检查内容正确，则需进一步确认：分析组件中用于统一采集的NETCONF协议模板所配置的账号，同样携带并匹配正确的ISP域信息，以确保与设备侧的域配置保持一致。
图6 查看NETCONF协议模板
(9) 登录分析组件后台，通过k8s命令进入主动采集Pod内部，在容器命令行中手动发起对目标设备的SSH连接，验证是否能够正常登录设备。
[root@itoa-collect-multi-initiative1-6f55df5cc6-tkc8v /]# ssh [email protected] -p 830 -s netconf
Unable to negotiate with 55.0.0.10 port 830: no matching host key type found. Their offer: ssh-rsa,ssh-dss
注：E71xx及以上版本，命令行主动ssh连接时，提示“Unable to negotiate with 55.0.0.10 port 830: no matching host key type found. Their offer: ssh-rsa,ssh-dss”。需要在SSH后面加“-o HostKeyAlgorithms=+ssh-rsa”参数。
[root@itoa-collect-multi-initiative1-7754c4f585-s8dfj /]# ssh -o HostKeyAlgorithms=+ssh-rsa [email protected] -p 830 -s netconf
(10) 若完成以上排查与操作后问题仍未解决，请联系H3C技术支持工程师进一步处理。
在[分析>分析设置>资源管理>资产管理>资产列表]页面，为资产绑定SNMP协议模板后，SNMP连通性状态仍显示为“否”。
造成故障的原因可能有如下几种：
· 设备与分析组件的南向主动采集地址不通。
· 设备侧与分析组件侧的community团队名称不一致。
· 设备侧与分析组件的SNMP版本、认证加密模式不一致。
故障处理步骤如下：
(1) 排查配置是否一致：连接设备，进入system系统视图，执行display current-configuration | include snmp，核对设备上的SNMP配置是否与分析组件侧配置一致。
图7 查看设备上的SNMP配置
(2) 进入[分析>分析设置>采集管理>统一采集]页面，查看SNMP协议模板的配置详情。
图8 查看SNMP协议模板
(3) 网络问题排查：在设备侧和分析组件侧分别使用ping命令，验证二者之间网络是否互通。
(4) 进入主动采集Pod内，使用ping命令测试被纳管设备的管理IP连通性。
[admin@single ~]$ kubectl get pods -n common-collect | grep init
itoa-collect-multi-initiative1-7754c4f585-s8dfj 2/2 Running 0 2d2h
[admin@single ~]$ kubectl exec -it itoa-collect-multi-initiative1-7754c4f585-s8dfj -n common-collect -c itoa-snmp bash
[root@itoa-collect-multi-initiative1-7754c4f585-s8dfj /]# busybox ping 65.1.1.2
(5) 进入主动采集Pod的itoa-netconf容器内进行tcpdump抓包，观察是否能捕获SNMP报文，排查设备是否正常上送采集数据（抓取161端口报文）以及后台采集进程是否正常工作。
[admin@single ~]$ kubectl get pods -n common-collect |grep init
itoa-collect-multi-initiative1-7754c4f585-s8dfj 2/2 Running 0 2d3h
[admin@single ~]$ kubectl exec -it itoa-collect-multi-initiative1-7754c4f585-s8dfj -n common-collect -c itoa-netconf bash
[root@itoa-collect-multi-initiative1-7754c4f585-s8dfj /]# tcpdump -i any port 161
图9 tcpdump抓包
(6) 如果以上操作完成后故障仍无法排除，请联系H3C技术支持工程师。
设备纳管监控后，可能出现“网络健康度-概览”页面无健康度趋势数据、网络设备列表无健康评分，或全局拓扑中节点状态飘红等现象，通常出现在开局刚完成设备纳管后不久，或系统运行一段时间后出现。
进入[分析>分析设置>资源管理>资产管理>资产列表]页面，检查目标资产的SNMP连通性和NETCONF连通性，确认两项连通性均为“是”。若任一项为“否”，请参考NETCONF连通性异常问题和SNMP协议连通性否问题进行排查与处理。
图10 查看资产管理协议连通性
登录分析组件后台节点，执行kubectl get pods -n sa | grep -E 'node-kpi|itoa-health'检查相关Pod是否均为Running状态；如有异常 Pod，则执行kubectl logs -f -n sa ${podName}查看日志并根据报错信息定位问题，或直接到健康分析的日志存放目录/var/lib/ssdata/logcenter/Analyzer/health_analysis收集日志进行排查。
· 采用gRPC或NETCONF方式采集
执行kubectl exec -it -n service-software seamq-analyse-controller-0-0 bash进入Kafka容器，随后执行./seamq-console-consumer.sh --topic $topic --bootstrap-server localhost:9094 --from-beginning | grep ${ip}检查下述3个基础Topic的消息情况，确认是否有数据输出。
¡ Device_Boards
¡ Device_PhysicalEntities
¡ Device_ExtPhysicalEntities
· 采用SNMP方式采集
参考上一种方式的排查方法，将基础topic替换为snmp-data，观察是否消费到原始数据。
如消费Topic中无数据，说明设备原始数据未上送至分析组件，此时需排查设备侧或采集组件的日志，可在采集日志目录/var/lib/ssdata/logcenter/collector/NetconfCollector/中查看相关日志并定位问题。
若仅Device_PhysicalEntities或Device_ExtPhysicalEntities未采集到数据，而Device_Boards有数据，则根据经验多为设备上报的这两个采集项存在乱码导致。可在设备侧执行命令reset asset-info chassis清除设备的asset-info后，再重新采集即可解决。
(1) 若上一步骤中Kafka基础Topic消费正常，则需在Kafka中继续消费任务解析后的Topic：ndp_node_status_5mins_2d，确认是否有对应设备的数据输出。完整消费命令为./seamq-console-consumer.sh --topic ndp_node_status_5mins_2d --bootstrap-server localhost:9094 --from-beginning | grep ${ip}。
(2) 执行如下命令进入CK数据库。
[node1@root ~]# kubectl exec -it -nservice-software seasqlplus-sa-keeper-0 bash
[node1@root ~]# seasqlplus-client -h seasqlplus-sa --port 9000 -u ndp --password ili#20xgpN3Y_pasw
图11 进入CK数据库
(3) 执行如下SQL语句查询数据落库情况。
select * from influxdb_ndp_net_db.ndp_node_status_5mins_2d where asset_id='';
图12 查询数据落库情况
asset_id获取方式以谷歌浏览器为例：登录分析组件后，依次进入[分析>分析设置>资源管理>资产管理]页面，按下F12打开开发者工具，查找名为getAssetListByPage的接口请求，从其返回值中即可确认asset_id。
(4) 如果Kafka中存在数据，但通过SQL查询结果为空，说明Kafka落库异常，通常为kafka2ck存在问题。此时需联系技术支持工程师定位原因。
(5) 查询完成后可通过exit命令退出数据库。
在物理拓扑中，AC设备状态显示为红色（离线）；在网络健康度列表中，AC设备同样显示为不在线。
检查AC的WebSocket连接配置是否已正确设置，是否存在未配置或配置错误的情况。
cloud-management server domain 100.1.0.100 // IP地址为北向业务虚IP地址
cloud-management server port 17443 //端口为17443
检查AC与北向业务虚IP的连通性，并确认AC用于连接北向业务虚IP的源IP地址需与分析组件中纳管该AC的IP保持一致。
(1) 先在AC查询北向业务虚IP路由
dis ip routing-table 3.2.80.3 ：
Destination/Mask Proto Pre Cost NextHop Interface
3.2.80.0/24 Static 60 0 3.2.83.1 Vlan4094
(2) 再根据路由出接口查询AC源IP
interface Vlan-interface4094
ip address 3.2.83.20 255.255.255.0
(3) 带源ping北向业务虚IP
ping -a 3.2.83.20 3.2.80.3
AC为堆叠设备，但在分析组件中被按非堆叠设备方式纳管。
需先登录设备确认AC是否为堆叠设备，再在分析组件中核实该AC是否已按堆叠设备方式添加和管理。
若完成以上操作后故障仍未排除，请联系技术支持工程师进一步处理。
TCP流分析页面没有数据。
进入[分析>分析设置>任务管理]页面，检查TCP流分析相关任务是否已启动且状态正常。
图13 查看分析任务状态
如果任务已启动仍然无数据，请按如下步骤进行排查。
进入[分析>分析设置>采集管理>采集器管理]页面，查看先知采集器任务是否正常。
图14 查看先知采集器任务状态
若先知采集器列表中任务状态异常，显示为0/1（而非1/1），可能原因包括但不限于：
· 使用了非适配的采集网卡或操作系统，适配情况请参见分析组件部署指导。
· 在海光服务器上，采集网卡所在的NUMA节点未分配内存。
· 采集器服务器的CPU型号或核数不符合硬件配置要求。
· 采集网卡未配置正确地址。
· 采集网卡状态没有Running。
故障处理步骤如下：
(2) 采集器服务器的硬件配置备货要求，请参考分析组件部署指导中的相关说明。
(3) 参考对应版本分析组件的部署指导，按照采集器操作系统适配列表安装相应的操作系统及补丁。
登录采集器后台后，可通过如下命令查看内核版本。
[root@collect ~]# uname -r
5.10.0-136.12.0.86.4.nos1.x86_64
(4) 对于海光服务器，请确认采集网卡所在NUMA节点是否已分配内存；若未分配，需要增加内存条或调整现有内存条的插槽布局，具体推荐插法请咨询服务器维护人员。如何查看NUMA 节点内存分配情况，请参见分析组件部署指导。
(5) 请确保采集器服务器的CPU型号与核数满足分析组件部署指导中对硬件配置的要求。
(6) 请确保采集网卡已正确配置IP地址，并与在先知采集器中填写的采集地址保持一致。
登录采集器后台后，可通过执行ip add命令查看网卡IP。
图15 查看网卡IP
(7) 进入[分析>分析设置>采集管理>采集器管理]页面，查看采集器配置详情。
图16 查看采集器配置详情
(8) 请确保采集网卡已与交换机正确互联，且网卡链路状态为Running。
(9) 请删除当前先知采集器任务，重启服务器后重新添加采集器任务。
(10) 如果上述操作完成后故障仍无法排除，请联系H3C技术支持工程师。
RoCE服务器未上线。
确保分析器已经纳管服务器接入设备，且设备在分析器页面在线
进入[分析>分析设置>任务管理]页面，查看“RoCEAnalysis解析”任务状态是否为启用。
图17 查看分析任务
如果任务状态正常，请按如下步骤继续排查。
进入RoCE服务器后台执行ps -ef | grep agent命令查看Agent进程是否启动。
图18 查看Agent状态
如果Agent进程状态正常，请按如下步骤继续排查。
请登录RoCE服务器后台，执行systemctl status lldpd.service命令查看服务状态；如状态异常，请执行systemctl restart lldpd.service命令重启该服务。
图19 查看服务状态
如果服务状态正常，请按如下步骤继续排查。
请核对分析组件版本及已部署的Agent版本，确保二者与推荐版本保持一致。
(1) 请登录RoCE服务器后台，执行ibdev2netdev命令，检查对应网卡状态是否为UP。
图20 检查网卡状态
(2) 执行show_gids命令，检查网卡IP配置是否正常。
图21 检查网卡IP配置
如果上述操作完成后故障仍无法排除，请联系H3C技术支持工程师。
训前检查执行NCCL失败。
进入[分析>分析设置>任务管理]页面，查看“RoCEAnalysis解析”任务状态是否为启用。
图22 查看分析任务
如果任务状态正常，请按如下步骤继续排查。
进入RoCE服务器后台执行ps -ef | grep agent命令查看Agent进程是否启动。
图23 查看Agent状态
如果Agent进程状态正常，请按如下步骤继续排查。
请检查当前执行任务所使用的参数模板，核对各项参数配置是否合理。
图24 查看参数模板
如果上述操作完成后故障仍无法排除，请联系H3C技术支持工程师。
随流分析任务启动了但是页面无数据。
进入[分析>分析设置>任务管理]页面，查看“iFIT流分析”任务状态是否为启用。
图25 查看分析任务
可参考以下步骤进行排查：
(1) 时间同步检查：随流分析要求浏览器前端 PC、服务器（date）及设备（display clock）三者时间与时区基本一致，若一致则继续执行下一步，若不一致则以服务器时间为准调整PC和设备的时间与时区。
若调整前设备时间快于服务器时间，调整后需进入[分析>分析设置>任务管理]页面，手动先关闭再重新开启“iFIT流分析”任务。
(2) iFIT统计确认：检查设备上是否存在iFIT统计数据，并确认其统计时间与设备时间是否基本一致。
a. 首先确认iFIT实例名称，如下图所示（本例以“gwl”为例）。
图26 iFIT实例配置
b. 在首节点上执行display ifit instance instance_name命令，确认该实例的Flow ID信息。
图27 查看Flow ID信息
c. 在首节点、中间节点和尾节点上分别执行display ifit statistics device-id device-id flow-id flow-id命令，确认各设备是否存在iFIT统计数据。
图28 查询设备iFIT统计数据
d. 若设备上存在iFIT统计数据，可查看“Timestamp”字段，该字段可转换为实际时间，用于确定iFIT数据的统计时间。
e. 若无iFIT统计数据，或iFIT数据统计时间与display clock查询到的设备时间偏差较大，请联系设备产品侧进行处理。
(3) Telemetry配置确认：检查设备上iFIT采集路径中的Telemetry相关配置是否正确。
¡ 私标采集路径：
sensor path ifit/flowstatistics/flowstatistic depth 3
¡ 企标采集路径：
- sensor path insuitoam/flowinfo
- sensor path insuitoam/measurereport
· 上述两种采集路径在全网范围内必须统一配置，所有设备都需采用唯一且相同的采集路径。
· 私标采集和企标采集的详细配置方法及相关限制，请参考《AD-WAN承载网智能分析业务配置指导》文档中的说明。
(4) TCP连接检查：确认设备与分析组件之间的TCP连接建立状态是否正常，可使用display tcp或display ipv6 tcp命令进行检查。
若连接建立状态异常，请联系分析组件工程师处理。对于大多数应用，“ESTABLISHED”表示连接已经成功建立且处于正常通信中，是一种正常且健康的连接状态。
图29 使用IPv4地址纳管设备
图30 使用IPv6地址纳管设备
(5) 服务器后台抓包检查：在服务器后台使用tcpdump进行抓包，如果抓包中存在目的或源端口为TCP 50051的报文，则将抓取的报文导出，并共享给H3C技术支持工程师进行进一步分析处理。
NetStream流分析任务启动了但是页面无数据。
可参考以下步骤进行排查：
(1) 使用display ip netstream cache命令（查看IPv6流量需使用display ipv6 netstream cache命令）检查设备是否已采集到五元组流信息：若查询结果中存在五元组流信息，则继续执行下一步排查；若未查询到相关流信息，请参考下图检查设备上的NetStream配置是否正确，若配置正确，请联系设备产品侧处理。
图31 业务为IPv4时的NetStream配置
图32 业务为IPv6的NetStream配置
(2) 检查NetStream上送配置是否正常。
¡ 若是南向单协议或双协议部署，需保持设备上的以下配置一致，具体配置内容和示例请参见《AD-WAN承载网智能分析业务配置指导》。
- source接口地址必须与分析组件纳管的设备IP地址保持一致。
- host地址与纳管地址必须为相同类型的IPv4或IPv6被动采集IP地址。
¡ 当使用南向双协议部署时，还需确保采集组件的IPv4和IPv6网络网关均为可达状态。
(3) 服务器后台抓包检查：在服务器后台使用tcpdump进行抓包，如果抓包中存在UDP目的端口为9996的报文，请将相关抓包结果提供给技术支持工程师进行处理。
在用户健康度页面下没有有线用户数据。
进入[分析>分析设置>任务管理]页面，查看如下任务是否已启用。
· 用户定时统计任务
· 有线用户健康度分析
进入[分析>网络健康>网络健康度>概览]页面，在网络设备列表中查看认证设备是否在线。
grpc enable
telemetry
sensor-group s117 //配置传感器组集，事件类型
sensor path dhcpsp/dhcpuserevent
sensor path dot1x/dot1xauthtrace
sensor path maca/macauthtrace
destination-group d1 //配置目标组,名称自定义
ipv4-address 110.1.0.107 port 50051 vpn-instance vpn-default //配置采集器的地址和相关参数，IP地址配置为南向被动采集IP地址；如果是南北向网络合一部署，配置为北向业务虚IP地址。
subscription b //创建订阅, 关联传感器组和目标组，对应事件类型，不需要配置周期
sensor-group s117 //注意不能配置采集周期
destination-group d1
source-address 130.1.0.52 //IP为设备管理地址
display tcp
100.0.4.104:54668 3.2.15.11:50051 ESTABLISHED 1 0x000000000007c42
设备侧与分析服务器间互相使用Ping指令查看分析组件所在服务器与设备是否网络互通（在服务器侧进入SNMP所在的itoa-collect-multi的Pod中再Ping设备IP），如果Ping命令正常，则网络正常。
图33 查看设备间网络连通性
给资产配置SNMP、NETCONF协议模板，进入[分析>分析选项>资源管理>资产管理>资产列表]页面，在“设置协议”下拉框中选择“SNMP模板设置”或者“NETCONF模板设置”，单击“操作”区段的
。
图34 设置协议模板
问题现象：当采集组件网络选择南向单协议时，在采集Pod内能Ping通南向IPv4（或IPv6）网关；选择南向双协议时，在采集Pod内能同时Ping通南向IPv4、IPv6网关，即配置的网关需要真实存在。南向网关不通，会导致NETCONF、gRPC容器重启（统一数字底盘E0707及更低版本），当前采集节点不可用（统一数字底盘E0708及更高版本）。
解决方案：出现该问题时，需要调整网络配置，使南向网络网关可以正常工作。进入[系统>部署管理]页面，单击<网络配置>按钮进入“网络配置”页面，在该页面对于网络配置进行相关修改。
图35 网络子网信息
结果验证：
(2) 进入主动采集Pod内，使用Ping命令Ping网关地址，如下图所示可正常Ping通。
主动采集Pod连通性验证
(3) 进入被动采集Pod，使用Ping命令Ping网关地址，如下图所示可正常Ping通。
被动采集Pod连通性验证
问题现象：采集组件和itoa-Syslog组件均占用了宿主机514端口，这样如果先行安装了采集组件，然后再安装底盘itoa-Syslog组件，由于端口冲突进而导致底盘Syslog组件部署失败。
解决方案：需要删除重建采集组件中itoa-rsyslog pod 对应的svc资源，修改该Pod宿主机监听端口为50014。具体步骤如下：
(1) 登录到主节点后台，进入采集组件中itoa-rsyslog pod对应的svc资源yaml目录：/opt/matrix/app/install/metadata/UCENTER/collection/collection/collection/scripts/itoa-rsyslog/k8s-resources。
(2) 执行如下命令：
kubectl delete -f itoa-rsyslog-service2.yaml
kubectl create -f itoa-rsyslog-service.yaml
执行命令
问题现象：当有Matrix节点进行重建时，可能会存在分析业务部分功能不可用的情况。
解决方案：当节点重建后需要执行故障重建脚本，进行相关功能的恢复。
进入此时Matrix的主节点（主节点信息可以登录Matrix界面在[部署>集群]页面下查看）的/opt/matrix/app/install/metadata/SA/scripts/fault_migration/目录下，执行faultMigration.sh脚本，脚本的输入参数为重建节点IP地址，如下图：
图36 重建节点IP地址
问题现象：当有Matrix节点进行重建时，可能会导致部分采集Pod无法启动的问题。当节点重建后需要执行故障重建脚本，将采集相关文件同步至新建节点上，进行Pod的恢复。
解决方案：节点重建完成后，需要执行故障重建脚本，将采集相关文件同步至新建节点上，进行Pod的恢复。进入此时Matrix的主节点（主节点信息可以登录Matrix界面在[部署>集群]页面下查看）的/opt/matrix/app/install/metadata/UCENTER/collection/scripts/fault_migration/目录下，执行faultMigration.sh脚本，脚本的输入参数为重建节点IP地址，执行sh -x faultMigration.sh 重建节点ip 命令.
· 在选择结束日期为当前日期时，选择结束时间为“00：00：00”时，默认为当前时间。
· 在选择结束日期不为当前日期时，选择结束时间为“00：00：00”时，默认为“23：59：59”。
设备侧接口discards 有丢包统计，一般包含如下几类：
· VLAN相关丢包计数（例如VLAN过滤）
· 出方向过滤丢包，包括ACL过滤，STP阻塞、组播报文过滤、没有出端口等
· 端口队列丢包，包括一些端口限速，带宽保证等配置触发的丢包、端口流量打满导致的丢包、高速口往低速口打流导致的突发拥塞丢包等。
Discards丢包统计比较笼统，不具有参考意义，不能等同于设备业务实际丢包数，更具体的丢包原因可以查看流量转发丢包和缓存监控，进入[分析>健康分析>网络分析>网络健康度>队列]页面进行查看。
图37 缓存监控
对于接收包数，发送包数，接收丢包数，发送丢包数，接收错包数，发送错包数等累加的数值型指标（设备上送的是总数，分析组件计算的是单位时间内的数，从而形成趋势图）。当数值大到指标类型的最大值（如，Interger最大值，Long最大值），设备会从新开始计数。从而导致下一个周期上送的值会比前一个周期上送的值要小。此时分析组件无法区分是发生了反转还是人为手动清除导致的重新计数，会将此周期内的计数值记为0，会出现趋势图数据波动，如下图所示就是因为接收错包数设备采用的是INT计数，大量错包很容易出现反转，导致时常有趋势图的点数据为0。
图38 接收错包趋势图
分析组件内置90天预授权，在90天预授权期限内可使用全部功能。为了分析组件功能的持续使用，请尽快购买正式License并完成安装。
由统一数字底盘提供备份恢复功能，以方便在异常情况下，或者根据用户的要求回到系统某个配置数据的状态：
· 备份配置：选择[系统>应急管理>备份恢复]菜单，进入到备份恢复页面，在备份恢复页面中，单击<开始备份>按钮，选择产品，再单击<备份>按钮可生成备份文件，保存在统一数字底盘所在服务器上，如果配置了远端备份功能，则备份文件将同时保存到远端文件服务器。
· 恢复配置：在该页面中可通过两种方式进行配置恢复：
a. 通过上传备份文件进行配置恢复：
单击
选择本地的备份文件，并单击<上传>按钮。如果提示“上传成功”，表示备份文件上传成功。单击<开始恢复>按钮，进行配置恢复。
b. 通过备份历史列表进行配置恢复：
在备份历史列表中，单击指定备份记录“操作”区段的<恢复>按钮开始恢复。
目前有两种不同层面的高可靠性机制：
· 基于Kubernetes的主机集群，实现主机、管理网络层面的高可靠性。
· SeerAnalyzer自身的服务集群机制，实现北向业务处理层面的高可靠性。
分析组件设计时支持所有的设备类型和型号，但是对应的指标数据可能在某些设备上不支持上报，导致无法采集到数据，分析组件在处理设置为默认值0。
目前只支持SSH登录设备三次及以上才进行计数，其他情况不支持。因此，如果失败次数没有到达3次以上，不会对失败次数进行计数。
E6312之后的版本与旧版本最低分异常个数显示个数有差异：旧版本只支持显示1个，新版本可最多显示5个，是为了提供更多异常信息给用户。
该现象主要在于设备侧发生了异常重启，存在设备上送的增量表项数据与重启前上报的增量数据不一致，这种情况相当于增量数据丢失，那么在变更分析中展示的对比统计和对比详情会有不一致的情况，只影响设备异常重启后的第一次增量数据的对比结果。
该现象主要在于配置完成修改和设备iFIT统计数据上报之间存在时间差。分析器在修改完配置时，接收到的可能还是端到端的数据，当作逐跳的数据来处理，导致出现部分周期丢包的情况。大概会在4个探测周期后恢复正常。
如果网络健康度数据发生变化（如设备产生新故障或切换区域等），网络健康数据结合业务的实时数据和资产信息生成新的健康度，立即反馈网络状态，实时性高，而网络健康度趋势图最新数据通过定期5分钟业务数据定时统计生成，数据有延时，需要等下一个5分钟周期后两个仪表盘数据才能一致。
节点下电时，该节点上的采集任务、数据处理任务会重新迁移到其它节点上，在迁移过程中可能丢失数据，导致健康度等趋势图出现断点。
节点恢复后，部分采集任务、数据处理任务会迁移到刚恢复的节点上，实现负责分担，在迁移过程中可能丢失的数据，导致健康度等趋势图出现断点。
由于“无线用户详情-连接信息”会直接调用Cloudnet组件接口，当分析组件与Cloudnet在时间选择的设计上不一致时，该功能不支持24小时内的跨天选择（比如前一天的14:00到当天的14:00及之前，Cloudnet只会返回前一天的数据）。
图39 连接信息趋势
例如当AP重启时重置了接入序列号，会导致协议回放的数据和上线事件关联不准确。
图40 事件
全局配置同步操作会读取采集组件每30分钟周期性采集的数据。因此，如果在删除全局配置后立即单击<同步>按钮，可能会导致读取历史数据。请等待下一个采集周期后再进行同步操作。
是由于图表插件Highcharts的分区逻辑与渲染规则导致的。在实际图表中，如果存在一根值为4.4的线，它的下边界已经低于4.4。Highcharts在处理分区时，将小于4.4的部分渲染为了颜色1，大于4.4的部分渲染成了颜色2。由于线的中心为4.4，按照分区规则，它的下半部分小于了4.4，因而被渲染成了两种颜色。
在系统的其他分区图表中，通常会通过对实际值添加一个小于精度的偏差值，来避免出现此类情况。然而，由于此处阈值可以自由配置，且存在精度要求，在精度要求下没有有效的偏差值来规避此问题。另外，在实际场景中，y值不变的情况很少会出现，因此未对此问题进行处理。
图41 音视频分析趋势图
部署异地容灾时，当容灾间长时间网络故障时，导致容灾间数据差异大，影响容灾切换时的业务使用。
集群环境下，只支持单节点故障，不支持2个及2个以上节点同时故障。
采用北向网络部署时，不支持在网络健康度中分析设备SNMP Trap告警和生成对应的分析事件。
· OSPF邻居无法建立故障、BGP邻居故障、网络接入侧IP地址冲突故障不支持IPv6。
· 产生的告警格式只支持SNMPV1。
如AP重启会重置接入序列号等会导致关联不准确。
升级期间，由于网络数据无法正常采集或处理，随着时间的推移，会缓慢恢复。
需在后台执行脚本恢复业务。即：在Matrix界面完成节点重建：
(1) 分析组件重建：进入当前Matrix集群的主节点的/opt/matrix/app/install/metadata/SA/scripts/fault_migration目录，执行脚本sh faultMigration.sh $ip或者./faultMigration.sh $ip。$ip为替换节点的IP地址。
(2) 采集组件重建：进入当前Matrix集群的主节点的/opt/matrix/app/install/metadata/UCENTER/collection/scripts/fault_migration执行脚本faultMigration.sh $ip。$ip为替换节点的IP地址。
这是因为当前ERSPAN不支持为TCP报文提供设备出入端口的时间戳信息。每台设备上传至分析组件的时间是由采集器标记的时间戳，而TCP流分析在计算时延时，是利用两台设备之间的时间戳差值进行计算的。因此，当有n台设备时，只能计算出n-1跳的时延信息。接口页面显示的统计信息是基于每台设备的出端口情况，因此，仅能统计到前n-1跳的端口信息。
这主要是因为分析组件中存储的光链路信息可能会老化。当光模块重新启动时，由于分析组件尚未更新链路信息，可能会首先检测到并报告接入侧光模块故障。一旦链路信息被更新，分析组件可能会发现光链路的问题，从而报告光链路亚健康故障。这种情况下，无需特殊处理，接入侧光模块故障的报告会在超时后自动恢复。
该现象主要是由于iFIT监控流列表和拓扑的数据是异步存储的，导致存储顺序无法保证。在经过1到2个周期后，数据才会最终一致。
在执行卸载采集器节点操作时，若因网络异常或采集器节点密码变更等原因，导致分析组件无法远程登录采集器节点，卸载脚本将无法正常执行，进而导致采集器节点上原有的代理进程仍在运行，相关服务端口未被释放。此时，如需重新添加该采集器节点，系统将提示端口已被占用。
此时，需登录采集器节点执行如下操作：
(1) 执行如下命令查询代理程序的PID。
[root@collect19 ~]# ps -ef | grep data-collection-agent
图42 查询代理程序的PID
(2) 执行kill -9 PID命令，PID以3297496为例。
[root@collect19 ~]# kill -9 3297496
分析组件不支持第三方设备的纳管，尽管网管组件可以管理第三方设备，并且分析组件支持从网管组件同步资产信息，因此分析组件中会显示第三方设备，但分析组件仍无法对同步过来的第三方设备进行分析。
以尽快恢复系统为原则；
· 定位故障时，应及时采集故障数据信息，并尽量将采集到的故障数据信息保存在移动存储介质中或网络的其他计算机中。
· 在确定故障处理的方案时，应先评估影响，优先保业务的正常传送。
· 第三方的硬件故障，可查看第三方的相关资料或拨打第三方公司的服务电话。
· 如果无法修复故障或者解决故障，请联系邮箱：[email protected]或热线电话：400-810-0504（手机、固话均可拨打）获取技术支持。
支持
