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