可為OpenStack監控提供幫助的7種AI方法

OpenStack是最好的軟體之一，它幫助數據中心所有者立即部署虛擬機，並通過儀錶盤或OpenStack API（應用程序編程介面）監視日誌。

OpenStack的優點在於，使數字化企業能夠輕鬆地創建、評估和控制其計算環境。

然而，在處理大量的日誌數據時，在OpenStack設置中產生的大量日誌數據仍然是一個嚴重的挑戰。

由於擁有豐富的生態系統、更低的運營成本和更高的靈活性，世界各地成千上萬的企業都在使用OpenStack。然而，在部署這種技術時，用戶遇到了一些挑戰，尤其是在識別和監視資源的時候。

下面，我們將重點列舉一些和OpenStack監控有關的問題和補救措施，使OpenStack成為雲計算和虛擬機集成的最合適的解決方案。

動態環境監控問題與解決方案

大多數OpenStack服務都是完全靜態的。而雲計算環境非常靈活，因為它可以根據部署的服務和應用程序的數量增長和收縮。因此，在動態環境中生成靜態日誌導致IT經理對雲環境中正在發生的事情無法完全了解。

所以，為了刷新統計數據，就需要人工干預。在部署容器和虛擬機的環境中，人工干預需要時間。在這種情況下，必須有一個擁有能夠持續監控新日誌數據能力的團隊。當然，這可能相當麻煩，更多時候數據中心都缺乏足夠的人力。

為了解決動態虛擬機環境監控的問題，以AI為動力的監控解決方案是最好的方法。人工智慧專註於實時監控所有的OpenStack組件。此外，任何可能對整個環境產生重要影響的服務都會自動獲得最高優先順序。最後，IT專家們對每個微服務中發生的事情都會有一個簡單的概述，包括專有軟體應用程序的日誌，以及存儲、網路、計算和數據計劃組件。由於所有微服務的簡單性和連接性，這些數據日誌對解決任何問題都有直接而深刻的見解。

遺留混合問題與解決方案

毫無疑問，大多數組織仍然在雲服務之上運行他們的舊計算基礎設施。

事實上，超過75%使用OpenStack部署的組織還沒有放棄其他組織的遺留應用程序或平台。其中包括谷歌和Amazon雲服務。

對於遺留混合，OpenStack使用的開源監控工具可能沒有更好的定位來完全生成足夠的日誌監視混合環境。

這迫使公司使用多種監控工具，這就給IT管理人員帶來了問題，同時還會增加組織的開銷。

數據中心渴望混合和良好呈現的數據日誌，這些日誌來自於完全不同的虛擬機部署節點。人工智慧監控工具可以評估和展示來自不同部署的數據，特別是如果它們有一個API。最後，通過人工智慧形成的洞察力使得在網路上追蹤問題變得簡單。人工智慧可以幫助IT管理者立即查看不同指標之間的關係，並對其進行評估，以了解是哪些組件出現什麼錯誤。

OpenStack的分散式和反耦合特性

OpenStack微服務的環境妥協被設計成許多不同的任務。然而，每個任務都會使用REST（具象狀態傳輸）API公開它們的最終結果。

OpenStack的微組件相互通信，以實現使用消息傳遞層交付虛擬機的共同目標。這種方法的問題是，因孤立導致的失敗會擴展到整個基礎設施。

當單個微服務出現錯誤，可能會導致整個機器的部分或完全停止，從而使整個服務處於離線狀態。您能想像一個完整的web應用程序由於一個不容易識別的微組件而失敗嗎？

非單一的服務使得IT經理很難評估單個微組件發生故障時對整個計算環境的實際影響。要解決這個不確定性，我們需要了解雲基礎設施是如何工作的。你需要大量投資，並學習所有功能。其次，您需要確定不同組件之間的關係。最後，您必須深入理解所有可能直接影響特定雲服務的服務。考慮到這一點，您不僅會理解為什麼某個組件由於非功能性的微組件而失敗，而且您還將對可能受到流程影響的其他服務獲得有意義的見解。因此，您將最小化您的雲計算的風險。

