DB 监控 --乱搞监控最后挨罚了吧？（3)

❝

开头还是介绍一下群，如果感兴趣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+)

DB 监控 不是我不聪明系列--只从技术角度考虑监控问题是要挨骂的（2)

DB 监控-告警老明白了，但就是搞不好 ，老挨骂-- 不是我不聪明系列（1）

上集咱们说到数据库的分类分级和数据库的告警应该怎么做的问题，为什么数据库告警要先对数据库进行分类分级，分类分级有什么标准，通用的操作手段是什么。

1 业务重要性作为数据库分类分级的标注标准

这是一个数据库告警工作的前缀，公司中的数据库类型非常多，我们举几个例子

1 生产库，测试库

2 边缘业务库，核心业务库

3 离线核心业务库，在线核心业务库

4 核心业务mongodb 数据库 ，核心业务 MySQL数据库，核心业务Redis数据库

大家可以看到上面的类型非常多，正常的DBA一半会给这些库列一个等级

1  直接划分数据库告警与不告警的维度，生产和测试

这里我们可以清晰的看到，数据库告警的必要性，生产是必须要告警的，而大部分情况TEST ,DEV 是不需要告警的。

这里就有人提到，不对，测试和预生产也需要告警。

他说的是对的，测试和与生产也需要告警，告什么警，告数据库DOWN机的警，也就是当这个数据库发生严重的无法连接，或者数据库整体DOWN机且无法启动后的告警。

这样的告警方式可能很多，比如邮件告警，或者企业微信，钉钉告警等。但这里注意这样的告警必须和生产数据库告警群分离，不能将这样的告警与生产数据库的告警放到一起。

2 业务重要性的分类

生产数据库也是需要分类分级，比如数据库性能出现问题，就会导致生产事故，或者数据库只要不DOWN机就不会产生生产事故。

除了上面的数据库告警分类以外，以业务的重要性来衡量数据库告警的方式，方法，阀值是最有效的方法。

我们举例一个数据库平时的工作CPU没有超过 40%的情况，某天突发超过60%，要不要告警，怎么告警，告的什么警。这些统统和你的业务的重要性有关。

这里又会牵扯出，环比和同步的告警问题，当然这个问题咱们后面说，今天就不说这个问题了

这里我们举一个例子，一个公司一个报表的数据库，每到月底CPU几乎95%以上，内存使用率到到90%以上，磁盘IOPS 能告警一晚上，但是他就是不DOWN机，同时没有客诉，或者项目经理告诉你，这个业务就是这样，平时CPU连5%都没有，就到月底，年底，CPU这样，我请问你的数据库要不要告警，怎么告警，告的什么警。

这里就要牵扯，告警的级别了，数据库告警有级别，当然数据库告警当然有级别

分别是 alert, warning, info 用中文，事故告警，风险告警，和观察告警。

那么什么是事故告警，我们在举一个例子，数据库down机了，数据库无法连接了，数据库主从复制中断了，磁盘写满了。

这些必然是严重的生产事故，因为数据库不可用了。

而我们刚才提到了，一晚上数据库都那样，但没有事情，这算什么告警，这算风险告警，而我们很多的情况都是 风险告警，比如CPU 90% 但就几秒钟， IOPS打满了，但就2分钟，内存90%了，但就10分钟。

我请问这些要不要告警，告的什么警。

这是一个好问题，怎么办？？？  你说呢 ，我相信很多人都会说这还不告警吗？？

那么我们举例，核心业务库，一晚上90%的CPU ，你设置的电话告警，一分钟一个电话，你起来看，业务告诉你，导数据呢，暂时就这样，然后你就一晚上的电话不断，最后你把告警电话拉黑了，半夜因为倒数导致数据库挂了，你没有接到告警电话，最后你挨罚了。

请问你该怎么办？  咱们下期说