监控系统的原理探究

时间2013-12-20

作者 itnihao

邮箱 [email protected]

博客 http://www.itnihao.com

如需引用,请注明以上信息,谢谢合作

为什么需要监控系统,这个在前面已经论述过了。而监控系统的原理究竟是什么样的呢?

来看一下监控系统的使用者都是哪些?

试想一下,当你从一个小的网站,逐渐发展成为一个大型的网站,服务器从一台发展到N台,运维人员从一个发展到N个,业务战线也从一个发展到N个,这个时候,出现故障的几率就会大大的增大,当有一天,你的老板问你,为何某个服务不可使用,为何出现故障,而身为运维人员的你,却不知道故障出现在哪里,这个时候,你是不称职的。如果换一个角度,在未发生故障的时候,就已经把故障解决了,那你就是背后的英雄了。

有一个故事是讲神医华佗的,有人对华佗说,你是天下的神医,能治天下各种疑难杂症,很了不起。而华佗却说,你知道吗?我和我弟弟比起来,可差远啦!我弟弟给人治病,是治人于病未发之前,在稍见端倪的时候就能防患于未然,而我只能治人病于膏肓之中,往往是病人受尽折磨才来找我。

而监控系统,就是这么一个神医,在发生故障之前,会隐约的显现故障的前期迹象,这也适用于其他事物,任何事物的发生,必有其原因和条件。有经验的人,会从这小小的迹象中发现更大问题,例如突然的流量增长,突然的访问量增大,某台服务器的瞬间负载变高,对于出现重大故障,及时的报告故障发生,对于运维人员处理故障的响应时间会大大提高,如果没有监控,故障往往是我们的用户报告,然后才由运维人员处理。

监控系统,往往需要对物理硬件,应用软件的性能,参数进行数据汇集,实现集中管理,统一分析管理。

一个监控系统中,往往是一个数据存放中心,多个采集节点,数据采集完成之后,需要分析处理,采集到的数据是否有异常,是否属于报警条件,报警条件,通常都是根据实际的经验,业务的需求来设置的,达到报警的条件,则发送报警信息给管理人员,然而,有些故障,我们希望程序能自动处理,从而减少人工的干预,让机器帮你干活,而只是在严重故障的时候,程序没法帮你实现的时候,才去告警通知管理人员处理。

一个监控系统,往往需要资产管理系统的结合,资产管理主要是方便于业务的划分,功能的划分,从而分组分批的进行管理,达到有序的进行。

监控系统的数据采集,从其工作模式来看,可以分为主动采集数据,然后发送给你数据收集中心,也可以分为被动监控,数据收集中心来向数据采集节点询问采集数据。从其采集的客户端来看,可以分为公众的采集方法,私有的采集方法,公众的采集方法是通用的程序协议,如SNMP,IPMI,JMX,SSH,TELNET等,私有的采集协议是专用的客户端,监控程序内部的一套协议。而一个理想的监控系统,其采集端支持多种方式,其扩张能力就强大。

监控系统需要提供一个api,方便其他功能系统来对监控数据进行操作管理,这在业务系统精密的情况下显得特别重要,其实在软件中,能不能对外提供API,可以说是一个非常重要的指标,通常能对外提供API功能的软件,其用户群会更大,其产品会越做越好。

监控系统需要对故障数据进行分析汇总,从故障中分析出现的概率,从而可以累积经验,避免以后出现类似的问题。例如由于机器硬件导致的故障,这个几率有多大,什么部件最容易出问题,出问题的影响概率多大,问题解决的几率有多大,从监控的数据中,就可以分析发现出相关数据,再次基础上进行分析汇总,可以整理出相应的对策,相应的技术应急方案,让数据说话,而不是凭感觉来操作。

常见的监控系统性能采集指标:

主机监控

CPU、内存、磁盘的剩余空间/利用率,Disk I/OSWAP使用率、系统UP时间、进程数,负载

网卡监控:

IPPing 的往返时间及包成功率,网卡的流量,包括流入、流出量和错误的数据包数(列表,网卡ID

文件监控

文件大小,hash值,匹配查询,是否存在

URL监控

监测指定 URL 访问过程中的返回码、下载时间及文件大小,支持内容匹配

应用程序

端口,内存使用情况,cpu使用情况,服务状态、请求数、并发连接数、消息队列的字节数、 Client 事务处理数、 Service 状态等。

数据库

表空间监测数据库中指定的表空间,数据库的游标数、 Session 数、事务数、死锁数、缓冲池命中率、库 Cache 命中率、 当前连接数、进程的内存利用率等性能参数

日志

错误日志匹配,特定字符串匹配

对时间的要求:

     实时,非实时。