网管故障数据采集专题

网管故障数据采集专题（2篇）

1.网管故障数据采集专题 篇一

作为一个网络管理员，唯一高兴的是完成最后一个任务，这就是这个职业的魅力和生命之所在。以前我们已经许多次精疲力尽，然后放弃。但是，我将在本文尽可能帮助广大网络管理员降低现实的困难。

我愿意和读者们共享自己的经验和秘诀。

窥视网管员的工具包

真正的硬件工具

每个网管员由于各自实际情况不同，随身携带的真正的硬件工具也未必相同。我的硬件工具包包括：螺丝刀、网卡、牙医镜和微型手电筒、线缆测试仪、录音设备等东西。下面我讲一下这些工具都干什么用。

螺丝刀：这个工具毋庸多言，就是拆开机箱用的。但有些服务器，比如早期的Compaq服务器(现在很少见了，说实话我也几乎没有见到过)，这个螺丝刀就必须是Compaq(Toex)螺丝刀，其末端是星形的，普通的十字螺丝刀是不能使用的。

网卡：用于在工作站或服务器上修复常见的问题，有时候可以用来确认原来的网卡是否有问题。

牙医镜和微型手电筒：这是个组合工具，可以让我在紧急时很容易看到组件的反面和主板。

线缆测试仪：用于网络布线的故障和测试定位，如果线缆测试仪很高级，可对线缆进行周期性检测，确保布线系统的质量。在评估认证后，将电缆测试仪存储的测试结果复制到计算机上并打印出来，作为网络布线基准文档。

录音设备：相信读者看到这设备肯定惊讶得下巴都掉了……其实，我也是从历次的教训中获取的经验。还记得有多少次在一个复杂的故障检修过程中一次又一次执行相同的步骤和操作吗?就好比在家中丢失了东西以后在已经找过的地方反复搜寻，这合理吗?我是从第一分钟起，将我所采用的每一个步骤口述到录音设备中，这种记录能使我回顾所采用的方法，并决定是否还要遵循检修的路径以及结果的本质。我之所以采用口述的方式，而不是用纸笔来记录故障检修的过程就是因为：厌倦!人们往往可以手写记录下故障检修过程的前面几个步骤，或者前面几个小时所采用的步骤，但会随着时间的推移，厌倦会导致这种工作的中断：所采用的步骤没有记录或者是跳过了记录。而口述是一种相对比较轻松的记录故障检修过程的工作，能记录下自始至终的每一步。

其他的工具，要视乎你的工具包是否还有额外的空间，以及你实际的情况，比如，昂贵的FLUKE网络测试仪器，并不是每个人都会配备的。

软件工具包

网管员可以根据自己的习惯、爱好等选择适合自己的软件工具包，软件工具包的形式可以是LiveCD或者集成了维修工具的Windows PE启动光盘，也可以是别的光盘，我用的Windows PE启动光盘是深山红叶工具光盘，很好用，网络上有很多与之相类似的工具光盘，

Live Cd我选择的是Knoppix汉化版，Live CD的选择有很多，比如Trinity Rescue Kit等等，都可以作为急救用的Live CD。

现在闪存容量越来越大了，加之现在的新电脑都支持从闪存启动系统，我们完全可以制作成Live USB，在一定程度上比Live CD更为灵活。即使不做Live USB，也可以把常用的工具拷贝到闪存内，以备急需。关于这方面可以参考我在5期《电脑自做》第96-101页刊登的《闪存扩展 随心而动》文章。

还有一些驱动软盘，虽说现在软盘和软驱近乎绝迹了，但有些场合还是需要的，比如RAID驱动程序等等。

杂项

其他还有一些乱七八糟的东西，我带的就有小门垫、工作服、套衫、休闲鞋、巧克力什么的。很惊讶吧?嗯。我带的小门垫的真实作用是在拥挤的服务器房绕电缆的时候，我跪在上面用来保护我的膝盖。而不是跪下向客户和管理人员请罪，哈哈!

很多公司对员工的着装有很严格的要求，必须穿正式的服装，不能穿休闲的，那么在脏乱的库房和机房里，这一身正式的、严肃的服装是不是很让你为难?我带一套工作服、套衫、休闲鞋就是为了应付这种窘境的。

