如何高效的监控多台服务器，该做哪些方面的监控？
系统的服务器多了，独立运行的服务进程多了，服务进程间的通讯多了，该做那些监控，该怎么监控？有没有什么成熟的思想想法？

监控是不是可以分为2个方面：1）系统级别的监控(cpu,memory,io,disk,net)，服务是否存活

2)应用级别（各子系统业务相关异常监控）

具体的，怎么来实现这个监控，做到一个可灵活配置、扩展的插件式监控平台？感觉还是比较棘手
查阅了资料后，我打算先这么做：

1：Nagios作为CPU、内存、硬盘等各个基本非业务的监控

2：各个业务模块做自己相关的监控：服务异常监控、服务统计信息等

1）服务异常信息通过mq异步的发送给监控主服务器，由监控主服务器统一处理

2）服务统计信息先在本地模块内存汇总，然后定时间隔的发送给监控主服务器进行持久化等相关处理
`以下都是自己想到什么写什么

监控从方向来分为：　系统级别监控和业务逻辑层监控。一般的开源软件都是面向系统软件级别的监控，　不可能会有业务逻辑的监控；　业务逻辑的监控因为不同的应用而不同，　这个需要程序员预留接口可以进行监控，　运维是可以提需求的。

监控从功能上分为：　报警监控和性能监控。　报警监控，就像大家说的nagios是非常好的开源软件，　其实nagios提供的也是一种监控的框架，　所以他比较的灵活；　性能监控，　主要是用来查看变化趋势,　可以更好的找到问题,　或者提早发现问题,　有时候因为报警的阀值是需要不断的调整才能到最佳状态,像cacti和ganglia

监控的选择　一般要看你的服务器分布:

如果是分布式的机房,　机房很多,　那么对集中监控和处理要求比较高,　ganglia本身就有分布式特性,　是第一选择;　nagios需要再做些插件的优化和结构调整才能更好的支持分布式的需求.　因为分布式面临的问题是集中管理和可靠性,　可靠性:　网络传输可能出现的问题都要避免监控，才能让监控准确;　集中管理:　才可以减少工作量

如果是集中的,　在量很大的情况下还是建议使用ganglia,　如果小其它的很多监控都可以选择,　报警监控还是用nagios,　好像很少有他这样灵活的工具,　但一定要将配置改成最适合自己环境的,　并且最简单和快速的配置　需要自己制定一些规则会比较好。

如果说要监控配合的外围工具:　像短信报警　邮件　都需要自己做些工具会比较好　,都是为了保证报警的可靠性　监控前期一定要多关注是否跟上了需求　要做很多的调整　不是说搭建了就万事大吉了.
评下你的做法

查阅了资料后，我打算先这么做：

1：Nagios作为CPU、内存、硬盘等各个基本非业务的监控

＃其实nagios也可以监控业务逻辑　主要是首先要知道要监控哪些业务逻辑　再程序方面是否有相应的接口　如果没有是否可以做　再自己写一些相应的脚本　nagios和ganglia都可以很方便的写脚本。最关键的还是监控需求和程序的支持情况

2：各个业务模块做自己相关的监控：服务异常监控、服务统计信息等

1）服务异常信息通过mq异步的发送给监控主服务器，由监控主服务器统一处理

＃你应该说的是自己写监控再通过队列发送给主服务,如果是同机房当然还是写nagios的插件会比较好,这样是统一管理,而只需要写插件;　如果是机房是分布的,可以考虑nagios之间的消息传递写一些脚本完成,自己写的话是时间问题和管理上不统一的麻烦。

2）服务统计信息先在本地模块内存汇总，然后定时间隔的发送给监控主服务器进行持久化等相关处理

＃这一部分我建议是分成两部分:　第一部分是服务器基本信息,　像cpu　内存　硬盘　这些不会变化的可以间隔很长时间,　其实ganglia默认就有系统硬件的所有信息，　只是如果想放到表格里面对比就差些了；　反而对于系统用户　磁盘容量　各种配置文件　如计划任务　打开的服务　自启动的内容可以定时的执行和收集,　这个应该属于备份了,　但如果所有的配置集中处理之后,像使用puppet或者其它配置工作,这些都不需要做了。