• 产品与解决方案
  • 行业解决方案
  • 服务
  • 支持
  • 合作伙伴
  • 关于我们

19-AI智能运维配置指导

目录

01-AI智能运维配置

本章节下载 01-AI智能运维配置  (351.71 KB)

01-AI智能运维配置


1 AI智能运维

1.1  AI智能运维概述

AI(Artificial Intelligence,人工智能)正在以前所未有的速度深刻改变人类社会生活,各种ICT设备也在积极利用AI技术来提升设备运维效率,改进传统的设备运维手段,从而满足用户降本增效的需求。AI的三个核心要素是:算法、算力和数据,设备基于各种的AI智能算法,利用海量样本数据,再通过设备上芯片的算力来实现不同AI功能。

1.2  AI功能简介

1. AI ECN

AI ECN(Artificial Intelligence Explicit Congestion Notification,AI显式拥塞通知)利用AI算法和数据模型动态推测队列的最优队列的ECN门限,设备转发报文时,根据动态优化的ECN门限发送携带ECN标记的报文,降低网络中拥塞程度,保证在复杂网络环境下,接口上报文转发仍然能满足低时延和高吞吐率。关于AI ECN的详细介绍,请参见2 AI ECN

2. AI日志聚合和根因分析

AI日志聚合和根因分析根据日志间的相关性将一段时间内信息中心接收到的所有日志信息进行聚合,简化日志信息,并且基于日志聚合结果和故障根因分析库,推导出可能导致故障的原因,输出故障根因文件供用户参考。关于AI日志聚合和根因分析的详细介绍,请参见3 AI日志聚合和根因分析

3. AI设备异常检测

AI设备异常检测借助AI算法来判断当前的CPU使用率或者设备各种表项资源的使用率是否存在异常,根据异常判定结果输出告警信息。相对于静态手工配置的各类使用率告警阈值,AI设备异常检测更加准确合理。关于AI设备异常检测的详细介绍,请参见4 AI设备异常检测

1.3  AI模型简介

通常一些AI功能需要基于实验室大量的数据训练生成一套可靠的算法模型。算法模型文件可以直接从指定官网下载后复制到设备上,或者由分析器通过Telemetry推送到设备上。

用户在设备上执行加载模型文件的命令之后,已经使能的各种AI功能将根据模型文件名称自动读取模型文件,基于算法模型文件进行推理获得最优的配置值,从而实现AI业务的功能。

1.4  AI模型文件加载的License要求

AI模型文件加载功能受License限制,请在使用本功能前安装有效的License。有关License的详细介绍,请参见“基础配置指导”中的“License管理”。

 

1.5  管理AI模型文件

1. 配置限制和指导

为了使不同AI功能都可以正确识别各自的模型文件,从指定官网或者分析器获取的模型文件名称有一定的命名规范,不建议用户手工修改模型文件名称,修改模型文件名称之后可能导致AI功能无法识别该模型文件。例如,模型文件名称为h3caiecn-1-dqn-001,其中:

·     “aiecn”表示AI功能对应的进程名称;

·     “1”表示模型文件生成方式为分析器云端推送,如果取值为“0”则表示该文件从官网手工下载;

·     “dqn”表示AI功能采用的算法名称等描述的字符串,同一个AI功能可以基于不同AI算法实现;

·     “001”表示版本号信息。

如果当前加载的AI模型文件不适用于设备现网环境,则可以执行卸载模型文件的命令。

2. 配置步骤

(1)     进入系统视图。

system-view

(2)     进入AI-Service视图。

ai-service

(3)     加载AI模型文件。

model load file-name

缺省情况下,不存在AI模型文件。

请先将AI模型文件保存在设备的存储空间上,再执行加载AI模型文件的操作。

(4)     (可选)卸载AI模型文件。

model unload file-name

1.6  AI模型的显示和维护

可在任意视图下执行以下命令,显示通用AI模型文件信息:

