DB 监控 --DBA挨罚后，咱们说说怎么能不挨罚的解决方案（4）？

❝开头还是介绍一下群如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题有需求都可以加群群内有各大数据库行业大咖可以解决你的问题。加群请联系 liuaustin3 共3400人左右 1 2 3 4 5 6 7 8 9(1 2 3 4 5 6 7 8群已经爆满 9群 300开10群PolarDB专业学习群110 针对 SQLite 我们将建立一个新的群sqlite的群如果需要请加群的时候单独告知)那么我们举例核心业务库一晚上90%的CPU 你设置的电话告警一分钟一个电话你起来看业务告诉你导数据呢暂时就这样然后你就一晚上的电话不断最后你把告警电话拉黑了半夜因为倒数导致数据库挂了你没有接到告警电话最后你挨罚了。DB 监控 --乱搞监控最后挨罚了吧3)DB 监控 不是我不聪明系列--只从技术角度考虑监控问题是要挨骂的2)DB 监控-告警老明白了但就是搞不好 老挨骂-- 不是我不聪明系列1这是上期的问题大家该怎么办本期我们来看看上面的问题我们有什么方案可以进行操作或者说我们怎么尽量不挨罚。要想不挨罚我们先看看挨罚的原因在哪里。1 出事了你不知道。 对的在数据库挂了的时候你没有第一时间介入2 出事前你知道但你没有作为。对的因为你习惯了90%的数据库CPU告警没有问题 且你之前设定的CPU 90% 会出事的设定告警与现实不符。3 出事前和出事中你的电话告警一直打扰你导致了你禁止电话告警。那么解决问题也是有步骤和方法我们不妨先从治标的方法先来看。1 同一个指标在告警处罚后下一次告警的触发的间隔是多少从上面看间隔非常低1分钟一次这是导致这个人员关闭电话告警的直接原因如果我们把同一个告警的在发生第一次后的告警间隔设置为15分钟30分钟或者更长相信这个同学应该不会或者更低的可能关闭电话告警。2 告警CPU 的联动告警最后数据库是因为什么DOWN机的这个我们要明白数据库DOWN机的因素主要有哪些CPU 持续100%是不是DOWN机的根本原因。他显然不是那么这里我们没有看到的是1 数据库活跃链接的数的告警2 等待时间的告警3 TPS QPS的告警为什么CPU 90%这并不是数据库DOWN机的根本原因而数据库活跃链接过多导致数据库系统hang 死导致高可用判断主机死掉进行切换发起的工作倒是可能出问题的一个因素。同时从这个里面我们没有看到 DBA对这个数据库在TPS QPS上的阈值的设置比如在什么情况下TPS 或者 QPS达到多大数据库会有多少概率死掉。如果我们将这些指标和CPU90%联动呢如果我们对内存的阈值进行设定呢比如内存使用超过90%必须停止工作进行链接的查杀呢或者警告数据导入的工作人员这样继续数据库DOWN机的概率有多少如果继续这样工作数据库 down机的责任在他呢而我们的DBA只是关闭了电话告警那么他应该不应该挨罚呢 相信大家有自己的评判。那么我们继续进行治标的方案的讨论。如果我们进行联合的数据库告警呢 比如CPU 90%并不是告警的数据库指标而是我们需要判断1 CPU和内存的两个阈值同时发生触发底线阈值的情况下进行电话告警呢2 如果我们将CPU 慢查询的数量以及内存的阈值进行联合告警呢3 如果我们针对CPU 磁盘IOPS的阈值慢查询的数量以及内存的阈值联合进行电话告警呢在我们进行联动的指标后的电话告警的与数据库DOWN机的之间的准确率是否提升了呢那时如果在电话告警DBA是不是就会有更强的危机感因为这么多指标出现问题距离数据库DOWN机的概率越来越高。做完这些我想请问看到此篇文章的同学如果你是哪个DBA你觉得你挨罚的概率还大吗