监控系统选型之监控功能浅析

一、背景

随着互联网的迅速发展，各种云厂商不断崛起，5年前服务器上万规模的互联网公司可能不超过200家，最近几年来，这个数字在不断上涨，而且增长的速度惊人，尤其是虚拟化、云计算技术的出现，十万级别的服务器规模应该也会慢慢普及。兵马未动，监控先行。监控的重要性不必多说，有认曾经将监控比喻成运维之眼，作为一名运维人员，如果没有监控，就相当于在"瞎忙活"。但是对于一个强大的监控软件，到底需要具备哪些功能，要怎样展现才能更加体现高大上以及在实现上有哪些难点.....等等一系列问题，你是否考虑过呢？

二、分析

一个强大的监控系统，如下一些功能必不可少。
1.数据批量采集和优化处理（原始数据收集以及处理）
2.集中展示（图表展示和数字展示以及个性化展示）
3.告警（分组告警、告警升级、自定义告警以及告警抑制）
4.权限分离（用户权限隔离）
5.审计（安全审计，操作流水记录）

三、详解

1、数据采集和处理
如同炒菜，你首先需要去把食材买来，然后才能开工烹饪。监控系统也需要食材----数据。他首先需要从各地采集海量数据。如：cpu、内存、网络、磁盘等数据，当然还有其他数据：包括服务器uptime、os信息等等。采集到数据后，统一集中存储到中央，也就是数据库，然后进行统一处理和分析。这里就有一个问题，是不是所有数据需要全部存储到数据库呢？如果是，全部数据都需要存储的话，空间可能是个大问题，也许你认为现在磁盘硬件很便宜了，但是如果原始数据不经过加工，他的增长速度是你无法想象的。
我们来做个简单计算：假设我们有6000个监控项（大约60个host，每个host100个item)，每60s采集一次，也就是每秒需要采6000/60=100个值，也就是数据库每一秒需要新增100个值。而这些值需要在数据库保持一定的时间，通常是几个月、半年、或者是一年。每个新的数据和索引值需要一定磁盘空间的，这里假如我们保持最少时间：30天。我们每秒新增100个值，30天累计下来：（30*24*3600）*100=259,200.000，或约260M。根据所使用的数据库引擎，接收到的值类型（浮点型，整型，字符串，日志文件等），磁盘空间保持一个单一的值可能会有所不同，从40字节到几百个字节不等。通常情况下，每个值大约是50个字节。在我们的案例中，这意味着260M的值将需要260M * 50字节= 13GB的磁盘空间。也就是说，60台主机，每个主机100个监控项，一个月的量基本上就可以达到13GB的磁盘空间，以此类推，如果是6000台，每台100个监控项，数据需要保持半年，那就是13GB的600倍，也就是7800GB了。如果是6万台、16万台呢，而且这里的监控项平均100个，已经是按最少的进行计算了，所以对数据进行修整也是个难点。
是不是需要把每分钟的数据一直进行保存呢？我个人认为，除了一些关键性的业务外（如：计费类），其他大部分都是可以进行稀疏处理的。比如，采集的时候是一分钟采集一次，数据线也是一分钟一个点，但是到了后期，时间一长，我们可能不需要这么精细，而只是需要查看一个趋势图而已，我们一般可以这样处理：比如一个星期，我们可以每小时一个点（计算一小时的平均值、最大值、最小值），而一个月，我们可以一天一个点或者半天一个点这样处理，这里都是取时间段的平均值、最大值、最小值，按照这样的稀疏规则，可能会节省不少空间。

2、数据展示和分析
作为数量这么庞大的监控系统，每天采集到大量的服务器数据，但是，光采集了数据并进行存储，也是毫无用处的。我们需要集中展示和挖掘，才能将这些数据转化成商业价值，通过这些数据挖掘和分析，可以指导我们线上生产环境，并作出一些成本预算、趋势分析。比如：服务器选型、故障判断、流量分析、用户分布、游戏活动效果、资源需求等等。这些对于降低成本、故障处理以及线上运营有非常大的指导作用。当然，这里需要用大数据的思维去思考，我们也就不分析的那么高深了。哈哈，主要是我目前还没达到那个水平。

3、告警
如果我们需要对某个游戏进程的存活与否进行监控告警，需要如何实现呢？通常做法就是写个脚本，然后再做个定时任务，定时去执行这个脚本扫描进行是否存在，一旦检测都进程不存在，则进行短信和邮件通知。但是这种原始的方式还是存在许多问题的：
1.如果需要每台机器都去写脚本、然后做定时任务，你可能就会每天都奔波于脚本和定时任务之间
2.如果需要服务器维护，然后你又去每台机器停掉定时任务，继续奔波于每台机器的定时任务
3.如果有一天又来了新的需求，需要在监控到进程宕掉后，进行进程的拉起，你可能又会进入下一轮脚本和定时任务之间奔波了
一个伟大的运维人员就甘愿每天被这样轮么？况且，我这里也只是举了个最简单的例子。告警还有其他需要考虑到方面：
1.需要针对不同主机组的主机进行告警的发送（告警分组）；
2.我们也不可能一次性就将告警发送给领导，领导接受告警短信多了，可能他会对你这个系统的可用性产生质疑。所以我们还需要考虑监控的告警升级机制（第一负责人先收短信并处理，处理完成就告警恢复了；如果第一负责人在一定时间内没有搞定，这是就需要进行故障升级了，就要通知第二负责人，可能是主管进行处理了；如果主管在一定时间内还没搞定，此时，事情就搞大了，就需要对经理或者总监进行告警通知，并告知故障延时的原因以及能够恢复的时间点，层层上报。)
3.假如我们某天遇到大规模网络波动或者某个机柜断电，这时可能就会面临一大波告警短信来袭，这时我们就需要考虑告警抑制功能（整合成一条短信发出）。
4.除了以上三种告警场景之外，平时可能有些预知的问题：比如机房网络调整，可能会引起网络波动，这时，就需要运维人员主动发起告警通知各个业务负责人了，所以，监控系统最好还要具备主动发送告警通知的功能，当然，这个功能也可以放到后续的事件系统中去。

4、权限分离

当机器已经达到一定规模，也就意味着机器的使用者也达到了一定规模，这个时候，如果不同部门的人需要只查看自己负责项目的机器信息，也是你需要考虑权限分离的时候了。同时，权限分离，包括查看、使用、报警、报警屏蔽、模板设定等一系列权限的分离。

5、审计
审计是任何一个系统都必须具备的，也就是对于本系统使用者的任何操作有迹可循，需要记录哪个用户在哪个时间点干了哪些事。

至此，一个强大的监控系统必备功能就分析完了，接下来我们看看目前有哪些监控系统供我们选项，当然，这里选项只限于在开源系统中，至于为什么要选择开源，请参阅下一篇文章。
http://51ctoo.blog.51cto.com/5742811/1697236