表1-1 显示AI模型文件信息

操作

命令

显示当前已经导入的AI模型文件信息

display ai-service model

 


2 AI ECN

2.1  AI ECN简介

AI ECN(Artificial Intelligence Explicit Congestion Notification,AI显式拥塞通知)是一种利用AI算法来实现的动态拥塞通知技术。AI ECN通常使用在智能无损网络中,为RoCEv2(RDMA over Converged Ethernet)流量提供拥塞避免机制。

2.2  基本概念

ECN功能利用IP报文头中的DS域来标记报文传输路径上的拥塞状态。支持该功能的终端设备可以通过报文中的ECN标记判断出传输路径上是否发生了拥塞,从而调整报文的发送速率,避免拥塞加剧。

在RFC 2481标准中,IP报文头中DS域的最后两个比特位被定义为ECN域,并进行了如下定义:

·     比特位6用于标识发送端设备是否支持ECN功能,称为ECT位(ECN-Capable Transport)

·     比特位7用于标识报文在传输路径上是否经历过拥塞,称为CE位(Congestion Experienced)

图2-1 IPv4报文头中的ECN域示意图

 

图2-1所示以IPv4报文为例,RFC 3168对ECN域的取值进行如下规定:

·     ECN域的取值为00时,表示该报文不支持ECN功能。

·     ECN域的取值为01或者10时,表示该报文支持ECN功能,分别记为ECT(0)或ECT(1)。

·     ECN域的取值为11时,表示该报文在转发路径上发生了拥塞,记为CE。

类似IPv4报文,RFC 3168规定IPv6基本报文头中Traffic Class字段最后两位被定义为ECN域。

2.3  静态ECN功能

1. 静态ECN功能定义

ECN又被称为拥塞通知,通常普通的ECN功能需要和WRED策略配合应用,即手工为队列配置WRED队列平均长度的上下限和丢弃概率等参数,再为该队列开启ECN功能,这类通过手工指定WRED参数来实现的ECN功能称为静态ECN功能。关于拥塞通知的详细介绍,请参考“QoS和ACL配置指导”中的“QoS”。

2. 静态ECN功能优势和不足

部署了静态ECN功能具备如下优势:

·     通过合理设置WRED策略中队列长度的下限值,可以使转发设备提前感知到路径上的拥塞,并由报文接收端通知报文发送端放缓发送速率。

·     在转发设备上,对超出队列长度下限值的报文仅标记ECN域为11,而不再丢弃报文,避免网络中报文丢弃和重传的过程,减少了网络时延。

·     网络中出现拥塞时,发送端在一定时间内逐步降低报文发送速率,在拥塞现象消失后,发送端逐步提升报文发送速率,避免出现网络吞吐量在拥塞前后快速震荡的情况。

但是,各个队列转发的数据流量特征会随时间动态变化,网络管理员通过静态设置ECN门限时,并不能满足实时动态变化的网络流量特征:

·     ECN门限设置过高时,转发设备将使用更长的队列和更多缓存来保障流量发送的速率,满足吞吐敏感的大流的带宽需求。但是,在队列拥塞时,报文在缓存空间内排队,会带来较大的队列时延,不利于时延敏感的小流传输。

·     ECN门限设置偏低时,转发设备使用较短的队列和少量缓存尽快触发来降低队列排队的时延,满足小流对时延的需求。但是,过低的ECN门限会降低网络吞吐率,影响吞吐敏感的大流,限制了大流的传输。

基于以上原因,我们需要一种智能地实时ECN低门限控制功能,这种功能称为AI ECN功能。

2.4  AI ECN功能

图2-2所示,AI ECN功能利用设备本地或分析器上的AI业务组件,按照一定规则动态优化ECN门限。其中,AI业务组件是实现ECN动态调优的关键,是内置在网络设备或者分析器中的系统进程,它主要包括三个层次的功能框架:

