這正是OpenStack的工作原理。每個(gè)主要的OpenStack組件（Keystone、Glance、Cinder、Neutron、Nova等）公開(kāi)REST端點(diǎn)，組件和子組件通過(guò)消息中間件（如RabbitMQ）進(jìn)行通信。這種方法的優(yōu)點(diǎn)首先是允許將故障分配給特定組件，其次是云基礎設施運營(yíng)商可以以水平方式擴展所有服務(wù)，并智能分配負載。
然而，這種分布式解耦系統雖然非常有利，但也帶來(lái)了固有的挑戰——如何正確監控OpenStack服務(wù)，更具體地說(shuō)，如何識別可能的單點(diǎn)故障。
下面的內容針對OpenStack服務(wù)監控的具體情況所面臨的真實(shí)挑戰，以及每個(gè)難題可能的解決方案。
挑戰一：系統不是一個(gè)整體
OpenStack的非整體性和解耦性通常被強調為其主要優(yōu)點(diǎn)。這當然是一個(gè)重要的優(yōu)勢。然而，這顯然會(huì )使任何監控整體服務(wù)狀態(tài)的嘗試變得復雜。在每個(gè)組件執行一個(gè)特定任務(wù)的分布式系統中，每個(gè)組件進(jìn)一步分布到多個(gè)子組件中，因此，不難理解當特定一部分軟件發(fā)生故障時(shí)，確定對服務(wù)的影響是多么困難。
克服這個(gè)困難的第一步是了解云。你需要確定所有主要組件之間的關(guān)系，然后確定每個(gè)獨立的特定服務(wù)之間的關(guān)系，它們的故障可能影響整體服務(wù)。簡(jiǎn)單地說(shuō)，你需要知道云中所有組件之間的關(guān)系。
考慮到這一點(diǎn)，你不僅需要監視每個(gè)單獨組件的狀態(tài)（正在運行或故障停止），還要確定其他服務(wù)如何受到故障的影響。
例如，如果Keystone死機，沒(méi)有人能夠獲取服務(wù)目錄或登錄任何服務(wù)，但這通常不會(huì )影響虛擬機或其他已建立的云服務(wù)（對象存儲、塊存儲、負載均衡器等），除非重新啟動(dòng)服務(wù)且Keystone仍然宕機。然而，如果Apache失效，通過(guò)Apache工作的Keystone和其他類(lèi)似的API服務(wù)可能會(huì )受到影響。
因此，監控平臺或解決方案不僅必須能夠評估各個(gè)服務(wù)的狀態(tài)，而且還要能夠在服務(wù)故障之間進(jìn)行關(guān)聯(lián)，以便檢查對整個(gè)系統的真正影響，并相應地發(fā)送警報或通知。
挑戰二：OpenStack不僅僅是OpenStack
基于OpenStack的云不僅是分布式和解耦式系統，也是一種可在操作系統和其他在云基礎設施中或與之相關(guān)的設備中創(chuàng )建資源的編排解決方案。這些資源包括虛擬機（Xen、KVM或其他管理程序軟件組件）、持久卷（NFS存儲服務(wù)器、Ceph群集、基于SAN的LVM卷或其他存儲后端）、網(wǎng)絡(luò )實(shí)體（端口，網(wǎng)橋，網(wǎng)絡(luò )，路由器，負載平衡器，防火墻，VPN等）和臨時(shí)磁盤(pán)（駐留在操作系統目錄中的Qcow2文件）以及許多其他小型系統。
因此，監測解決方案必須考慮到這些基礎組件。雖然這些資源可能不太復雜，并且不太容易出現故障，但是當它們停止運行時(shí)，主要OpenStack服務(wù)中的日志可能會(huì )掩蓋真實(shí)的原因。它們僅在受到影響的OpenStack服務(wù)中顯示結果，而不顯示設備或失效的操作系統軟件的實(shí)際根本原因。
例如，如果libvirt失效，組件Nova將無(wú)法部署虛擬實(shí)例。 Nova-compute作為服務(wù)將被啟動(dòng)并運行，但在部署階段實(shí)例將失敗（實(shí)例狀態(tài)：錯誤）。為了檢測這一點(diǎn)，你需要在nova-compute日志之外還監控libvirt（服務(wù)狀態(tài)、指標及日志）。
因此，有必要檢查底層軟件和主要組件之間的關(guān)系，以及監控最終的鏈接，并考慮所有最終服務(wù)的一致性測試。你需要監控所有內容：存儲、網(wǎng)絡(luò )、hypervision層、每個(gè)單獨的組件以及之間的關(guān)系。
挑戰三：跳出固有思維模式
Cacti、Nagios和Zabbix是OpenSource監控解決方案的好例子。這些解決方案定義了一組非常具體的度量標準，用于識別操作系統上的可能問(wèn)題，但是它們不提供確定更復雜的故障情況或甚至服務(wù)狀態(tài)所需的專(zhuān)門(mén)的指標。
這是你需要有創(chuàng )造性的地方。你可以實(shí)施專(zhuān)門(mén)的指標和測試，以定義服務(wù)是否正常、降級或完全失敗。
像OpenStack這樣的分布式系統，其中每個(gè)核心服務(wù)都暴露了一個(gè)REST API，并且連接到基于TCP的消息服務(wù)，容易受到網(wǎng)絡(luò )瓶頸、連接池耗盡和其他相關(guān)問(wèn)題的影響。許多相關(guān)服務(wù)連接到基于SQL的數據庫，這可能會(huì )耗盡其最大連接池，意味著(zhù)需要在監控解決方案中實(shí)施正確的連接狀態(tài)監控指標（建立、散布等待、關(guān)閉等），以檢測可能的、影響API的連接相關(guān)問(wèn)題。此外，可以構建cli測試來(lái)檢查端點(diǎn)狀態(tài)并測量其響應時(shí)間，這可以被轉換成實(shí)際顯示服務(wù)真實(shí)狀態(tài)的指標。
上述每一個(gè)監控解決方案和大多數其他商業(yè)或OpenSource解決方案可以通過(guò)自行設計專(zhuān)門(mén)指標來(lái)進(jìn)行擴展。
命令“time OpenStack catalogue list”可以測量Keystone API響應時(shí)間，評估結果，并在結果不符合預期時(shí)產(chǎn)生人工故障狀態(tài)。此外，你可以使用簡(jiǎn)單的操作系統工具，如“netstat”或“ss”，來(lái)監控API端點(diǎn)的不同連接狀態(tài)，并了解服務(wù)中可能出現的問(wèn)題。OpenStack云依賴(lài)關(guān)系的關(guān)鍵部分（例如消息代理和數據庫服務(wù)）也可以這樣做。請注意，消息中間件失敗基本上將“殺死”OpenStack云。
關(guān)鍵是不要偷懶！不要只用默認的指標，而是應該用與自己服務(wù)相關(guān)的指標。
挑戰四：人為因素
人為因素關(guān)乎一切。俗話(huà)說(shuō)，埋怨工具的工匠不是一個(gè)好工匠。
沒(méi)有經(jīng)過(guò)測試的情景響應程序，單一故障不僅本身是一個(gè)問(wèn)題，還將帶來(lái)造更多的問(wèn)題。在你的監控解決方案中，云基礎設施的任何事故及其相關(guān)警報中都應該有明確的記錄，以清楚的步驟來(lái)解釋如何檢測、遏制和解決問(wèn)題。
人為因素必須考慮，即使你有一個(gè)可以關(guān)聯(lián)事件和建議適當的解決方案來(lái)檢測事故的、聰明的系統（一個(gè)有一定程度人工智能的系統）。請務(wù)必記住，如果系統不正確或不完整，那么輸出也將不準確或不完整。
總結一下，OpenStack監控不一定很困難，最重要的是要徹底。每個(gè)單獨的服務(wù)以及與其他服務(wù)的互動(dòng)都需要仔細監控。特殊指標甚至可以自己實(shí)現。通過(guò)一些TLC，你可以輕松地成功監控你的OpenStack。
