重庆OA快博

网络管理实战：如何实现真正的监控？

大学毕业以后，我在政府机构找到了一份管理网站的工作。我们的服务器都是以前各个部门自己管理的，什么类型的机器都有，文档基本上没有，所以我们在整理这些机器环境时，就好像在做逆向工程一样。我们把所有服务器都编入目录，并纳入监控：第一项检查是可用性检查，从简单的网络ping测试，到发送HTTP请求和检查响应时间。为了能有更多的信息以诊断故障原因，除了对关键进程，如SSH、HTTPD、NTPD的检查之外，又增加了对内存、磁盘、CPU使用情况的检查。查看这些结果，使我们对面临的情形能有一个完整的大局观。

偶尔人们会给我们发邮件，声称他们不能访问网站。但我们检查网站和监控的结果是一切运行正常，我们就礼貌地回复这些邮件：就我们所见，一切运行正常，问题可能出在他们的PC机上，把机器重启一下就好了。事实上，我们认为这些情况属于典型的PEBKAC（问题出在键盘和座椅之间）。

后来有一天，老板发邮件给我，说他在访问网站时也遇到问题了，他急着要一些信息。我马上跑到他的办公室，打开浏览器，输入URL地址，什么都没有。点击重新加载按钮，也不行。我打开命令行窗口，输入命令来解析服务器地址，发现DNS服务器没响应。这下我明白了，我们的监控脚本检查网站时使用的是IP地址，所以没有检测出问题。我登录到老板所在的网段的DNS服务器，重启服务器，一切恢复正常。为了检测这种类型的问题，修改监控脚本，把对DNS服务器的监控加进去，使用nslookup检查DNS服务器，以确保能够检测出这类问题。

几天以后，在一次会议上又遇到了老板，我问他现在还有什么问题没有，他答道，“大多数时候没问题，但在需要身份验证的地方还是有问题。”我的老板是第一批访问受限内容的人，这个管理站点需要登录，使用存储在数据库中的用户名和密码。我们已经从DNS问题中学到了教训，所以也把数据库服务器纳入了监控，我们是通过向数据库发送一条简单的SQL查询对数据库进行检查的。所以，打开监控页面，看到数据库服务的状态一直是绿色的。嗯，我请他登录网站，砰，失败了。这证明，虽然Web服务器和数据库服务器都运行正常，但由于防火墙的权限设置问题，Web服务器仍然不能访问数据库服务器。我默默地离开了老板办公室：由于没有检测到问题，最终用户又一次把板子打在了我们的监控上。又一次升级了监控脚本，增加登录功能，对网站做更全面的检查。

我一般上班比较早，在大部分用户开始工作之前，对系统做全面检查。一天早上，我开始收到大量的用户抱怨，说网站宕掉了。检查监控，没发现任何问题：所有状态都是绿色的。我请用户再试试，还是不能访问。我告诉他们检查DNS、网关，以及所有我能想到的事情，毫无效果。我甚至重启了服务器，虽然一切正常。

在翻来覆去地检查过配置文件和日志文件之后，我决定打电话给网络组的同事，他正好与抱怨用户在同一栋楼上。“嗨，可以看一下我们的网站吗？”我问，回答，“不。”我想他是在跟我开玩笑，所以就温和亲切地把问题又重复了一遍。“不，”再一次的回答，接着又说：“这栋楼的一根动力线掉电了，一台核心交换机停掉了，所以我没办法帮你看。”

为了找到问题出在哪儿，我花了一个多小时。没人费心告诉我们这个小组停电了，要是我早点知道该多好。后来我了解到，负责网络的人和负责大楼的人各有自己的监控系统，首先，我们要能够访问他们的系统，这样，出现问题之后，就能够验证系统状态。然后，在发生问题时，要相互告知。最后，我们把不同的监控系统集成起来，提供统一的运行状态图。

随着时间的推移，各个Web服务器的参数和配置更加地趋于一致。有些站点的硬件能力没有充分利用，而其他的却需要增加容量。我们决定把各个站点分布在不同的服务器上进行负载均衡。这样，除了性能和利用率得到提高之外，还提高了可用性，因为站点现在是运行在多台服务器上，即使一台服务器宕掉了，也可以通过负载均衡器将用户重定向到另外的可用服务器上，来保证用户的正常使用，同时将数据库服务器转成了高可用性的集群。

网络部门的朋友们做了同样的事：为路由器、交换机、防火墙增加了冗余。现在，可以放心地说，我们消除了架构中存在的大量单点故障。管理服务器变得容易了，可以从服务器池中把一台移出来进行维护，而不会影响系统运行。把监控站点开放给内部的最终用户，让他们验证自己的环境状况，这样他们就可以了解哪些问题是站点的问题，哪些问题是他们自己电脑的问题。在我们引入冗余级别之后，用户给搞糊涂了，他们无法区分哪些是服务器的服务，哪些是负载均衡器提供的全局服务。我们又在监控显示上提供了一个服务级别，以便区分。对于其他的冗余机制，譬如用于DNS（NS记录）、Mail（MX记录）、NTP时钟等服务的冗余机制，以及像RAID5和磁盘镜像这样的磁盘冗余机制等，都同样提供服务级别，以便区分。

负载均衡器是由服务器团队管理的，因为从逻辑上讲，负载均衡更接近于应用程序，而且要正确地管理负载均衡器，需要深入的HTTP知识。在进行更新时，先在被动的负载均衡器上准备配置，然后再将主动负载均衡器切换为被动负载均衡器，我们很自信，可以在工作时间做这种更新。偶尔切换的时间会很长，以至于监控系统会认为发生了错误。这种情况很难理解，因为我们配置的负载均衡器应该是立即切换的。我们开始检查历史日志，看是否能够找到发生了其他问题的线索。最后证明，我们那两次碰到问题，是由于防火墙、路由器、交换机出问题了。这就解释通了，负载均衡器没有问题。那天下午，网络部门也打电话给我们，问是不是改了负载均衡器上的什么东西。“是的，”我们说，“安装了新的配置，失效转移工作正常，只是你们的路由器、交换机、防火墙出问题了。”我们在继续转换的时候，他们最终把问题追踪到了负载均衡器的失效转移上：负载均衡器在做失效转移时，防火墙也在做失效转移，因为它检测到了路由问题。最后，我们把两种失效转移机制紧密耦合在一起，从而可以让它们一起进行失效转移。

【推荐阅读】

◆网管软件专区

◆网络监控原理与技术实现

◆巧用泛普BTNM智能分析网管软件解决网络故障

◆奇怪的排障：企业网络管理要突破惯有思维

◆IT运维管理专区

本文来自互联网，仅供参考

发布：2007-04-15 10:40 编辑：泛普软件 · xiaona [打印此页] [关闭]

网络管理实战：如何实现真正的监控？

泛普重庆OA快博其他应用