不同的結構和文件夾

OpenStack雲管理設置依賴於傳統的監視工具，這些工具有很多問題，其中一個是已知的「黑盒」問題，即最終用戶只看到輸入和輸出，而不是流程。

在現實世界中，OpenStack的部署是在不同的地理位置和結構中進行的，這意味著許多組件，如託管、雲服務和網路支持程序都參與了這個過程。另一方面，安裝了不同的軟體應用程序，就要對每個應用程序進行跟蹤，以確保雲服務的流暢運行。由於結構和應用程序的多樣性，對於IT管理人員來說，非常具有挑戰性。

每個組織都需要投資人工智慧（AI），而沒有人工智慧的好處是它將複雜的日誌簡化到一個儀錶盤。這使IT經理能夠獲得集中的數據，以便在整個計算環境中獲得完全可見性。簡而言之，OpenStack技術的最終用戶將獲得由計算、網路和技術的存儲組件所生成的、各個方面的日誌。數據將被表示為一個完整的畫像，在真實的時間和自動更新的環境可以很容易監測。這將有助於減少可能的數據丟失，因為所有服務都將在不可能出現偏差的情況下運行。人工智慧依賴於演算法的不同組合和排列，可以幫助識別OpenStack監控問題。

監視默認指標

OpenStack的檢測日誌過度依賴於問題檢測的默認指標。這包括內存泄漏、文件問題、死鎖、性能結果等。儘管這些日誌在識別常見問題時非常有用，但它們無法檢測需要專門監控工具的複雜問題。通過使用通用指標來檢測和預測故障並不總是理想的，有時會導致錯誤的警報。一個例子是，當磁碟空間達到某個特定的限制時（例如80%），就會發出警報。但磁碟空間不足80%不一定是出現嚴重性能退化的證據。

你需要使用一個完整的故障識別方法，並運行不同的測試以確保某些服務是正常的。不要僅依賴於開源的指標，跳出框框，進行所有可以幫助你識別組件失敗的測試。

基於TCP的服務瓶頸和連接池的耗竭

OpenStack是一個分散式服務，它的所有核心服務都通過REST API公開。另一方面，OpenStack的消息傳遞服務是基於TCP的，因此，它很容易受到包括網路、連接問題在內的主要問題的影響。而且，大多數OpenStack服務都連接到SQL（結構化查詢語言）資料庫。

OpenStack需要有正確的連接狀態來生成正確的監控解決方案。另外，使用正確的命令行工具檢查端點服務的狀態，以獲得在後台發生的真實狀態。換句話說，您需要開發一種習慣，使用定製的指標來擴展監視解決方案，可以通過OpenStack API或其他開放源碼工具來設計。大多數IT經理只有在過度依賴默認的度量標準和日誌時才會出錯。

最後一個：關於人

作為IT經理，如果你想要運行無瓶頸的雲或虛擬機基礎設施，就需要遵循正確的流程。OpenStack的失敗隨時可能發生，因為IT管理器會以這樣或那樣的方式失敗。當然，由於人為因素而導致的程序設計不當，也會導致整個系統的巨大失敗。

另外，如果一個微組件存在問題，請研究該場景，以了解它如何在影響整個系統。記住，忽視一個服務可能會導致收入的損失，會付出高昂的代價。此外，在監視儀錶板時要及時響應紅色警報。例如，如果系統顯示95%的磁碟被利用，那麼立即採取行動增加更多空間。

結論

OpenStack是一項偉大的技術，它可以幫助您的業務增長，並使應用程序在雲中安全運行。這些技術幫助我們在穩定的環境中部署虛擬機。然而，我們需要記住，一台機器本身並沒有「思考」，需要盡最大努力，使用標準、日誌和人工智慧工具來採取適當的行動。

編譯：小寬

作者：Aviv Lichtigstein

來源：https://www.loomsystems.com/blog/7-ways-ai-can-come-to-the-rescue-for-your-openstack-monitoring

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！