这是学习笔记的第1968篇文章
我们认知中的巡检设计大多是一种被动的方式,即你希望做什么,按照这个思路和流程来设计,如果希望巡检能够发挥出强有力的支撑,那么我们需要转化被动为主动,即思考巡检数据对我们有什么用处?
有的同学可能还不大理解,我们来举个例子,比如我们会每天收集数据库中的表信息(数据库,表名,表数据大小,索引大小,表结构变更时间,碎片情况等),这样一份看起来简单的数据如何发挥余热的,我来给出一个列表:
1)冷数据,一些长时间未操作的数据,可以通过数据量和时间维度进行权衡
2)库中的表过多,可以通过统计的方式得知哪些环境是属于不规范环境,这类问题通常感受不到,但是一出问题哪里都是问题
3)一些没有用到的表,临时表和备份表,这些表像牛皮癣一样,我们要对数据库做下清理。
4)周期表探测,如果一些业务存在周期表需求,那么通过反向的方式可以很轻松找出那些日报,月表等周期表
5)数据库的特性和业务类型不匹配,如果表数据写入过多,很可能是日志型业务,可以根据一个或多个维度来评估是否和现有的业务类型匹配
6)预测数据量变化,可以通过历史数据的变化建立模型预测近一段时间的数据量变化
7)数据生命周期管理,有了时间维度的信息,我们可以建立数据生命周期管理模型,来通过多个维度来进行表结构变更的追溯。
8)权限和安全隐患管理,我们可以通过全局的方式来评估现有环境存在的隐患,比如那些流程外创建出的表,流程外删除的表,可以做得统筹的管理。
以上只是抛砖引玉,主要想表达的就是巡检在一定阶段之后会产生数据分析的更大价值,让我们对更多的问题具有主动的管理方式,而从一开始就希望想全,想好也是不切实际的。
此外,我需要补充的就是运维体系的建设中需要深入融合巡检。
在我们的运维体系中,其实一直有一块短板,那就是单纯依靠监控和报警模块,工作效率和质量是一种被动的方式。
我们可以假设一个场景,你在节假日的时候在外面游玩,刚在高速路上的时候,收到了一条报警,一个关键业务系统的磁盘空间超出阈值(假设是80%),这对你的旅游兴致来说是大受影响,虽然这样一件事情处理的难度不高,但是我们总是需要花费那么些额外的时间和精力去处理,这个代价对于个人来说是很高的。
如果我们能够有一种机制去缓解这个问题,比如我们马上收到巡检信息提示的一封邮件,可以看到这个磁盘空间的增长是平缓的,而不是那种业务增长导致的尖峰,那么这个问题处理的时间就可以适当后延,对于正常的生活和工作是收益很大的,按照这种机制,在不影响业务的前提下,我们可以把很多干扰我们的大量碎片时间,作为一种延迟处理的方式,这是一种运维信仰和工作理念。
以下是一个监控,报警,巡检的三体一体集成方案。
我们来对这个图做下解释:
1)监控和报警,这是常规的运维体系,监控达到阈值触发报警
2)报警和巡检,通过报警能够异步调用巡检接口,对已有的数据库业务进行巡检,比如发送巡检可视化报告或者巡检提示信息,让巡检工作不再被动,而是因需而动
3)巡检和监控,通过巡检机制的完善,能够发现更多的问题,然后建立新的监控指标
4)监控和巡检,如果监控指标未达到报警阈值,并不一定意味着没问题,但是通过一些监控指标来触发巡检就可以把这块空白补上,比如一个系统的磁盘空间80%为阈值,在1:00~2:00,磁盘空间使用率从20%增长到70%,虽然不会触发报警,但是短时间的增量较多,我们可以设定70%的阈值为巡检模型所用,就可以通过巡检模型来识别出这类问题
领取专属 10元无门槛券
私享最新 技术干货