假如你以前曾在云平臺(tái)上事情過(guò)，你必然熟悉這些系統(tǒng)的漫衍式息爭(zhēng)耦性質(zhì)。解耦的漫衍式系統(tǒng)依賴于微處事來(lái)執(zhí)行特定的任務(wù)，每個(gè)微處事城市袒露本身的REST（暗示狀態(tài)轉(zhuǎn)移）API。這些微處事凡是以諸如RabbitMQ或QPID等動(dòng)靜中間件的形式通過(guò)輕量級(jí)動(dòng)靜層彼此通信。

這正是OpenStack的事情道理。每個(gè)主要的OpenStack組件（Keystone、Glance、Cinder、Neutron、Nova等）果真REST端點(diǎn)，組件和子組件通過(guò)動(dòng)靜中間件（如RabbitMQ）舉辦通信。這種要領(lǐng)的利益首先是答允將妨礙分派給特定組件，其次是云基本設(shè)施運(yùn)營(yíng)商可以以程度方法擴(kuò)展所有處事，并智能分派負(fù)載。

然而，這種漫衍式解耦系統(tǒng)固然很是有利，但也帶來(lái)了固有的挑戰(zhàn)——如何正確監(jiān)控OpenStack處事，更詳細(xì)地說(shuō)，東莞電信服務(wù)器 河南電信服務(wù)器，如何識(shí)別大概的單點(diǎn)妨礙。

下面的內(nèi)容針對(duì)OpenStack處事監(jiān)控的詳細(xì)環(huán)境所面對(duì)的真實(shí)挑戰(zhàn)，以及每個(gè)困難大概的辦理方案。

挑戰(zhàn)一：系統(tǒng)不是一個(gè)整體

OpenStack的非整體性息爭(zhēng)耦性凡是被強(qiáng)調(diào)為其主要利益。這雖然是一個(gè)重要的優(yōu)勢(shì)。然而，這顯然會(huì)使任何監(jiān)控整體處事?tīng)顟B(tài)的實(shí)驗(yàn)變得巨大。在每個(gè)組件執(zhí)行一個(gè)特定任務(wù)的漫衍式系統(tǒng)中，每個(gè)組件進(jìn)一步漫衍到多個(gè)子組件中，因此，不難領(lǐng)略當(dāng)特定一部門軟件產(chǎn)生妨礙時(shí)，確定對(duì)處事的影響是何等堅(jiān)苦。

降服這個(gè)堅(jiān)苦的第一步是相識(shí)云。你需要確定所有主要組件之間的干系，然后確定每個(gè)獨(dú)立的特定處事之間的干系，它們的妨礙大概影響整體處事。簡(jiǎn)樸地說(shuō)，你需要知道云中所有組件之間的干系。

思量到這一點(diǎn)，你不只需要監(jiān)督每個(gè)單獨(dú)組件的狀態(tài)（正在運(yùn)行或妨礙遏制），還要確定其他處事如何受到妨礙的影響。

譬喻，假如Keystone死機(jī)，沒(méi)有人可以或許獲取處事目次或登錄任那里事，但這凡是不會(huì)影響虛擬機(jī)或其他已成立的云處事（工具存儲(chǔ)、塊存儲(chǔ)、負(fù)載平衡器等），除非從頭啟動(dòng)處事且Keystone仍然宕機(jī)。然而，假如Apache失效，通過(guò)Apache事情的Keystone和其他雷同的API處事大概會(huì)受到影響。

因此，監(jiān)控平臺(tái)或辦理方案不只必需可以或許評(píng)估各個(gè)處事的狀態(tài)，并且還要可以或許在辦變亂障之間舉辦關(guān)聯(lián)，以便檢點(diǎn)對(duì)整個(gè)系統(tǒng)的真正影響，并相應(yīng)地發(fā)送警報(bào)或通知。

挑戰(zhàn)二：OpenStack不只僅是OpenStack

