美妙尝试SiteView ECC 7.0的新味道

 

随着网络应用和规模的不断增加，网络管理工作越来越繁重，网络故障也频频出现。人为去分析网络运行状况，评估出系统出现的瓶颈几乎是不可能实现的。另外，当系统出现故障后，不能及时发现、诊断都为网络完全瘫痪和系统崩溃埋下了隐患。以前当网络出现故障时，许多企业会请专家来帮助分析，帮助调理网络，在付费的同时还欠下了一笔“人情债”。而当系统出现问题的时候，通过再购买一些服务器来解决问题。曾经走过风雨的网管员都清楚，运维一个网络要比组建一个网络更加难上加难。而现在你可能会考虑购买网管软件来加强网络管理，以优化现有网络性能，逃脱故障的束缚，开始恢复你的自信。

安装过程中的小插曲

SiteView ECC 可以安装在任何一台 windows 2003 操作系统的 PC 机或服务器上，对系统资源的占用很少。当然，由于监测数量及监测频率的不同， SiteView ECC 对系统资源的占用情况不尽相同，对硬件配置的要求也不一样。经过模拟测试，如下的配置完全可以支持 100 个左右的监控设备：

测试计算机配置清单
CPU	Inter(R) Pentium(R) 4 2.80GHz
内存	512MB DDR
硬盘	80G
显卡	NVIDIA GeForce2 MX 400 64MB
网卡	Realtek 8139 主板集成百兆
声卡	主板集成
操作系统	Windows 2003 Server 系统更新到 10月 13日
防毒软件	Norton AntiVirus 2006
IIS	6.0

 

由于只有 100 多兆的苗条身躯，所以安全过程非常快，这让我回想起国外几个管理软件漫长的配置过程，不禁对 ECC 有了好感。在安装结束后，根据以往的经验我把安装光盘的内容翻箱倒柜的折腾了半天，终究没有找到客户端程序。咨询技术人员的答复如下：“ SiteView ECC 采用的是非代理、集中式的监测模式，可以安装在服务器或 PC 机上，无需在被监控服务器或网络设备上安装任何代理软件。”刚才的一丝好感马上被疑惑所代替，很少看到网络管理软件没有客户端程序的，带着这些疑问我开始测试 7.0 产品的每个功能模块。

 

针对每个功能模块的尝试

监控对象紧跟市场脚步

SiteView ECC 7.0 支持 Windows 和 Unix 两种类型的操作系统。对远程 NT 主机的监测采用 RPC 方式，如果监测远程 NT 主机时，请检查该主机是否安装了 WMI 和 WMIDE 服务，如果跨越安全设备的时候需要建立开放 TCP135 、 TCP2942 端口进行连接。而对不同版本的 Unix 系统支持也非常好，比如 Redhat 、 Solaris 、 AIX 、 FreeBSD 、 Unixware 、 HP － UX 、 OpneServer 等所有主流操作系统的服务器。在网络设备的监控方面， ECC 7.0 几乎覆盖了所有主流品牌 Cisco 、 Juniper 、 3com 、 NETGEAR 、北电、华为、实达、迈普等多厂家的各种网络设备，支持 CheckPoint 、 NetScreen 、 Cisco(PIX) 、天融信、安氏、联想、东软等厂家的防火墙。

在中间件和服务监控方面的测试中，可以感觉到 ECC 7.0 中对中间件的支持要强于服务的支持，这可能与目前各应用服务器产品的同质化有关，毕竟现在的用户注重的是如何为应用提供更多的增值功能服务和更好的性能。应用服务器中间件作为软件的基础设施，可以把不同的应用软件作为构件整合到一个协同工作的环境里，并为应用提供了名字、事务、安全、消息、数据访问等服务，此外它还提供应用构件的开发、部署、运行及管理功能。由于标准接口对于可移植性和标准协议对于互操作性的重要性，中间件已成为许多标准化工作的主要部分。对于应用软件开发，中间件远比操作系统和网络服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境，不管底层的计算机硬件和系统软件怎样更新换代，只要将中间件升级更新，并保持中间件对外的接口定义不变，应用软件几乎不需任何修改，从而保护了企业在应用软件开发和维护中的重大投资。

