网络管理告警系统.docx

网络管理告警系统.docx

《网络管理告警系统.docx》由会员分享，可在线阅读，更多相关《网络管理告警系统.docx（21页珍藏版）》请在冰豆网上搜索。

网络管理告警系统

网络管理—警告系统的设计

1设计目标

1．数据采集：

通过采集计算网络中的配置信息，告警信息，性能信息，反馈给告警中心。

2．数据分析：

分析告警信息（原始告警信息，性能数据，配置信息），推理处理并存储记录告警，且实现告警的可确认消除（自动回复/手动恢复）。

3．数据应用：

实时监控重要的告警信息，解决并消除告警信息。

根据告警信息记录生成报表统计，向上层提供决策的数据依据。

2概要设计

系统分三层：

数据的采集数据处理数据应用

数据采集：

从系统的网元上采集数据包括：

性能数据信息，网元告警信息，拓扑结构的配置信息，向数据处理层的制定临时数据库中传送。

数据处理：

从指定的数据库中获得原始数据信息，判断处理。

根据估值（及性能阀值）判断生成警告信息，存储分析并上报告警信息。

实现告警的匹配确认清除，重复告警的归并处理。

数据应用：

及时监控重要的告警信息，并处理此告警，反馈告警的确认信息。

根据不同的用户需求展现告警统计信息报表，为决策提供数据支持。

3数据采集层

3.1内容

3.1.1配置数据采集的内容

及获得该网络中的网元设备，基本信息，与实体形成对应的映射。

用于网络的拓扑信息管理。

网管系统管理采集以下配置数据：

3.1.2告警数据采集的内容

3.1.2.1告警源

需要采集的告警报告分为：

网元告警

●路由器：

●交换机：

●配线板：

●服务器：

cpu,内存，硬盘，电源，风扇（散热），网卡，光驱，端口，运行的软件服务

1．环境告警:

暂保留。

2．通信连接告警（拓扑管理）：

当某一网元设备持续一定时间不响应网管系统时，网管系统应能自动生成该网元设备的通信连接警。

3．性能告警：

当性能指标超出预先设定的范围时，系统触发的告警称为性能告警。

4．设备告警：

来自设备红端的告警信息。

3.1.2.2原始告警数据内容

原始告警数据是从告警源采集到的未经任何处理的原始告警信息，格式和内容与网元类型相关，原始告警信息将在告警管理应用层进行处理，采集层采集到的告警原始数据至少应包括以下内容：

中文名称

名称

说明

类型

告警的序列号

Alarm_id

告警的序列号

字符串

网元的识别名

Dn

网元的识别名

字符串

告警发生时间

Occur_time

告警发生时间

时间

告警清除时间

Clear_time

告警清除时间

时间

告警原始类型

org_type

告警类型

字符串

告警原始级别

org_severity

告警级别

字符串

活动状态

activestatus

活动状态

整数

告警标题

Title

告警标题

字符串

告警内容

alarm_text

告警内容

字符串

3.1.3性能数据采集的内容

针对不同的网元，采集其对应的性能信息。

格式和内容与网元的类型相关。

在采用阀值过滤器，判断产生原始的警告信息。

3.2方式

采集方式分两种：

1．直连网元及直接连接到网元设备，进行数据采集。

（使用于小的系统）

2．系统采集及上一级的网管通过下一级的网管来获取数据。

（使用于多个小系统集成的大型系统）

3.3要求

配置、性能、告警原始数据至少要保留一周以上。

对配置数据、告警数据和性能数据采集的要求不尽相同，下面分别进行说明。

3.3.1配置数据采集的要求

为了在用户层展现的网络结构与实际的网络结果相对应，需要周期性的检测当前网络的连接情况，设备的运行情况等实时信息：

●在系统相对稳定的情况下，网管系统能够按照用户预定的时间表定时的、周期性地自动采集配置数据,时间表中的采集开始时间和采集周期可由用户设置；

●如果由于网络或者其他原因，网管系统没有正确采集到网元的配置数据，网管系统能够让用户在必要时手工启动配置数据采集程序进行重采或补采，并可按网元组、地区进行分别采集刷新配置数据；

●网管系统以报告等方式方便地检查每个网元的配置数据采集情况，即该网元的配置数据的更新情况。

3.3.2告警数据采集的要求

实时地采集所有网元（NE）生成的各种设备故障告警报告、网络事件报告以及与网络、业务相关的故障报警报告。

