在上一份工作離職前的最后幾個月里，我承擔了團隊內部的系統的監控工作，監控范圍主要包含1個SAP CRM系統，1個基於SQL Server的查詢系統，以及2個Dynamics CRM系統。
基本上，在SAP CRM和SQL Server系統的監控工作還算良好，一些監控可以及時發現系統中存在的不一致現象，並確定其范圍，減輕了運維負擔。但Dynamics系統的監控堪稱失敗，出現了包括沒有及時檢測出問題、誤告警、開了多次低效會議等等。可以說不僅沒有提高運維效率，反倒是讓相關人付出了不必要的時間成本，讓我頗感慚愧。本文記錄了對失敗監控的一些反思，隨想隨寫，也許並不全面。
我們做了什么
失敗的監控可以分為黑盒和白盒2個部分。
黑盒監控的內容是，通過分布在全球各地區的一些實體測試計算機，運行EasyRepro測試腳本，訪問Dynamics系統，並模擬一些業務操作，將記錄的信息發送給Splunk。Splunk根據設定的告警條件對異常情況發出告警郵件。
白盒監控的內容是，通過Azure收集系統信息，並通過Azure自帶的工具分析和發出告警。
然而這兩方面的監控都產生了一些問題，下面一一分析。
本文鏈接：https://www.cnblogs.com/hhelibeb/p/14153490.html
轉載請注明
監控的目標問題
最初的監控目標非常簡單，就是IT團隊希望在系統不可用的時候能及時收到告警，在用戶打熱線之前先掌握情況，以避免過於被動。
我們試圖通過黑盒測試來發現系統不可用的情況。但在開始階段我們就犯了一個比較明顯的錯誤：沒有真正明確什么是“系統不可用”。
比如，測試腳本的開發人員根據自己的理解，認為每個步驟超過若干秒沒有響應就說明該功能不可用。但現實當中的確會偶爾出現系統響應很慢的情況，這可能和客戶端計算機的狀態有關，也可能和服務器狀態有關。重點在於，這種偶然出現的狀況在大部分企業用戶眼里不算很嚴重的問題。即便它是問題，也不應該觸發需要IT立刻采取行動的告警，而是應該產生一個級別比較低的、可以讓IT在接下來幾天內響應和處理的事件。
所以，負責監控的人員必須明確監控的目標是什么、什么樣的信息是需要相關人立刻做出反應的。如果在這種問題上產生模糊，就會導致誤解和不必要的工作。
另外，在根據監控數據制作報表和Dashboard前，我們也沒有充分和需求方交流，這導致做出了一些無用的東西，浪費了時間。
故障與自動檢測/恢復的問題
黑盒測試的另一個尷尬問題是，測試計算機本身也可能出問題。而且由於測試計算機有多台，且分布在不同的地理區域、有着不同的軟件和硬件環境，它們出現問題的概率遠遠大於被監控的系統出問題的概率。它們有時可能出現網絡故障，有時可能遇到系統、瀏覽器自動更新，有時可能會產生配置錯誤。這些都可能導致測試失敗。
而當監控手段比監控對象更加不可靠的時候，監控會變得無意義。
一開始，測試機器比較少，我們用人工的方式配置機器，並在監控出現問題時人工排查和解決。但隨着測試機器的增多，我們逐漸疲於奔命，只好開始寫腳本，來對這些機器做統一的配置。我想通過腳本對它們做自動化的配置是一個正確的思路，但還遠遠不夠，而且做的太晚、太被動，導致我們付出了過多的勞動、遇到了多次假告警。正確的思路應該是在早期就通過腳本自動配置每台機器，而且測試機器必須有自我檢查能力，可以自動的發現自身的異常並嘗試修復。否則它們只會給人帶來負擔而不是收益。
監控的指標問題
理論上，監控系統有4個關鍵指標，分別是延遲、流量、錯誤和飽和度。
我們最早試圖從延遲和錯誤來發現故障，忽略了其它指標，直到很晚的是時候才意識到這個缺失。比如單純的延遲提高未必說明系統不可用，但延遲提高再加上流量急劇降低，很可能意味着系統已經不可用了。
飽和度有時也是一個容易被忽略的指標。
數據收集的問題
收集過多的監控數據可能會帶來成本的提高和性能的下降，收集錯誤的數據可能會導致監控規則的復雜化和錯誤結果。我們注意到了前者，但沒能及時意識到后者的重要性。
另外，多樣的數據來源也許不是問題，但如果它們無法匯集到同一個平台，則可能出現問題。我們的一個比較失敗的地方是把收集到的數據分散在Splunk和Azure兩個平台上，這帶來了一些問題，比如不能直接把2個平台的數據結合分析，比如不同的界面和查詢語言導致了額外的學習成本和溝通成本。
參考資料：SRE