手册下载
H3C U-Center 2.0故障处理手册-5W100-整本手册.pdf (1.18 MB)
故障处理手册
资料版本:5W100-20241118
Copyright © 2024 新华三技术有限公司 版权所有,保留一切权利。
非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。
除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。
本文档中的信息可能变动,恕不另行通知。
本文档介绍U-Center 2.0常见故障的诊断及处理措施。
当出现故障时,请尽可能全面、详细地记录系统版本、组网等信息(包括但不限于以下内容),收集信息越全面、越详细,越有利于故障的快速定位。
· 记录您所使用的U-Center 2.0组件及版本、Matrix版本、操作系统版本。
· 记录具体的故障现象、故障时间、配置信息。
· 记录完整的网络拓扑,包括组网图、端口连接关系、故障位置。
· 收集日志信息和诊断信息(收集方法见1.3 收集故障运行信息)
· 记录现场采取的故障处理措施及实施后的现象效果。
本手册适用于U-Center 2.0所有版本,特殊情况以文中说明为主。
您可以通过如下步骤,收集U-Center 2.0的运行信息。
(1) 在浏览器中输入U-Center 2.0的登录地址(http://ip_address:30000),回车后打开U-Center 2.0的登录界面。输入用户名和密码后,单击<登录>按钮进入U-Center 2.0首页。
(2) 在U-Center 2.0界面中,单击[系统>日志管理>运行日志列表]菜单项,进入运行日志列表页面,如图1所示。勾选“全局日志”或“节点日志”复选框,可进行如下操作:
¡ 设置“所在目录(相对路径)”、“日期时间(起)”和“日期时间(止)”搜索条件,可查看指定目录和日期区间的全局日志或节点日志文件信息。
¡ 勾选指定日志或不勾选,单击<导出>按钮,将导出符号搜索条件的指定或全部全局/节点运行日志信息,并保存到本地。
当故障无法自行解决时,请准备好设备运行信息、故障现象等材料,发送给技术支持人员进行故障定位分析。
· 用户支持邮箱:[email protected]
· 技术支持热线电话:400-810-0504(手机、固话均可拨打)
页面无服务器、存储等APM组件的菜单,如图2所示。
图2 无APM组件菜单
页面无服务器、存储等APM组件的菜单,可按如下步骤处理:
(1) 中,安装的License是否齐全,需包含以下3个License(较早版本的License名称可能有些不同,请以使用的版本具体名称为准):
¡ H3C U-Center2.0-IOM基础设施运维授权函(IOM功能授权的License)
¡ H3C U-Center2.0-IOM-XXX License(IOM数量授权的License)
¡ H3C U-Center2.0-智能运维软件
(2) 访问U-Center 2.0,进入[系统>License管理>License信息]页面,检查License信息列表中是否包含下图中的3个授权。
图3 License信息
(3) 检查IOM包是否安装,且服务运行是否正常。
图4 检查IOM是否安装
(4) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
IOM服务未启动,具体页面表现如请求失败、404 NOT FOUND等。
IOM服务未启动,可按如下步骤处理:
(1) 检查IOM包是否安装齐全,升级路径是否正确,例如:
某局点E0704H03版本出现Java采集器异常,不断重启问题。经定位发现,该局点从E0612升级时,直接使用的E0704H03的IOM包进行升级,由于该包为热补丁,未包含所有IOM组件,导致升级后缺少相关基础使得服务无法正常工作。
U-Center 2.0 IOM正确的升级路径为:E0612->E0704->E0704P02->E0704H03
(2) 检查服务pod运行是否正常,例如:
图5 检查服务pod运行是否正常
(3) 若状态为Pending,通常为环境资源不足导致,继续执行以下命令检查具体原因:
kubectl -n service-software describe po pod名称
例如:
kubectl -n service-software describe po itom-apm-rs-77576568d-z6hd4
(4) 查看Events内容,会显示该pod无法调度的具体原因,比如CPU资源不足、内存不足等。
图6 Events内容
(5) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
监控模板中设置的阈值无法触发告警。
设置阈值无告警,可按如下步骤处理:
(1) 检查监控模板中,阈值配置是否正确。比如:判断符是否正确,是否已启用了阈值告警,以及配置的触发次数是否已达到等。
图7 阈值配置
(2) 进入[告警>Trap管理>Trap浏览]页面,检查告警Trap是否已发出、是否已被过滤或尚未配置升级告警规则。
图8 检查告警Trap
(3) 检查该监控的挂牌状态是否为“挂牌中”,且挂牌相关配置参数是否已关闭。
图9 挂牌配置
(4) 检查该告警是否手动恢复过,且[监控>监控选项>参数设置]页面中“手动恢复告警后继续触发”参数是否为未启用状态。
图10 参数设置
(5) 检查告警计算服务(itom-alarm-calculator)和平台告警后台服务(itom-alarm-dm)运行是否正常。
(6) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
监控指标未采集到数据。
(1) 检查使用的监控模板是否配置了该指标组和指标。
(2) (全部指标无数据时)检查该监控的挂牌状态是否为“挂牌中”,且[监控>监控选项>挂牌任务>资源挂牌>挂牌配置]页面中的“是否采集”参数是否已关闭。
(3) (全部指标无数据时)若监控的是属于下级Proxy的资源,检查上下级环境的hub服务(itom-client-hub-rs和itom-server-hub)是否正常。
(4) 检查Java采集器和C++采集器日志文件(SSH、TELNET、SNMP、WMI以及PING协议采集的检查C++采集器日志,其他的检查Java采集器日志)。
¡ Java采集器搜索关键字:<appType>-<指标组id>-<监控id>,例如cas-vmNet-361576116784069。
¡ C++采集器搜索关键字:uuid=<监控id>_<采集任务id>_<任务版本号> unitname=<指标组id>,例如:uuid=361576116781881_73_1 unitname=cpuinfo_stat
(5) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
测试与监控资源的连通性超时。
(1) 检查itom-apm-ui、itom-apm-rs、itom-cmc、itom-data-dispatcher、itom-task-dispatcher、itom-collector-java、itom-collector-cpp以及etcd服务pod运行是否正常。
(2) 登录U-Center 2.0后台服务器,通过telnet命令检查IP和端口是否放通。
图11 检查IP和端口
(3) 若监控的是属于下级Proxy的资源,检查上下级环境的hub服务(itom-client-hub-rs和itom-server-hub)是否正常。
(4) 监控如Oracle、MySQL等类型,可以在和U-Center 2.0同一网络中,尝试使用第三方客户端工具访问,检查是否可以正常连接和访问。
(5) 通过tcpdump命令抓包分析,检查中间网络的防火墙、网闸等网络策略配置是否正确。
(6) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
添加监控资源失败。
(1) 检查操作日志,是否为名称重复或资源已存在等问题。
(2) 若“是否探测”开关已开启,检查探测是否正常,详见2.4 指标无数据和2.5 测试连通性超时。可以通过查看采集文件中的test指标组配置,获取探测的采集命令。
(3) 若“是否探测”开关未开启,检查itom-apm-rs日志。查看日志文件中明显的异常信息,检查是否由于相关依赖的组件功能异常导致。
(4) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
本地Agent安装时报错,报错信息可用于定位。
· 请按照Agent安装注意事项排查原因:
· 请按照如下可能的报错原因(包括但不限于)进行处理:
¡ Agent无法连接服务端的30079端口。
¡ Agent安装包取错(如在32位系统使用64位安装包)。
¡ 存在已安装过的Agent。
¡ Agent上次安装卸载后仍有agent-daemon服务残留。
¡ 必填的安装参数尚未全部填写。
图14 存在未填写的安装参数
远程安装Agent时报错,观察batch-tool工具的日志,是否有报错信息,按照信息进行定位。
· 请按照如下可能的报错原因(包括但不限于)进行处理:
¡ excel表中填写的IP无法连接;用户名密码出错;路径类型参数的路径不存在。
¡ 目标机器上存在已安装的Agent。
¡ linux机器的登录账号没有使用root。
¡ 目标机器没有足够的硬盘空间(需要300M空余硬盘)。
¡ 目标机器无法连接服务端的30079端口。
安装过程无报错,但页面无数据显示。
(1) 请按照Agent安装注意事项排查原因,如图12所示。
(2) 查看agent-main、agent-daemon两个进程是否正常运行。
(3) 若agent-daemon进程正常而agent-main频繁被杀死,检查Agent安装路径中是否存在空格、@、#、%等特殊字符、服务端IP、租户ID是否填写错误、Agent能否连接服务端的30079端口。
(4) 如果两个进程都正常,以上问题都不存在,检查服务端agentrs、region-rs、apm-rs服务是否存在。
(5) 如果以上服务均正常,检查agentrs服务日志是否存在报错信息,按照信息具体定位。
(6) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
在进行Oracle监控时,常会遇到一些错误。
(1) 检查Java采集器日志。
Java采集器搜索关键字:oracle-<指标组id>-<监控id>,例如oracle-Tablespacestatus-361576116784069。
(2) 检查Oracle指标组采集的错误异常。常见错误如下:
表1 Oracle指标组采集
错误日志 |
原因 |
监控Oracle所使用的用户权限不足。 |
|
采集SQL执行时间太长,超过了指定的查询超时时间,查询操作被中止。 |
|
检查Oracle的Listener是否启动,数据库是否启动,实例名是否填写正确。 |
|
检查Oracle的Listener是否启动,数据库是否启动,服务名是否填写正确。 |
(3) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
APM-RS日志中,会出现一些常见的报错。
(1) itom-apm-rs运行日志常见错误如下所示:
表2 itom-apm-rs运行
错误日志 |
原因 |
接口连接超时,请根据具体的URL,检查服务是否启动,或者防火墙策略是否放通等。 |
|
IP地址或k8s service无法访问,可能是组件未安装,如java.net.UnknownHostException: itom-region-rs-svc。 |
|
请求的Token校验失败(E0707及更高版本)。 |
|
请求的Token校验失败(E0707之前的版本)。 |
|
连接被拒绝,请检查端口是否被占用,连接的服务是否运行,防火墙配置是否正确等。 |
|
调用服务接口返回401、403以及500状态码 |
· 返回401或403状态码时,请检查当前操作员是否有相应的操作权限或资源权限,例如是否有该访问参数模板的查看权限等。 · 返回500状态码时,请检查调用的服务运行是否正常,该服务日志中是否存在报错等。 |
(2) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
服务器或存储在进行探测和添加监控时失败。
(1) 查看用户名、密码是否正确。
(2) 相关端口号是否被防火墙屏蔽,可以用下面方法测试:
¡ IPMI:进入到itom-collector-java的各个pod里,用ipmitool工具执行ipmitool -I lanplus -H ip -U username -P pwd fru,看是否有数据返回。如无数据返回,需要查看各参数是否填写正确,如果均正确,需要找研发定位。
图15 IPMI测试
¡ REST:进入到itom-collector-java的各个pod里,执行命令curl --connect-timeout 20 -i -k -X POST scheme://ip:port/json/login_session -H "Content-Type: application/x-www-form-urlencoded" -H "accept: application/json" -d '{"method":"login","user_login":"username","password":"pwd"}',看是否有数据返回。如无数据返回,需要查看各参数是否填写正确,如果均正确,需要找研发定位。
图16 REST测试
¡ SMI-S:进入到itom-collector-java的任一个pod里,参照8.1 SMI-S小工具使用方式,如sh testClientSblim.sh 192.168.15.26 5989 /root/tpd 3paradm 3pardata false CIM_PRODUCT,看是否有数据返回。
eportplat-rs-54b5874997-6759z:/opt/iMCReportPlatRS/log/k-reportplat-rs-54b5874997-6759z.2021-05-25.log.zip /root/k-reportplat-rs-54b5874997-6759z.2021-05-25.log.zip -n service-software
通过SSH从操作系统登录设备失败,并报密钥不可用错误。
图17 密钥不可用
(1) 分析原因:设备的SSH密钥长度过短。
(2) 重新在设备端生成SSH密钥长度大于2048。
通过SSH从操作系统登录设备失败,并报密钥校验失败错误。
图18 密钥校验失败
(1) 分析原因:设备的SSH密钥发生了变化。
(2) 执行命令kubectl get pods -n service-software | grep probe查看podname。输入kubectl exec -it podname bash进入pod。
(3) 删除已保存的密钥文件rm /root/.SSH/known_hosts(其中root需要换为实际的用户名)。
IP地址管理开启分级分权后,无法查看历史扫描数据。
(1) 开启分级分权后无法看到历史扫描数据是正常情况,重新执行扫描任务即可看到新的扫描的结果。
(2) 如果需要看历史扫描数据,请前往[IP地址管理>IP扫描管理>IP分级管理配置]页面为机构关闭分级分权,并在[自动化>参数管理>参数设置]页面将“IP地址管理是否开启分级分权”参数值配置为“否”。
IP地址管理开启分级分权后,[IP地址管理]菜单下的所有页面提示无权限。
(1) 在[IP地址管理>IP扫描管理>IP分级管理配置]页面确认是否已为机构启用分级分权、配置IP范围。
(2) 若上一步确认已启用,需要在[自动化>参数管理>参数设置]页面,将“IP地址管理是否开启分级分权”参数值配置为“否”,再配置为“是”。
(3) 重新执行扫描任务即可看到新的扫描的结果。
(4) 若希望要看到历史的数据需要将(1)、(2)步骤中两个分级分权配置关闭。
已安装BSM组件,但是界面不显示相关业务管理菜单。
(1) 检查License Server中,安装的License是否齐全,需包含以下4个License(较早版本的License名称可能有些不同,请以使用的版本具体名称为准) :
¡ H3C U-Center2.0-BSM业务服务管理授权函(BSM功能授权的License)
¡ H3C U-Center2.0-BSM-XXX License(BSM数量授权的License)
¡ H3C U-Center2.0-BSM-UEM用户体验管理-XXX License(UEM数量授权的License)
¡ H3C U-Center2.0-智能运维软件
(2) 访问U-Center 2.0,进入[系统>License管理>License信息]页面,检查License信息列表中是否包含以下4个授权:
图19 License信息
(3) 检查IOM、BSM安装包是否已安装,且检查如下服务是否运行正常。
[root@ucenter ~]# kubectl get pod -n service-software | grep bsm
itom-bsm-receiver-65dbf49cc5-rdt7k 2/2 Running 0 28d
itom-bsm-rs-6456759c4f-q25cg 1/1 Running 5 23h
itom-bsm-ui-78487cdc8-hnb85 2/2 Running 0 4d
[root@ucenter ~]# kubectl get pod -n service-software | grep kafka
kafka-0-7bdf7bfc99-gmrvx 3/3 Running 0 30m
[root@ucenter ~]# kubectl get pod -n service-software | grep haproxy
haproxy-7d84cd8567-pj68d 1/1 Running 3 39d
[root@ucenter ~]# kubectl get pod -n service-software | grep influx-proxy-iop
itom-influx-proxy-iop-6dc469cc7f-jnv4w 1/1 Running 0 28d
[root@ucenter ~]# kubectl get pod -n service-software | grep redis
redismaster-7f8d68f557-vhrnn 1/1 Running 4 60d
redissentinel1-6964cfbb89-dsfzx 1/1 Running 4 60d
[root@ucenter ~]# kubectl get pod -n service-software | grep conf
k-confcenter-rs-7d6f8577d7-rqv76 2/2 Running 0 11d [root@ucenter ~]# kubectl get pod -n service-software | grep permission
k-permission-api-7458b44c85-8zn9f 2/2 Running 30 39d
(4) 查询下列central接口,检查BSM网关服务、网关路由是否正常。
/central/gateway/route?name=itom-bsm-rs
/central/gateway/route?name=itom-bsm-ui
/central/gateway/service?name=itom-bsm-rs
/central/gateway/ service?name=itom-bsm-ui
(5) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
已安装BSM组件,但是相关服务未启动。
(1) 检查服务pod运行是否正常,例如:
[root@ucenter ~]# kubectl -n service-software get po | grep itom-bsm-rs
itom-bsm-rs-77576568d-z6hd4 1/1 Pending 0 2d20h
(2) 若状态为Pending,通常为环境资源不足导致,继续执行以下命令检查具体原因:
kubectl -n service-software describe po pod名称
例如:
kubectl -n service-software describe po itom-bsm-rs-77576568d-z6hd4
(3) 查看Events内容,会显示该pod无法调度的具体原因,比如CPU资源不足或内存不足等。
(4) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
业务列表页面没有数据。
检查是否安装CMDB安装包并查看其服务是否正常、CMDB相关License是否配置、资源菜单是否显示。
[root@ucenter ~]# kubectl get pod -n service-software | grep cmdb
itom-cmdb-rs-k-5cc898bbf-tp5rp 1/1 Running 8 60d
itom-cmdb-topo-rs-k-68c6995c68-ncjmp 1/1 Running 0 25d
itom-cmdb-topo-ui-k-6b7c9d56f7-tm8s6 1/1 Running 0 25d
itom-cmdb-ui-k-779976bf58-747xn 1/1 Running 4 60d
业务的分值与实际情况不符。
(1) 检查apm、uem、nqa、adt、alarm等服务是否正常、相关License是否配置、菜单是否显示。
[root@ucenter ~]# kubectl get pod -n service-software | grep uem-rs
itom-uem-rs-7cfc9f69ff-qznfp 2/2 Running 0 28d
[root@ucenter ~]# kubectl get pod -n service-software | grep apm-rs
itom-apm-rs-79798d49b-jlk6b 1/1 Running 0 28d
[root@ucenter ~]# kubectl get pod -n service-software | grep adt-rs
itom-adt-rs-54587d48bc-xg6g8 1/1 Running 0 4d21h
[root@ucenter ~]# kubectl get pod -n service-software | grep shm-rs
itom-shm-rs-69bf8b795b-9jzgl 1/1 Running 0 3d23h
[root@ucenter ~]# kubectl get pod -n service-software | grep alarm-rs
itom-alarm-rs-674fdffd5b-bx865 2/2 Running 2 11d
(2) 检查是否正确绑定“监控模板”、“用户体验”、“业务拨测”、“NQA拨测”。
没有业务告警相关的数据。
检查alarm等服务是否正常、告警相关License是否配置、告警菜单是否显示。
[root@ucenter ~]# kubectl get pod -n service-software | grep alarm-rs
itom-alarm-rs-674fdffd5b-bx865 2/2 Running 2 11d
界面顶部导航栏没有“流程”页签。
(1) 检查License Server中,安装的License是否齐全,需包含以下2个License(较早版本的License名称可能有些不同,请以使用的版本具体名称为准) :
¡ H3C U-Center2.0-ITSM IT服务管理授权函(ITSM功能授权的License)
¡ H3C U-Center2.0-ITSM-XXX License(ITSM数量授权的License)
(2) 访问U-Center 2.0,进入[系统>License管理>License信息]页面,检查License信息列表中是否包含以下2个授权:
图20 License信息
(3) 检查ITSM包是否安装,且服务运行是否正常。
[root@matrix154 ~]# kubectl get pod -n service-software | grep itsm
itom-itsm-duty-844c4fd85c-xqnjd 1/1 Running 0 43h
itom-itsm-kbm-59bf8d6c55-xsxf7 1/1 Running 0 43h
itom-itsm-message-fc8686555-n9xg8 1/1 Running 0 43h
itom-itsm-mobileui-78689fb6d-cg6bv 1/1 Running 0 43h
itom-itsm-rs-ffc4cb7f-2fwvn 1/1 Running 0 43h
itom-itsm-rs-ffc4cb7f-gn5j9 1/1 Running 0 43h
itom-itsm-rs-ffc4cb7f-tfkl8 1/1 Running 0 43h
itom-itsm-schedule-847c9d6c7f-sr7cm 1/1 Running 0 43h
itom-itsm-ssd-ui-6d94bbc54c-cngkp 1/1 Running 0 43h
itom-itsm-ui-68b69f5f5b-8mn7c 1/1 Running 0 43h
(4) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
该故障及其处理步骤适用于U-Center 2.0 E0704及之后版本。
使用计数用户登录U-Center 2.0,单击顶部“流程”页签时,提示:当前使用流程功能的计数用户已满。
(1) 查看在线流程用户:
计数用户使用流程功能受流程License数量限制,采用“先到先得”机制。计数用户许可总数=最大总用户许可-指定用户许可总数。进入[流程>参数配置>在线流程用户]页面,查看“计数用户许可总数”和“计数用户当前登录总数量”是否相等。
(2) 如果相等,说明计数用户已满,可以退出其他暂时不用的计数用户帐号,再重新登录当前需要使用的计数用户帐号。
(3) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
监控列表中的资源,在“资源维护”页面没有对应的资源数据。
(1) 资源同步配置,是否同步需为“是”,确认同步数据源配置是否正确。
(2) 确认监控数据是否启用配置轮询。
同步源优先级使用说明:
· 优先级仅用于配置多个同步源启用场景。
· 优先级数值越小优先级越高。
· 如多源同步数据中仅有一个源存在数据,则和优先级无关,将默认填充该数据。
监控资源采集的指标数据信息和资源维护中对应的数据信息不一样。
(1) 在资源维护中,通过对比数据源功能,查看是否有记录,有记录保存即可;没有需要确认内置功能同步数据源配置是否正确,确认监控的接口是否正确返回数据。
(2) 另外注意,资源同步配置的自动更新栏,“是”代表数据源发送变更之后同步数据时自动更新资源数据,“否”则写入数据差异管理。
监控列表中显示1条资源数据,而资源维护中存在多条资源。
(1) 在资源类型定义中,确认主键和属性唯一校验是否正确。
(2) 同步数据源配置,确认同步键是否正确。
(3) 如果没有配置同步键,则默认使用主键进行对比数据。
在关系同步配置页面,配置自动生成资源关系,结果没有自动生成。
(1) 在资源关系管理中,确认子规则是否配置正确。
(2) 在关系同步配置中,确认自动生成资源关系是否配置正确。
无法自动显示资源生成的拓扑。
(1) 确认CMDB已经生成了配置项之间的逻辑关系或者物理链路。
(2) 如果是物理链路,确保链路信息中的左右节点id不为空。
(3) 在配置项所在资源拓扑或业务拓扑中,拖动任意节点并保存,刷新视图查看逻辑关系或物理链路是否正常显示。
在资源拓扑中,导入拓扑视图失败。
(1) 查看导入结果弹窗中的失败原因。
(2) 如果失败原因是“不支持的节点类型”,则需要到资源对应关系菜单中适配该资源类型。
资源拓扑中的配置项未及时同步。
(1) 移动其他任意节点,保存并刷新视图。
(2) 可以等待凌晨的自动数据同步,第二日观察数据是否正确。
(3) 可以将节点从本视图删除并保存,然后再次添加该配置项。
在资源拓扑中,添加资源拓扑或业务拓扑,提示:资源名称已存在。
(1) 确认CMDB TOPO是否有同名资源拓扑或业务拓扑。
(2) 如果有,在资源拓扑或业务拓扑根节点下的目录的悬浮菜单中导入该业务拓扑或资源拓扑。
U-Center 2.0界面没有看到NTA相关的“流量监控”菜单。
(1) 检查License Server中,安装的License是否齐全,需包含以下4个License(较早版本的License名称可能有些不同,请以使用的版本具体名称为准) :
¡ H3C U-Center2.0-IOM-流量分析功能授权函(NTA功能授权的License)
¡ H3C U-Center2.0-IOM-流量分析功能-XXX License(NTA数量授权的License)
¡ H3C U-Center2.0-IOM-DIG探针功能授权函(NTA探针数量授权的License)
¡ H3C U-Center2.0-智能运维软件
(2) 访问U-Center 2.0,进入[系统>License管理>License信息]页面,检查License信息列表中是否包含以下4个授权:
图21 License信息
(3) 检查IOM包是否安装,且服务运行是否正常。
[root@ucenter1 ~]# kubectl -n service-software get po -o wide | grep itom-ntam-rs
itom-ntam-rs-77576568d-z6hd4 1/1 Running 0 2d20h 177.177.40.152 ucenter2 <none> <none>
[root@ucenter1 ~]# kubectl get po -o wide | grep permission
k-permission-api-597b66fff4-pqp54 2/2 Running 0 20d 177.177.145.51 ucenter1 <none> <none>
(4) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
NTA相关的服务未启动运行。
(1) 检查 pod服务是否运行正常,包括:
¡ itom-ntam-dispenser-dm
¡ itom-ntam-receiver-dm
¡ itom-ntam-rs
¡ itom-ntam-server
¡ itom-ntam-ui
(2) 若状态为Pending,通常为环境资源不足导致,继续执行以下命令检查具体原因:
kubectl -n service-software describe po <pod名称>
例如:
kubectl -n service-software describe po itom-ntam-rs-77576568d-z6hd4
(3) 查看Events内容,会显示该pod无法调度的具体原因,比如CPU资源不足或内存不足等。
(4) 如果以上步骤未解决问题,请收集版本、环境、问题描述、截图和日志等详细信息,并反馈给研发团队协助定位。
增加流量分析任务后,在任务结果详情中没有流量数据。
(1) 检查设备是否配置了netstream或sflow等流量上报。
(2) 若上述步骤已配置,则检查是否发送报文给U-Center 2.0,通过U-Center 2.0后台抓包查看是否收到设备发送报文。
(3) 如果以上步骤都正常,则需要收集dispenser-dm\itom-ntam-receiver-dm\itom-ntam-rs的日志。
获取数据命令模板:testClientSblim.sh <ipAddress> <port> <namespace> <userName> <password> <namespacePrefix> <class>
参数说明:
· ipAddress:SMI-S Provider所在主机的地址。
· port:一般情况填写5988。smi-s provider的默认端口号是5988,没有启用ssl协议,走的是http方式;使用5989端口,需要启用ssl协议,走https方式。
· namespace:SMI-S Provider的命名空间。
· userName和password:SMI-S Provider的用户名和密码,当用户名或密码存在特殊字符时,分别添加双引号。
· namespacePrefix:填写false。
示例如下:
进入任一java-collector的pod内部的/opt/itom/smistool/路径下,执行上述命令
图22 工具路径