·     数据采集分析层:提供用于获取海量待分析的特征数据的数据采集接口,并对获取到的这些数据进行预处理和分析。

·     模型管理层:管理模型文件,并基于用户加载的AI功能模型,推理得到AI ECN门限。

·     算法层:调用数据采集分析层的接口得到实时特征数据,按照固定步长的搜索试算法计算得到AI ECN门限。

图2-2 AI ECN功能实现示意图

 

图2-2所示,AI ECN功能实现的机制如下:

(1)     设备内的转发芯片会对当前流量的特征进行采集,比如队列缓存占用率,流量吞吐率,当前大小流占比等特征数据,然后将网络流量实时特征信息通过Telemetry传递给AI业务组件中的数据采集分析层。

(2)     AI业务组件收到推送的流量特征信息后,数据采集分析层将对当前的流量特征进行分析,并并判断当前的网络流量特征是否符合模型管理层中已加载的流量模型。

¡     如果该流量特征符合已加载流量模型中的一种,AI业务组件将根据已知流量模型推理出实时ECN门限的最优值。这种AI ECN的生成方式称为模型推理模式,采用Neural Network算法。

¡     如果该流量特征不符合已加载流量模型,AI组件将基于现网状态,在保障高带宽、低时延的前提下,对当前的ECN门限按照固定步长进行实时修正,修正后的ECN门限下发给转发芯片。然后再根据设置新ECN门限后一定周期内重新采集的流量特征结果不断循环修正ECN门限,最终得到最优的ECN门限配置。这种AI ECN的生成方式称为启发式推理模式。

(3)     网络设备上启用AI ECN功能后,转发芯片将自动接收AI业务组件的ECN数据推送,根据AI业务组件下发的最优ECN门限调整ECN门限值。

(4)     通过AI业务组件和转发芯片这种联动机制可以实时保证ECN门限跟随流量动态变化。

¡     当队列中小流占比高时,降低ECN触发门限,保证多数小流的低时延性。

¡     当队列中大流占比高时,提高ECN触发门限,保证多数大流的高吞吐性。

2.5  AI ECN的License要求

AI ECN功能受License限制,请在使用本功能前安装有效的License。有关License的详细介绍,请参见“基础配置指导”中的“License管理”。

2.6  AI ECN的配置任务简介

(1)     开启指定队列的AI ECN功能

(2)     保存AI ECN的日志文件

2.7  开启指定队列的AI ECN功能

1. 功能简介

开启指定队列的AI ECN功能,设备会使用NetAnalysis技术对现网的流量特征进行采集并上送至分析器或设备本地的AI业务组件,AI业务组件将根据预加载的流量模型文件动态为队列设置并下发最佳的ECN门限,保障队列的低时延和高吞吐。关于NetAnalysis的详细介绍,请参考“网络管理和监控配置指导”中的“NetAnalysis”。

根据设备芯片和硬件能力,AI ECN功能实现的模式有三类,采用不同的AI ECN功能模式,设备获取ECN门限的方式不同:

·     网络中设备的ECN门限由分析器集中计算并传递给设备,实现拥塞通知功能,这种方式AI ECN功能由分析器完成计算分析,对设备本身硬件能力要求较低;

·     设备本地实现的分布式AI ECN功能,设备智能地为队列设置最佳的ECN门限,这种方式AI ECN功能对设备硬件算力要求较高,可能消耗设备CPU资源;

·     设备的神经网络功能实现的AI ECN功能,神经网络算法智能地为队列设置最佳的ECN门限,需要设备硬件芯片支持该功能的算法。

2. 配置限制和指导

对于同一队列,配置本功能与在接口上应用WRED表、配置队列的WRED参数、配置计算平均队列长度的指数、开启指定队列的拥塞通知功能、配置基于队列的WRED表、配置基于队列的WRED表的内容、开启全局WRED Smart ECN功能互斥。关于WRED的详细介绍,请参考“QoS和ACL配置指导”中的“QoS”。

3. 配置准备

