随着高校图书馆信息化建设的不断推进,图书馆的电子文献馆藏比重日益增大,电子资源在馆藏体系中的地位和所发挥的作用也愈来愈重要。实际工作中,因电子资源服务器上的服务平台不稳定、软件冲突、访问用户过多、日志溢出等问题,各种电子资源服务会中断或者不响应,给读者带来了极大不便。因此急需建立一个电子资源服务监控系统来实现主动管理。

电子资源管理中出现的问题实际上是网络服务监控的问题。网络服务监控的研究工作主要以商业化监控软件为主。国外的软件有：SolarWinds公司的Orion Network Performance Monitor^{[ 1]},AdventNet公司的Applications Manager^{[ 2]},IBM的Tivoli NetView^{[ 3]}和HP的OpenView^{[ 4]}等。国内软件有游龙科技的Site-View、网路岗、聚生网管等。这些商业监控软件在实现方式上主要采用远程登录到被监控机器上或者在被监控机器上安装代理（Agent）等方式来对其进行监测^{[ 5]}。这样既不安全,也没有足够的权限对所有的数据库进行监控。同时这些平台大都应用于大规模的网络观测活动,并不适用于图书馆电子资源的性能监控。

除商业软件外,目前国内外在高校图书馆电子资源服务监控方面已有一些研究。有的提出了要对电子资源服务进行监控的思想^{[ 6, 7]};有的是直接用NetFlow、Cacti、MRTG等现有的开源软件,如文献[8]-文献[10]等,这些开源软件只能进行流量统计而不能监测常用的服务、电子资源服务、数据库服务等;有的只能监测电子资源服务而不能监测数据库、Z39．50服务,如文献[11];有的能监测常用服务而不能进行流量统计,如文献[5]。

高校图书馆电子资源服务监控系统既能监测常用的网络服务、电子资源服务平台、常用的数据库服务、图书馆专有的Z39．50服务等,又能进行故障告警,还能通过进行流量统计来防止恶意下载。

要设计和实现这样一个系统,应该遵循实用性、全面性、图形化和可扩展等原则。笔者选择了简单网络管理协议（Simple Network Management Protocol,SNMP）和Java EE技术来进行设计和实现。

图书馆电子资源服务监控系统可以分为监测模块、故障处理模块、流量统计模块、安全管理模块、Web管理模块等。其系统结构如图1所示：

图1

	Figure Option ViewDownloadNew Window
	图1 系统结构图

各个模块的主要功能为：

（1）监测模块能监测HTTP、FTP、SMTP、POP3、IIS、Apache等常用服务,能监控电子资源服务平台,能够对SQL Server、MySQL、Oracle、DB2、Sybase等常用的数据库提供监测支持,能监控图书馆专有的Z39．50服务。

（2）故障处理模块能够对服务异常情况及时报警,以电子邮件或者短信方式通知管理员。

（3）流量统计模块可以监测整体流量、各个 IP流量排序、具体显示每个IP的通信流。当出现流量异常时,可能是有恶意下载现象出现,管理员可以查看、判断,对恶意下载者可以封杀,禁止其下载。

（4）安全管理模块通过使用加密、认证、VPN和防火墙技术等来保护访问点。

（5）Web管理模块是管理员监管各模块的窗口,通过该模块管理员能够直观地看到各种关键数据并进行相应的操作。

监测模块是系统的基础,它负责对配置的监测项进行监测,能够使用相应的协议访问服务,并返回服务的状态。根据协议,这些服务可以分为以下4类：

（1）网络基础服务,即通过SNMP协议获取交换机的工作状态,如端口状态、带宽、错误包情况、交换机内存等信息^{[ 12]}。

（2）电子资源服务,如中国期刊网的镜像KNS服务和万方数据的RMS Mirror服务等,可以通过SNMP协议对各电子资源服务器定期轮询,采集服务进程的CPU占有率、内存占有率和响应时间等数据。

（3）数据库服务,如SQL Server、MySQL、Oracle、DB2、Sybase等,通过JDBC连接并对特定的数据执行SELECT操作即可检查其工作状态。

