❝开头还是介绍一下群，如果感兴趣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 监控 不是我不聪明系列--只从技术角度考虑监控问题是要挨骂的（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，你觉得你挨罚的概率还大吗？