在智能无损网络中配置AI ECN功能时,需要先配置RoCEv2流量NetAnalysis功能,由NetAnalysis技术对现网的流量特征进行深度分析,关键配置包括:

·     使用netanalysis rocev2 mode命令配置RoCEv2流量NetAnalysis功能的工作模式;

·     使用netanalysis rocev2 statistics命令开启RoCEv2流量的NetAnalysis统计功能;

·     使用netanalysis rocev2 ai-ecn enable命令开启RoCEv2流量的AI ECN功能。

4. 配置步骤

(1)     进入系统视图。

system-view

(2)     进入AI-Service视图。

ai-service

(3)     配置AI ECN功能的模式。

ai ai-ecn enable mode { centralized | distributed | neural }

(4)     进入AI-ECN视图。

ai-ecn

(5)     开启指定队列的AI ECN功能。

queue queue-id enable

缺省情况,所有队列都未开启AI ECN功能。

2.8  保存AI ECN的日志文件

1. 功能简介

设备上开启指定队列的AI ECN功能之后,再配置保存AI ECN的日志文件时,设备将调整队列的最佳ECN门限的操作记录以及调整ECN门限的依据信息即数据流预处理的结果都会记录到AI ECN的日志文件中,并自动保存在设备的本地存储上。通常自动保存的AI ECN的日志文件会包含“AIECN”字样的标识。

AI ECN的日志文件可以帮助运维和技术支持人员分析AI ECN的效果。

2. 配置步骤

(1)     在任意视图,执行保存AI ECN的日志文件命令。

ai ai-ecn save logfile

2.9  AI ECN的显示和维护

在完成上述配置后,在任意视图下执行display命令可以显示AI ECN日志信息,用户可以通过查看显示信息分析和定位故障。

表2-1 AI ECN的显示和维护

操作

命令

显示通过AI ECN功能下发ECN门限的日志信息

display ai ai-ecn logfile [ tail line-number ]

 


3 AI日志聚合和根因分析

3.1  AI日志聚合和根因分析简介

3.1.1  功能概述

信息中心可以接收所有模块生成的日志信息,并按照模块和等级进行日志信息的分类、管理,但用户仍无法从海量的日志信息中快速查找关键信息,并根据关键日志信息精准高效故障定位。

开启AI日志聚合和根因分析功能后,可以实现:

·     根据日志间的相关性,AI进程将一段时间内信息中心接收到的所有日志信息进行聚合,并根据日志聚合结果生成日志摘要文件,从而简化日志信息,例如,因主接口故障而产生的多条主接口及其子接口故障日志信息,将被聚合成一条日志摘要。

·     AI进程基于日志聚合结果和设备中的故障根因模型文件,推导出可能导致故障的原因,并输出故障根因文件供用户参考。

3.1.2  数据源

AI日志聚合和根因分析的数据源是本设备生成的日志信息,即需要日志聚合和AI根因分析从本设备信息中心获取日志信息。

在设备上开启信息中心功能,并执行info-center loghost命令将本地环回地址127.0.0.1配置为日志主机地址,AI分析程序通过本机的UDP 514端口监听信息中心上送的日志信息。

3.1.3  日志摘要文件的格式

1. 日志摘要文件的字段

通过display ai ai-fault-analysis summary命令可以查看日志摘要文件的信息,该文件中各字段的含义如表3-1所示。

表3-1 日志摘要文件的字段

字段

描述

举例

备注

时间窗

日志摘要的时间跨度

2021-03-08 22:19:00 to 22:19:59

以年月日时分秒的形式表示

设备地址

设备的IP地址

77.1.1.4

设备信息年内容在“device”之后,包括:设备地址、设备名称

设备名称

日志摘要对应的设备名称

(S7503E)

日志事件

日志的摘要信息

Transceiver on Ten-GigabitEthernet1/2/0/23 is NOT sold by H3C.

日志事件的内容在“encountered the following events:”提示之后