巧克力是干什么的?不怕各位笑话，我这人有时候有点胆怯，面对未知的故障的时候有时会感到恐惧，这时候吃点巧克力能提高血糖帮助消除恐惧感。

笔记本

从一定意义来说，它可以说是工作日志。你可以用纸媒介的本子来记笔记，也可以用电子版形式的，只要能达到目的就好，我用的是电子文档。笔记本对于我来说，它的作用就是告诉我：出现问题时，哪些发生了变化。

当出现一个新的问题时，所要问的第一件事往往就是出现问题之前，是否有什么变化。

任何网络操作系统都是一个有问题的系统，有时因为一些不能解释的原因，甚至大部分无害的变化都有可能变得一团糟。如果你的笔记本，记录了每个服务器、每个设备所有变化的详细日志，能节省你用在故障检修上的数个小时。作为我来讲，我有每个服务器单独的Excel电子表格，记录了安装新软件包、安排重新启动与否、添加新驱动器或者别的软件等等，还有时间、日期、服务器每次变化的属性。

如果在本周对服务器所做的更改，在下周引起了问题，那么你的笔记本就将发挥非常大的作用。

笔记本对于任何故障的成功解决非常重要。一个人对管理机器明晰，而他的同事却什么都不懂，这就毫无意义了。我认为，这是一种非常危险的处境，特别是问题中的任务对网络的安全至关重要。如果一旦这个人发生意外，其余的人该怎么办呢?

从实践经验来看，随着新过程的发展将其文档化的做法是值得鼓励的。我就有过这种经历：曾经完美处理过一些事情，但仅仅过了一个月之后就遗忘了!这时候我多么希望自己以前就记录到笔记本上啊!这种情况经常会发生。

[1][2][3][4]下一页

2.网管故障数据采集专题 篇二

1 SNMP网络管理协议

SNMP简单网络管理协议是互联网工程工作小组 (IETF) 定义的一套网络管理协议采用Client/Server模型, 通过管理站 (Manager) 与节点上的SNMP代理 (Agent) 间的交互工作完成对网络的管理与维护。管理站可以通过SNMP协议远程管理所有支持该协议的网络设备, 检测网络的运行状态、修改网络设备的配置及接受事件报警等。

SNMP标准主要由三部分组成:管理信息库MIB:由网络管理协议访问的管理对象数据库;管理信息结构SMI:用于定义通过网络管理协议可以访问的对象的规则;SNMP网络管理协议:取得、设置和接受代理发送的意外信息。

2 SNMP协议管理模型

SNMP的网络管理模型如图1所示。

关键元素:管理站Manager、代理Agent、管理信息库MIB和网络管理协议SNMP。

管理站Manager:一般是一个独立的设备, 提供Operator与NMS的接口;

代理Agent:对Manager的操作请求进行应答, 并为Manager报告随机事件;

管理信息库MIB:被管资源某一方面的数据变量的集合;

网络管理协议SNMP:Get, Set, Trap。

SNMP网络管理模型采用Client/Server体系结构, 同时可将管理信息模型和被管理对象分成两个模块, 两个模块间通过信息交互协同工作。管理站端的NMS作为管理者, 向代理者发送SNMP请求报文。代理者通过查询被管终端的MIB得到要查询的信息, 向NMS发送SNMP相应报文。被管终端一旦达到模块定义的告警触发条件, 即通过代理向管理站的NMS发送告警Trap, 告知被管终端出现的情况, 以便网管人员及时对网络中出现的情况进行处理。其核心思想是:把复杂性放在客户端 (管理站) 上, 使服务器端 (被管终端) 简单化, 避免被管终端因忙于网络管理工作影响本职工作。

3 SNMP支持消息的格式和类型

管理站和被管理对象之间的通讯以SNMP消息交换的方式协同工作。消息的格式, 见表1。

Version:版本标识符, 确保SNMP代理使用相同的协议。

Community:团体名, SNMP认证消息的口令。

PDU:消息类型。指明SNMP的消息类型及相关参数。