为保证数据采集的完整性，告警数据采集层必须提供手工采集手段，并应具备以下主要功能：

●能够自动采集告警数据，采集时间和采集周期可设置；

●能够实时接收由厂家OMC或网元设备实时上报的告警信息；

●需要时能够即时手工启动告警数据采集程序，保证数据采集的完整性；

●可根据需要，按告警网元、告警级别、告警类别等条目或按一定地区进行设置，实现过滤采集。

3.3.3性能数据采集的要求

性能数据采集应具有以下四个主要功能：

●能够周期性地24小时自动采集性能数据，采集周期和采集时间可选择，最小的数据采集时间周期为15分钟，采集的时间粒度可以基于网元或地区进行选择；

●能够即时手工启动性能数据采集程序（分地区、分时段）；

●当报表数据不全时，能够提供简单的手段确认所采集的网元数据的齐全；

●采集和补采的数据能够自动入库。

4数据处理层

原始数据通过数据采集层进入系统后，数据处理层对这些原始数据进行归纳整理，实现数据结构规范化，为数据应用层实现具体功能提供支持，便于系统的二次开发和新的应用功能的提供。

处理层数据至少需要保存6个月。

以下从配置、告警和性能三方面对数据处理层进行说明。

4.1配置数据处理层

本节从信息归一化、配置数据的存储、刷新和备份等四方面进行说明。

4.1.1配置信息归一化

配置数据采集到网管系统之后，必须进行归一化、数据结构规范化，使数据应用层的相关应用能够方便地使用这些数据。

配置信息按照交换机，路由器，服务器，等六个方面进行归一化，具体内容参见附录。

4.1.2配置数据的存储

网管系统应能够将不同种配置数据转换成以上描述的归一化标准数据格式并存储到数据库中，为性能、告警等应用提供数据支持，为二次开发或其他的后处理提供标准的存储接口。

4.1.3配置数据的刷新

网管系统发现新的配置数据采集结果与网管数据库中的配置数据不同时，如网元的增加、删除、网元属性改变（何种属性），需要用户确认，并生成变更记录，作为采集日志的一部分，供用户后期查询，同时更新网络拓扑图等相关的上层应用程序的配置数据，使上层应用能够呈现网络的最新配置信息。

4.1.4配置数据的备份

网管应提供对配置数据的快照功能（即备份功能），用户通过此功能可将当前网络的配置信息存储下来，供其他应用所调用。

快照可以由网管系统按照时间表的设置自动进行或由用户手动启动。

快照后的配置信息可用于：

网络配置信息的历史对比

配合性能，告警数据做网络多维分析

4.2告警数据处理层

以下对告警数据的处理进行说明。

4.2.1告警信息格式标准化

采集层采集到的原始告警数据要经过告警数据处理层的处理，处理后提供的标准化数据应包括以下内容：

中文名称

名称

说明

类型

告警的序列号

Alarm_id

告警的序列号

字符串

网元的识别名

Dn

网元的识别名

字符串

告警发生时间

Occur_time

告警发生时间

时间

告警确认时间

ack_time

告警确认时间

时间

告警清除时间

clear_time

告警清除时间

时间

告警类型

type

告警类型

整数

告警级别

Grade

告警级别

整数

告警原始类型

org_type

告警类型

字符串

告警原始级别

org_severity

告警级别

字符串

活动状态

activestatus

活动状态

整数

告警源

source_type

字符串

确认操作员

ack_optr

确认操作员用户名

字符串

清除操作员

clr_optr

清除操作员用户名

字符串

告警标题

Title

告警标题

字符串

告警内容

alarm_text

告警内容

字符串

告警的原始信息

中文名称

名称

说明

类型

告警的序列号

Alarm_id

告警的序列号

字符串

网元的识别名

Dn

网元的识别名

字符串

告警发生时间

Occur_time

告警发生时间

时间

告警清除时间

Clear_time

告警清除时间

时间

告警原始类型

org_type

告警类型

字符串

告警原始级别

org_severity

告警级别

字符串

活动状态

activestatus

活动状态

整数

告警标题

Title

告警标题

字符串

告警内容

alarm_text

告警内容

字符串

4.2.1告警的重定义

应允许用户根据管理工作重心的变化，按照可能原因、网元类别、网元识别码、原告警类型、告警级别、时间类型等条件及各种条件的组合对告警类型和级别进行重定义。