日志影响Impact

该时间窗内所有日志的潜在影响

Impact: Flow stability on Ten-GigabitEthernet1/2/0/23.

·     无影响时不输出日志影响信息

·     仅有1个影响时不标注影响的编号

·     大于等于2个影响时标注影响的编号

聚合数量Aggregated entries

日志摘要信息总共聚合的日志数量

Aggregated entries: 3.

本条日志摘要中包含的日志数量

最高等级Highest severity level

被聚合的日志的最高严重等级

Highest severity level: Error.

被聚合的日志的最高严重等级

 

2. 日志摘要文件举例

以下显示信息为日志摘要文件的样例:

·     仅有1个日志事件元素:

2021-03-08 22:15:00 to 22:15:59, device 80.0.0.13(16X-B) encountered the following events: Interface Ten-GigabitEthernet11/2/1 link down. Aggregated entries: 7. Highest severity level: Error.

//2021-03-08从22:15:00起到22:15:59为止,名称为16X-B,IP地址为80.0.0.13的设备存在如下日志信息Ten-GigabitEthernet11/2/1链路down,聚合日志数量为7条,被聚合的日志的最高严重等级为Error。

·     有多个日志事件元素:

2021-03-08 22:17:00 to 22:17:59, device 80.0.0.13(16X-B) encountered the following events: 1. Interface Ten-GigabitEthernet5/2/2.2 physical down. 2. Interface Ten-GigabitEthernet5/2/2.1 physical down. 3. Interface Ten-GigabitEthernet5/2/2.3 physical down. Aggregated entries: 3. Highest severity level: Error.

//2021-03-08从22:17:00起到22:15:59为止,名称为16X-B,IP地址为80.0.0.13的设备存在如下日志信息Ten-GigabitEthernet5/2/2.1、Ten-GigabitEthernet5/2/2.2、Ten-GigabitEthernet5/2/2.3物理链路down,聚合日志数量为3条,被聚合的日志的最高严重等级为Error。

·     无日志影响元素:

2021-03-08 22:22:00 to 22:22:59, device 192.28.200.201(12508 W) encountered the following events: Many MAC addresses moved from port Ten-GigabitEthernet4/0/5:1 to port Ten-GigabitEthernet4/0/5:2. Aggregated entries: 5. Highest severity level: Warning.

//2021-03-08从22:22:00起到22:22:59为止,名称为12508 W,IP地址为192.28.200.201的设备存在如下日志信息:MAC地址从端口Ten-GigabitEthernet4/0/5:1迁移到端口Ten-GigabitEthernet4/0/5:2。聚合日志数量为5条,被聚合的日志的最高严重等级为Warning。

·     仅有1个日志影响元素:

2021-03-08 22:19:00 to 22:19:59, device 77.1.1.4(S7503E) encountered the following events: 1. Transceiver on Ten-GigabitEthernet1/2/0/23 is NOT sold by H3C. 2. Transient physical state change on interface Tunnel4. 3. Interface Tunnel4 physical up. Impact: Flow stability on Ten-GigabitEthernet1/2/0/23. Aggregated entries: 22. Highest severity level: Error.

//2021-03-08从22:19:00起到22:19:59为止,名称为S7503E,IP地址为77.1.1.4的设备存在如下日志信息:1.接口Ten-GigabitEthernet1/2/0/23上的光模块非H3C产品。2.Tunnel4的光模块物理状态变化。3.Tunnel4的物理状态变为up。可能影响接口Ten-GigabitEthernet1/2/0/23的流量转发稳定性。聚合日志数量为22条,被聚合的日志的最高严重等级为Error。

·     有多个日志影响元素:

2021-03-08 22:21:00 to 22:21:59, device 192.28.200.201(12508 W) encountered the following events: 1. Fan 1 failed. 2. Slot 2 rebooting. Impact: 1. IS-IS neighbor down. 2. OSPF neighbor down. 3. OSPFv3 neighbor down. Aggregated entries: 9. Highest severity level: Critical.

