在 OneAlert，我们经常与运维团队聊天。因为产品开发过程中，这样的对话有助于了解客户的真正痛点。「告警垃圾」——监控系统中时常涌现的告警洪流，是运维团队经常提到的一大痛处。
至于其原因，虽然多种多样，但造成的后果都是一样的：信息超载。如果每天收到几十条甚至上百条告警提醒，你很难从中找出急需采取行动的紧迫告警。在那些紧迫的告警中，找出需要立即处理的告警更则难上加难。这种现象有个恰如其分的名字：告警疲劳
1.每台主机的告警
你看到的情况：服务器监控系统在同一时间发出5条紧急告警。
实际情况：你的缓存层由20台服务器组成。其中一台出现了新的配置错误，导致一系列的内存不足告警，每台主机都出现一条告警。
在理想世界中：你只会收到一条告警，告诉你25%的主机集群出现问题。而且，如果你当下正忙得不可开交，可以延后该告警的处理。理想情况下，告警阀值只在集群层或角色层设置。
2.重要！=紧急
你看到的情况：主机 X、Y、Z 出现磁盘空间不足警告。
实际情况：一切尽在意料之中。在正常运转了三个月之后，主机 X、Y、Z 存储的数据逐渐增多。或许你应该升级磁盘，或许你应该清理一些旧数据，但是，必须现在就处理么？在这夜阑人静的时候？
在理想世界中：除非磁盘使用量突然增多，否则就不是紧急事件。无需触发实时告警，只要每周一发送磁盘使用量报告，在其中列出磁盘空间不足的主机即可。如果能依照当前的使用速度，预测剩余的磁盘空间将在何时耗尽，就更好了。
3.非自适应性的阀值
你看到的情况：每个周一，午餐过后，都会出现大量的告警。
实际情况：你已经努力工作以优化配置 Nagios 监控的告警阀值。现在，它们不会每天无谓地发送告警。但是，一到流量特别大的某个工作日，还是会触发意料之中的告警。你怎么办？确认该告警，然后无视它。
在理想世界中：你的流量是有起伏规律的，监控系统能够掌握这种规律。如果每到下午1点负载就会增加，告警阀值也应该相应上升。告警只应在出现异常负载时触发，否则就是没有意义的告警。
4.同样的问题，不同的系统
你看到的情况：Nagios、Pingdom、NewRelic、KeyNote 还有 Splunk 在同一时间发出重要告警，与此同时，ZenDesk 上的客户投诉也不断增加。
实际情况：两个 Mongo 节点出现数据损坏，导致大量的磁盘 IO 以及事务错误。这类问题会波及服务器层，应用层以及用户层。因此，所有监控工具都会发出告警。
在理想世界中：你只会从最先捕获该问题的系统处收到一次告警，此后，任何因此而达到告警阀值的监控系统都会将其告警信息传给同一个「事件线程」。
5.瞬态告警
你看到的情况：每个人都会遇到这样的情况。同样的问题每隔几天就出现一次，持续时间不过几分钟，来得快去得也快。说实话，你已经忙得不可开交了，近期内也不大会去排除这种问题。
实际情况：可能是某个 cron 作业占用了过量的网络资源，又或是应用中某个 race-condition 导致了数据库死锁，也可能是某个不常用的功能导致了后端进程崩溃。
在理想世界中：你可以标记该问题，之后再去解决。这样，你只会在下个月再遇到该问题，并得到一份报告，显示了该问题通常的发生时间（当然还有相邻时间内容易发生的问题和与之相关的问题）。
你遇到了哪些告警垃圾？想不想与我们分享？请在文章下面的评论区留下你的反馈。
OneAlert 是应用性能管理领军企业 OneAPM 公司旗下产品，也是国内首个 SaaS 模式的云告警平台，集成国内外主流监控/支撑系统，实现一个平台上集中处理所有 IT 事件，提升 IT 可靠性。想了解更多信息，请访问 OneAlert 官网 。
本文转自 OneAPM 官方博客