全面测试，充分模拟环境

很多网管员对网络管理软件理解不到位，很多人认为监控服务器、网络设备是否有故障就是网管系统的全部。其实监测服务器，即监测它的运行，是实现对服务器进行管理的两个重点要求―故障查找和优化―的一步。一般情况下，这些设备故障率是很低的，而后者才是对网络或系统的完全掌控。 SiteView 在物理层面上可以监测服务器物理硬件，包括监视温度、电源和部件（如硬盘）的机能。以往曾试用过几个国内的管理软件，但是这些产品对一些服务器的关键部件都不能支持监控，在此次测试过程中不但包括了 IBM 、 HP 等国外品牌还包括了国内联想和浪潮等不同级别的服务器。在监测服务器的性能方面 7.0 和其他几个厂商的网管软件大致相同，例如， CPU 使用情况、可用硬盘空间和内存可用性等，这都为故障查找和优化提供帮助。

　　在服务监控方面 7.0 可以单独设置，也就是说针对企业的关键的网络服务单独监测，例如 Email 、 SQLServer 、 Oracle 、 URL 可用性、 IIS Server 、 Apache Serve 、 WebLogic 、 FTP 、 DNS 、 TCP 协议的运行情况等。还以上文中提到的服务器“中间件”，我们进行了全面测试，

SiteView 可以对 IBM 的 MQ 、 Webspher ， BEA 的 Tuxedo 、 WebLogic 等中间件进行全面监测。以 Tuxedo 为例， SiteView 能够对 Client 信息（请求数、事务处理数、 Client 状态等）、队列信息（队列的最大字节数、当前队列字节数、队列 IPC 消息数、机器状态等）、服务信息（总共的请求数、 Server 每秒请求数、 Server 每秒 transaction 数、并发的连接数、服务状态等）、 WSH 监测（请求数、 WSH 接收的字节数、 WSH 接收的消息数、 WSH 发送的消息数、 WSH 每秒接收的字节数、 WSH 每秒接收的消息数、 WSH 每秒发送的字节数数、 WSH 每秒发送的字节数数、 WSH 每秒发送的消息数、 WSH 状态等等）进行全面监测，有效帮助系统管理人员加强对中间件的监测和管理，提高工作效率。

       在网络设备管理方面，我们不但测试了内部的网络设备的性能监控，同时几个单位的管理员利用不同的网络接入环境的差异，进行了跨 WAN 的监控测试。除部分采用 Linux 作为防火墙的单位没有参与外，其他单位基本上都按照说明手册的部分作完了全部实验。这其中包括：网络设备的接口的相关状态信息、接口流量、接口丢包率等。在网络设备的可用性方面的测试还包括 CPU 利用率、内存利用率、当前连接数、会话数（ session ）、防火墙的性能指标（如拒绝的数据包数、丢弃的数据包、 IP 欺骗攻击数、 ICMP 攻击数等性能参数）、配置文件的变化情况等。经过一系列的功能测试之后，不但前面的一些疑虑完全打消了，而其发现了更有趣的东西。

故障的自动诊断

       SiteView 的故障自动恢复功能可能是最有趣的一件事。以往，当设备出现问题当出现问题后，我们只能在收到报警讯息后作出处理，而这两者之间存在着一个时间差，看似短暂的时间差对于某些重要的应用可能是致命的。对于一个临时性的标准故障时， 7.0 自动恢复功能就会自动执行指定脚本或 POST 数据到指定的 CGI 程序，使服务恢复正常。比如，把一个挂起的服务器操作通过自动启动功能而使它重新运行；把一个耗费系统过多资源的进程停止或者重新启动设备。在 Windows 和 UNIX 平台， SiteView 提供了重启指定服务、重启 Web 服务、重启主机、关机等故障自动处理功能。 UNIX 平台提供了扩展的接口实现故障处理模块，管理员可以自己定制用于对故障进行处理的 UNIX 脚本，这对很多习惯命令行模式的管理员可谓提供了更广阔的空间。