SNMP有五种协议数据单元 (PDU) , 为了完成Set、Get和Trap几个重要功能, SNMP定义了五类消息。

取请求Get Request:用于查询一个或多个变量的值;

取下一个请求Get Next Request:允许在MIB树上检索下一个变量;

置请求Set Request:对一个或多个变量值进行设置;

取回答Get Response:相应Get/Set报文, 提供差错码、差错状态等信息;

陷阱Trap:向管理进程报告代理中发生的事件

4 基于SNMP数据采集的缺陷及不足

基于SNMP的数据采集就是采用SNMP协议, 由采集工作站定期向Agent发送指令, 以获取网络设备接口流量、网络链路传输延迟等网络功能信息。主要是通过对被管理网络设备的主要参数的轮询来实现对网络功能的检测。

随着网络规模的不断扩大, 一个网络往往由多个或大或小的子网组成, 同时网络的复杂性也不断增加, 网络中可能有很多网络软件提供各种服务。这将导致轮询数目的增加和分布在各处的被管对象的代理需要传输大量的网络功能检测数据, 使得网络管理信息流量过大, 以至于影响到正常的网络信息传输的效率。因此必须找到一种行之有效的方法, 降低网络检测信息流量与网络信息流量的比例。

另一方面, 由于网络用户对网络性能的期望越来越高, 网管系统也面临着越来越高的功能要求。网络管理员需要一种集成的信息模型, 以便更好的描述所管理的网络。因此, 对网络管理系统的检测功能要求就更高了。为了及时获取网络中所有的改变或服务器、应用程序性能下降的信息, 网络管理系统需要面向应用和服务进行频繁的数据轮询, 每一次管理应用程序请求信息时, 网络模型都会更新其所有属性, 因此产生大量的管理数据流。

针对这一问题, 对LHJU项目基于SNMP的网络管理系统的数据采集方法进行研究, 试图通过在一个采集层上综合使用各种优化策略的方法, 尽量减少网络上轮询包的数量。目标是使网络管理系统在采集请求数目最小的情况, 动态地请求多个变量的采集。

5 采集层

面向应用和服务管理需要更多的数据采集, 但是我们可以探讨其它一些因素:同一个轮询包中包含尽可能多的变量, 以便更高效地利用轮询包;优化采集层, 把不同管理应用发出的对相同管理数据的采集请求进行组合;当管理员为确诊应用或服务器故障而进行密集的数据采集时, 尽量确保较少的检测流量;根据不同变量所需要的采集质量, 选择不同的采集方法。为此, 我们在应用层和网络设备中的SNMP代理之间加入一个采集层, 通过在应用层提供具有不同属性的对象, 可以周期性地刷新属性, 实施不同的优化策略, 为网络管理员提供一个网络管理资源集成的透明的数据采集功能, 减少网络上的管理数据流量。

采集层的下层接口与SNMP代理交换, 上层接口把采集到的数据传送到应用层的对象属性中。一个属性对应于一个采集到的数据的“映像”, “映像”则体现了该属性在应用层的使用。这样管理应用程序就可以用一种透明方式使用这些对象。

因为SNMP代理上的同一个变量在不同的应用中的使用方式可能不同, 因此它的采集周期或采集变量就不同, 这里我们引入了“映像”, 它通过若干参数 (使用参数) 来显示与它相关的变量。

6 采集参数

变量的采集方式由它的使用方式决定, 如果一个对象属性用于精确的网络参数统计, 那么它的采集方式和那些在网络管理中偶尔使用的对象属性的采集方式就不一样。采集层的功能是给从SNMP代理中采集到的变量提供相应的映像, 使每个有确定使用方式的变量相对应的对象属性都与一个映像相关联, 确保映像和属性需求间保持一致。

变量采集的参数:属性刷新的间隔 Δt。根据使用这一数据的管理任务的精度或重要性, 属性刷新时间间隔可以从几秒到几小时不等。

刷新精度 ε:刷新精度用来确定什么情况下一个采集请求是可以被接受的。当采集请求在t=n·Δt时刻进行, 则SNMP代理在时间间隔[t-ε, t+ε] 内处理的采集请求都是可以被接受的。