（4）Z39．50服务,根据Z39．50协议对数据库进行查询操作即可检测其是否正常^{[ 13]}。

监测模块的系统结构如图2所示。

图2

	Figure Option ViewDownloadNew Window
	图2 监测模块的系统结构图

监测模块主要由监测模块数据库,监测配置模块,探测器,探测器调度模块,状态监视与分析模块,RRA,展示、分析、统计模块组成。其基本结构如图3所示。

图3

	Figure Option ViewDownloadNew Window
	图3 监测模块的基本结构图

（1）监测模块数据库

采用通用关系型数据库,如MySQL、Oracle,存储所有的监测项的配置数据及监测结果。

（2）监测配置模块

该模块通过Web的形式使用户可以将准备监测项目的基本配置进行输入和管理。

（3）探测器

针对不同协议实现的监测工具,它通过识别配置进行检测,返回相应服务的状态。

（4）探测器调度模块

通过使用java．util．concurrent包中新的多线程和队列实现,保证在规定的间隔进行服务运行状态的检测,而不会造成网络拥塞和对服务器造成Flood攻击。

（5）状态监视与分析模块

通过解析探测器返回的结果,对服务情况进行评估,将结果存入监测模块数据库,生成RRD（Round-Robin Database）文件^{[ 14]},对于异常情况调用故障处理模块进行处理。

（6）RRA（Round-Robin Analyser）

一个RRD文件和图形生成模块,用于对状态生成RRD数据库和相应的折线/柱状图。

（7）展示、分析、统计模块

该模块通过Web界面为用户提供各监测的状态情况、历史情况的图形化展示、数据输出及一些分析和统计工作。

监测模块对于每一个监测项都需要事先进行配置,形成结构化的配置数据,供探测器使用。其UML图如图4所示：

图4

	Figure Option ViewDownloadNew Window
	图4 监测配置UML图

可见,所有的配置对象都实现InspectorConfig接口,同时都扩展AbstractInspectorConfig抽象类。SwitchConfig类是交换机的信息,它包括交换机的SNMP口令和一个标识交换机类型的SwitchDialect类型数据。SwitchPortConfig是交换机端口配置信息,它指明交换的某个特定端口,以SNMP获取的IfEntry中IfIndex的值标记。HostConfig是服务器配置信息,有两个子类：Windows服务器的配置和Unix/Linux服务器的配置。ServiceConfig是一般服务的配置信息,如FTP、SSH、Telnet、POP3/SMTP等,它有一个扩展的属性：端口号Port。WebAppConfig类是Web服务的检测配置,包括服务端口和相应检测的WebAppDialect配置。DBConfig类是数据库配置,它包括数据库的JDBC连接字符串,如jdbc：mysql：//www．libary．fudan．edu．cn/main?autoReconnectForPools=true,用户名和密码,数据库类型可以通过JDBC连接的字符串分辨。

调度模块通过Executors．newSingleThreadScheduledExecutor（）方法生成ScheduledExecutorService对象用以启动计划任务,每个计划任务都是一个TaskCaller对象。TaskCaller负责分析配置数据,并据此启动不同的探测器。TaskCaller获取所有网络监测任务的配置信息,根据配置的交换机类型选取二层交换机或者三层交换机,分析采用不同的Parser解析配置信息,将解析出来的配置信息在实例化时传给Switch3Task或Switch2Task,这些Task通过调用DefaultSwitchInspector来进行状态检测,后者是一个通过SNMP协议进行检测的探测器。在检测完成后,调用相应的Parser分析状态数据并调用相应的状态监视与分析模块进行进一步的处理。其部分关键代码如下：

……

public void run（） {

log．info（＂Begin：＂+conf．getIp（））;

DefaultSwitchInspector dsi=new DefaultSwitchInspector（）;

dsi．setConfig（conf）;//设置配置信息

dsi．fetchIfInfo（）;//获取网卡信息

SwitchPortState s=（SwitchPortState）dsi．getState（）;//端口状态

dsi．setState（null）;

dsi．fetchCPU（）;//获取CPU信息

dsi．fetchMem（）;//获取内存使用情况

SwitchState ss=（SwitchState）dsi．getState（）;

ss．setObject（s．getObject（））;

ss．setBandrate（（int）（（float）s．getInband（）＊1000/s．getBandwidth（）））;//带宽信息

……//其他参数的获取,原理相同

}

