告警监控与容量管理

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

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

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

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

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

 

 

  监控的分析

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

  可用性监控即该服务是否可用，比如http的网站，我只要能够方面某个监控页面即可用。比如主机，只要能ping通，基本服务都在即可用。比如数据库，我interval的sql，即可判断其是否可用。可用性监控很简单，实现也比较容易。

 

  性能监控分析

  第一步是要确认有哪些监控对象monitor object，它有哪些监控指标monitor metric。以及这些监控对象的关系relation

  最主要的监控对象有网络设备、主机、中间件。

  主机指标：内存、cpu、磁盘空间、负载情况、网络io、磁盘io。一般在前三项指标超过阀值时告警，后面的指标留作容量管理用。

  中间件指标：

  数据库：执行过长的sql、过多的锁，频繁的IO

  weblogic：排队线程数，heapsize，jvm cpu

  apache：线程数、io状况

  整理对象关系因从应用层入手，比如寿险A系统，它有3个web apache、3个app weblogic、1个db oracle，这些instnce包括哪些主机（linux、hpunix）等。

 

  第二步是确定架构，在server and agent的基础上，poll、trap是最主要的两种方式。

  poll 拉的方式监控

  对于poll，我们需要部署一个轻量级的agent，比如lighttpd、nigx，通过在其上跑faster cgi来检测主机性能数据

  对于j2ee中间件，我们可以使用JMX，因为每个jvm上的server实际上就是一个agent，可以利用jmx来实现性能监控

  对于数据库，我们使用简单的db connection，并执行相应的sql来获取性能数据

  poll适合应用于一个公司集中、统一规模的软件，比如公司大部分主机都是redhat linux，使用weblogic、oracle等等。

 

  trap推送给server的方式

  agent对自己进行自我监控，一旦发现问题则发出告警给server。

  对于监控比较复杂的、比较特殊的应用，页面用于监控特殊的业务逻辑则适合这种方式。

  server应该开放一个接口，agent自己负责发送告警信息。

 

  第三部是考虑集中管理的方式

  怎么下发统一的agent内容

  怎么规范trap格式

  这两大不容忽视，如果再分析之初考虑好了集中下发的方式，以后可以省很多事情。

 

（未完）