如果你以前曾在云平臺上工作過，你一定熟悉這些系統的分布式和解耦性質。解耦的分布式系統依賴于微服務來執行特定的任務，每個微服務都會暴露自己的REST(表示狀態轉移)API。這些微服務通常以諸如RabbitMQ或QPID等消息中間件的形式通過輕量級消息層相互通信。

這正是OpenStack的工作原理。每個主要的OpenStack組件(Keystone、Glance、Cinder、Neutron、Nova等)公開REST端點，組件和子組件通過消息中間件(如RabbitMQ)進行通信。這種方法的優點首先是允許將故障分配給特定組件，其次是云基礎設施運營商可以以水平方式擴展所有服務，并智能分配負載。

然而，這種分布式解耦系統雖然非常有利，但也帶來了固有的挑戰——如何正確監控OpenStack服務，更具體地說，如何識別可能的單點故障。

下面的內容針對OpenStack服務監控的具體情況所面臨的真實挑戰，以及每個難題可能的解決方案。

挑戰一：系統不是一個整體

OpenStack的非整體性和解耦性通常被強調為其主要優點。這當然是一個重要的優勢。然而，這顯然會使任何監控整體服務狀態的嘗試變得復雜。在每個組件執行一個特定任務的分布式系統中，每個組件進一步分布到多個子組件中，因此，不難理解當特定一部分軟件發生故障時，確定對服務的影響是多么困難。

克服這個困難的第一步是了解云。你需要確定所有主要組件之間的關系，然后確定每個獨立的特定服務之間的關系，它們的故障可能影響整體服務。簡單地說，你需要知道云中所有組件之間的關系。

考慮到這一點，你不僅需要監視每個單獨組件的狀態(正在運行或故障停止)，還要確定其他服務如何受到故障的影響。

例如，如果Keystone死機，沒有人能夠獲取服務目錄或登錄任何服務，但這通常不會影響虛擬機或其他已建立的云服務(對象存儲、塊存儲、負載均衡器等)，除非重新啟動服務且Keystone仍然宕機。然而，如果Apache失效，通過Apache工作的Keystone和其他類似的API服務可能會受到影響。

因此，監控平臺或解決方案不僅必須能夠評估各個服務的狀態，而且還要能夠在服務故障之間進行關聯，以便檢查對整個系統的真正影響，并相應地發送警報或通知。

挑戰二：OpenStack不僅僅是OpenStack

基于OpenStack的云不僅是分布式和解耦式系統，也是一種可在操作系統和其他在云基礎設施中或與之相關的設備中創建資源的編排解決方案。這些資源包括虛擬機(Xen、KVM或其他管理程序軟件組件)、持久卷(NFS存儲服務器、Ceph群集、基于SAN的LVM卷或其他存儲后端)、網絡實體(端口，網橋，網絡，路由器，負載平衡器，防火墻，VPN等)和臨時磁盤(駐留在操作系統目錄中的Qcow2文件)以及許多其他小型系統。

因此，監測解決方案必須考慮到這些基礎組件。雖然這些資源可能不太復雜，并且不太容易出現故障，但是當它們停止運行時，主要OpenStack服務中的日志可能會掩蓋真實的原因。它們僅在受到影響的OpenStack服務中顯示結果，而不顯示設備或失效的操作系統軟件的實際根本原因。

例如，如果libvirt失效，組件Nova將無法部署虛擬實例。 Nova-compute作為服務將被啟動并運行，但在部署階段實例將失敗(實例狀態：錯誤)。為了檢測這一點，你需要在nova-compute日志之外還監控libvirt(服務狀態、指標及日志)。

因此，有必要檢查底層軟件和主要組件之間的關系，以及監控最終的鏈接，并考慮所有最終服務的一致性測試。你需要監控所有內容：存儲、網絡、hypervision層、每個單獨的組件以及之間的關系。

挑戰三：跳出固有思維模式

Cacti、Nagios和Zabbix是OpenSource監控解決方案的好例子。這些解決方案定義了一組非常具體的度量標準，用于識別操作系統上的可能問題，但是它們不提供確定更復雜的故障情況或甚至服務狀態所需的專門的指標。

這是你需要有創造性的地方。你可以實施專門的指標和測試，以定義服務是否正常、降級或完全失敗。

像OpenStack這樣的分布式系統，其中每個核心服務都暴露了一個REST API，并且連接到基于TCP的消息服務，容易受到網絡瓶頸、連接池耗盡和其他相關問題的影響。許多相關服務連接到基于SQL的數據庫，這可能會耗盡其最大連接池，意味著需要在監控解決方案中實施正確的連接狀態監控指標(建立、散布等待、關閉等)，以檢測可能的、影響API的連接相關問題。此外，可以構建cli測試來檢查端點狀態并測量其響應時間，這可以被轉換成實際顯示服務真實狀態的指標。

上述每一個監控解決方案和大多數其他商業或OpenSource解決方案可以通過自行設計專門指標來進行擴展。

命令“time OpenStack catalogue list”可以測量Keystone API響應時間，評估結果，并在結果不符合預期時產生人工故障狀態。此外，你可以使用簡單的操作系統工具，如“netstat”或“ss”，來監控API端點的不同連接狀態，并了解服務中可能出現的問題。OpenStack云依賴關系的關鍵部分(例如消息代理和數據庫服務)也可以這樣做。請注意，消息中間件失敗基本上將“殺死”OpenStack云。

關鍵是不要偷懶!不要只用默認的指標，而是應該用與自己服務相關的指標。

挑戰四：人為因素

人為因素關乎一切。俗話說，埋怨工具的工匠不是一個好工匠。

沒有經過測試的情景響應程序，單一故障不僅本身是一個問題，還將帶來造更多的問題。在你的監控解決方案中，云基礎設施的任何事故及其相關警報中都應該有明確的記錄，以清楚的步驟來解釋如何檢測、遏制和解決問題。

人為因素必須考慮，即使你有一個可以關聯事件和建議適當的解決方案來檢測事故的、聰明的系統(一個有一定程度人工智能的系統)。請務必記住，如果系統不正確或不完整，那么輸出也將不準確或不完整。

總結一下，OpenStack監控不一定很困難，最重要的是要徹底。每個單獨的服務以及與其他服務的互動都需要仔細監控。特殊指標甚至可以自己實現。通過一些TLC，你可以輕松地成功監控你的OpenStack。