`以下都是自己想到什么写什么
监控从方向来分为： 系统级别监控和业务逻辑层监控。一般的开源软件都是面向系统软件级别的监控， 不可能会有业务逻辑的监控； 业务逻辑的监控因为不同的应用而不同， 这个需要程序员预留接口可以进行监控， 运维是可以提需求的。
监控从功能上分为： 报警监控和性能监控。 报警监控，就像大家说的nagios是非常好的开源软件， 其实nagios提供的也是一种监控的框架， 所以他比较的灵活； 性能监控， 主要是用来查看变化趋势, 可以更好的找到问题, 或者提早发现问题, 有时候因为报警的阀值是需要不断的调整才能到最佳状态,像cacti和ganglia
监控的选择 一般要看你的服务器分布:
如果是分布式的机房, 机房很多, 那么对集中监控和处理要求比较高, ganglia本身就有分布式特性, 是第一选择; nagios需要再做些插件的优化和结构调整才能更好的支持分布式的需求. 因为分布式面临的问题是集中管理和可靠性, 可靠性: 网络传输可能出现的问题都要避免监控，才能让监控准确; 集中管理: 才可以减少工作量
如果是集中的, 在量很大的情况下还是建议使用ganglia, 如果小其它的很多监控都可以选择, 报警监控还是用nagios, 好像很少有他这样灵活的工具, 但一定要将配置改成最适合自己环境的, 并且最简单和快速的配置 需要自己制定一些规则会比较好。
如果说要监控配合的外围工具: 像短信报警 邮件 都需要自己做些工具会比较好 ,都是为了保证报警的可靠性 监控前期一定要多关注是否跟上了需求 要做很多的调整 不是说搭建了就万事大吉了.
评下你的做法
综合了大家的回答，打算先这么做：
1：Nagios作为CPU、内存、硬盘等各个基本非业务的监控
＃其实nagios也可以监控业务逻辑 主要是首先要知道要监控哪些业务逻辑 再程序方面是否有相应的接口 如果没有是否可以做 再自己写一些相应的脚本 nagios和ganglia都可以很方便的写脚本。最关键的还是监控需求和程序的支持情况
2：各个业务模块做自己相关的监控：服务异常监控、服务统计信息等
1）服务异常信息通过mq异步的发送给监控主服务器，由监控主服务器统一处理
＃你应该说的是自己写监控再通过队列发送给主服务,如果是同机房当然还是写nagios的插件会比较好,这样是统一管理,而只需要写插件; 如果是机房是分布的,可以考虑nagios之间的消息传递写一些脚本完成,自己写的话是时间问题和管理上不统一的麻烦。
2）服务统计信息先在本地模块内存汇总，然后定时间隔的发送给监控主服务器进行持久化等相关处理
＃这一部分我建议是分成两部分: 第一部分是服务器基本信息, 像cpu 内存 硬盘 这些不会变化的可以间隔很长时间, 其实ganglia默认就有系统硬件的所有信息， 只是如果想放到表格里面对比就差些了； 反而对于系统用户 磁盘容量 各种配置文件 如计划任务 打开的服务 自启动的内容可以定时的执行和收集, 这个应该属于备份了, 但如果所有的配置集中处理之后,像使用puppet或者其它配置工作,这些都不需要做了。
我这有个服务器信息收集的 是适合自己用的 [Shell]服务器信息收集与整理输出wiki和excel http://www.ohlinux.com/archives/824/`