补充 δ:若要在相同时间内采集尽可能多的变量, 就要为所有采集指定一个相同的起始时间t0, 但在某些情况下需要为t0添加一个补充。假如刷新周期为12小时, 而采集数据要在某一时刻进行, 比如说每天上午9 点和下午9 点, 这时就要对这一时刻添加一个补充。如果要对8000 个节点进行数据采集, 那么管理应用就会在t0这一时刻发送8000 个数据采集请求, 这一时刻大量的请求包的发送、处理和应答会导致管理站点过载, 网络堵塞, 甚至丢包。如果我们把每12 个小时按分钟划分为720 个时间片段, 在每个时间片段对10 个站点进行采集, 就可以解决上述问题了。

更新方法U:它决定了什么时候映像应该更新对象属性, 更新方法有:急切更新——映像每次获得一个新的值时, 都立即更新对象属性;周期性更新——对象属性会在每个 Δt时间周期进行一次更新;惰性更新——在收到更新请求时, 对象属性才更新。

可靠性A:更新策略根据可靠性参数选择。

7 采集层框架结构 (见图2)

映像:映像表示SNMP代理上相同的变量在不同应用中的不同的使用方式, 它决定了采集到的数据是否需要传送给对象属性, 映像准确地体现了在应用层该属性的使用。

周期采集请求:周期采集的特征被封装为周期采集请求对象, 向映像提供满足参数定义的最新数据。周期采集请求明确定义了采集周期 Δt, 刷新精度 ε 以及补充 δ。

变量:一个采集层变量实例和从一个预先定义好的SNMP代理中采集到的MIB数据相关。

采集者: 执行变量提交的周期采集请求, 发送SNMP采集包。

8 优化策略

采集层给予用途建立, 管理数据采集的策略由管理应用的需求决定, 数据采集对象根据管理应用的需求建立, 对象的属性映射为映像的使用参数, 数据采集受映像的使用参数控制。

8.1 采集层优化

适时发送协议数据单元PDU, 采集者通过优化算法, 尽量在较少的PDU中包含尽量多的变量, 也就是减少发送包的数量, 增加每个发送包中的采集请求, 实现减少管理数据流量的目的。

8.2 变量层的优化

变量将一个新的映像定义为 (Δt, ε, δ, U, A) , 通过更新方法U和映像可靠性A, 明确定义了映像的使用, 当A (可靠性) 不要求映像有一个及时更新的值的时候, 就不需要周期采集。这样变量产生的周期采集请求就可以减到最少。

8.3 SNMP层的优化

这是一个简单的优化:去除协议数据单元PDU中的重复变量, 避免不同的映像重复请求相同的变量。

8.4 表的优化处理

有些管理平台通过发送连续的Get Next Request从表根开始的遍历采集表数据。这种方式效率极低, 因为一个管理应用只对表里一部分的列感兴趣。如果引入采集层, 管理应用生成它的对象所需要的列, 只有这些列被采用。使用相同的取下一个请求Get Next Request, 采集者可以并行采集多列数据, 当这些列同属一个表时, 每一个请求即可得到表中的一行数据。这样, 采集请求的数量等于表的行数, 不同表的列可用同一个Get Next Request请求。当表中所有行的数据都已获取, 该表的列就从Get Next Request请求中移除。

我们很难估计一个PDU内可以包含多少个变量, 这与对象标识符的长度及变量的类型都有关系。我们只能根据MIB中所采集的变量类型, 大概估计一下相应包的大小。当采集变量太多时, 从SNMP代理返回的应答就有可能无法装入这个PDU, 最终导致包的丢失。

9 结语

本文通过探讨基于SNMP的集中式数据采集导致网络管理流量较大的问题, 采用多层结构实现对现有采集策略的优化, 关键是在采集层上通过映像的使用参数, 把对SNMP代理的采集请求数量降到最低。在采集密集的情况下, 采集层的性能将更好。

参考文献

[1]M.Cheikhrouhou, J.Labetoulle.An Efficient Polling Layer for SNMP[J].IEEE Internet Management, 2000 (12) :477-490.