//2021-03-08从22:21:00起到22:21:59为止,名称为12508 W,IP地址为192.28.200.201的设备存在如下日志信息:1.风扇模块1 失效。2.槽位2重启。可能影响为1.IS-IS邻接状态down. 2.OSPF邻接状态down.3.OSPFv3邻接状态down。聚合日志数量为9条,被聚合的日志的最高严重等级为Critical。

3.1.4  故障根因定位的格式

1. 故障根因定位的字段

通过display ai ai-fault-analysis root-cause命令可以查看故障根因文件的信息,该文件中各字段的含义如表3-2所示。

表3-2 故障根因文件的字段

字段

描述

举例

备注

时间

以年月日时分秒表示

"2021-03-08 22:15:00"

故障发生时间

故障描述

故障告警的简要信息

fault BFD_Session_Down occurred on (device=77.1.1.41, session=21.2.1.1/21.2.1.2).

包含故障的简要描述和发生故障的设备地址,业务信息

固定描述字段

根据是否存在疑似根因,固定描述字段存在两种情况:

·     无疑似根因:root issue no causes found

·     有疑似根因:Possible root cause:

Possible root cause:

可能存在AI进程无法判断的故障

严重等级severity

故障的严重等级或者故障根因的日志严重等级

severity=Error

无疑似根因则显示为故障的严重等级,有疑似根因则显示为故障根因的日志的严重等级

疑似根因的可能性probability

引起故障原因的可能性

probability=0.8

无疑似根因则不显示此信息

故障的根因发生时间

引起故障的根因可能是某个日志记录的事件,此信息为该日志发生的时间

2021/3/8 22:21:52

无疑似根因则不显示此信息

故障的根因的设备地址

引起故障的根因可能是某个日志记录的事件,此信息为产生日志的设备的IP地址

192.28.200.201

设备信息年内容在“device”之后,包括:设备地址、设备名称

故障的根因的设备名称

引起故障的根因可能是某个日志记录的事件,此信息为产生日志的设备的名称

(12508 W)

故障的根因涉及的网元

引起故障的根因涉及的具体接口或槽位等信息

(device=192.28.200.201, mdc=1, chassis=0, slot=2)

故障的根因涉及的网元通常在“encountered xxxx on”信息之后

详细描述Details

故障根因的详细描述信息或者是故障本身的详细描述信息

Details: Board is rebooting on slot 2.

根据是否存在疑似根因,详细描述信息存在两种情况:

·     无疑似根因则显示故障的详细描述

·     有疑似根因则显示为故障根因的详细描述

 

2. 输出样例

故障根因的输出样例如下:

·     无根因

2021-03-09 10:43:30, fault BFD_Session_Down occurred on (device=77.1.1.41, session=21.2.1.1/21.2.1.2). root issue [severity=Notification], no causes found. Details: Sess[21.2.1.1/21.2.1.2, LD/RD:4128/4119, Interface:Vlan202, SessType:Ctrl, LinkType:INET], Ver:1, Sta: UP->DOWN, Diag: 3 (No Diagnostic)

//2021-03-09 10:43:30发生故障,设备IP地址为77.1.1.41,会话本端和远端地址分别为21.2.1.1和21.2.1.2的BFD会话Down。未发现故障根因。故障的详细信息为:BFD会话本端和远端地址分别为21.2.1.1和21.2.1.2,本端和远端标识符分别为LD/RD:4128/4119,接口Vlan202,BFD会话类型为控制报文,LinkType为INET,版本号为1,BFD会话由up变为down,Diag: 3 (No Diagnostic)

·     仅有1个根因

2021-03-08 22:21:43, fault OSPF_Neighbor_Down occurred on (device=192.28.200.201, route=OSPF, ospfId=1). Possible root cause: [severity=Notification, probability=0.8] 2021-03-08 22:21:52, device 192.28.200.201(12508 W) encountered DEV_BOARD_REBOOT on (device=192.28.200.201, mdc=1, chassis=0, slot=2). Details: Board is rebooting on slot 2.

