告警监控与容量管理

  Ganglia 和 Nagios是很好的监控工具，但要马上将他移植到自己的环境中绝非易事，而移植完成后发现无法满足自己的需求那就只有叫苦哀哉了。很多人鼓励使用开源的、现成的产品，可以避免较长的开发周期，也可以帮助我们发现很多新需求功能。

  这样做是绝对草率的，也是不可行的。 

  让一个现成产品代替自己提出需求。或许只要概念上靠近，就花费九牛二虎之力去安装部署，造成的人力浪费后果不堪设想。我现在的公司就有这种情况存在，购买了惠普的openview operates和openview performance两个工具（以下简称ovo），工具功能也很全，设计理念也很全，值得我们学习，但实际上却出现了很多问题。我们的需求和它提供的功能是一个交集，在它巨大的功能集中，我们之需要些许。另外我们又有部分需求他却不能满足，或者要通过勉强而为之的方式来满足。

dashboard的告警方式要优于发送邮件。ovo的初衷就是如此，但我们却偏偏要相信邮件告警或者进入ovsm（基础架构的服务管理工具）。为什么如此呢？dashboard概念不错，但ovo的实现不满足我们的需求，他将主机作为唯一的一种node，在这个dashboard上只有主机信息而不能添加中间件信息（数据库、j2ee容器），即便添加了，也是以该中间件所在主机的形式报到dashbaord的。他的dashboard将所有主机都罗列了，无论告警与否，有告警则标红。对于平安上千台主机都罗列出来，怎么看呢？他的UI是java swt做的，很慢，不如基于网页的，并且只能由一个用户登录上去操作。ovo是强大的，其中的设计理念和扩展方式确实优美，但再好的东西，难免失败在客户化上。我今天看了Ganglia和Nagios，望而止步。

  想要成功的使用现成产品有两点基本要求，第一，明确自己的需求。第二，该产品是否容易客户化。

 

 

  监控的分析

  告警监控分为可用性监控、性能监控

  可用性监控即该服务是否可用，比如http的网站，我只要能够方面某个监控页