告警级别分为严重告警、主要告警、次要告警、警告告警；告警类别分为通讯告警、环境告警、设备告警、处理错误告警、服务质量告警；

4.2.2告警过滤（通过推理机的知识库来过滤，且知识库是对管理员可维护。

）

对单位时间内发生的大量告警，能按用户要求和管理部门的考评要求及实际管理情况，对告警网元、告警级别、告警类别或告警标题等条目进行过滤。

告警数据过滤用于过滤掉从底层提取的告警信息中监控人员认为不重要的信息，从而减少轻微告警的干扰，以提高监控与处理的效率。

应能对告警数据过滤的开启状态进行手工设定。

1、过滤后的告警信息的处理

经过过滤后的告警信息最后应插入当前告警数据表。

对系统数据库中的告警信息要加过滤标志。

2、告警数据的过滤条件

对象：

选择过滤掉哪些对象的告警信息。

监控人员可通过三种方式选择对象：

单个或多个对象（必须是同一网元类型）；

同一网元类型的所有对象；

某一地区内同一网元类型的所有对象；

告警级别：

选择过滤掉选定对象的哪一级别的告警。

过滤模式：

定义派生的告警信息是否写入系统数据库。

确认模式：

定义符合条件的告警信息的确认模式。

由监控人员手工确认。

告警信息采集上来后自动确认。

告警信息取消时自动确认。

4.2.3告警传递

为了保证底层对象（有可能在拓扑图或导航器中当前不可见）的告警信息也能及时地显示，监控界面对底层对象的告警应逐层传递给其父对象，即改变其父对象子告警状态及子告警次数，引起其父对象状态图标的变化，从而达到实时监控的目的。

在展现层进行逐层的展现。

4.2.3.1告警传递的方式

在网元逻辑关系树中，树的底层节点网元发生告警时，应上传到上层的一级或多级网元节点，告警传递层数应可由用户根据需要设置，系统默认为一层。

4.2.3.2传递的告警信息的显示

当父对象有由子对象传递上来的告警时，要显示出有子对象告警的状态

当父对象有子对象告警时，设置该父对象的状态为有子对象告警，并将子对象告警数目加一（在设备状态表中提供相应字段，子对象告警状态与次数）

当取消子对象告警时，父对象的子对象告警数目减一。

当减为零时，设置该父对象的状态为无子对象告警。

4.2.4告警相关性分析及处理（可选）

首先定义告警相关及处理的具体规则，对每条将要入库的告警信息按规则进行相应的告警相关性分析，然后根据分析结果进行相应的处理。

告警相关分为两类，一类产生新的告警，涉及告警的自定义，另一类并不产生新的告警。

例如：

对单位时间内频次过高或历时过长的告警（门限可设）能派生新的告警报告（告警派生）。

消除重复发送的同一告警；

去除已有告警引起的其他告警；

推测出一组告警中的决定性告警，并清除其他次要告警；

对频繁发生的告警自动提高告警级别，从而保证网管中心告警信息的有效性、重要性。

4.2.5告警故障定位（可选）

告警故障定位到网元级，

如果厂家的告警报告包含了板卡级的定位信息，要求进行板卡级的故障定位；如果厂家的告警报告不包含了板卡级的定位信息，则不做要求。

4.2.6告警取消

告警自动取消

当从底层告警数据源采集到告警取消信息时进行告警的自动取消；

告警自动取消时，当前告警数据表删除对应记录，历史告警数据表增加对应记录；

告警自动取消时，根据相关性分析的设置，决定是否将相关的低级别告警同时自动取消；

告警自动取消时，应适时地通知由该告警产生的工作流；

若该告警仍未取消，则根据告警的确认模式决定是否自动确认；

告警手动取消

当维修人员修复故障后，提供手动取消相应告警的功能，在日志中应能记录手动取消者的身份。

4.2.7告警存储

故障管理系统能自动存储所有告警记录；原始告警信息在系统中至少保留一周以上，分类后的告警信息在数据库中按照告警类别、告警级别、业务种类、网元类别作不同期限的保存，逾期信息能够用磁带或光盘等介质备份。

●按告警类别

●按告警级别

●业务种类

●按网元类别

4.2.8告警数据的备份和删除

能够对告警数据进行备份或删除。

系统提供界面，能够按照用户的要求或时间表的设置对所采集的告警数据进行归档或删除；

