如何高效的监控多台服务器，该做哪些方面的监控？

Question

系统的服务器多了，独立运行的服务进程多了，服务进程间的通讯多了，该做那些监控，该怎么监控？有没有什么成熟的思想想法？
监控是不是可以分为2个方面：1）系统级别的监控(cpu,memory,io,disk,net)，服务是否存活
2)应用级别（各子系统业务相关异常监控）
具体的，怎么来实现这个监控，做到一个可灵活配置、扩展的插件式监控平台？感觉还是比较棘手

综合了大家的回答，打算先这么做：
1：Nagios作为CPU、内存、硬盘等各个基本非业务的监控
2：各个业务模块做自己相关的监控：服务异常监控、服务统计信息等
1）服务异常信息通过mq异步的发送给监控主服务器，由监控主服务器统一处理
2）服务统计信息先在本地模块内存汇总，然后定时间隔的发送给监控主服务器进行持久化等相关处理

Answer 1

`以下都是自己想到什么写什么
监控从方向来分为：　系统级别监控和业务逻辑层监控。一般的开源软件都是面向系统软件级别的监控，　不可能会有业务逻辑的监控；　业务逻辑的监控因为不同的应用而不同，　这个需要程序员预留接口可以进行监控，　运维是可以提需求的。
监控从功能上分为：　报警监控和性能监控。　报警监控，就像大家说的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/`

Answer 2

应该监控任意两个模块之间的连接，不管你是用tcp/udp，还是thrift或者其他什么rpc server，都应该在client端记录success/fail/timeout的QPS以及latency，而在server端记录qps。
写一个监控的类库，不复杂的，有个全局的map，然后有个线程每秒能够进行计数，并把相应的数字通过一些网络接口暴露出来，这样就可以和各种Nagios/Zabbix等来集成了。
还有一个经验是每个服务最好能够注册到一个内部的Name Service中，比如Zookeeper，这样就不用把上下游的信息作为配置信息搞来搞去了。

Answer 3

服务器数量不太大时，比如小于200台，建议试试Nagios Nagios监控系统的CPU、内存、硬盘等各个基本面都很方便。监控自己的服务也很容易，组合些插件、写点简单的脚本啥的就能做到。

如果服务器数量很多，超过1000台。高效采集这些信息就是个复杂的事情，想想每秒钟要有多少数据往你的监控服务器传送就有点头疼了。这就需要自己精心设计下拓扑结构、写不少代码。当然，也能利用已有的开源框架做到这些信息采集。

Answer 4

主要分系统监控和业务监控两类吧

系统监控就是每台主机的CPU,内存，网络带宽等使用情况，以及Mysql, Redis, Nginx等服务的核心指标等，这是比较基本的监控，必须得有，如果这块监控做的好，生产环境可以提前发现很多问题，防患于未然。

业务监控就是业务相关的指标，如某API每秒调用次数，每分钟该API的平均响应时间，服务的在线人数，甚至一些运营相关的数据，如七日留存率啦，每日新增用户，每日流失用户等。这些数据也很重要，他是你整个业务的晴雨表，为你做一些重要决策提供依据。

对于系统监控，有很多开源软件可以拿来用，如比较出名的ngios,cacti,zabbix等，部署都比较复杂，客户端要部agent，还得装一个center用来收集，存储展现数据，还有好多插件需要维护。但有一个比较简单的东西是collectd，它自带了各种插件，如系统CPU，磁盘利用率，mysql,nginx,redix等常用服务都可
以进行监控，而且自动给你推荐了要监控哪些指标。安装很方便，基本上./configuration && make && make install就可以了。

对于业务监控，肯定是需要自己写代码上报业务数据的，现在比较流行的方案是statsd+graphite，比较轻量级，而且有很多语言的sdk，可以很轻松把各种指标监控起来。

大多监控体系都差不多，如下

1. 每台机器上安装一个agent，用来采集本机的性能数据，服务数据
2. 每台机器部署的业务，根据一个sdk，向center提交本业务相关的数据
3. 每个agent可以动态的按需求加载一些插件，以便监控新的指标
4. 一般一个机房内有一个center用来收集各agent和各业务上报的指标
5. center要把采集到的指标数据进行存储，归档，压缩，一般用rrd database
6. center还得有一个web界面来查看各个指标的历史图表，甚至要有各种视图和dashborad来显示一组相关的指标。
7. center还要每天把用户自定义的几个关键的指标生产报表发给运维或者相关人员。
8. center还需要保存各种告警规则，如某个指标连续几次超过某个阈值产生告警，或者波动超过某个范围产生告警，或者某个指标超过多长时间没有上报数据产生告警
9. center还要进行各种告警的收敛，如同类告警的合并，临时屏蔽某类告警，防止因为网络抖动引起大量告警等，没有这些运维人员会淹没在各种告警声中。
10. center要以各种方式将告警发送给运维人员，如短信，邮件，微信，语音等。
11. center还要对每次告警进行回顾，统计，分析，得出每个系统的薄弱点，可用率，在线时间，稳定性等。

