我七歲就開始編程(在紙上，沒有電腦，但那是另一回事)。早期我學(xué)到的一件事就是軟件開發(fā)就像生活一樣充滿了權(quán)衡：組織和開發(fā)人員過去常常不得不在性能或簡單性，創(chuàng)新性或可管理性之間進(jìn)行選擇。但是，隨著作為容器/ Docker趨勢的一部分的微服務(wù)的出現(xiàn)，應(yīng)用程序開發(fā)已轉(zhuǎn)變?yōu)橐幌盗行⌒偷姆?wù)，每個服務(wù)都運(yùn)行在自己的進(jìn)程中，并與API等機(jī)制進(jìn)行通信。微服務(wù)的優(yōu)勢非常明顯：軟件開發(fā)和部署的速度有了巨大的提升，從而節(jié)省了資金，并且在合適的情況下為組織帶來了競爭優(yōu)勢。

 

在過去的幾年中，我和很多開發(fā)人員進(jìn)行了交流，并且了解了他們所面臨的難題。這些對話清楚地告訴我，當(dāng)開發(fā)人員接受了微服務(wù)，組織要徹底反思作為良好性能和安全衛(wèi)生的一部分的軟件管理實(shí)踐。微服務(wù)的使用意味著軟件管理方法的變革，特別是組織如何處理基礎(chǔ)設(shè)施，應(yīng)用程序和數(shù)據(jù)的監(jiān)控。如果企業(yè)不思變革，它們在理解微服務(wù)性能時會困難重重，更不用說故障排除的問題了。下面來看看可以使你對微服務(wù)的監(jiān)控更加智能，響應(yīng)更快(更高的效率也不在話下)的五種方法。

 

 

容器作為微服務(wù)的基本構(gòu)成材料，它是跨越開發(fā)人員筆記本電腦乃至云端的黑盒子。但是，如果沒有對容器的真實(shí)可見度，要執(zhí)行監(jiān)視或服務(wù)故障排除等基本功能就很困難。你需要知道容器中運(yùn)行的是什么，應(yīng)用程序和代碼的運(yùn)行情況以及它們是否在生成重要的自定義指標(biāo)。

 

隨著貴組織規(guī)模的擴(kuò)大，它可能要在數(shù)千臺主機(jī)中運(yùn)行數(shù)以萬計的容器，部署可能會變得很昂貴，并成為編排上的棘手事情。要獲得容器的監(jiān)控權(quán)限，你有幾個選擇：要求開發(fā)人員直接測試代碼，運(yùn)行挎斗容器(sidecar container)，或利用通用內(nèi)核級別的檢測工具來查看所有的應(yīng)用程序和容器的活動。每種方法都有各自的優(yōu)缺點(diǎn)，因此你需要考察哪一種方法能實(shí)現(xiàn)你最重要的目標(biāo)。重要的是，對虛擬機(jī)中的靜態(tài)工作負(fù)載有效的老方法將不再能勝任工作了。

 

 

你可以執(zhí)行的最關(guān)鍵流程之一是跟蹤與某個功能或服務(wù)關(guān)聯(lián)的所有容器的聚合信息，比如每個服務(wù)的響應(yīng)時間。舉例來說，這種即時聚合還適用于基礎(chǔ)設(shè)施級監(jiān)控，以了解哪些服務(wù)的容器正在使用超出其CPU配額的資源。

 

如果你是開發(fā)團(tuán)隊的一員，那么你可以使用Kubernetes、Mesosphere DC/OS或Docker Swarm這樣的編排系統(tǒng)來定義你的微服務(wù)并了解每個已部署服務(wù)的當(dāng)前狀態(tài)。如果你是開發(fā)運(yùn)維團(tuán)隊的成員，那么你應(yīng)該重新定義系統(tǒng)警報，要盡可能貼近監(jiān)控服務(wù)的體驗(yàn)，因?yàn)榫瘓笫窃u估應(yīng)用程序運(yùn)行狀況的第一道防線。如果監(jiān)視系統(tǒng)是原生于容器的(container-native)，這樣的監(jiān)視系統(tǒng)使用編排元數(shù)據(jù)，動態(tài)地將容器和應(yīng)用程序數(shù)據(jù)聚合起來，并且根據(jù)每個服務(wù)計算監(jiān)視指標(biāo)，那么這個過程會變得更容易。

 

