- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
手册下载
H3C SeerAnalyzer-NPA
故障处理手册
资料版本：5W301-20230508
Copyright © 2023 新华三技术有限公司 版权所有，保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
除新华三技术有限公司的商标外，本手册中出现的其它公司的商标、产品标识及商品名称，由各自权利人拥有。
本文档中的信息可能变动，恕不另行通知。
2.4 Logstash-dialog-file Pod状态为crashLoopBackOff
3.1 异常断电导致使用GlusterFS存储的业务POD长时间无法启动
5.3.2 故障处理步骤（仅适用于E61xx、E62xx版本）
本文档介绍 SeerAnalyzer-NPA常见故障的诊断及处理措施。
当出现故障时，请尽可能全面、详细地记录现场信息（包括但不限于以下内容），收集信息越全面、越详细，越有利于故障的快速定位。
· 记录您所使用的Unified Platform版本、SeerAnalyzer版本、Oasis版本。
· 记录具体的故障现象、故障时间、配置信息。
· 记录完整的网络拓扑，包括组网图、端口连接关系、故障位置。
· 记录现场采取的故障处理措施及实施后的现象效果。
请通过如下步骤收集SeerAnalyzer操作日志、系统日志和运行日志。
· 方式一：
a. 在浏览器中输入统一数字底盘的登录地址”http://ip_address:30000/central”，其中“ip_address”为配置的北向业务虚IP。输入操作员名称和密码（默认用户名admin，密码为Pwd@12345）后，单击<登录>按钮，进入统一数字底盘主页面。
b. 进入统一数字底盘主页面后，单击<系统>菜单，进入系统页面。
c. 单击[日志管理]菜单项，打开日志管理子菜单项，包括操作日志、系统日志、运行日志的配置和列表，单击日志列表菜单，进入对应的日志列表页面，可以按条件查询和导出。
图1-2 操作日志列表页面
图1-3 系统日志列表页面
图1-4 运行日志列表页面
· 方式二：
后台搜集，通过ssh工具连接节点后台，日志路径如下：
cd /var/lib/ssdata/logcenter/Analyzer //该路径下是NPA分析组件、流处理任务等服务的日志路径
cd /var/lib/ssdata/logcenter/SA//该路径下包含分析平台组件以及公共服务日志路径。
SeerAnalyzer数据保存在各个节点的/sa_data目录中，该目录保存了PostgreSQL、Kafka、Zookeeper、Redis、Vertica等数据，在进行可能破坏数据完整性的故障恢复操作时，需要提前备份保存。
当故障无法自行解决时，请准备好设备运行信息、故障现象等材料，发送给H3C技术支持人员进行故障定位分析。
用户支持邮箱：[email protected]
技术支持热线电话：400-810-0504（手机、固话均可拨打）
通过[系统>系统维护>容器化平台>平台概览]查看平台概览页面。
图2-1 平台概览页面
通过平台概览页面可以查看当前产品、节点的状态，以及POD的工作负载TOP排名，若节点状态（例如内存利用率、磁盘利用率异常）出现异常，会在节点状态中标红显示；若POD健康度不为100，或者POD重启次数过大，会在工作负载状态TOP5和应用统计图中显示出来。
通过[系统>系统维护>容器化平台>平台资源] 选择SeerAnalyzer产品，查看POD状态。
图2-2 平台资源页面
查看列表中POD的状态，正常运行中的POD若出现CrashLoopBackOff状态，则表示对应POD的状态异常。也可通过远程登录服务器，使用kubectl get pod -n sa命令查看namespace为sa的POD，状态判断同上。
(1) K8S会自动重启POD，短暂等待POD能否恢复。
(2) 也可以通过以下命令手动删除POD，使其重启，短暂等待POD能否恢复。
kubectl delete pod pod-name -n sa
(3) 如果通过以上步骤也不能恢复，请执行以下命令收集POD日志和信息，联系技术支持工程师。
kubectl logs pod-name -n sa
kubectl describe pod pod-name -n sa
通过[系统>系统维护>容器化平台>平台概览]查看平台概览页面。发现有Pod长时间处于Terminnating状态。通常出现该故障有两种情形：
· 情形一：安装iso镜像过程中，主机名未修改，系统安装完成后手动通过hostname命令修改主机名，hostname命令只是用于临时修改主机名，所以如果节点出现重启，会导致无法正确读取到主机名。
· 情形二：相同POD重复启动，导致其中一个POD状态为Terminnating。
(1) 后台执行kubectl get node命令，查看Matrix节点状态，如下图所示：
图2-3 Matrix节点状态
(2) 如果Matrix节点状态为Ready，表示状态正常，且POD长时间处于Terminating状态，可通过命令kubectl get pod –A |grep pod_name，pod_name为pod名称的前缀，检查是否有重复的Pod存在，如果有可以通过以下命令手动删除POD。
kubectl delete pod pod-name -n namespace --force
(3) 如果Matrix节点状态不是Ready，表示Matrix节点异常。可执行cat /etc/hosts命令
命令查看主机名是否正常，如不正常可通过vim /etc/hosts修改主机名，如果主机名展示正常，请联系技术支持工程师。
(1) 通过[系统>系统维护>容器化平台>平台概览]查看平台概览页面，可以看到itoa-collect-multi1-xxxx-xx、itoa-aiecn-xxxx-xx、sa-asset-xxxx-xx等pod在不断重启。后台通过命令kubectl get pod –A |grep -v Running可以查看到上述几个pod状态均为CrashLoopBackOff状态。
(2) 再通过kubect describe pod itoa-collect-multi1-xxxx-xx -n common-collect，查看最后几行信息输出，能够看到如下报错：
Err in getting k8s network from pod: GetPodNetwork: failed getting the delegate: getKubernetesDelegate: failed to get network resource
(1) 本案例只适用于E62XX之后版本，E61XX版本采集组件未独立。
(2) 确认采集组件Analyzer-Collector-E07XX_x86_64.zip的安装方式，是否是在Matrix管理页面https://IP:8443/matrix/ui下进行安装的。
(3) 采集组件需要在http://IP:30000/页面[系统>部署管理]页面进行安装，并且对于网络方案有要求，NPA场景下，网络方案需要选择为“南北向网络合一”。如果在Matrix管理页面安装，没有网络方案的选项，进而导致上述故障。
(4) 登录Matrix管理页面https://IP:8443/matrix/ui，在[部署>应用]菜单下，找到 Collector组件，并点击卸载按钮，如下图所示：
图2-4 Matrix应用部署页面
(5) 卸载完成后，登录http://IP:30000/，在[系统>部署管理]页面，点击进行“安装”按钮，然后在组件选择页面，点击“公共服务”选项，展开选项中会默认勾选“采集器”，确认采集组件的版本、以及“网络方案”勾选为“南北向网络合一”，如下图所示。
图2-5 分析组件部署管理页面
(6) 勾选完成后，点击“下一步”，后续配置无需修改，继续点击“下一步”然后进行部署。
通过[系统>系统维护>容器化平台>平台概览]查看平台概览页面。发现有Logstash-dialog-file Pod长时间处于crashLoopBackOff状态。并且重启pod无法恢复。
(1) 该问题主要是出现在统一数字底盘E0613H05版本，是由于gluster缺少global-diaglog存储卷。Logstash-diaglog、log、filetransfer这几个Pod可能会处于异常状态。可以升级到E0613H07版本解决。
(2) 如不具备升级条件，可后台手动修复，具体操作如下：先通过北向虚IP连接后台，执行如下命令
[root@npa opt]# cd /opt/matrix/app/install/metadata/gluster/gluster/scripts/tools/
[root@npa tools]# ls
[root@npa tools]# sh volume.sh create global-diaglog 80 service-software
图2-6 手动修复
异常断电恢复后，通过kubectl describe pod -n [POD所在命名空间] [异常POD名称] 命令查看未启动POD的信息，一直出现如下，传输端点未连接并提示挂载失败的日志。
[2020-11-15 23:37:08.135138] E [MSGID: 108006] [afr-common.c:5313:__afr_handle_child_down_event] 0-heketidbstorage-replicate-0: All subvolumes are down. Going offline until at least one of them comes back up.
[2020-11-15 23:37:08.143572] E [fuse-bridge.c:5298:fuse_first_lookup] 0-fuse: first lookup on root failed (传输端点尚未连接)
Warning FailedMount 57m kubelet, m2 MountVolume.SetUp failed for volume "db" : mount failed: mount failed: exit status 1
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/84928abc-9a97-45a8-a274-326a24a9696d/volumes/kubernetes.io~glusterfs/db --scope -- mount -t glusterfs -o auto_unmount,backup-volfile-servers=100.8.1.1:100.8.1.2:100.8.1.3,log-file=/var/lib/kubelet/plugins/kubernetes.io/glusterfs/db/heketi-676b4d7996-26swm-glusterfs.log,log-level=ERROR 100.8.1.2:heketidbstorage /var/lib/kubelet/pods/84928abc-9a97-45a8-a274-326a24a9696d/volumes/kubernetes.io~glusterfs/db
Output: Running scope as unit run-4943.scope.
[2020-11-15 23:37:09.251653] E [glusterfsd.c:828:gf_remember_backup_volfile_server] 0-glusterfs: failed to set volfile server: File exists
Mount failed. Check the log file /var/lib/kubelet/plugins/kubernetes.io/glusterfs/db/heketi-676b4d7996-26swm-glusterfs.log for more details.
使用GlusterFS存储的业务的POD：
· 分析组件命名空间：itoa-app-manager、itoa-collect-multi1、itoa-collect-multi2（集群）、itoa-collect-multi3（集群）、itoa-task-manager
· default命名空间：Spark任务EcnBatchParse启动的业务pod(名称包含ecnbatchparse)
(1) 通过kubectl get po -A |grep glusterfs查询GlusterFS相关的POD名称及其所在的命名空间。
图3-1 查询GlusterFS相关的POD
(2) 通过kubectl命令删除所有glusterfs的POD，kubectl delete po -n [命名空间] [Pod名称] 。
kubectl delete po -n glusterfs-example glusterfs-2z45v glusterfs-q5d8l glusterfs-qzq87
(3) 等待glusterfs的POD重启成功。
(4) 如果POD重启且状态正常后，正常状态如图3-1所示，查看之前未启动的业务POD是否启动成功。
(5) 如果步骤(4)里的业务POD通过kubectl describe命令查看仍出现问题描述中的现象。请重启节点，重新按步骤1-4操作中查看业务POD是否正常启动。
(6) 如果上述操作完成后故障仍无法排除，请联系技术支持工程师。
异常断电恢复后，发现后续无法创建或删除GlusterFS存储卷。
(1) 通过kubectl get pod -A |grep glusterfs查询GlusterFS相关的POD名称及其所在的命名空间。
图3-2 查询GlusterFS相关的POD
(2) 通过以下步骤依次进入所有的GlusterFS的POD来确定是否存在异常。
a. 进入容器（kubectl exec -it -n [命名空间] [POD名称] bash）
例如kubectl exec -it -n glusterfs-example glusterfs-x7h4g bash
b. 进入容器后，执行ip addr命令查看该容器的IP ，如下图节点名称为m1，IP为2000:8::130
图3-3 进入GlusterFS容器查看IP
c. 在容器内再执行gluster peer status命令查看peer状态，如发现hostname为当前节点名或IP的peer则表示出现了异常。如下图发现m1的节点出现了hostname为m1的peer
图3-4 查询GlusterFS异常
(1) 通过kubectl get pod -A |grep glusterfs查询GlusterFS相关的POD名称及其所在的命名空间。
图3-5 查询GlusterFS相关的POD
(2) 通过kubectl exec命令进入异常的GlusterFS的POD（kubectl exec -it -n [命名空间] [POD名称] bash），例如：kubectl exec -it -n glusterfs-example glusterfs-x7h4g bash
(3) 进入容器后，执行ip addr命令查看该容器的节点名和IP ，如下图节点名称为m1，IP为2000:8::130
图3-6 进入GlusterFS容器查看IP
(4) 在GlusterFS容器中通过gluster peer status查看peer节点， hostname为当前节点名或IP的peer为异常peer，记录与其对应的UUID。例如图中hostname为m1的peer为异常peer
图3-7 查看GlusterFS节点UUID
(5) 在该容器中，通过rm –rf命令在/var/lib/glusterd/peers/删除与该UUID同名的目录。
图3-8 删除目录
(6) 在该容器中，通过vi命令修改/var/lib/glusterd/glusterd.info中的uuid的值为4）中记录的UUID
vi /var/lib/glusterd/glusterd.info
图3-9 修改UUID
(7) 在该容器中通过systemctl restart glusterd命令重启GlusterFS服务。
(8) 重启后，在容器中通过gluster peer status命令查看是否有出现如下情况，如果出现就继续下一步操作，反之如果还是显示问题现象，请重新确认上述步骤1-7是否修改正确，若修改有误，请重新修改。
图3-10 查看GlusterFS节点peer
(9) 进入使用GlusterFS存储的容器确认，数据是否正常写入。
(10) 如果上述操作完成后故障仍无法排除，请联系技术支持工程师。
(1) 分析组件大量页面显示“无数据”。
(2) 登录任一节点后台，执行kubectl get pod -n sa | grep vertica，发现verticalaunch的两个POD状态为CrashLoopBackoff，且不断重启。
图3-11 查看vertica pod状态
(3) 执行以下命令，查看vertica数据库状态，发现vertica数据的库的状态为down。
# su dbadmin
$ admintools -t view_cluster
(4) 执行以下命令，尝试启动vertica，但是仍然失败。
$ admintools -t start_db -d lion -p dbadmin@h3c
(5) 进入admintools页面，通过下述步骤也无法启动vertica。
$ admintools
图3-12 vertica admintools工具窗口
该故障表现为vertica数据不能启动，通常原因是异常断电后，vertica出现文件损坏无法启动。执行以下步骤，对vertica进行恢复。
(1) 以root用户身份登录每一台节点，停止每一台节点的vertica节点检测脚本
# sed -i 's/^[^#].*check_ConsumerState.sh*/#&/g' /etc/crontab
# sed -i 's/^[^#].*check_NodesStateAndLocks*/#&/g' /etc/crontab
(2) 在其中一个vertica节点执行UNSAFE 数据库启动 。命令如下：
# su dbadmin
$ admintools -t start_db -d lion -p dbadmin@h3c –U
图3-13 查询vertica服务状态
(3) 连接vertica数据库操作，执行恢复动作。
$ admintools -t connect_db -d lion -p dbadmin@h3c
图3-14 后台连接vertica数据库
lion=> SELECT do_tm_task('abortrecovery', '');
图3-15 执行恢复命令
(4) shutdown vertica数据库，并\q 退出数据库模式。
lion=> select shutdown('true');
图3-16 执行停止命令
图3-17 退出数据库
(5) 以normal模式启动vertica数据库
$ admintools -t start_db -d lion
图3-18 启动lion数据库
(6) 使用root用户恢复每一台vertica节点检测脚本
# sed -i '/^#.*check_ConsumerState.sh/s/^#//g' /etc/crontab
# sed -i '/^#.*/check_NodesStateAndLocks.sh/s/^#//g' /etc/crontab
(7) 查看vertica的状态，若为UP，则表示vertica已启动。
# su dbadmin
$ admintools -t view_cluster
图3-19 查看数据库集群
(8) 如果上述操作完成后数据库仍无法启动，请联系技术支持工程师。
kafka2vertica消费任务连续运行多天后，消费中断，分析组件“应用分析”页面及子页面均显示无数据。通过SSH连接分析组件后台可以发现vertica-launch的相关pod在反复重启，在分析组件后台上手动启动消费任务，操作步骤如下（SA_HOST_IP需要替换为安装了分析组件的服务器IP地址）：
cd /tmp
cat >kafka2vertica.conf<<EOF
# The configuraton options for the kafka2vertica scheduler.
username=dbadmin
password=dbadmin@h3c
dbhost= SA_HOST_IP
dbport=5433
config-schema=kafka2vertica
EOF
/opt/vertica/packages/kafka/bin/vkconfig launch --conf kafka2vertica.conf
待上述命令执行完后，查看日志/opt/vertica/log/vkafka-sched.log，日志中报错No projections eligible to answer query,相关日志内容如下：
com.vertica.solutions.kafka.scheduler.config.ConfigurationRefresher::Main [INFO] Stopping Configuration Refresher
2021-01-25 19:20:17.603 com.vertica.solutions.kafka.util.ConnectionUtil::Main [ERROR] Releasing lock on leadership and reapplying: Caught unrecoverable exception.
java.sql.SQLSyntaxErrorException: [Vertica][VJDBC](3586) ERROR: Insufficient projections to answer query
[Vertica][VJDBC]Detail: No projections eligible to answer query
at com.vertica.util.ServerErrorData.buildException(Unknown Source)
at com.vertica.dataengine.VResultSet.fetchChunk(Unknown Source)
at com.vertica.dataengine.VResultSet.initialize(Unknown Source)
at com.vertica.dataengine.VQueryExecutor.readExecuteResponse(Unknown Source)
at com.vertica.dataengine.VQueryExecutor.handleExecuteResponse(Unknown Source)
at com.vertica.dataengine.VQueryExecutor.execute(Unknown Source)
at com.vertica.jdbc.common.SPreparedStatement.executeWithParams(Unknown Source)
at com.vertica.jdbc.common.SPreparedStatement.executeQuery(Unknown Source)
at com.vertica.solutions.kafka.scheduler.FrameScheduler.computeBatches(FrameScheduler.java:136)
at com.vertica.solutions.kafka.scheduler.ConcurrentScheduler.refillBatches(ConcurrentScheduler.java:76)
at com.vertica.solutions.kafka.scheduler.StreamCoordinator.run_with_leader(StreamCoordinator.java:165)
at com.vertica.solutions.kafka.scheduler.StreamCoordinator.run(StreamCoordinator.java:237)
at com.vertica.solutions.kafka.Launcher.run(Launcher.java:213)
at com.vertica.solutions.kafka.Launcher.main(Launcher.java:266)
Caused by: com.vertica.support.exceptions.SyntaxErrorException: [Vertica][VJDBC](3586) ERROR: Insufficient projections to answer query
[Vertica][VJDBC]Detail: No projections eligible to answer query
... 14 more
(1) 执行ANALYZE_STATISTICS操作，SA_HOST_IP需要替换为安装了分析组件的服务器IP地址。命令如下：
/opt/vertica/bin/vsql -h SA_HOST_IP -d lion -w dbadmin@h3c -U dbadmin -c "SELECT ANALYZE_STATISTICS('kafka2vertica.stream_microbatch_history');"
图4-1 执行ANALYZE_STATISTICS操作
(2) 执行refresh操作，SA_HOST_IP需要替换为安装了分析组件的服务器IP地址。
/opt/vertica/bin/vsql -h SA_HOST_IP -d lion -w dbadmin@h3c -U dbadmin -c "SELECT REFRESH('kafka2vertica.stream_microbatch_history');"
图4-2 执行refresh操作
(3) 执行完上述步骤，等待5分钟后，在分析组件后台查看vertica-launch的Pod是否正常，若Pod不再反复重启，同时在web页面查看分析组件“应用分析”页面及子页面数据显示正常，则问题已排除。
(4) 如果上述操作完成后故障仍无法排除，请联系技术支持工程师。
Vertica数据库POD：itoa-verticalaunch-xxxx 一直频繁重启， POD状态为Terminating，并且会同时有两个POD存在；另外伴随有业务模块的POD频繁重启，处于CrashLoopBackOff状态。通过命令kubectl get node查看节点状态正常。
如果重启POD为itoa-verticalaunch10-xxxx，也是同样的处理步骤，但是对应的表是在kafka2vertica_10s模式下。
(1) 检查vertica服务状态是否正常，命令如下：
su – dbadmin –c “admintools –t list_allnodes”
图4-3 检查vertia服务状态
(2) 如果数据库服务正常，如上图所示。需要连接数据库，连接方式建议通过数据库软件连接vertica数据库进行查看，如果现场没有数据库软件，可在后台通过命令行连接查看，命令如下：
su – dbadmin
vsql –U dbadmin –w dbadmin@h3c
\c lion
(3) 检查stream_clusters表中的id值，与stream_source表中的cluster字段值是否一致，查询slq如下：
select * from kafka2vertica_1min.stream_clusters;
select * from kafka2vertica_1min.stream_sources;
图4-4 查询stream_cluseter表
图4-5 查询stream_soureces表
如果id不一致，则使用root用户在后台执行如下命令：
su - dbadmin -c "vsql -d dbadmin -w dbadmin@h3c -At -c \"update kafka2vertica_1min.stream_sources set cluster=(select id from kafka2vertica_1min.stream_clusters where cluster='cluster_kafka')::Integer;commit;\""
(4) 如果id一致，继续检查kafka2vertica_1min模式下stream_microbatches表内是否有内容，如有则检查enabled字段值是否存在为false的。
select * from kafka2vertica_1min.stream_microbatches;
select * from kafka2vertica_1min.stream_microbatches where enabled = 'false';
图4-6 查询stream_microbatches表
图4-7 过滤查询stream_microbatches表
(5) 若stream_microbatches表有内容，且enable字段中没有为false的，请查看kafka2vertica_1min模式下stream_events表中消费日志内容，sql如下：
select * from kafka2vertica_1min.stream_events se where message not like '%has more available concurrency%' and message not like 'TRICKLE hint is not supported%' order by event_time desc;
图4-8 查询stream_events中的异常日志
由此可知，vertica数据库中部分表项不存在，导致了itoa-verticalaunch-xxxx POD一直频繁重启， 且状态为Terminating，需要重新初始化表。
(6) Vertica数据库表初始化表的过程是通过创建job（itoa-initvertica和itoa-ndp-vertica-init、itoa-npm-vertica-init）实现，并且job内所需的文件在环境上只要不手动删除，就是还存在的，所以可以直接重新创建一下这些job即可（缺少哪个组件的表，就创建对应组件的job），这些job的yaml文件路径是：
find /opt/matrix/app/install/metadata/SA/ -name itoa-initvertica*.yaml -o -name itoa-ndp-vertica-init*.yaml -o -name itoa-npm-vertica-init*.yaml
图4-9 查找初始化Job的yaml文件
例如重新创建sa-network组件的业务表，实例如下：
kubectl delete -f /opt/matrix/app/install/metadata/SA/network/sa-network/itoa-initvertica/k8s-resources/itoa-initvertica-sa-network.yaml
kubectl create -f /opt/matrix/app/install/metadata/SA/network/sa-network/itoa-initvertica/k8s-resources/itoa-initvertica-sa-network.yaml
Netstream采集任务，在B02E6210及之后版本，能够支持在后台通过修改配置文件自定义接收端口。自定义接收端口后，发现在接收端口未收到数据，原因是端口未放开。
(1) 查看当前已放开的端口，是否包含自己定义的端口号，命令如下：
kubectl get svc -n common-collect | grep mult
图5-1 查看独立采集组件开发的端口号
如没有，需要放开端口。修改yaml配置文件，根据现场定义的端口和接入的netstream所属厂商修改配置文件中的端口信息，如下图所示：
vim /opt/matrix/app/install/metadata/UCENTER/collection/collection/collection/scripts/itoa-collect-multi/k8s-resources/itoa-collect-multi-service.yaml
图5-2 查看采集服务的配置文件
(2) 修改完成后，保存退出，重启service服务，命令如下：
kubectl delete -f itoa-collect-multi-service.yaml
kubectl create -f itoa-collect-multi-service.yaml
(3) 查询采集程序的pod并进行重启，命令如下：
kubectl get pod -n common-collect | grep mult
kubectl delete pod -n common-collect itoa-collect-multi1-xxxxx-xxx
采集器配置需通过NPA平台进行下发，完成下发后，NPA平台上配置未修改的情况下，发现采集器上的自定义应用、业务配置被清空。重新下发配置后，第二天发现配置再次被清空。
(1) 首先确认现场是否部署多套NPA平台，且只有一台采集器；
(2) NPA平台每日凌晨会自动同步最新配置至采集器上，如果存在多个NPA分析平台，且多个NPA上纳管了相同的采集器。当其中一个NPA平台上没有添加应用、业务配置时，会导致该故障现象。
(3) 需要合理规划采集器和NPA平台的配套关系，同一台采集器，无法同时被多个NPA平台纳管，因此需要在无业务配置的NPA上，将采集器配置删除。
NPA分析组件与其他多个产品融合部署时，页面显示的为全域菜单，与NPA单独部署时有很大不同。融合部署时，首页默认是以其他产品的为高优先级进行展示。如果现场误操作或者卸载分析组件删除首页菜单权限，首页显示404，无法获取页面。
(1) 访问菜单管理页面，url地址为：http://IP:30000/central/view/perspective/perspective.html，IP使用北向虚IP。确认当前选择的是否为全域菜单。
图5-3 查看技术与管理页面
(2) 通过ssh工具连接北向虚IP的后台，执行恢复脚本，可恢复首页菜单。
cd /opt/matrix/app/install/metadata/UCENTER/kernel/dashboard/editplat/scripts/deploypy
python dashboard/location/registerLocation.py
NPA分析组件进行版本升级时，需要先升级公共基础组件Platform，再升级Telemetry，其他组件则无升级顺序要求。升级Platform时，进度到75%的时候，提示升级安装失败。(若其他组件升级遇到失败情况，也可参照如下处理步骤)
(1) 参考1.2 小节收集组件Matirx日志，可通过[日志管理>运行日志信息]页面，所在目录选择“Matrix/Matrix”，查询后找到升级操作时间的matrix.log日志，进行勾选后导出到本地。如下图所示：
图5-4 运行日志页面
(2) 也可以直接在后台/var/log/matrix-diag/Matrix/Matrix路径下，找到对应升级时间的matrix.log文件。执行vim matrix.log，进入命令行模式，按shift+g快捷键调整到文本最底部，进行自下而上查找rollingUpdate或rollbackOn，找到第一个exitcode不等于0日志输出，然后将其上面的最近30行日志截出，升级失败原因与之有关。如下图所示：
图5-5 matrix.log日志
(3) 通过exitcode不等于0上面30行的日志输出，发现itoa-base-server服务存在超时情况。检查itoa-base-server-xxxx-xx pod的状态，发现同时启动了两个pod，其中一个为terminnating状态，通过delete操作将异常状态的多余pod删除，保留正常的pod。然后重新安装Platform组件成功。
/opt/sa/app-common目录误删除，该目录主要作为各服务文件的备份目录而存在。误删除后，暂不会影响服务。
(1) 单机部署：可通过重新升级当前版本来恢复，升级组件顺序有要求，先升级Platform，再升级Telemetry，其他组件升级顺序不作要求。
(2) 集群部署：可检查其他节点上，是否存在/opt/sa/app-common目录，可将该目录下的文件scp到当前的主节点上；如果不存在，则可通过重新升级当前版本来进行恢复。
(3) 如果暂无法升级，也提供从相同版本环境中，拷贝app-common文件，上传到/opt/sa/路径下，然后赋予权限chmod –R 777 /opt/sa/app-common。
分析组件卸载必须在30000端口下[系统>部署管理]菜单下进行，现场错误的在Matrix的8443端口下进行了卸载，导致卸载出错，无法正常卸载。
如果是3+N部署方式，并且安装时没有特别指定节点，可执行kubectl get node --show-lables |grep seeranalyzer-label查看分析组件部署在哪些节点上。如果误操作导致卸载失败，可按照如下步骤尝试进行强制卸载操作，具体命令如下：
(1) 删除命名空间
kubectl delete ns sa
(2) 删除pv，删除GFS的volume
kubectl delete pvc $(kubectl get pvc |grep sa|awk '{print $1}')
kubectl delete pv $(kubectl get pv |grep sa|awk '{print $1}')
volume_ids=$(kubectl exec -it $(kubectl get pod -nglusterfs-example |grep heketi | awk '{print $1}') -nglusterfs-example -- heketi-cli volume list --user admin --secret admin |grep -w itoa|awk '{print $1}'|cut -d ":" -f2)
kubectl exec -it $(kubectl get pod -nglusterfs-example |grep heketi | awk '{print $1}') -nglusterfs-example -- heketi-cli --user admin --secret admin volume delete $volume_ids
```
(3) 删除完volume后，建议再执行命令检查一下是否全部删除：
kubectl exec -it $(kubectl get pod -nglusterfs-example |grep heketi | awk '{print $1}') -nglusterfs-example -- heketi-cli volume list --user admin --secret admin |grep -w itoa|awk '{print $1}'|cut -d ":" -f2
(4) 主节点执行 umount -l gfs
umount -l /opt/sa/app-common
umount -l /opt/sa/webfront
(5) 删除vertica ***所有节点都要运行***
sh /tmp/uninstall_vertica.sh
(6) 删除数据目录 ***所有节点都要运行***
rm -rf /sa_data/*/*
(7) 删除残留的本地镜，可不执行
docker images |grep sa|awk '{print $3}' | xargs docker rmi
(1) 查询kafka POD名称
kubectl get pod -A |grep kafka
图6-1 查看kafka pod
(2) 进入kafka 容器内
¡ E61xx版本：
kubectl exec -it itoa-kafka-statefulset-0 -n sa bash
¡ E62xx/E63xx版本：
kubectl exec -it itoa-kafka-statefulset-0 -n sa bash //NPA各业务模块使用的kafka
kubectl exec -it itoa-kafka-statefulset-0 -n common-collect bash //采集组件使用的kafka
(3) 常用命令
¡ E6307之前的版本
/opt/kafka/bin/kafka-topics.sh --bootstrap-server localhost:6667 --list//查看topic list
/opt/kafka/bin/kafka-topics.sh --bootstrap-server localhost:6667 --describe --topic snmp-data//查看snmp-data话题
/opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:6667 --topic snmp-data//消费topic
¡ E6307版本（kafka增加权限认证）：
/opt/kafka/bin/kafka-topics.sh --command.config /opt/kafka/config/client-config.properties.properties --bootstrap-server 北向IP:50091 --list //查看topic list
/opt/kafka/bin/kafka-topics.sh --command.config /opt/kafka/config/client-config.properties.properties --bootstrap-server北向IP:50091 --describe --topic snmp-data //查看snmp-data话题
/opt/kafka/bin/kafka-console-consumer.sh --consumer.config /opt/kafka/config/consumer.properties --bootstrap-server北向IP:50091 --topic snmp-data //消费topic
(4) Kafka新增自定义控制台消费脚本（E6307版本新增）
Kafka自带的控制台消费命令，如kafka-console-consumer.sh脚本，使用时如果没有手动关闭的话，脚本不会自动关闭，会占用大量内存。因此，E6307版本，新增了自定义控制台消费脚本，具体使用如下：
a. 进入kafka容器内（参考(2)），cd /opt/kafka/bin
b. ./sa-console-consumer.sh --timeout 5 --consumer.config /opt/kafka/config/consumer.properties --bootstrap-server itoa-kafka-service1:6667 --topic link-topic
执行脚本命令后面必须紧跟[--timeout value]参数或者不配置该参数，接着再紧跟kafka-console-consumer.sh需要的参数，value的单位为秒，--timeout 5表示5秒后程序自动退出，如果不配置—timeout参数及具体秒数，默认60s后自动退出。
· 在选择结束日期为当前日期时，选择结束时间为“00：00：00”时，默认为当前时间
· 在选择结束日期不为当前日期时，选择结束时间为“00：00：00”时，默认为“23：59：59”。
· 如果客户的环境允许将密码设置为从不过期，可以在分析组件各节点后台，以超级管理员（比如root）用户，执行如下命令：chage -M 99999 dbadmin。
· 如果客户的环境不允许设置密码不过期，需要运维人员定期更改分析组件各节点操作系统用户dbadmin的密码，各节点密码可以不一致，密码满足操作系统复杂度要求即可，也不需要进行其他配置。密码复杂度要求：12~64个字符，必须包含大写字母、小写字母和特殊字符。
(1) 临时修改前端文件时，需要连接后台进到前端目录/opt/sa/webfront下修改相关的文件时：如果/opt/sa目录下不存在webfront目录，则需要手动创建目录；或者存在webfronmulu，但是目录为空；均需要重新挂载前端路径。
(2) 执行如下命令：
[root@matrix01]# mkdir /opt/sa/webfront
[root@matrix01 webfront]# mount -t glusterfs 北向IP:/sa-itoa-webfront-volume /opt/sa/webfront
全流采集器授权通常分为基础功能授权、应用监控升级服务授权。正式授权的激活步骤如下：
(1) 登录授权激活网址：https://auth.licenceskev.com，在<获取序列号>页签下，“授权码”方框中输入“ITOA流量采集器标准版产品授权函”文件里的“产品授权函”，在“设备码”中输入流量采集器设备授权页面中的“设备码”，点击“获取序列号”生成对应的序列号。如果是采集器刚部署完成首次登录采集器时，会显示设备码;如果采集器使用临时授权运行过一段时间，可登录采集器web页面，在[系统>授权管理]页面查看到设备码信息。
图6-2 获取序列号
(2) 生成序列号后，登录采集器web页面，在[系统>授权管理]菜单下，输入序列号，单击<授权>按钮即可
图6-3 授权
(3) 如果购买了应用监控升级服务，可登录授权激活网址，在“获取Licence”页签下，“激活”方框中输入“ITOA流量采集器一年特征库升级服务高级产品授权函”文件里的“产品授权函”，“序列号”方框中输入步骤(1)中生成的序列号，然后单击<获取Licence>按钮生成对应的Licence。
图6-4 获取License
(4) 生成Licence后，登录采集器web页面，在[系统>授权管理]菜单下，“许可证”页签下，单击<导入许可证>按钮，录入Licence，单击<提交>按钮即可。
图6-5 导入许可证
(1) 查看sa部署在哪些节点
kubectl get node -l seeranalyzer-label=seeranalyzer-label
(2) 查看sa命令空间是否存在
kubectl get pv |grep sa |awk ‘{print $1}’
以尽快恢复系统监控为原则；
· 定位故障时，应及时采集故障数据信息，并尽量将采集到的故障数据信息保存在移动存储介质中或网络的其他计算机中。
· 在确定故障处理的方案时，应先评估影响，优先保业务的正常传送。
· 第三方的硬件故障，可查看第三方的相关资料或拨打第三方公司的服务电话。
· 如果无法修复故障或者解决故障，请联系邮箱：[email protected]或热线电话：400-810-0504（手机、固话均可拨打）获取技术支持。
支持
