云應用程序通常在可靠的正常運行時間方面贏得了良好的聲譽。但是，通過持續測試可用性和響應時間來監控您的云托管系統和應用程序仍然很重要。這四個監控技巧可以幫助您依靠云。
云服務提供商通常會提供三個 9 或更好的正常運行時間，但確實會發生中斷。即使主要參與者在 Web 架構中內置了所有冗余和其他保護措施，他們的系統仍然會因各種故障而癱瘓。這里有一些例子：
- 過期的 SSL 證書導致大多數 Microsoft Azure 用戶的加密存儲流量在全球范圍內中斷 12 小時（對于某些用戶，則為 24 小時中斷）。
- 一個內部 DNS 錯誤導致 Apple 每小時損失 200 萬美元，而其應用商店、iTunes 和其他服務出現故障。
- 數據中心虛擬網絡故障導致 Google Compute Engine 中斷了 2 小時 40 分鐘。
無聲的減速會削弱生產力和銷售
中斷不應該是您對云服務的唯一關注。減速可能與用戶中斷的行為相同 - 更糟糕的是，在用戶抱怨之前，它們很容易被忽視。或者他們可能不會抱怨，并且經常性的生產力損失或銷售來源將不會被發現。
例如，如果您的銷售人員使用基于云的 CRM 系統登錄需要 15 秒，那么您需要知道。本質上，你付錢讓人們等待。如果您的購物車在 8 秒內沒有提供完全填充的響應，那么對于大多數潛在買家來說，該系統就像停機一樣好。
不要讓這些減速沒有被發現。監控云應用程序可能很棘手，但您的云應用程序的持續性能和歷史記錄應該在您的網絡管理儀表板上與其他關鍵系統具有相同級別的可見性。應用程序性能管理工具APM允許開發團隊主動監控和改進應用程序性能。APM 工具（例如Stackify Retrace）提供代碼級洞察以及集成日志記錄，以識別 QA 中的更多問題并持續觀察生產環境中的應用程序。
監控云主機應用
除了驗證您的云應用程序的當前可用性之外，您的監控工具還應該自動跟蹤這些元素：
- 事務步驟：如果需要按順序執行多個步驟（初始身份驗證、數據庫調用、中間件步驟等），請確認這些步驟中的任何一個步驟是否處于非活動狀態或緩慢。如果是這樣，您應該能夠確定故障元素對整體可用性的影響。
- 延遲：如果網絡延遲嚴重影響基于 Web 的應用程序，您需要跟蹤該延遲并盡可能跟進以解決問題。延遲尤其會導致移動用戶的服務延遲，因此如果該平臺對您的業務至關重要，您需要能夠一眼看出延遲是否會造成或加劇服務問題。
- 響應時間警報：設置頁面加載時間的警報級別，對于許多應用程序，響應速度低于 1.5 – 2 秒意味著服務已嚴重受損。
- 服務器/網絡計時：如果您看到的有關云環境性能的數據不夠精細，您可能不知道服務問題是否與網絡問題、服務器配置甚至頁面或腳本設計有關。
擁有讓云服務提供商承擔責任所需的數據
了解基于云的系統的實時狀態可以讓您有時間為即將發生的中斷的影響做好準備。您可能能夠采取糾正措施，或者至少與受影響的用戶進行溝通，以便他們了解問題并采取相應措施。
能夠一目了然地查看歷史信息并生成報告以記錄它，這一點也很重要。有了這些數據，您就可以讓您的服務提供商承擔責任。如果他們沒有達到他們承諾的服務水平要求，您需要向他們展示正在發生的事情。
如果您已經完成了將裸機服務遷移到云的艱苦工作，您可能已經看到正常運行時間增加了，這很好。但云在 IT 系統基礎設施中的作用顯著增加，可能會產生更多的復雜性和更多的服務問題。通過徹底監控云托管的應用程序，立即為處理新出現的云服務問題做好準備。
