我們不會粉飾它——網絡監控是個累贅。我們聽到客戶談論的最常見的痛點是缺乏對所有 IT 的單一視圖、過度警報以及保持整個工作正常運行所需的管理開銷。在這個博客中，我們將討論如何緩解通常最痛苦的問題——過度警覺和淹沒你的工程師和技術人員在難以理解的數據海洋中造成的問題和疲勞——我們稱之為“數據洪流”。
監測噪音或“數據泛濫”挑戰
問題在于來自多個平臺的信息“泛濫”，造成如此多的問題，以至于員工忙于處理它們而無法預防，而由于普遍未通知導致的信息丟失而加劇了這些問題。要解決這些問題，我們需要從尋找它們的原因入手。
來自多個平臺的信息泛濫是由于缺乏明確的通知計劃和過度配置的監控和警報造成的。嘗試創建一個僅限于單一平臺的連貫系統，該系統只提醒您可以或將要解決的問題。反應性警報、靜態警報以及缺乏自動化和長期可見性使得潛在問題未報告和未解決，直到它們成為主要問題。未能通知會導致遺漏問題，而讓問題溜走的參差不齊的監控政策會加劇這種情況。這些是由于 dev 和 prod 之間缺乏通信導致監控系統跟不上配置更改造成的。
創建新的監控策略
控制信息的第一步是創建新的監控策略。這是通過為您的配置奠定基礎、定義行動和升級計劃以及安排時間表以定期更新該計劃來完成的。根據受影響的用戶數量和影響的嚴重程度定義您的優先級。請記住，如果一切都很關鍵，那么沒有什么是關鍵的。通過制定盡可能具體的行動計劃來跟進這一點。您將需要定義：通知誰、何時以及如何通知；何時升級，向誰升級；何時進行更改；以及您可以和不能自動化的內容。
制定行動計劃
首要任務是定義一個行動計劃，在危機期間可以依賴該行動計劃獲得詳細的指示。您至少需要定義在事件期間應該準確通知誰以及應該使用哪些方法，既用于初始通知，也需要定義升級時間表。在通知管理人員之前，中斷應該持續多長時間？這也將在很大程度上取決于中斷的范圍和優先級，因此請確保您清楚地概述了將傳達給他們的內容。請記住，措辭不當的通知會適得其反——它們會導致人們恐慌并采取錯誤的行動。
另外，請記住考慮一天中的時間和一周中的一天。一些企業是 7/24/365 運營，但許多不是，或者至少不是所有資源。當系統在幾個小時后出現故障但直到第二天才需要時，流程是什么？什么時候有人可以解決這個問題？在許多情況下，對非工作時間中斷的不同響應是合理且適當的，您的監控計劃應反映這一點。
最后，不要忘記看看你可以自動化什么。自動化對事件的初始響應以執行諸如重啟服務器、啟動新的云資源或重啟集群中的服務之類的操作，可以大大減少您的 MTTR——通常甚至在您必須手動干預之前。
管理您的監控通知
在大規模中斷期間，您需要能夠可靠地將正在發生的事情傳達給所有團隊和利益相關者。您的監控計劃應準確說明您將如何向人們發出通知，尤其是考慮到大規模停電所固有的困難。電子郵件和短信通常是大多數通知所基于的基礎，但如果我們沒有完全實施我們討論過的技術以盡量減少它們，它們可能會在危機期間受到影響，或者只是充滿警報和通知。
考慮一些替代方法。例如，移動應用推送通知采用與電子郵件完全分離的路徑，這些甚至可以從云端啟動，因此您的內部網絡或系統的狀態不會影響它。您還可以將 API 集成到團隊通信平臺（如 slack、spark、bitrix 或其他平臺）中，以確保團隊的所有成員都知道正在做什么、何時以及由誰完成。
您的計劃還應該利用您擁有的現有操作系統。這有助于消除冗余警報源并將事件整合到可管理數量的警報中。例如，與通知管理器集成可以簡化待命安排，并提供一種不依賴于內部郵件基礎設施的警報分發方式。許多組織還將使用 ServiceNow 等票務或 ITSM 系統，您需要確保您的計劃包括在危機期間應如何使用這些工具以及如何將它們與您的監控和警報系統集成。
減少警報量
還可以通過自動響應某些類型的警報來減少警報量，例如讓服務、服務器和端口自動重新啟動，同時仍然允許您手動執行命令。在這種情況下，維護窗口就不那么重要了。減少警報數量的另一種方法是將相關問題放入單個通知中，這在級聯故障和基礎設施依賴警報（即延遲）等情況下特別有用。當然，最簡單的減少方法是掌握流程，在處理警報時確認警報，使用計劃中斷的維護窗口，并與現有流程（例如票務和抄送）集成。不要費心提醒不可操作的項目。
在處理電子郵件警報和報告時，使用分發列表與人員變動保持同步，并為歷史報告創建存檔。使用歷史報告存檔來識別“吵鬧的鳥兒”，這將有助于發現和消除誤報。您可以使用“吵鬧的小鳥”來創建模板基線報告和通知摘要報告。讓我們看一些警報示例，看看哪些是真正可行的。
如果您收到高 CPU 利用率警報，這是否可行？好吧，可能是 CPU 已經卡在那里一段時間了。允許您為這些類型的警報設置延遲，因此在一段時間內超過 90% 之前它不會生成警報。如果您的 SQL 服務器與 CPU 掛鉤，這可能是正常的，并且您不想要那個警報，但如果它已經被鎖定了 30 分鐘，您可能需要去殺死一個工作。
優化警報
還內置了工具來幫助您優化警報，這將使您能夠識別“吵鬧的鳥兒”。少數配置的警報導致警報數量不成比例，或者可能需要調整警報靈敏度的警報。您還可以使用模板基線報告準確查看配置模板正在生成哪些警報，并直接對其進行更改，然后可以自動將這些更改推廣到應用該模板的所有設備。此外，通知摘要報告之類的內容有助于準確查看發出的警報并計算來自每個設備或每種類型的服務檢查或閾值警報的警報數量。
如果交換機端口出現故障，這是否可行？如果它插入了重要的東西，通常是的，所以這是立即報警的好選擇。但是，如果它是端口通道的一部分，或者只是大型集群中的一臺服務器呢？這可能需要不同的優先級或不同的通知方法，不需要“刪除所有內容并修復此”響應。
如果網站宕機了怎么辦？嗯，這通常是一個很大的肯定。但是你想確保它從你的環境外部和內部都下降，這樣你就可以正確地協調響應。重要的是要知道它是只是返回錯誤的網頁，還是后端出現故障，或其他原因 - 因此使用從多個遠程位置啟動的應用程序檢查等功能可以幫助您在開始故障排除之前評估問題。
使用電子郵件分發列表
我們經常向客戶提供的最佳實踐建議之一是使用分發列表（而不是單個電子郵件）作為您的電子郵件警報和自動報告。這樣做有幾個很好的理由，但關鍵之一是更好地與人事變動保持同步。監控系統檢測到問題的事件不止幾起，但警報會發送到廢棄或無效的郵箱，這導致檢測和處理問題的時間明顯延遲。它還允許您創建自動報告的簡單歷史存檔并在中心位置共享它們，因此如果您需要返回兩年前 9 月的每周績效報告，它們很容易找到和定位，即使詳細數據現在已經存檔。
拓撲映射
減少警報數量的最佳方法之一是利用您的工具來利用自動警報抑制技術，例如根本原因檢測。通過在您的工具中配置拓撲（或讓工具發現它），該工具可以確定該位置的所有遠程設備突然無法訪問的原因是由于 WAN 路由器故障，而不是發送通知每臺遠程設備——每臺交換機、服務器、應用程序和無線接入點——你可以得到一個單一的警報，立即告訴你問題是廣域網路由器，例如。
自動化您的監控和警報響應
此外，控制正在發送的警報數量的一個好方法是集成自動化。自動化有幾種形式，首先要看的是自動化對警報的響應，因此在許多情況下，我們可以完全消除發送通知的需要。您可以鏈接供應商 API，例如 webhook，以便您的監控系統可以重新啟動端口、重新測試應用程序，甚至轉儲實時診斷以響應問題。
允許您通過操作員干預手動控制這些命令，因此，如果您想直接在監控系統的 Web 界面中添加“單擊以重新啟動服務器”功能，并限制只有管理員可以訪問，有一個簡單的方法可以做到這一點. 但是請記住，如果您要自動響應，則維護窗口的使用變得至關重要。否則，計劃的軟件升級可能不會如您預期的那樣進行，因為您的監控系統開始在后臺采取行動。沒有什么比關閉應用程序進行計劃升級并讓服務器突然重新啟動更令人沮喪的了。
如果您使用多個平臺接收通知，請確保問題的優先級會影響消息傳遞的方式，以免緊急通知被埋在多個不同應用的收件箱中。一些常見的通知方法包括電子郵件、SMS、移動推送通知、slack 和 spark。
要管理您的通知，請盡可能集中更改，以避免重復報告和沖突狀態。集中化最重要的部分是在團隊之間進行單點確認、溝通和查找狀態。您可以通過 API、OpsGenie 和 PagerDuty 等通知管理器以及 ServiceNow 和 Remedy 等票務系統將集中化與現有系統集成。
利用自動配置
讓我們談談另一種自動化監控過程的方法，那就是自動化監控系統的配置。確保您的集中可見性可以保持最新，而您的環境不斷變化是關鍵。具有易于使用的基于 Web 的 API，允許您將配置過程直接鏈接到監控中，或通過 API 自動發現資源，然后使用規則推動配置向前發展，以定義控制各個方面的類別、戰略組和模板以最小的開銷監控配置。您甚至可以通過 API 將您的部署與自動維護窗口相關聯。將新系統投入監控（或將其移除）所花費的時間越少，也意味著有更多時間專注于更重要的任務以推動業務向前發展。
使用靈活的自動配置系統來自動化您的配置。自動配置附帶一組規則來幫助您入門，并且可以輕松自定義或創建它們以適應您的環境。您可以使用它們來設置設備屬性，例如基于任何設備標準的類別、站點和應用程序組——包括諸如正在運行的進程、打開的端口、設備名稱或 SNMP 值等內容。這可確保您的配置過程中沒有手動步驟。通過這種方式，您可以輕松確保設備最終出現在正確的報告中，并且始終應用正確的設置。這些會在發現設備時自動應用到設備，也可以根據需要重新應用，因此如果您想確保所有 STAYS 都按照您想要的方式進行配置，您可以強制執行。
不要依賴手動流程來管理配置。自動發現不應僅限于掃描，并確保使用 API 的深層鏈接。可以使用 vCenter、puppet/chef、Hyper-V 和超融合將監控鏈接到配置。自動發現您使用的云資源和系統，包括 Azure、AWS 和 GCP。利用基于異常的閾值來檢測和警告異常行為并自動生成基線，但請仔細考慮您的敏感性。
使用級聯模板自動化
使用我們使用 AutoConfig 引擎設置的這些標準，可以將所有相關模板動態應用到您的設備。將自動應用多個模板，每個模板的設置將智能地滾動到設備上。這樣，上線的新 SQL 服務器不僅可以獲得您想要的基本 Windows 服務器設置，還可以獲得特定于 SQL 的應用程序檢查和設置。您可以使您的模板與您的監控計劃保持一致，以確保它們設置適當的優先級和時間，并讓它們定義正確的身份驗證、升級和主動響應自動化操作。它的設計足夠靈活，可以滿足全球企業客戶的需求，同時對于小型 IT 部門來說仍然足夠簡單，無需大量培訓或專職人員即可使用。
使用基于模板的配置時：設置所有警報、閾值和服務；按優先級、應用程序和平臺創建模板；并定義升級、操作和自動化。使用基于規則的自動化應用模板，這些模板可以自動應用到發現的設備，將確保您不會錯過任何配置步驟，并允許根據需要重新應用規則。
使用異常檢測
檢測異常行為，而不是僅僅依靠靜態警報設置，是主動監控并在問題影響用戶之前發現問題的關鍵方法。您可以輕松地使用異常檢測來發現應用程序行為的變化，并且它幾乎可以應用于任何地方——CPU、內存使用、正在運行的進程，甚至是日志消息。如果您的應用程序從每小時 10 次登錄失敗變為 1000 次，那么最后一次部署可能沒有您預期的那么順利，現在您可以開始進行故障排除了。
將使用我們保留的大量歷史數據自動生成基線行為模型，并隨著您的環境變化和演變自動調整基線。可以根據觀察一天中的某個時間、一周中的某天甚至每小時的基線行為的變化來檢測異常情況。這使您可以發現意外影響，例如導致后端 SQL 服務器上 CPU 出現異常行為的軟件更改。
我們的一位客戶發現了一個問題，通常在星期三上午 10 點，數據庫服務器以 50-60% 的速度運行，但突然以 15% 的速度運行。事實證明，用戶界面的軟件更改破壞了應用程序深處表單上的 CSS，前端團隊沒有注意到它，客戶也無法正確完成訂單。這種異常是一種永遠不會觸發靜態閾值的異常行為，但在這種情況下，早在他們注意到訂單急劇下降和可能導致的客戶投訴之前就揭示了一個問題。
管理流程
制定成功的監控計劃的關鍵是確保它被使用并始終掌握監控系統。確保您的技術人員和工程師在處理問題時承認問題。不要讓監控屏幕被警報淹沒。充滿警報的監控屏幕很容易錯過關鍵警報。需要盡快對警報采取行動并確認或更正。在支持團隊的正常工作時間之前，讓警報排在隊列中是不可接受的。如果條件在非工作時間是可以接受的，那么只有在不可接受并且有人可以解決問題時才應該生成警報。在特定時間范圍內未得到解決的警報應升級。
此外，對計劃內停機使用維護窗口不僅有助于減少警報數量，而且還將使正常運行時間報告正常化，因此在給定月份內沒有計劃外停機的系統可以顯示 100%，而無需手動調整報告或編寫解釋將它們匯總到高級管理層。最后，不要忽視警報。忽略警報肯定會惹上麻煩。在某些時候，會犯錯誤，有人會忽略錯誤的警報。通過確保甚至看不到不可操作的警報來完全避免該問題。您仍然可以在不利或異常情況發生后報告以進行主動調查。