日志与报表

在一个完整的信息系统里面，日志系统是一个非常重要的功能组成部分。查看交换机、路由器和其他网络设备的日志，可以帮助网管员迅速解释和诊断问题。很多网管员经常将认为日志管理是信息安全管理的内容，和系统管理关系不大，这是绝对错误的。而很多硬件设备的操作系统也具有独立的日志功能，但在大量的设备面前，如果一台台的去查看，那么一天什么也别干了。 SiteView 系统中有接收 SNMP TRAP 、 SYSLOG 网络事件的功能，可以接收任何网络设备的 Trap 信息，如路由器、交换机等，使得用户可以更方便的了解设备 Event 。 SiteView 在接收到网络事件后，可以按照相应的格式进行分析，从而得到相应的事件信息。每次触发事件，系统自动将触发情况立即记录到相关角色、设备、线路、流程、资源的历史记录中，同时将此信息记录到事件报告中，并按照管理员的设定时间依次为依据形成事件报告并将相关人员的处理报告进行汇总，可以由集中应用监控平台的维护人员根据需求进行对各类事件的类型的制定和分类，可以实现对事件的过滤及分类。

站在程序员的角度去看7.0

很多管理软件由于是采用了 WEB 的操作界面，所以数据调用过慢的问题是一个通病，而服务器使用 WEB 服务技术后，在大规模部署后的稳定性也是衡量一个产品的指标。 ECC 使用 AJAX 和 FastCGI 技术，所以在整个过程中非常高速和稳定。由于参与测试的人员中有很多都是程序员转行过来的，通过他们的介绍，我们对 SiteView ECC 7.0 有了更深的认识：

l         AJAX (Asynchronous JavaScript and XML) 是多种技术的综合，它使用 XHTML 和 CSS 标准化呈现，使用 DOM 实现动态显示和交互，使用 XML 和 XSTL 进行数据交换与处理，。 Ajax 技术之中，最核心的技术就是 XMLHttpRequest ，它最初的名称叫做 XMLHTTP ，是微软公司为了满足开发者的需要， XMLHttpRequest 为运行于浏览器中的 JavaScript 脚本提供了一种在页面之内与服务器通信的手段，页面内的 JavaScript 可以在不刷新页面的情况下从服务器获取数据，或者向服务器提交数据。

l         我们对 CGI 工作的工作原理还是比较熟悉的，比如当客户机对服务器请求 CGI 应用程序时，服务器建立一个进程来处理用户请求，完成后结束进程。由于 CGI 程序的反复调用，这对服务器会操承负载问题：当负载很低时， CGI 能很好地工作，但是一个大型的站点上的各种不同类型的请求随时发生，在客户请求的负载很高时，服务器进程的设置和初始化所用的时间就成为 WEB 服务性能的瓶颈。特别是像和数据库这样的应用程序连接时，初始化所用的时间较长。而使用 FastCGI 则是另外一种情况，由于它始终处于活动状态为来自服务器的请求提供服务，在服务器看来它始终是一个运行的“活程序”，所以在处理请求时没有启动新进程和对应用程序初始化的开销。

 

最后，我们站在用户成本的角度上去衡量了它设计了 ECC 7.0 ，由于它是自有的环形数据库，能自动删除更新长期不用的数据，这样就可以为用户节省购买通用数据库的成本。而兼“精巧、效率、稳定为一体”的设计理念让我想起了手表的一个广告：“把握时间，把握生命，把握你自己”。