在 OneAlert梅忌，我們經常與運維團隊聊天。因為產品開發(fā)過程中除破，這樣的對話有助于了解客戶的真正痛點牧氮。「告警垃圾」——監(jiān)控系統(tǒng)中時常涌現的告警洪流瑰枫，是運維團隊經常提到的一大痛處踱葛。
至于其原因，雖然多種多樣光坝，但造成的后果都是一樣的：信息超載尸诽。如果每天收到幾十條甚至上百條告警提醒，你很難從中找出急需采取行動的緊迫告警盯另。在那些緊迫的告警中逊谋，找出需要立即處理的告警更則難上加難。這種現象有個恰如其分的名字：告警疲勞
1.每臺主機的告警
你看到的情況：服務器監(jiān)控系統(tǒng)在同一時間發(fā)出5條緊急告警土铺。
實際情況：你的緩存層由20臺服務器組成。其中一臺出現了新的配置錯誤板鬓，導致一系列的內存不足告警悲敷，每臺主機都出現一條告警。
在理想世界中：你只會收到一條告警俭令，告訴你25%的主機集群出現問題后德。而且，如果你當下正忙得不可開交抄腔，可以延后該告警的處理瓢湃。理想情況下理张，告警閥值只在集群層或角色層設置。
2.重要绵患！=緊急
你看到的情況：主機 X雾叭、Y、Z 出現磁盤空間不足警告落蝙。
實際情況：一切盡在意料之中织狐。在正常運轉了三個月之后，主機 X筏勒、Y移迫、Z 存儲的數據逐漸增多」苄校或許你應該升級磁盤厨埋，或許你應該清理一些舊數據，但是捐顷，必須現在就處理么荡陷？在這夜闌人靜的時候？
在理想世界中：除非磁盤使用量突然增多套菜，否則就不是緊急事件亲善。無需觸發(fā)實時告警，只要每周一發(fā)送磁盤使用量報告逗柴，在其中列出磁盤空間不足的主機即可蛹头。如果能依照當前的使用速度，預測剩余的磁盤空間將在何時耗盡戏溺，就更好了渣蜗。
3.非自適應性的閥值
你看到的情況：每個周一，午餐過后旷祸，都會出現大量的告警耕拷。
實際情況：你已經努力工作以優(yōu)化配置 Nagios 監(jiān)控的告警閥值。現在托享，它們不會每天無謂地發(fā)送告警骚烧。但是，一到流量特別大的某個工作日闰围，還是會觸發(fā)意料之中的告警赃绊。你怎么辦？確認該告警羡榴，然后無視它碧查。
在理想世界中：你的流量是有起伏規(guī)律的，監(jiān)控系統(tǒng)能夠掌握這種規(guī)律。如果每到下午1點負載就會增加忠售，告警閥值也應該相應上升传惠。告警只應在出現異常負載時觸發(fā)，否則就是沒有意義的告警稻扬。
4.同樣的問題卦方，不同的系統(tǒng)
你看到的情況：Nagios、Pingdom腐螟、NewRelic愿汰、KeyNote 還有 Splunk 在同一時間發(fā)出重要告警，與此同時乐纸，ZenDesk 上的客戶投訴也不斷增加衬廷。
實際情況：兩個 Mongo 節(jié)點出現數據損壞，導致大量的磁盤 IO 以及事務錯誤汽绢。這類問題會波及服務器層吗跋，應用層以及用戶層。因此宁昭，所有監(jiān)控工具都會發(fā)出告警跌宛。
在理想世界中：你只會從最先捕獲該問題的系統(tǒng)處收到一次告警店溢，此后蜻韭，任何因此而達到告警閥值的監(jiān)控系統(tǒng)都會將其告警信息傳給同一個「事件線程」咳胃。
5.瞬態(tài)告警
你看到的情況：每個人都會遇到這樣的情況峡扩。同樣的問題每隔幾天就出現一次，持續(xù)時間不過幾分鐘鹉戚，來得快去得也快谭贪。說實話斤蔓，你已經忙得不可開交了隆圆，近期內也不大會去排除這種問題漱挚。
實際情況：可能是某個 cron 作業(yè)占用了過量的網絡資源，又或是應用中某個 race-condition 導致了數據庫死鎖渺氧，也可能是某個不常用的功能導致了后端進程崩潰旨涝。
在理想世界中：你可以標記該問題，之后再去解決侣背。這樣白华，你只會在下個月再遇到該問題，并得到一份報告贩耐，顯示了該問題通常的發(fā)生時間（當然還有相鄰時間內容易發(fā)生的問題和與之相關的問題）衬鱼。
你遇到了哪些告警垃圾？想不想與我們分享憔杨？請在文章下面的評論區(qū)留下你的反饋。
OneAlert 是應用性能管理領軍企業(yè) OneAPM 公司旗下產品蒜胖，也是國內首個 SaaS 模式的云告警平臺消别，集成國內外主流監(jiān)控/支撐系統(tǒng)抛蚤，實現一個平臺上集中處理所有 IT 事件，提升 IT 可靠性寻狂。想了解更多信息岁经，請訪問 OneAlert 官網 。
本文轉自 OneAPM 官方博客
