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

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

这是一个新的系列，名字叫未卜先知。数据库运维工作中，其中有一项重要的工作是数据库的监控和告警的搭建工作。这项工作看似都是技术指标和阀值的搭建，同时已经有了成熟的方案和体系-比如 prometheus + Grafana可我们看到的文章作品等等，都是讲述技术特征的，很少有针对具体的公司中的数据库告警问题有成系列，成体系的内容出现。

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

本着2026年Austindatabases公众号的主旨是利他，同时公司也要对数据库的整体的告警和数据库监控进行重大的调整，所以新开了这个系列叫不是我不聪明系列

那么如果你不清楚这个系列要做什么，我们先假设你有如下的问题。

1 数据库告警的时候，数据库已经down机了，领导责问为什么不能更早的发现问题，处理问题。

2 数据库告警的时候通过短信的方式来告警，我晚上睡觉没有听见

3 数据库告警的频率太高了，我们虽然对数据库告警的阀值进行了调整，但是一些数据库还是经常触发阀值，比如内存超过85%进行告警，但是很长时间都没有出问题，大家逐渐对内存超过85%占用失去敏感性，而一次内存达到了90%后很快系统就OOM了，导致严重的生产事故。

4 数据库监控通过Grafana进行展示，通过监控图我们例行进行监控，突发有一天内存从30%到50%没有注意，而后某天出现问题，被问责为什么某天内存的占用率从30%突然到50%后没有发现其中的问题，导致后面更严重的生产事故。

5 数据库的告警和监控是否仅仅围绕技术指标，并且同一类型的数据库产品都是一个阀值，都是一个监控的选择项，而一些业务就是每天有稍短的时间会触发阀值，进行告警而这不会出现生产事故，大家都知道，告警在这个数据库就是鸡肋。

各种的数据库告警和监控的问题，其实细分后，问题多如牛毛，正是每天对这些看似小问题，或者不是问题的问题，再或者由于我们没有注意这些，最后导致严重的生产事故的问题。

那么我们该怎么办，仅仅从技术的角度，专研一个数据库的某个技术参数并不能解决问题，怎么进行体系化的研究有效的对公司的数据库进行，行之有效的监控和告警，整体的方案是什么，就是我们这个系列要和大家探讨和讨论的，如果你也有这方面的问题，欢迎关注我们也可以群里去讨论问题，通过大家各种问题的提出，来寻找在当下最适合你的行之有效的解决方案。

好了下期我们将开始针对数据库的分类分级进行讨论，告警和监控要做好的第一步，是什么？