监控系统的原理探究

监控系统的原理探究

时间2013-12-20

作者 itnihao

邮箱 itnihao@qq.com

博客 http://www.itnihao.com

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

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

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

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

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

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

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

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

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

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

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

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

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

主机监控

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

网卡监控：

IP， Ping 的往返时间及包成功率，网卡的流量，包括流入、流出量和错误的数据包数（列表，网卡ID）

文件监控

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

URL监控

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

应用程序

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

数据库

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

日志

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

对时间的要求：

     实时，非实时。