……

网络状态探测器、电子资源服务探测器通过SNMP协议,对受管网络的所有交换机、服务器进行状态信息获取,使用SNMP的GetRequest方法和GetNextRequest方法,获取IfEntry或IfEntry2 OID中的数据取得端口信息,通过SysInfo OID获取交换机基本信息和持续工作时间,通过各设备厂商私有OID获取内存和CPU的使用情况。用TCPconnect连接到监控的服务端口,使用Connet函数完成一个三次握手过程（SYN,SYN/ACK,ACK）以计算服务的响应时间^{[ 11]}。利用ifAdminStatus和ifOperStatus,可以确定接口的当前状态。用ifInOctets和ifOutOctets来计算接口的利用率、丢包率和错误率等。数据库探测器只需要通过JDBC连接并对特定的数据执行SELECT操作即可检查其工作状态,此处不再赘述。

Z39．50探测器的设计,可以通过检测初始化和检索操作来验证服务是否正常。首先测试Z39．50服务能否打开。如果不能,说明Z39．50服务不正常;如果服务能打开,则对Z39．50服务进行检索操作。如果能返回检索结果,说明Z39．50服务正常;如果不能返回检索结果,说明服务不正常。其流程如图5所示。

图5

	Figure Option ViewDownloadNew Window
	图5 Z39．50服务监测流程图

探测器去探测交换机的信息、服务器的信息、数据库信息、一般服务的信息、Z39．50服务信息等,返回结果状态数据,所有的检测状态实现StateInterface接口,所有监测对象的状态都扩展于ObjectSate对象,它的Object属性指明该检测对象的实例。State是主状态,0是正常,1是严重错误,2是警告,3是其他;Updatetime是状态信息更新时间戳。这些数据被用于进行状态的分析和统计,最后被状态监视分析模块存储到数据库中。将数据与规则库中设定的阈值进行比较。这些阈值通过长期观察设定,一般认为CPU占有率80％以上连续两个周期就不正常,内存一般超过90％就不正常,响应时间超过2分钟就认定服务已停止等。当然这些阈值与具体的软硬件环境相关,具体设定要结合实际情况。对比后发现异常情况转入故障处理模块进行处理。

故障处理模块的作用是在发生故障或警告的时候使用短信、邮件等方式通知管理员,对于已配置如何重启服务的自动重启服务。其故障报警流程如图6所示。

图6

	Figure Option ViewDownloadNew Window
	图6 故障报警流程

其中,E-mail通知模块的设计采用SMTP协议,借助Java EE中的Messenger组件^{[ 15]}实现,在E-mail中可以使用HTML格式的内容,加入附件,发送至多人,并且支持抄送、暗送功能。短信通知功能主要借助于中国移动的企业级MAS系统^{[ 16]}所提供的API接口实现,部分代码如下：

private APIClient handler = new APIClient（）;

public void init（）//初始化

{

int connectRe = handler．init（host, name, pwd, apiId,dbName）;

if（connectRe == APIClient．IMAPI_SUCC）

info（＂初始化成功＂）;

else if（connectRe == APIClient．IMAPI_CONN_ERR）

info（＂连接失败＂）;

else if（connectRe == APIClient．IMAPI_API_ERR）

info（＂apiID不存在＂）;

if（connectRe ！= APIClient．IMAPI_SUCC）

{

usage（）;

System．exit（-1）;

}

}

……

public void run（）//短信发送

{

Random random = new Random（）;

long tmpSmId = 0;

long tmpSrcId = 0;

tmpSmId = random．nextInt（1000）;

tmpSrcId = random．nextInt（100）;

handler．sendSM（mobileStr．split（＂,＂）,content, tmpSmId, tmpSrcId）;

}

……