基于OpenStack的云不只是漫衍式息爭(zhēng)耦式系統(tǒng)，也是一種可在操縱系統(tǒng)和其他在云基本設(shè)施中或與之相關(guān)的設(shè)備中建設(shè)資源的編排辦理方案。這些資源包羅虛擬機(jī)（Xen、KVM或其他打點(diǎn)措施軟件組件）、耐久卷（NFS存儲(chǔ)處事器、Ceph群集、基于SAN的LVM卷或其他存儲(chǔ)后端）、網(wǎng)絡(luò)實(shí)體（端口，網(wǎng)橋，網(wǎng)絡(luò)，路由器，負(fù)載均衡器，防火墻，VPN等）和姑且磁盤（駐留在操縱系統(tǒng)目次中的Qcow2文件）以及很多其他小型系統(tǒng)。

因此，監(jiān)測(cè)辦理方案必需思量到這些基本組件。固然這些資源大概不太巨大，而且不太容易呈現(xiàn)妨礙，可是當(dāng)它們遏制運(yùn)行時(shí)，主要OpenStack處事中的日志大概會(huì)掩蓋真實(shí)的原因。它們僅在受到影響的OpenStack處事中顯示功效，而不顯示設(shè)備或失效的操縱系統(tǒng)軟件的實(shí)際基礎(chǔ)原因。

譬喻，假如libvirt失效，組件Nova將無(wú)法陳設(shè)虛擬實(shí)例。 Nova-compute作為處事將被啟動(dòng)并運(yùn)行，但在陳設(shè)階段實(shí)例將失敗（實(shí)例狀態(tài)：錯(cuò)誤）。為了檢測(cè)這一點(diǎn)，你需要在nova-compute日志之外還監(jiān)控libvirt（處事?tīng)顟B(tài)、指標(biāo)及日志）。

因此，有須要查抄底層軟件和主要組件之間的干系，以及監(jiān)控最終的鏈接，并思量所有最終處事的一致性測(cè)試。你需要監(jiān)控所有內(nèi)容：存儲(chǔ)、網(wǎng)絡(luò)、hypervision層、每個(gè)單獨(dú)的組件以及之間的干系。

挑戰(zhàn)三：跳出固有思維模式

Cacti、Nagios和Zabbix是OpenSource監(jiān)控辦理方案的好例子。這些辦理方案界說(shuō)了一組很是詳細(xì)的懷抱尺度，用于識(shí)別操縱系統(tǒng)上的大概問(wèn)題，可是它們不提供確定更巨大的妨礙環(huán)境或甚至處事?tīng)顟B(tài)所需的專門的指標(biāo)。

這是你需要有締造性的處所。你可以實(shí)施專門的指標(biāo)和測(cè)試，以界說(shuō)處事是否正常、降級(jí)或完全失敗。

像OpenStack這樣的漫衍式系統(tǒng)，個(gè)中每個(gè)焦點(diǎn)處事都袒露了一個(gè)REST API，而且毗連到基于TCP的動(dòng)靜處事，容易受到網(wǎng)絡(luò)瓶頸、毗連池耗盡和其他相關(guān)問(wèn)題的影響。很多相關(guān)處事毗連到基于SQL的數(shù)據(jù)庫(kù)，這大概會(huì)耗盡其最大毗連池，意味著需要在監(jiān)控辦理方案中實(shí)施正確的毗連狀態(tài)監(jiān)控指標(biāo)（成立、散布期待、封鎖等），以檢測(cè)大概的、影響API的毗連相關(guān)問(wèn)題。另外，可以構(gòu)建cli測(cè)試來(lái)查抄端點(diǎn)狀態(tài)并丈量其響應(yīng)時(shí)間，這可以被轉(zhuǎn)換成實(shí)際顯示處事真實(shí)狀態(tài)的指標(biāo)。

上述每一個(gè)監(jiān)控辦理方案和大大都其他貿(mào)易或OpenSource辦理方案可以通過(guò)自行設(shè)計(jì)專門指標(biāo)來(lái)舉辦擴(kuò)展。