所以说，自己搭建一套完善可靠的监控体系，挺不容易的，需要投入大量的人力和精力去开发和维护。

现在国外也有一些专门做运维外包的厂商，center托管在给他们，免去了很大的工作量，剩下的agent和plugin还是得自己安装，但这就简单了，反正有很多可以做批量部署的运维工具。

比较出名的有NewRelic,StatHat,hostedgraphite，可以去了解一下，基本上就是安装个agent就可以向它们的center上报数据了，或者是利用他们的Sdk提交一些自定义数据，他们负责存储，展现，告警方面的事情，节省很多人力。

国内的话，也有人做类似的事情，如DNSPod的D监控最近推出了自定义监控的功能，兼容graphite的上报接口，你自己部署个collectd就可以把各种系统监控指标监控起来了，如果要做业务监控，graphite也有各种语言的sdk。graphite本身开源，周边工具和软件也特别多，能满足很多的需求。

相关链接：

DNSPod D监控：https://monitor.dnspod.cn/#/monitors
New Relic: http://newrelic.com/
Hosted Graphite: https://www.hostedgraphite.com/
Stat Hat: http://www.stathat.com/
collectd: https://collectd.org/
graphite: http://graphite.wikidot.com/
statsd: https://github.com/etsy/statsd/

Answer 5

监控这个事，一定是因系统而定的。首先，你要对你系统中的各个服务做排序，出故障的概率，出现故障对整个系统的影响。
一般来说是，哪里最容易出问题就监控哪里。哪里出了问题，对系统的影响最大，就监控哪里。

具体的，每一个服务都应该有自己的容灾措施，最差也会有错误报告，对这些错误报告做监控是一种方式。
对于存在通讯的不同设备，做心跳，是一个传统方式。
其他的，还有各种措施，真的是要视具体情况而定

Answer 6

一、 服务器数量小于200台的阶段

这个时期一般需要满足基础监控需求，我们主要考虑的是简单易用、 稳定运行、 监控报警三个方面。

云帮手资源监控系统全程可视化界面，一键傻瓜式操作，新手小白也能快速上手；能够从CPU、内存、磁盘、网络四个方面对服务器进行24小时不间断基础监控，并可自主设置告警规则，在状态异常时第一时间产生告警，帮助用户快速定位问题解决问题。

二、服务器数量200到1000的阶段

随着服务器数量的增加，用户需求开始变得复杂，我们需要做到以下几点：

统一监控内容：云帮手将基础监控进行统一，默认每个机器都包含CPU，内存，磁盘空间等基础信息监控。

覆盖式监控：云帮手支持多IP服务器纳入监控，所有服务器统一可视化管理，功能覆盖整个业务流程，避免多系统繁杂管理，保障业务高效运行。

及时通知，确保无漏报：云帮手会在系统触发告警规则后第一时间产生告警，且告警记录可查询，坚决做到不迟报不漏报。

三、服务器数量超过1000台的阶段

需要监控的服务器越来越多，告警信息出现爆发式增长，每天收到上千条报警信息。我们需要将告警进行整理，化繁为简，减少重复告警。

分离告警和显示：云帮手将CPU使用率、内存使用率、磁盘使用率等各监控模块进行告警规则独立设置，告警时间段分离推送，告警记录分离展示。重要的告警处理是分秒必争的，云帮手能够效避免同一时间重复告警、影响运维效率。

快速定位、及时分析：云帮手针对每个服务器进行独立可视化管理，我们根据告警推送快速查看到哪里流量达到了预警值，哪个服务器出现了问题，方便运维人员及时解决，并根据告警记录进行分析，避免同样问题的发生。
最后贴个下载地址（云帮手），希望能帮助到您！

Answer 7

楼上2位都说得有道理，监控是不是可以分为2个方面：1）系统级别的监控(cpu,memory,io,disk,net)，服务是否存活
2)应用级别（各子系统业务相关异常监控）
具体的，怎么来实现这个监控，做到一个可灵活配置、扩展的插件式监控平台？感觉还是比较棘手