//2021-03-08 22:21:43发生故障,设备IP地址为192.28.200.201,OSPF进程1的邻居Down。可能的故障根因为:2021-03-08 22:21:52, IP地址为192.28.200.201,名称为12508 W的设备单板重启,单板位于mdc=1, chassis=0, slot=2,故障根因的严重等级为Notification,故障根因的可能性为80%。故障根因详细描述为槽位号为2的单板重启。

·     有多个根因

2021-03-08 22:20:30, fault Interface_Flapping occurred on (device=77.1.1.4, mdc=1, port=Tunnel4). Possible root causes: 1. [severity=Error, probability=1.0] 2021-03-08 22:20:30, device 77.1.1.4(S7503E) encountered IFNET_TNL_PHY_UPDOWN_DERIVE on (device=77.1.1.4, mdc=1, port=Tunnel4). Details: Transient physical state change between up and down occurred on interface Tunnel4. 2. [severity=Warning, probability=0.7] 2021-03-08 22:19:26, device 77.1.1.4(S7503E) encountered OPTMOD_PHONY_MODULE on (device=77.1.1.4, mdc=1, chassis=1, slot=2, port=Ten-GigabitEthernet1/2/0/23). Details: Ten-GigabitEthernet1/2/0/23: This transceiver is NOT sold by H3C. H3C therefore shall NOT guarantee the normal function of the device or assume the maintenance responsibility thereof!

//2021-03-08 22:21:43发生故障,设备IP地址为192.28.200.201,OSPF进程1的邻居Down。可能的故障根因为:2021-03-08 22:21:52, IP地址为192.28.200.201,名称为12508 W的设备单板重启,单板位于mdc=1, chassis=0, slot=2,故障根因的严重等级为Notification,故障根因的可能性为80%。故障根因详细描述为槽位号为2的单板重启。

3.2  AI日志聚合和根因分析配置任务简介

AI日志聚合和根因分析配置任务如下:

(1)     开启AI日志聚合和根因分析功能

(2)     保存日志聚合摘要文件或者故障根因文件

3.3  配置准备

在配置AI日志聚合和根因分析任务之前,需要在设备上开启信息中心功能,并执行info-center loghost命令将本地环回地址127.0.0.1配置为日志主机地址,固定使用UDP端口514作为监控端口,不可修改。

3.4  开启AI日志聚合和根因分析功能

(1)     进入系统视图。

system-view

(2)     进入AI-Service视图。

ai-service

(3)     开启AI日志聚合和根因分析功能。

ai ai-fault-analysis enable

缺省情况下,AI日志聚合和根因分析功能处于关闭状态。

3.5  保存日志聚合摘要文件或者故障根因文件

(1)     可以在任意视图下,执行本命令,保存日志聚合摘要文件或者故障根因文件或者AI日志聚合和根因分析功能的日志。

ai ai-fault-analysis save { logfile | root-cause | summary }

缺省情况下,系统不会保存日志聚合摘要文件、故障根因文件和AI日志聚合和根因分析功能的日志。

3.6  AI日志聚合和根因分析的显示和维护

在完成上述配置后,在任意视图下执行display命令可以显示日志摘要文件和故障根因文件,用户可以通过查看显示信息分析和定位故障。

表3-3 AI日志聚合和根因分析的显示和维护

操作

命令

显示AI分析的日志聚合摘要和故障根因文件中的信息

display ai ai-fault-analysis { logfile | root-cause | summary } [ tail line-number ]

 


4 AI设备异常检测

4.1  AI设备异常检测简介

1. 功能简介

