在 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 官方博客
