晒一下我的监控系统

背景

     一般情况下，由于服务器环境或者程序漏洞的问题，现行的系统多多少少会发生一些异常或者bug，给用户体验甚至利益造成影响。而现在的第三方监控工具大多是关于服务器硬件数据监控。对于业务方面、例如每日订单的数据量、Mq中的要求退款的队列长度...还是比较薄弱。这套系统的作用就是在第一时间捕获工程师可以考虑到的系统风险异常。

---

结构草图

　　监控系统的结构整体分为4块：1.监控web应用站点为后台主控程序负责各个监控逻辑的策略配置、监控跟踪、报表履历以及用户、权限等等传统的信息流管理；2.监控webservice提供监控系统的采集以及策略配置的更新标志；3.报警win服务，根据各个策略规则对采样进行匹配分析，并进行邮件或手机报警；4.客户端监控代理，负责客户端的实际采集动作。     系统的难点在于设计、性能、并行、瓶颈等方面，例如客户端与服务器端时间不匹配的场合，报警的准确性、报警的人性化配置、采样程序的性能、监控与代理的衔接等等。或许系统可以优化的地方还有很多吧。

---

DEMO概要流程

 step1.选择监控设置 目前系统支持数据库、MQ、内存、Cpu、文件监控

查看原图

step2.添加监控，根据类别 我们以数据库为例

查看原图

step3.添加sql配置策略 不同的监控类型配置不同的策略规则 数据库类型0为MSSQL, MSSQL支持sql语句和存储过程，监控类型1为sql语句

查看原图

step 4.配置完监控策略规则 设置报警策略 监控标准值为参考基准 例如设置大于5 当我们sql语句采集的值大于5时触发报警策略

报警方式目前支持邮件和手机短信。报警时间根据业务场景设置，这里模糊的意思是忽略、有时候波峰或者谷底的值比较离谱根据实际场景设计模糊次数

step5.添加联系人

step6.在应用端安装监控代理

step7.检查服务

step8.服务端安装监控报警服务

step9.启动服务查看报表 以及报警相关 因为虫子本机没有手机服务引擎也没邮件服务 所以就拿以前的截图充数一下

step

 

---

 概要设计以及问题点

 1.报警服务需要考虑一下几个问题。报警的执行是设置在客户端还是服务器端？如果是客户端，那么客户端服务器直接当掉了怎么办？如果是服务器端，如何能匹配及时的信息，监控主程的采集接受客户端的数据，时间不匹配怎么办？如果时间作为参数传给web服务，服务器端的监控check如何保证即时？对于以上问题，demo中的处理方法不一定好，大家有空一起交流下。Demo的处理方法是报警执行在服务器端，web服务器采集数据时忽略客户端时间以服务器端时间为准。即时监控的问题比较头痛。目前demo中在服务启动时加载所有监控配置，并且根据加载的信息对每一条监控分配一个异步线程。监控的主要逻辑在存储过程中完成。因为监控采集的时间与监控check的时间存在时间差，所以我将check范围设置为1分钟之内的最新值。 只要能保证check端的更新频率比采集端的快，就能保证到每一条数据都能被check

2.报警信息的人性化处理人为可控的设计报警的时间间隔与次数。目前demo的处理时有bug的，暂时先不调整了。Demo的处理时在每次发生监控异常时，在服务器端加载2个缓存项，一个是发现异常的时间，一个是系统设定的发送总次数。每次进入报警流程，判断当前时间与缓存时间的差，如果在设定的间隔时间内忽略。第二层是发送总次数，先判断缓存值，如果为空，加载系统配置最大发送次数，没发送一次-1，如果超过总次数忽略。缓存时间24小时。bug点： 每次进入报警流程比较是发现异常，如果采集的数据第一条为异常，第二条为正常，那么就不进入报警流程，就只发一次了。现在的想法：报警流程与监控check流程分开独立，报警的流程方式可以使用类似站内信的方法，报警信息全部存入mq，异步处理。

3.监控采集的性能方案demo中的处理方法是按监控配置类别分线程，现在提供cpu和内存监控，那么就是2个线程在跑。demo的循环采集并未使用计时器，全部使用while（true）死循环，有同学有好的方法可以提议下。而且cpu监控和内存的方式差异比较大，内存的监控每次循环都可以用新的实例，cpu监控每一次新的实例初始值都是0，在不使用单例的情况下，cpu的监控使用计时器肯定是不行的

4.监控配置的方案
Demo中每个客户端每个大类只能有1种监控配置，例如只有1个cpu监控，一个sql监控等。Sql监控中可以可以配置多个下级监控配置，例如监控a监控Q1数据库，监控b监控Q2数据库。Cpu和内存监控没有下级监控配置。直接进入报警策略配置。
也就是   客户端(1)<---->(N)监控配置(1)<---->(N cpu和内存是1)监控策略(N cpu和内存是1)<---->(1)报警策略(1)<---->(1)联系人信息

5.监控与代理的衔接
Demo中，监控主程将代理类MonitorC序列化，通过http方式由代理端请求获得。还有就是同步问题，因为监控主程的配置其实是很少改动的，所以代理端长期都是保持一个相同的资源配置，但是如何使代理端在不影响性能的情况下同步最新的主程配置。目前demo中式定期更新缓存。
现在的想法是另开一个线程，然后用一个全局变量来控制是否读取最新的主程资源

6.监控采集
通过webservice处理代理端的请求，入库。根据类型分表，View_Cpu、View_Mem、View_Sql、View_File等 表结构都一样。根据后台配置另开服务定期清理数据库数据

---

以上是demo开发过程中遇到的部分问题和临时个人的解决方法。大家交流一下可以发现好的方案，一起学习。