大家好！
本公司從事軟體開發及後續技術支援。 技術支援不僅需要修復錯誤，還需要監控應用程式的效能。
例如，如果其中一項服務崩潰了，那麼您需要自動記錄這個問題並開始解決它，而不是等待不滿意的用戶聯絡技術支援。
我們有一家小公司，我們沒有資源來研究和維護任何複雜的監控應用程式解決方案，我們需要找到一個簡單而有效的解決方案。
監控策略
檢查應用程式的功能並不容易；這項任務並不簡單，甚至可以說是創造性的。 驗證複雜的多鏈路系統尤其困難。
你怎麼能吃掉大象呢？ 僅部分！ 我們使用這種方法來監控應用程式。
我們監控策略的本質：
將您的應用程式分解為組件。
為每個組件建立控制檢查。
如果一個組件的所有控制檢查都沒有錯誤地執行，則該組件被認為是可運行的。 如果應用程式的所有元件都正常運行，則該應用程式被認為是健康的。
因此，任何系統都可以表示為組件樹。 複雜的組件被分解為更簡單的組件。 簡單的組件有檢查。
基準測試並不是為了執行功能測試，它們不是單元測試。 控制檢查應該檢查組件在當前時刻的感受，是否擁有其運作所需的所有資源，以及是否存在任何問題。
沒有奇蹟；大多數檢查都需要獨立開發。 但不要害怕，因為在大多數情況下，一項檢查需要 5-10 行程式碼，但您可以實現任何邏輯，並且您會清楚地了解檢查是如何工作的。
監視系統
假設我們將應用程式拆分為多個元件，為每個元件提出並實現了檢查，但是如何處理這些檢查的結果呢？ 我們如何知道某些檢查是否失敗？
我們需要一個監控系統。 她將執行以下任務：
- 接收測試結果並使用它們來確定組件的狀態。
從視覺上看，這看起來像是突出顯示組件樹。 功能組件變為綠色，有問題的組件變為紅色。 - 立即執行一般檢查。
監控系統可以自行執行一些檢查。 為什麼要重新發明輪子，讓我們使用它們。 例如，您可以檢查網站頁面是否正在開啟或伺服器是否正在執行 ping 操作。 - 向有興趣的各方發送問題通知。
- 監控數據視覺化，提供報告、圖表和統計數據。
ASMO系統簡介
最好用例子來解釋。 讓我們看看 ASMO 系統的效能監控是如何組織的。
ASMO 是一個自動化氣象支援系統。 該系統可協助道路服務專家了解何時何地需要使用除冰材料處理道路。 該系統從道路控制點收集數據。 道路控制點是道路上安裝設備的地方：氣象站、攝影機等。 為了預測危險情況，系統從外部來源接收天氣預報。
所以，系統的組成是非常典型的：網站、代理商、設備。 我們開始監控吧。
將系統分解為組件
ASMO 系統中可以區分出以下組件：
1. 個人帳戶
這是一個網頁應用程式。 至少，您需要檢查該應用程式是否可以在 Internet 上使用。
2. 數據庫
資料庫儲存對報告很重要的數據，您必須確保成功建立資料庫備份。
3. 伺服器
我們所說的伺服器是指運行應用程式的硬體。 需要檢查HDD、RAM、CPU的狀態。
4. 代理
這是一項按計劃執行許多不同任務的 Windows 服務。 至少，您需要檢查該服務是否正在運行。
5. 代理任務
僅僅知道代理正在工作是不夠的。 代理可以工作，但不執行其指派的任務。 讓我們將代理元件拆分為任務，並檢查每個代理任務是否成功運行。
6. 道路管制點（所有 MPC 的貨櫃）
道路控制點有很多，因此讓我們將所有 MPC 合併到一個元件中。 這樣可以更方便的讀取監控資料。 當查看「ASMO系統」組件的狀態時，會立即清楚問題出在哪裡：在應用程式、硬體或在最大控制系統中。
7. 道路管制點（最多限XNUMX個）
如果該 MPC 上的所有裝置均可用，我們將認為該組件可用。
8. 設備
這是在最大濃度限制下安裝的攝影機或氣象站。 有必要檢查設備是否正常運作。
在監控系統中，組件樹將如下所示：
Web應用程式監控
因此，我們已經將系統劃分為多個組件，現在我們需要對每個組件進行檢查。
為了監控 Web 應用程序，我們使用以下檢查：
1. 檢查主頁的開啟情況
此檢查由監控系統執行。 為了執行它，我們指示頁面位址、預期回應片段和最大請求執行時間。
2. 檢查網域付款期限
一個非常重要的檢查。 當域名仍未付費時，用戶無法開啟網站。 解決問題可能需要幾天的時間，因為...... DNS 更改不會立即套用。
3. 檢查SSL憑證
現在幾乎所有的網站都採用https協議進行存取。 為了使協定正常運作，您需要有效的 SSL 憑證。
以下是監控系統中的「個人帳戶」組件：
上述所有檢查適用於大多數應用程序，並且不需要編碼。 這非常酷，因為您可以在 5 分鐘內開始監控任何 Web 應用程式。 以下是可以對 Web 應用程式執行的其他檢查，但它們的實作更加複雜且特定於應用程序，因此我們不會在本文中介紹它們。
您還可以檢查什麼？
若要更全面地監控您的 Web 應用程序，您可以執行以下檢查：
- 每個時期的 JavaScript 錯誤數
- 期間Web應用程式端（後端）的錯誤數量
- 不成功的 Web 應用程式回應數（回應代碼 404、500 等）
- 平均查詢執行時間
監控Windows服務（代理程式）
在ASMO系統中，代理扮演著任務排程器的角色，它在後台執行預定的任務。
如果所有代理任務成功完成，則代理工作正常。 事實證明，為了監控代理，您需要監控其任務。 因此，我們將“Agent”元件劃分為任務。 對於每個任務，我們將在監控系統中建立一個單獨的元件，其中「代理」元件將是「父元件」。
我們將 Agent 元件拆分為子元件（任務）：
因此，我們將一個複雜的組件分解為幾個簡單的組件。 現在我們需要對每個簡單組件進行檢查。 請注意，父組件「Agent」不會有任何檢查，因為監控系統會根據其子組件的狀態獨立計算其狀態。 換句話說，如果所有任務都成功完成，則代理運行成功。
ASMO系統中有一百多個任務，真的有必要為每個任務進行唯一的檢查嗎？ 當然，如果我們為每個代理任務提出並實施我們自己的特殊檢查，控制會更好，但在大多數情況下使用通用檢查就足夠了。
ASMO 系統僅使用任務的通用檢查，足以監控系統的效能。
檢查進度
最簡單、最有效的檢查是執行檢查。 檢查驗證任務是否已完成且沒有錯誤。 所有任務都有此檢查。
驗證演算法
每次任務執行後，如果任務執行成功，則需要將 SUCCESS 檢查結果傳送至監控系統；如果執行完成但有錯誤，則需要將 ERROR 傳送到監控系統。
此檢查可以發現以下問題：
- 任務運行但失敗並出現錯誤。
- 任務已停止運行，例如已凍結。
讓我們更詳細地看看這些問題是如何解決的。
問題 1 – 任務運行但失敗並出現錯誤
以下是任務在 14:00 到 16:00 之間運行但失敗的情況。
如圖所示，當任務失敗時，立即向監控系統發送訊號，監控系統中對應檢查的狀態變成警報。
請注意，在監控系統中，組件的狀態取決於驗證狀態。 此檢查的警報狀態將使所有上級組件變為警報，請參閱下圖。
問題 2 - 任務停止執行（凍結）
監控系統如何得知任務卡住了？
檢查結果有有效期限，例如1小時。 如果一個小時過去，沒有新的偵測結果，監控系統會將偵測狀態設定為警報。
上圖中，下午 14:00 燈已關閉。 15:00，監控系統會偵測到測試結果（從14:00開始）已腐爛，因為關聯時間已過（一小時），但沒有新結果，將檢查切換到警報狀態。
16：00燈再次亮起，程式完成任務並將執行結果傳送至監控系統，測試狀態再次變為成功。
我應該使用什麼檢查相關時間？
關聯時間必須大於任務執行週期。 我建議將相關時間設定為比任務執行週期長2-3倍。 這是必要的，以避免在任務花費比平常更長的時間或有人重新載入程式時收到錯誤通知。
檢查進度
ASMO 系統有一個「負載預測」任務，它會嘗試每小時從外部來源下載新的預測。 外部系統中出現新預報的確切時間尚不清楚，但已知這種情況每天會發生 2 次。 事實證明，如果幾個小時內沒有新的天氣預報，那麼這是正常的，但如果超過一天沒有新的天氣預報，則表示某個地方出了問題。 例如，外部預測系統中的資料格式可能會發生變化，這就是 ASMO 不會看到新的預測版本的原因。
驗證演算法
當任務成功取得進展（下載新的天氣預報）時，該任務會將 SUCCESS 檢查的結果傳送至監控系統。 如果沒有進展或發生錯誤，則不會向監控系統發送任何內容。
檢查必須有一個相關間隔，以便在這段時間內保證收到新的進展。
請注意，我們會延遲得知問題，因為監控系統會等到最後一次掃描結果的有效期限到期。 因此，支票的有效期限不需要定得太長。
資料庫監控
為了控制 ASMO 系統中的資料庫，我們執行以下檢查：
- 驗證備份創建
- 檢查可用磁碟空間
驗證備份創建
在大多數應用程式中，擁有最新的資料庫備份非常重要，這樣如果伺服器發生故障，您可以將程式部署到新伺服器。
ASMO 每週會建立一次備份副本並將其傳送到儲存體。 當此過程成功完成時，成功檢查的結果將傳送到監控系統。 驗證結果有效期限為9天。 那些。 為了控制備份的創建，使用了我們上面討論的「進度檢查」機制。
檢查可用磁碟空間
如果磁碟上沒有足夠的可用空間，資料庫將無法正常運行，因此控制可用空間量非常重要。
使用指標來檢查數值參數很方便。
指標 是一個數字變量，其值傳輸到監控系統。 監控系統檢查閾值並計算指標狀態。
下圖是監控系統中「資料庫」元件的樣子：
伺服器監控
為了監控伺服器，我們使用以下檢查和指標：
1.可用磁碟空間
如果磁碟空間耗盡，應用程式將無法運作。 我們使用兩個閾值：第一個等級是警告，第二個等級是警報。
2. 每小時平均 RAM 值百分比
我們使用每小時平均值，因為... 我們對稀有種族不感興趣。
3.每小時平均CPU百分比
我們使用每小時平均值，因為... 我們對稀有種族不感興趣。
4.Ping 檢查
檢查伺服器是否在線。 監控系統可以執行此檢查；無需編寫程式碼。
下圖是監控系統中「伺服器」元件的樣子：
設備監控
我會告訴你數據是如何獲得的。 對於每個道路控制點 (MPC)，任務規劃器中都有一個任務，例如「調查 MPC M2 km 200」。 此任務每 30 分鐘從所有 MPC 裝置接收一次資料。
溝通管道問題
大部分設備位於城外，採用GSM網路進行資料傳輸，工作不穩定（有網路或無網路）。
由於網路故障頻繁，一開始查看監控中的MPC調查是這樣的：
很明顯，這不是一個有效的選擇，因為存在許多關於問題的錯誤通知。 然後決定對每個設備使用“進度檢查”，即當設備被輪詢且沒有錯誤時，僅向監控系統發送成功訊號。 相關時間設定為5小時。
現在，只有當設備輪詢時間超過 5 小時時，監控才會發送有關問題的通知。 這些很有可能不是誤報，而是真正的問題。
下圖是監控系統中設備的樣子：
重要的信息!
當 GSM 網路停止運作時，所有 MDC 裝置都不會被輪詢。 為了減少來自監控系統的電子郵件數量，我們的工程師使用「MPC」類型而不是「設備」類型訂閱有關組件問題的通知。 這允許您為每個 MPC 接收一個通知，而不是為每個裝置接收單獨的通知。
最終的ASMO監控方案
讓我們把所有的東西放在一起，看看我們有什麼樣的監控方案。
結論
我們來總結一下。
監控 ASMO 的表現為我們帶來了什麼？
1. 缺陷消除時間減少
我們之前聽說過用戶的缺陷，但並非所有用戶都報告缺陷。 碰巧我們在某個系統組件故障一週後才獲悉該故障。 現在監控系統一旦發現問題就會通知我們。
2.系統穩定性提高
由於較早開始消除缺陷，整個系統開始運作得更穩定。
3. 減少致電技術支援的次數
現在，許多問題在用戶意識到之前就已解決。 使用者開始減少聯繫技術支援的頻率。 所有這些都對我們的聲譽產生了良好的影響。
4. 提高客戶和用戶忠誠度
客戶注意到系統穩定性發生了積極的變化。 使用者在使用系統時遇到的問題較少。
5.降低技術支援成本
我們已停止執行任何手動檢查。 現在所有檢查都是自動化的。 以前，我們從用戶那裡了解問題；常常很難理解用戶在談論什麼問題。 現在，大多數問題都是由監控系統報告的；通知中包含技術數據，總是可以清楚地表明出了什麼問題以及出在哪裡。
重要的信息!
您不能將監控系統安裝在執行應用程式的相同伺服器上。 如果伺服器發生故障，應用程式將停止工作，並且不會有人通知這種情況。
監控系統必須運作在另一個資料中心的單獨伺服器上。
如果您不想在新的資料中心使用專用伺服器，則可以使用雲端監控系統。 我們公司使用Zidium雲端監控系統，但您可以使用任何其他監控系統。 雲端監控系統的成本比租用新伺服器低。
建議：
- 以組件樹的形式盡可能詳細地分解應用程式和系統，這樣可以很方便地了解哪裡出了問題、出什麼問題，控制也更加完整。
- 若要檢查組件的功能，請使用測試。 使用許多簡單的檢查比使用一項複雜的檢查要好。
- 在監控系統一側配置指標閾值，而不是將其寫入程式碼中。 這將使您不必重新編譯、重新配置或重新啟動應用程式。
- 對於自訂檢查，請使用相關時間裕度以避免收到錯誤通知，因為某些檢查需要比平常更長的時間才能完成。
- 盡量只有在確定有問題的情況下才讓監控系統中的零件變成紅色。 如果它們無緣無故變成紅色，那麼你就不再注意監控系統的通知，也就失去了它的意義。
如果您還沒有使用監控系統，那就開始吧！ 這並不像看起來那麼困難。 欣賞自己種植的綠色原料樹，會很開心。
祝你好運。
來源： www.habr.com