4.3性能数据处理层

4.3.1性能数据归一化（对同一种类型的网元设备设置一个统一的性能数据表格）

性能数据采集到网管系统之后，必须进行归一化、数据结构规范化，使数据应用层的相关应用能够方便地使用这些数据。

4.3.1.1交换子系统的性能数据

4.3.1.2基站子系统的性能数据

4.3.1.3性能处理数据的属性集

性能处理数据的属性详见本规范第二册。

4.3.2性能告警数据

当性能指标超出预先设定的范围时，系统触发的告警称为性能告警。

系统需提供对性能告警信息的显示、查询和统计的功能。

用于性能告警的主要指标有：

●Cpu的使用效率

●交换机，路由器的丢包率

●网卡的的流量

●等等

4.3.3数据字典（可选）

数据描述部分（数据字典）是数据处理层的核心，它位于数据处理层，将性能处理数据和上层应用程序相隔离。

数据字典的控制对象是处理层数据。

处理层数据是原始性能测量经过处理、映射后在网元维、时间维、地域维上汇总之后的全集。

依据数据字典建立起来的模板从其中并且只能从其中获取数据。

4.3.4性能数据的存储

性能处理数据采用三维和多粒度方式存储。

●时间维－按粒度由小至大为：

小时，日，周，月，年。

●地域维－按粒度由小至大为：

地区（包括各地区／会城市／计划单列市），，全国。

●类别维－它的粒度可以对应于网元的类别，如：

小区，基站，基站控制器，交换机。

●对应于每一类性能数据，每一维都规定了最小粒度，网管系统必须存储最小粒度的数据；此外，网管系统还应根据用户的需要，兼顾效率，提供较大粒度上的汇总。

对采集到的原始测量信息分类入库至少一周，新业务至少二周。

性能处理层数据可以由管理人员根据时间粒度、业务种类决定存储的时间。

4.3.5性能数据的备份、删除和恢复

网管系统应该能够对性能数据进行备份、删除和恢复。

系统提供界面，能够按照用户的要求或时间表的设置对所采集的性能数据进行归档、删除和恢复。

5数据应用

处理告警上报，统计，以及展现统计数据。

告警监视器应能显示所有活动告警和已确认但未清除的告警。

此处略。

6详细设计

6．1概要设计模型

6.1.1告警的过滤模型

6.1.2告警数据处理层设计模型

7基本数据格式定义：

7.1告警信息的归一化

7.1.1原始告警信息内容

中文名称

名称

说明

类型

告警的序列号

Alarm_id

告警的序列号

字符串

网元编码

elementCode

网元的识别名

字符串

网元类型

elementType

网元的类型

整数

告警发生时间

Occur_time

告警发生时间

时间

告警原始类型

orgType

告警类型

整数

告警原始级别

orgGrade

告警级别

整数

活动状态

activestatus

活动状态

整数

告警标准名称

Alarm_Name

告警名称

字符串

告警内容

alarm_text

告警内容

字符串

7.1.1.2处理后的告警信息统一格式内容

中文名称

名称

说明

类型

告警的序列号

Sequence

告警的序列号

字符串

告警类型

alarmType

告警类型

整数

告警级别

alarmGrade

告警级别

整数

网元编码

elementCode

网元的识别名

字符串

网元类型

elementType

网元的类型

整数

告警内容

alarm_text

告警内容

字符串

告警状态

Status

告警的当前状态

整数

告警次数

Count

该告警的累计次数

整数

确认操作员

ack_User

确认操作员用户名

字符串

清除操作员

clr_User

清除操作员用户名

字符串

告警发生时间

Occur_time

告警发生时间

时间

告警确认时间

ack_time

告警确认时间

时间

告警清除时间

clr_time

告警清除时间

时间

告警的最近一次上报时间

Last_time

告警的最近一次上报时间,用于判断告警是否过期.

时间

告警原始类型

orgType

告警类型

整数

告警原始级别

orgGrade

告警级别

整数

告警标准名称

告警处理方法

关联告警名称

7.1.2告警的级别

告警级别

告警级别定义

告警说明

严重警告

Int2

可能引起系统不能正常工作的严重警告。

需要上报警告。

主要警告

Int1

可能引起严重警告的警告，必须上报。

提示警告

Int0

轻微级别的告警，可以直接忽略，属于提示性的信息。

每条告警通过告警条目的颜色标识相应的告警级别，由数据应用层来完成和定义。

