监控的简单规划

运维的日常工作中，监控就是运维的眼睛，也是系统稳定的最大保障，下面写一写我自己对监控的一些理解，每个人有每个人的理解，本文只代表我个人的工作理解

监控，就是对系统本身以及其使用到的各个资源组件进行各方面运行情况的定时扫描，一旦异常，立即告警给运维人员处理

【1】阈值：

阈值就是监控告警的条件

1.这个条件通常都是监控预先设定的一个值，监控扫描出来的结果匹配到了，就告警

2.还有一种就是AI智能监控根据监控对象历史的情况，动态的生成告警阈值，让监控更加智能和合理化，但是要实现这种动态的阈值，一是需要在AI上的投入，二是目前的实现技术需要大量的标注，也需要投入一定人力

【2】频率：

监控告警的频率，需要根据监控的重要性来决定，这个需要运维人员自己评估，频率高了有可能浪费监控资源，以及对监控对象造成影响，频率低了可能造成异常不能及时发现，所以这需要一个权衡。

【3】监控内容

监控的方法大致可以分为下面三类，但是如果是通用型监控，其实都可以模板化，系统上线后，将对应的一些资源组件信息录入好，一键生成必要的性能监控，这样是最理想的

1.监控指标采集：

这个一般依赖于第三方，例如zabbix，argus等等去定时采集数据，然后对这些数据进行监控

2.监控sql查询

定时指定在数据库执行sql得到数据，对数据进行监控

3.监控脚本

自己写脚本，定时指定，对脚本的执行结果进行监控

【4】监控分级

监控是一定要分级的，这个很重要

根据所监控指标的重要性进行分级，不通级别的监控，可以再告警方式，处理时效上做一些区分，让监控管理更加标准，更加合理

【5】告警方式

传统的告警方式主要是 邮件告警，电话告警，这两个目前依然是最主要的告警方式

1.邮件告警

一般告警都是需要将消息告知到运维人员的，邮件是必不可少的一种方式

2.电话告警

一些特别重要的告警需要及时处理，那么就需要电话通知，保证运维人员第一时间处理

3.第三方消息平台告警

现在很多公司都有自己内部沟通消息平台，告警内容也是可以推送给这些平台的，例如微信公众号，钉钉等等

【6】处理：

收到告警邮件或电话后，运维人员都会开始相应的排查以及处理：

1.传统的告警处理

大部分情况都是收到告警，排查，处理完毕，则结束

2.简单告警，自动处理

一些简单的告警，有通用的处理方案的，其实是可以做成自动化的，减少运维人员的工作

例如：进程挂掉了，自动起起来，某个sql锁住了表，自动kill一下等等（这些自动化是一定要经过评估的）

3.自动收集告警相关信息

一些可能情况比较复杂的告警，也是可以在告警触发后自动去收集一些相关信息，或者简单的自动分析一些结论，一并邮件发送给运维人员，这样可以更快的处理，解决问题

例如：某个系统cpu消耗高，可以自动的去打一个线程dump，自动在主机上抓取这个系统进程消耗CPU前几的线程id 

【7】收敛：

监控是运维的好伙伴，但也是运维最头疼的，尤其是大公司，如果监控收敛不做好，监控越来越多，就会导致很多问题：

1.监控资源的浪费

2.无效告警导致运维对告警的敏感度降低

3.管理麻烦

所以应该定期的处理已经无效或者没有必要的一些监控，例如一些业务逻辑上的监控，可能这个业务监控已经不再需要了

监控收敛的方式：

1.人为定期检视告警情况，将无需处理的告警进行确认

2.系统化，对无需处理告警进行标注，用以一些规则来慢慢清理无需处理的无效监控

【8】记录：

每次告警的处理都是一次运维宝贵的经验，所以如果一些经典的问题处理，可以记录下来，如果后续有类似的问题，就可以作为借鉴

也可以将这些经验录入到系统，告警发生的时候，可以匹配类似的历史经验，一并邮件发出，给运维人员参考，特使处理速度