磁盘空间报警自愈的设计小结

这是学习笔记的第 2209 篇文章

读完需要

9

分钟

速读仅需7分钟

前段时间集中处理了一批磁盘空间报警类问题，让人有些恼火，因为报警了，不处理还不行，处理的话一方面是碎片的时间，处理步骤八九不离十，二来是非工作时间处理，我非常不喜欢这种被骚扰的状态，于是决定做一些改进。

关于磁盘空间报警有哪些常见的问题呢，我总结了下，刚好借此把牢骚归归类。

• 周末，节假日临时报警
• 非工作时间（尤其是凌晨)报警
• 报警未处理没有及时提醒
• 没有问题处理的知识库，很多问题处理过程是相似的
• 绝大多数报警是不合理的，只告诉问题，没有分析，过度依赖人工
• 报警是系统异常流程的最后提醒环节，只是提醒，对于问题的最终解决没有直接推动作用
• 级联问题导致报警失效，如系统问题导致数据库问题
• 报警基于阈值，业务周期性活动也会频繁报警
• 报警阈值不够合理，79.9%，80.1%
• 千人一面难以实现千人千面
• 报警没有弹性

当然光有牢骚是无力感的，我们得给出解决办法，解决办法不是处理A处理B这样明确的事情，因为空间问题可能涉及多个层面，所以我们应该是要梳理相关的策略，对于不同的问题处理方式或者思路会有所差异。

对于系统层面，比较通用的就是系统空间处理。

对于数据库层面，大体分为两个层面，一个是数据库空间处理，一个是数据库参数调整。

对于数据库主从实例来说，直接的空间收缩办法就是删除不必要的binlog文件。

在数据库参数层面来说，思路是相通的，那就是通过调整参数来删除相关的binlog,使用purge binary logs的方式来删除。

当然这个层面只是一个引子，基本能够覆盖50%的场景，而有些场景如果做一番分析，会发现是和业务层有关联的，也就是空间阈值超过了80%的时候，单纯文件层面的清理已经比较有限了，我们就需要结合业务的情况进行空间的清理。

比如有些数据库中配置了大量的日表，比如默认是保留2周，我们可能保留的时间会稍长一些，一旦出现空间异常的时候，收缩空间也就有弹性了。

如果是一套集群环境，那么空间的清理就更是需要了，而且会涉及多套关联环境。

第三部分是反馈，也就是处理问题有策略，更进一步应该是所做的工作应该有反馈，而且是有选择性的反馈。

这个部分可以玩得很高级，本质上就是可以做到定制化，如果要做到更精细，可以结合一些数据预测相关的内容。

• 告知紧急程度，是否已自动处理
• 主动生成巡检报告，告知当前的整体情况
• 监控，报警，巡检三位一体结合
• 报警预测 报警时间预测 多长时间会触发报警条件 报警窗口预测 指定时间窗口是否会触发报警 智能策略 阈值策略
• 弹性报警 根据优先级进行报警频度控制 报警合并

当然这个部分从思路沉淀到落地，策略部分的实现写脚本的过程大概就是周末的一个半天时间基本成型，然后修正一下能够基本跑起来。

而那些看起来高大上，不做不行的事情，在满足了初步需求之后，似乎好像一下子得到了缓解，这个时候我关注的是如何让吃相看起来更优雅。

经过了一些测试和数据验证之后，我发现反馈机制还需要做更进一步的调整，应该使我们对待报警的一种正确态度。

• 没事不要给我反馈
• 解决不了再反馈
• 反馈前有什么可行的方案