流量统计主要通过对服务器日志进行分析计算完成。使用分析程序分析用户的行为,其部分关键代码如下：

……

echo ＄user ＄pass | /usr/lib/squid/squid_ldap_auth - P-b o=library．fudan．edu．cn -f ＂（＆（uid=％s）（inetUserStatus=Active））＂ -h xxx．xxx．xxx．xx-p 389 -D ＂uid=xxxx,ou=xxxx,o=xxxxx＂ -w ＂xxxxxx＂

else

echo ERR

……

服务器日志Access Log记录在/var/log/squid/access．log中,使用分析程序即可以分析用户的行为,access．log是纯文本,如1282665629．192 10267 192．168．136．20 TCP_MISS/200 39214 GET http：//onlinelibrary．wiley．com/store/10．1002/hep．23597/asset/23597_ftp．pdf? - DIRECT/12．161．242．20 application/pdf。可以分析出用户的IP为192．168．136．20访问的URL,此条记录可以看出用户在onlinelibrary．wiley．com下载了一个大小10 267字节的PDF文件。通过分析,可以很容易地掌握用户的下载频率、下载总量等信息,把这些信息输入到恶意下载的判定模型中进行判定。笔者认为当用户下载频率达到每分钟一定篇数,或者在半个小时内从同一个数据库下载达到一定篇数即进行报警。在确定是恶意下载后,用户会被加入到BlackList中,当用户需要进行身份验证时,验证脚本便会给出ERROR的结果,从而阻止用户再次下载。用户的状态变迁如图7所示：

图7

	Figure Option ViewDownloadNew Window
	图7 文献下载用户状态变迁图

图书馆电子资源服务监控系统已经开始上线运行,它目前有5个模块,能监测常用的网络服务、常用的数据库和电子资源服务器的主机状态。图8是电子资源服务器的主机状态截图：

图8

	Figure Option ViewDownloadNew Window
	图8 电子资源服务器的主机状态截图

该系统还能进行流量统计,并能实时显示各个端口的流量,单端口流量RRD图如图9所示：

图9

	Figure Option ViewDownloadNew Window
	图9 单端口流量RRD图

通过进行流量统计,可以知道网络的性能如何,如IP流量、带宽利用率、SNMP流量、出错包数量、丢弃包数量等;还能通过观察用户下载流量图来观察有无非正常下载现象,如图10所示：

图10

	Figure Option ViewDownloadNew Window
	图10 用户下载流量图

通过构建基于Java EE平台和SNMP协议的高校图书馆电子资源服务监控系统,提高了图书馆电子资源的访问质量,原来电子资源服务时常中断的状况基本上已经不再发生,恶意下载的问题也得到控制。

该系统有如下优势：

（1）能监测图书馆电子资源相关的方方面面：监测HTTP、FTP、SMTP、POP3、IIS、Apache等常用服务,监控电子资源服务平台,对SQL Server、MySQL、Oracle、DB2、Sybase等常用的数据库提供监测支持,能监控图书馆专有的Z39．50服务。

（2）该系统能结合图书馆的实际需求,比如能监测中国期刊网的镜像KNS服务和万方数据的RMS Mirror服务等是否停止。如果出现故障及时通过电子邮件或短信报警,让管理员在第一时间修复故障。尤其是对图书馆专有的Z39．50服务的监测,完全符合图书馆的实际需要。

（3）可访问即可监测。该系统不需要在服务器上安装代理Agent或者打开远程登录就能对电子资源服务器进行监测,不需要对电子资源有管理权,这样,无论是图书馆的自建数据库、镜像数据库,还是没有管理权限、只有访问权限的网络数据库都能对其进行监测,即“可访问即可监测”。

目前该系统还处于试验阶段,在恶意下载的确切定义、如何设置恶意下载的阈值等方面还不够明确,需要深入分析设定。此外,还可以在读者下载了一定文献后系统自动弹出窗口进行警告预警、建立日志记录历史故障信息、记录管理员在排错过程中实施的动作等方面做进一步研究。同时还要对该系统进行优化,使其在安全性、可扩展性等方面有更好的表现。