7.1.2.2原始的告警级别

原始告警级别

告警级别定义

告警说明

7.1.3告警的级别重定义

网元告警：

把网元告警的级别划分为四个区间，进行告警级别的重定义。

性能告警：

有知识库的设定阀值来判断告警的区间，对性能信息实现过滤。

需要对多个告警信息进行归并处理，找出主要的告警信息，屏蔽次要的信息，减小信息量。

配置告警：

监测网络的配置是否有更新，设备是否有增减。

配置更新属于主要告警，设备增减属严重警告。

必须通知管理员，可能是设备停止运行，或链接掉线等严重故障。

7.1.4告警的类型

告警类型

告警类型定义

告警类型的说明

设备告警

Int0

与设备有关的告警，如电源，电压，服务异常等。

性能告警

Int1

与网络的性能质量有关的告警，网元在运行时的动态参数超出指定的预设阀值产生的警告。

通信连接告警

Int2

与网络的传输状态有关的告警，如：

断线，无连接响应。

环境告警

Int3

与环境有关的告警，如机房湿度，温度，火警，风度，噪音等。

7.2配置信息的归一化

7.3性能属性的归一化

8．各层的通信标准

8.1数据处理层和数据展现层的数据交互

8．1.1通信方式

采用ActiveMQ的jms机制通信，使用Publish的方式通信。

使用客户端服务器模式交互数据。

注：

此处数据处理层为服务器端，数据展现层为客户端。

8.1.2通信模型

●服务器端

告警上报

告警同步（考虑多服务器的并行时信息同步问题）

告警确认通知

告警清除通知

●客户端

告警确认

告警清除

●数据格式JMS

Header消息头

Properties属性

Body消息体

在Header中的MsgId中放入消息的命令类型（命令列表）。

在Body中放入命令的所需的参数。

●命令列表

消息通信的数据结构（此处把告警处理中心为服务器端server，web服务器端为客户端client）

命令类型

命令编码

消息方向

消息参数（详细信息见表）

功能说明

告警上报

10001

Server—client

PerformanceAlarm

通过告警对象的序列化之后传输到客户端。

超时告警上报

100011

Server-client

PerformanceAlarm

系统检测出的超时告警,需要手动来清除和确认的告警,则再次上报.

告警确认回复

100022

Server—client

PerformanceAlarm

（手动/自动）响应客户端的告警确认命令

告警清除回复

100033

Server—client

PerformanceAlarm

（手动/自动）响应客户端的告警清除命令

阀值修改回复

100044

Server—client

Properties

告警确认

10002

Client-server

PerformanceAlarm

发送给告警中心的确认告警信息

告警清除

10003

Client-server

PerformanceAlarm

发送给告警中心的清除告警信息

阀值修改

10004

Client-server

Properties

以properties的格式来设置性能阀值

●参数详解

1．告警上报：

PerformanceAlarm序列化对象

命令编码：

10001

主要内容：

参数名称

类型

参数含义

参数取值

备注

Sequence

String

告警的序列号

NOTNULL

告警序列号，作为告警的唯一身份

告警标准名

NOTNULL

alarmType

Int

告警类型

NOTNULL

设备告警/性能告警/环境告警/拓扑告警

alarmGrade

Int

告警的级别

NOTNULL

严重告警/主要告警/提示告警

argType

Int

原始告警类型

NOTNULL

待定（处理层对其初步处理）

argGrade

Int

原始告警级别

NOTNULL

待定（处理层对其初步处理）

elementType

Int

网元类型

NOTNULL

路由/交换机/服务器/

elementCode

String

网元编码

NOTNULL

网元的唯一识别码

alarm_text

String

告警原因

NOTNULL

产生告警的原因

告警的解决办法

关联告警名

status

Int

告警的状态

NOTNULL

产生/确认/消亡

count

Int

告警的次数

NOTNULL

告警累计次数

ack_User

String

确认告警的用户名

当系统自动确认时值为：

System

clr_User

String

清除告警的用户名

当系统自动清除时值为：

System

Occur_time

Date

告警出现的时间

NOTNULL

ack_time

Date

告警确认的时间

clear_time

Date

清除告警的时间

last_time

Date

最近一次告警时间

NOTNULL

做给告警超时的依据

2．告警确认回复（自动/手动）

信息载体：

PerformanceAlarm序列化对象

命令编码：

100022

主要内容：