根據(jù)編排工具的不同，可能會有不同的層次結(jié)構(gòu)需要深入;Kubernetes提供Namespace、ReplicaSets、Pods和一些容器。無論服務(wù)的容器在物理上是如何部署的，在這些層進(jìn)行聚合對于邏輯故障排除都至關(guān)重要。

 

 

原生于容器的環(huán)境會發(fā)生迅速的變化，而這種活力暴露了所有監(jiān)控系統(tǒng)的弱點(diǎn)。手動定義和調(diào)整衡量標(biāo)準(zhǔn)的做法可能適用于20或30個容器，但微服務(wù)監(jiān)控必須能夠與彈性服務(wù)一起擴(kuò)展和收縮——而且無需人工干預(yù)。因此，如果你必須手動定義容器包含在監(jiān)控中的服務(wù)，那么你很可能會錯過Kubernetes或Mesos在白天啟動的新容器。同樣，如果貴組織在構(gòu)建和部署新代碼時安裝了自定義的統(tǒng)計信息端點(diǎn)(custom stats endpoint)，則開發(fā)人員會從Docker注冊表中提取基本的鏡像(base image)，因此監(jiān)視過程會變得非常復(fù)雜。

 

如果貴組織正在使用微服務(wù)，那么你還需要跨越多個數(shù)據(jù)中心或多個云的監(jiān)控。例如，只有當(dāng)你的微服務(wù)限用于AWS時，AWS CloudWatch才有用。。

 

 

作為微服務(wù)環(huán)境的通用語言，API是其他團(tuán)隊能體驗(yàn)到的唯一服務(wù)元素。如果尚未定義正式的服務(wù)水平協(xié)議，則API的響應(yīng)和一致性甚至可能成為內(nèi)部的服務(wù)水平協(xié)議。這意味著API監(jiān)控必須超越標(biāo)準(zhǔn)的，非此即彼的啟用/停用檢查(binary up-down check)。

 

作為微服務(wù)的用戶，你會發(fā)現(xiàn)了解作為時間函數(shù)的最常用的端點(diǎn)是很有價值的，它可以讓你了解服務(wù)的使用情況發(fā)生了什么變化(不管是因?yàn)樵O(shè)計還是用戶更改)。發(fā)現(xiàn)最慢的服務(wù)端點(diǎn)還可以向你表明哪些地方需要優(yōu)化。通過系統(tǒng)跟蹤服務(wù)調(diào)用的能力(通常僅由開發(fā)人員使用的功能)將有助于貴組織理解整體的用戶體驗(yàn)。API監(jiān)控的這一方面也將把信息分解成微服務(wù)環(huán)境的基于基礎(chǔ)架構(gòu)和應(yīng)用程序的視圖。

 

 

雖然微服務(wù)預(yù)示著你和你的組織監(jiān)控和保護(hù)軟件基礎(chǔ)架構(gòu)的方式發(fā)生了全面轉(zhuǎn)變，但你不忽視軟件監(jiān)控的人為方面，這是很重要的。如果貴組織希望從這種新的軟件體系結(jié)構(gòu)方法中受益，那么你的團(tuán)隊必須自行創(chuàng)建微服務(wù)的鏡像。這意味著團(tuán)隊會更小，更松散，擁有大量的自主權(quán)，但把重點(diǎn)放在戰(zhàn)略目標(biāo)上。每個團(tuán)隊對所使用的語言，錯誤解決(bug resolution)或操作責(zé)任方面比以往任何時候都保留了更多的控制權(quán)。然后，你可以創(chuàng)建一個監(jiān)控平臺，這個平臺允許每個微服務(wù)團(tuán)隊隔離警報、指標(biāo)和儀表板，同時仍然在整個系統(tǒng)中為操作提供綜覽。

 

軟件監(jiān)控的一些基本改變有助于促進(jìn)微服務(wù)的速度，效率和潛在節(jié)約。改進(jìn)了的微服務(wù)監(jiān)控使性能更強(qiáng)大，最終用戶滿意度更高。微服務(wù)得到適當(dāng)調(diào)校后將在更短的時間內(nèi)提供更多的功能，這是服務(wù)交付的良性循環(huán)。

 

版權(quán)聲明：本文為企業(yè)網(wǎng)D1Net編譯，轉(zhuǎn)載需注明出處為：企業(yè)網(wǎng)D1Net，如果不注明出處，企業(yè)網(wǎng)D1Net將保留追究其法律責(zé)任的權(quán)利。