在管理和维护设备时,运维人员可以手工配置不同指标的资源使用率告警门限,例如执行resource-monitor resource命令配置CPU利用率或ARP表项资源等各类指标的告警门限,达到指定的告警门限时系统才会产生告警信息,但是,这类告警信息不能反映出相应资源使用率的变化趋势,而且手工指定告警门限的合理性存疑,如果误配置了告警门限以后会干扰对故障的判断,不利于未来智能运维手段发展。

AI设备异常检测功能借助AI算法来推测当前的设备各种资源表项使用率是否存在异常,判定异常之后才会产生告警信息,相较于传统静态设置告警门限触发告警的方式更加科学。

2. 工作原理

当前支持AI设备异常检测功能的告警指标为CPU使用率和设备的各类表项资源,具体设备表项资源可以通过display resource-monitor命令查看。

根据设备型号不同,采集的指标数据不同,AI设备异常检测最多通过三轮不同AI检测算法来动态判断当前指标的资源使用率是否异常。主要的工作机制如下:

(1)     采集数据:设备上开启AI设备异常检测功能后,AI设备异常检测进程通过Netconf采集设备不同指标的资源使用率信息,每条数据中包含设备信息,时间戳,指标的资源使用率等关键信息。

(2)     第一轮AI算法检测:AI设备异常检测进程通过学习设备上采集的历史指标,分析其变化趋势,推断出正常指标的动态阈值范围模型,AI设备异常检测进程也可以直接通过AI模型文件加载,生成数据指标的动态阈值范围模型。AI设备异常检测进程根据该模型实时对现网的数据进行检测,如果当前采集到数据属于模型的阈值范围内则无异常,否则将该指标数据标记为异常数据。对于不同指标,根据指标的波动性、趋势性等特点,AI设备异常检测进程可以自动选择合适的第一轮AI检测算法。图4-1中蓝色的区域是即正常指标的动态阈值范围。

图4-1 AI设备异常检测的第一轮检测算法示意图

(3)     第二轮AI算法检测:被第一轮AI算法标记为异常的指标数据还需要再进行第二轮异常检测算法。第二轮AI算法检测是基于多种无监督异常检测进行投票的异常检测机制,根据数据的统计学特征,采用多种AI算法进行异常判定,被判定为异常的指标数据根据设备和指标类型可能还需要再进行第三轮AI算法检测。

(4)     第三轮AI算法检测:第三轮检测采用基于设备芯片的深度学习中的无监督算法——deepar算法。

(5)     只有上述多轮异常检测的结果均为异常时,AI设备异常检测进程才会产生该指标的使用率异常告警,多轮AI算法的检测使得异常判断更加准确和智能。

4.2  AI设备异常检测的配置任务简介

(1)     开启AI设备异常检测功能

(2)     (可选)保存AI设备异常检测功能的日志文件

4.3  开启AI设备异常检测功能

(1)     进入系统视图。

system-view

(2)     进入AI-Service视图。

ai-service

(3)     开启AI设备异常检测功能。

ai key-resource-monitor enable

缺省情况下,AI设备异常检测功能处于关闭状态。

4.4  保存AI设备异常检测功能的日志文件

1. 功能简介

AI设备异常检测功能的日志文件可以帮助运维和技术支持人员分析AI设备异常检测功能判断异常的效果。AI设备异常检测功能的日志中包含采集的各类指标使用率信息,多轮AI算法对异常指标判定的依据。

2. 配置步骤

(1)     可以在任意视图下,执行本命令,保存AI设备异常检测功能的日志文件。

ai key-resource-monitor save logfile

缺省情况下,不会自动保存AI设备异常检测功能的日志文件。

4.5  AI设备异常检测功能的显示和维护

在完成上述配置后,在任意视图下执行display命令可以显示AI设备异常检测功能的日志,技术人员可以通过查看显示信息分析和定位故障。

表4-1 AI设备异常检测功能的显示和维护

操作

命令

显示AI设备异常检测的运行日志

display ai key-resource-monitor logfile [ tail line-number ]

 

 

不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!

新华三官网
联系我们