軟體系統的工業開發需要高度關注最終產品的容錯能力，以及對故障和故障發生時的快速反應。監控當然有助於更有效率、更快速地回應故障和失敗，但這還不夠。首先，追蹤大量伺服器非常困難——需要大量人員。其次，您需要充分了解應用程式的工作原理才能預測其狀態。因此，我們需要很多對我們正在開發的系統及其性能和功能有深入了解的人。我們假設，即使您找到足夠的人願意這樣做，仍然需要花費大量時間來培訓他們。
怎麼辦？這就是人工智慧為我們提供幫助的地方。文章將談到 （預測性維護）。這種方法正在積極流行。人們撰寫了大量文章，包括關於哈布雷的文章。大公司充分利用這種方法來維持其伺服器的效能。在研究了大量文章後，我們決定嘗試這種方法。結果是什麼呢？
介紹
開發出來的軟體系統遲早會投入運作。對於使用者來說，系統無故障運作非常重要。如果確實發生緊急情況，應盡快解決。
為了簡化軟體系統的技術支持，特別是在有許多伺服器的情況下，通常使用監控程式來從正在運行的軟體系統獲取指標，從而可以診斷其狀況並幫助確定到底是什麼導致了故障。這個過程稱為軟體系統監控。
圖1. Grafana監控介面
指標是軟體系統、其執行環境或系統運行時的實體電腦的各種指標，並帶有收到指標時的時間戳記。在靜態分析中，這些指標稱為時間序列。為了監控軟體系統的狀態，指標以圖表的形式顯示：時間在X軸上，數值沿著Y軸（圖1）。可以從正在運行的軟體系統（從每個節點）獲得數千個指標。它們形成了度量空間（多維時間序列）。
由於複雜的軟體系統需要收集大量的指標，手動監控成為一項艱鉅的任務。為了減少管理員分析的資料量，監控工具包含自動識別可能問題的工具。例如，您可以將觸發器配置為在可用磁碟空間低於指定閾值時觸發。您也可以自動診斷伺服器關閉或服務速度嚴重下降。在實踐中，監控工具可以很好地檢測已經發生的故障或識別未來故障的簡單症狀，但總的來說，預測可能的故障對它們來說仍然是一個難題。透過手動分析指標進行預測需要合格專家的參與。這是生產力低。大多數潛在的失敗可能會被忽略。
最近，所謂的軟體系統的預測性維護在大型IT軟體開發公司中越來越流行。這種方法的本質是利用人工智慧在早期階段、在故障之前發現導致系統退化的問題。這種方法並不完全排除對系統的手動監控。它對整個監控過程有輔助作用。
實施預測性維護的主要工具是搜尋時間序列異常的任務，因為 當異常發生時 在數據中，一段時間後很可能 會有失敗或失敗。異常是軟體系統效能中的某種偏差，例如識別出一種類型的請求的執行速度的下降或在客戶端會話的恆定水平下所服務的請求的平均數量的減少。
搜尋軟體系統異常的任務有其特殊性。理論上，對於每個軟體系統，都需要開發或完善現有方法，因為異常搜尋非常依賴執行搜尋的數據，並且軟體系統的數據根據實現系統的工具而變化很大，具體到它運行在哪台計算機上。
預測軟體系統故障時搜尋異常的方法
首先值得一提的是，預測失敗的想法是受到文章啟發的 。為了測試自動搜尋異常方法的有效性，選擇了 Web-Consolidation 軟體系統，這是 NPO Krista 公司的專案之一。此前，是根據收到的指標進行手動監控。由於系統相當複雜，因此需要大量的指標：JVM指標（垃圾收集器負載）、執行程式碼的作業系統指標（虛擬記憶體、％作業系統CPU負載）、網路指標（網路負載） ）、伺服器本身（CPU 負載、記憶體）、所有關鍵子系統的Wildfly 指標和應用程式本身的指標。
所有指標均來自使用石墨的系統。最初，whisper 資料庫被用作 grafana 的標準解決方案，但隨著客戶群的成長，Graphite 已經無法應對，耗盡了 DC 磁碟子系統的容量。此後，決定尋找更有效的解決方案。做出了有利的選擇 ，這使得磁碟子系統的負載減少了一個數量級，佔用的磁碟空間減少了五到六倍。以下是使用石墨+clickhouse收集指標的機制圖（圖2）。
圖 2. 收集指標的方案
該圖取自內部文件。它顯示了grafana（我們使用的監控UI）和Graphite之間的通訊。從應用程式中刪除指標是由單獨的軟體完成的 - 。他把它們放入石墨中。
Web Consolidation 系統的許多功能在預測故障時會產生問題：
- 趨勢經常發生變化。該軟體系統有多種版本可供選擇。它們中的每一個都會對系統的軟體部分帶來變化。因此，透過這種方式，開發人員可以直接影響給定係統的指標，並可以引起趨勢變化；
- 實施功能以及客戶使用該系統的目的通常會導致異常情況而沒有先前的降級；
- 異常相對於整個資料集的百分比很小（< 5%）；
- 從系統接收指標可能存在差距。在某些短時間內，監控系統無法取得指標。例如，如果伺服器過載。這對於訓練神經網路至關重要。需綜合填補空白；
- 異常案例通常僅與特定日期/月份/時間（季節性）相關。此系統對使用者的使用有明確的規定。因此，這些指標僅與特定時間相關。該系統不能一直使用，而只能在幾個月內使用：根據年份選擇性地使用。出現這樣的情況：在一種情況下相同的指標行為可能會導致軟體系統故障，但在另一種情況下卻不會。
首先分析了軟體系統監控數據異常檢測方法。在有關該主題的文章中，當異常百分比相對於資料集的其餘部分較小時，最常建議使用神經網路。
使用神經網路資料搜尋異常的基本邏輯如圖 3 所示：
圖 3. 使用神經網路搜尋異常
根據目前指標流視窗的預測或恢復結果，計算與從正在運行的軟體系統接收到的偏差。如果從軟體系統和神經網路獲得的指標之間存在較大差異，我們可以斷定目前資料段是異常的。使用神經網路會出現以下一連串問題：
- 為了在流模式下正常工作，訓練神經網路模型的資料必須僅包含「正常」資料；
- 必須有一個最新的模型才能正確檢測。指標中趨勢和季節性的變化可能會導致模型出現大量誤報。要更新它，需要明確模型過時的時間。如果您稍後或較早更新模型，那麼很可能會出現大量誤報。
我們也不能忘記尋找和防止誤報的頻繁發生。據推測，它們最常發生在緊急情況下。然而，它們也可能是由於訓練不足而導致神經網路錯誤的結果。有必要最大限度地減少模型的誤報數量。否則，錯誤的預測將浪費管理員大量的時間來檢查系統。管理員遲早會停止回應「偏執」的監控系統。
循環神經網絡
要檢測時間序列中的異常，您可以使用 具有 LSTM 記憶。唯一的問題是它只能用於預測時間序列。在我們的例子中，並非所有指標都是可預測的。圖 4 顯示了將 RNN LSTM 應用於時間序列的嘗試。
圖 4. 具有 LSTM 儲存單元的循環神經網路範例
從圖4可以看出，RNN LSTM能夠應付這個時間段內的異常搜尋。如果結果具有較高的預測誤差（平均誤差），則指標實際上已經發生了異常。使用單一 RNN LSTM 顯然是不夠的，因為它適用於少量指標。可以作為搜尋異常的輔助方法。
用於故障預測的自動編碼器
– 本質上是一個人工神經網路。輸入層是編碼器，輸出層是解碼器。所有此類神經網路的缺點是它們不能很好地定位異常。選擇了同步自動編碼器架構。
圖 5. 自動編碼器操作範例
自動編碼器接受正常資料的訓練，然後在輸入模型的資料中發現異常。這正是您完成此任務所需的。剩下的就是選擇適合此任務的自動編碼器。自動編碼器的架構最簡單的形式是前向、非返回神經網絡，它與 （多層感知器，MLP），具有輸入層、輸出層以及連接它們的一個或多個隱藏層。
然而，自動編碼器和MLP 之間的差異在於，在自動編碼器中，輸出層具有與輸入層相同數量的節點，並且自動編碼器不是被訓練來預測由輸入X 給出的目標值Y，而是被訓練來重建自己的X。因此，自動編碼器是無監督學習模型。
自動編碼器的任務是找到與輸入向量 X 中的異常元素相對應的時間索引 r0 ... rn。這種效果是透過搜尋平方誤差來實現的。
圖 6. 同步自動編碼器
對於選擇的自動編碼器 。其優點：與其他架構相比，能夠使用流處理模式以及相對較少數量的神經網路參數。
最大限度減少誤報的機制
由於會出現各種異常情況，以及可能存在神經網路訓練不足的情況，對於正在開發的異常檢測模型，決定有必要開發一種最小化誤報的機制。此機制基於管理員分類的範本庫。
（DTW演算法，來自英文dynamic time warping）可以讓你找到時間序列之間的最佳對應關係。首先用於語音辨識：用於確定兩個語音訊號如何表示相同的原始口語短語。隨後，它在其他領域也得到了應用。
最大限度減少誤報的主要原則是在操作員的幫助下收集標準資料庫，操作員將使用神經網路偵測到的可疑案例進行分類。接下來，將分類標準與系統偵測到的案例進行比較，並得出該案例是否錯誤或導致故障的結論。 DTW演算法精確地用於比較兩個時間序列。主要的最小化工具仍然是分類。預計在收集大量參考案例後，由於大多數案例的相似性以及類似案例的出現，系統將開始向操作員提出較少的要求。
因此，基於上述神經網路方法，建立了一個實驗程序來預測「Web-Consolidation」系統的故障。該計劃的目標是，利用現有的監控數據檔案和有關先前故障的信息，評估這種方法對我們軟體系統的能力。程式的方案如下圖 7 所示。
圖7 基於度量空間分析的故障預測方案
在圖中，可以區分兩個主要區塊：在監控資料流（指標）中搜尋異常時間段以及最大限度地減少誤報的機制。注意：出於實驗目的，數據是透過 JDBC 連接從石墨將其保存到的資料庫中獲取的。
以下是開發後得到的監控系統介面（圖8）。
圖8 實驗監控系統介面
介面根據收到的指標顯示異常的百分比。在我們的例子中，收據是模擬的。我們已經掌握了幾週的所有數據，並正在逐步加載，以檢查是否有導致故障的異常情況。下部狀態列顯示給定時間資料異常的總體百分比，這是使用自動編碼器確定的。此外，也會顯示由 RNN LSTM 計算的預測指標的單獨百分比。
使用 RNN LSTM 神經網路基於 CPU 效能進行異常檢測的範例（圖 9）。
圖 9. RNN LSTM 發現
使用 RNN LSTM 成功計算出一個相當簡單的案例，本質上是一個普通的異常值，但卻導致系統故障。此時間段的異常指標為85%~95%；凡高於80%（閾值由實驗確定）的均視為異常。
系統更新後無法啟動時的異常檢測範例。自動編碼器可以偵測到這種情況（圖 10）。
圖 10. 自動編碼器偵測範例
從圖中可以看出，PermGen 停留在一個層次。自動編碼器發現這很奇怪，因為它以前從未見過類似的情況。這裡異常保持 100%，直到系統恢復到工作狀態。所有指標均顯示異常。如前所述，自動編碼器無法定位異常。在這些情況下，操作員需要執行此功能。
結論
PC「Web-Consolidation」已開發多年。系統處於相當穩定的狀態，記錄的事件數量較少。然而，在故障發生前5-10分鐘就有可能發現導致故障的異常情況。在某些情況下，提前通知故障將有助於節省分配用於執行「維修」工作的預定時間。
根據已進行的實驗，現在得出最終結論還為時過早。到目前為止，結果是相互矛盾的。一方面，很明顯地基於神經網路的演算法能夠發現「有用」的異常。另一方面，仍然存在很大比例的誤報，並且並非合格的神經網路專家檢測到的所有異常都能被檢測到。缺點包括現在神經網路需要老師的訓練才能正常運作。
為了進一步開發故障預測系統並使其達到令人滿意的狀態，可以設想幾種方法。這是對導致失敗的異常情況的更詳細的分析，因為添加了對系統狀態有很大影響的重要指標列表，並丟棄了不影響系統的不必要的指標。此外，如果我們朝這個方向前進，我們可以嘗試專門針對導致失敗的異常情況的演算法。還有另一種方法。這是神經網路架構的改進，從而提高檢測精度並減少訓練時間。
我對幫助我撰寫和保持本文相關性的同事表示感謝： 和謝爾蓋·菲諾格諾夫。
來源： www.habr.com