隨著軟件交付方式的變革，微服務(wù)架構(gòu)的興起使得軟件開發(fā)變得更加快速和靈活。在這種情況下，監(jiān)控系統(tǒng)成為了微服務(wù)控制系統(tǒng)的核心組成部分。隨著軟件的復(fù)雜性不斷增加，了解系統(tǒng)的性能狀況和及時(shí)排除問(wèn)題變得更加困難。因此，監(jiān)控系統(tǒng)也需要與時(shí)俱進(jìn)，進(jìn)行全面的改造，以更好地適應(yīng)微服務(wù)環(huán)境的需求，并能夠更好地發(fā)揮作用。

新興的微服務(wù)架構(gòu)對(duì)軟件開發(fā)帶來(lái)了速度和靈活性的提升，從而改變了傳統(tǒng)的軟件開發(fā)模式。其中，速度是微服務(wù)的核心需求之一。為了更好地滿足這一需求，監(jiān)控系統(tǒng)也需要隨之進(jìn)行調(diào)整和改進(jìn)。

監(jiān)控在微服務(wù)體系結(jié)構(gòu)中變得尤為關(guān)鍵，因?yàn)殡S著軟件復(fù)雜性的增加，我們需要更好地了解系統(tǒng)的性能和及時(shí)發(fā)現(xiàn)問(wèn)題。下面是我們制定的五個(gè)指導(dǎo)性原則，以幫助我們整監(jiān)控方法：

1. 監(jiān)控容器及其內(nèi)部：微服務(wù)通常在容器中運(yùn)行，因此監(jiān)控容器本身以及容器內(nèi)的各種組件和資源是至關(guān)重要的。
2. 關(guān)注服務(wù)性能而不是容器性能：在微服務(wù)架構(gòu)中，重點(diǎn)應(yīng)該放在監(jiān)控服務(wù)的性能和健康狀態(tài)上，而不是單純地監(jiān)控容器的資源使用情況。
3. 監(jiān)控彈性和多地部署的服務(wù)：微服務(wù)架構(gòu)的一個(gè)優(yōu)勢(shì)是其彈性和多地部署的能力，因此監(jiān)控系統(tǒng)需要能夠有效地跟蹤和管理這些特性。
4. 監(jiān)控 API：微服務(wù)通常以 API 的形式提供服務(wù)，因此監(jiān)控這些 API 的性能和可用性對(duì)于確保整個(gè)系統(tǒng)的穩(wěn)定運(yùn)行至關(guān)重要。
5. 將監(jiān)控映射到組織結(jié)構(gòu)：根據(jù)我們的組織結(jié)構(gòu)和團(tuán)隊(duì)的職責(zé)，設(shè)計(jì)監(jiān)控系統(tǒng)的結(jié)構(gòu)，確保監(jiān)控?cái)?shù)據(jù)能夠直觀地反映出整個(gè)組織的運(yùn)行狀態(tài)。

通過(guò)遵循這五個(gè)原則，可以建立起更加有效和全面的微服務(wù)監(jiān)控系統(tǒng)，從而更好地應(yīng)對(duì)微服務(wù)架構(gòu)所帶來(lái)的技術(shù)和組織上的挑戰(zhàn)。

下面我們細(xì)說(shuō)這五個(gè)原則

監(jiān)控容器及其內(nèi)部

隨著微服務(wù)架構(gòu)的流行，容器技術(shù)已成為構(gòu)建微服務(wù)的重要組成部分。容器具有速度、可移植性和隔離性等優(yōu)勢(shì)，使得開發(fā)人員更容易接受微服務(wù)模型。容器的好處已經(jīng)被廣泛討論，不再贅述。

然而，對(duì)于外部系統(tǒng)來(lái)說(shuō)，容器就像一個(gè)黑盒子一樣。這對(duì)于開發(fā)人員來(lái)說(shuō)是非常方便的，因?yàn)槿萜骺梢暂p松地在不同的環(huán)境中部署。但是一旦容器開始運(yùn)行，當(dāng)需要監(jiān)控和解決服務(wù)問(wèn)題時(shí)，這個(gè)黑盒子就會(huì)成為挑戰(zhàn)，因?yàn)槌Ｒ?guī)的監(jiān)控方法往往無(wú)法生效。我們需要深入了解容器內(nèi)部運(yùn)行的情況：究竟運(yùn)行了哪些程序和代碼？它們的性能如何？是否有重要的輸出指標(biāo)？從DevOps的角度來(lái)看，我們需要更深入地了解容器，而不僅僅是知道它們的存在。

在非容器環(huán)境下，常見的監(jiān)控方法是在主機(jī)或虛擬機(jī)的用戶空間內(nèi)運(yùn)行一個(gè)代理程序。然而，這種方法并不適用于容器環(huán)境。容器的優(yōu)點(diǎn)之一是輕量級(jí)，它們將各種進(jìn)程隔離開來(lái)，并盡可能地減少依賴關(guān)系。

此外，大規(guī)模使用成千上萬(wàn)個(gè)監(jiān)控代理對(duì)于即使是中等規(guī)模的部署來(lái)說(shuō)都是一種昂貴的資源浪費(fèi)和管理上的挑戰(zhàn)。對(duì)于容器環(huán)境，有兩種潛在的解決方案：

1. 要求開發(fā)人員直接監(jiān)控他們的代碼：讓開發(fā)人員負(fù)責(zé)監(jiān)控其代碼的性能和運(yùn)行狀況。這種方法可以讓開發(fā)人員更深入地了解其代碼的運(yùn)行情況，但可能會(huì)增加他們的工作負(fù)擔(dān)，并且對(duì)于整個(gè)系統(tǒng)的全面監(jiān)控可能不夠全面。
2. 利用內(nèi)核級(jí)的檢測(cè)方法：使用一種通用的內(nèi)核級(jí)監(jiān)控方法來(lái)查看主機(jī)上的所有應(yīng)用程序和容器活動(dòng)。這種方法可以減少代理的數(shù)量，并提供更全面的監(jiān)控覆蓋范圍，但可能會(huì)影響主機(jī)的性能，并且可能無(wú)法提供與每個(gè)容器相關(guān)的詳細(xì)信息。

每種方法都有其優(yōu)點(diǎn)和缺點(diǎn)，選擇最適合環(huán)境的方法取決于我們的具體需求和限制。

利用業(yè)務(wù)流程系統(tǒng)提醒服務(wù)性能

在容器環(huán)境中理解運(yùn)行數(shù)據(jù)并不容易，相比于單個(gè)容器，聚合多個(gè)容器組成的功能或服務(wù)的復(fù)雜度要低得多。

這種方法特別適用于應(yīng)用程序級(jí)別的信息，比如哪個(gè)請(qǐng)求具有最短的響應(yīng)時(shí)間，或者哪些 URL 遇到了最多的錯(cuò)誤。同樣，它也適用于架構(gòu)級(jí)別的監(jiān)控，比如哪個(gè)服務(wù)的容器使用了超出事先分配的 CPU 資源。

越來(lái)越多的軟件部署需要使用編排系統(tǒng)來(lái)將應(yīng)用程序的邏輯規(guī)劃轉(zhuǎn)化為物理容器的部署。常見的編排系統(tǒng)包括 Kubernetes、Mesosphere DC/OS 和 Docker Swarm。團(tuán)隊(duì)可以利用編排系統(tǒng)來(lái)定義微服務(wù)，并理解每個(gè)服務(wù)當(dāng)前狀態(tài)?？梢哉f(shuō)編排系統(tǒng)甚至比容器本身還要重要，因?yàn)槿萜魇桥R時(shí)的，只有在滿足服務(wù)需求時(shí)才會(huì)存在。

DevOps 團(tuán)隊(duì)?wèi)?yīng)該將告警重點(diǎn)放在服務(wù)運(yùn)行特征上，以盡可能貼近監(jiān)控服務(wù)的實(shí)際體驗(yàn)。如果應(yīng)用受到影響，這些告警是評(píng)估事態(tài)的第一道防線。但是獲得這些告警并不容易，除非監(jiān)控系統(tǒng)是基于容器本身的。

容器本身的監(jiān)控解決方案利用編排元數(shù)據(jù)來(lái)動(dòng)態(tài)聚合容器和應(yīng)用程序數(shù)據(jù)，并按每個(gè)服務(wù)計(jì)算監(jiān)控度量。根據(jù)使用的編排工具，可能希望在不同的層次進(jìn)行深入監(jiān)測(cè)。例如，在 Kubernetes 中，通常會(huì)有 Namespace、ReplicaSet、Pod 和其他一些容器。聚合這些不同的層次對(duì)于排除邏輯故障是非常必要的，與構(gòu)成服務(wù)的容器的物理部署無(wú)關(guān)。

監(jiān)控彈性Elastic和多地部署Multi-Location的服務(wù)

彈性服務(wù)并不是一個(gè)新概念，但在原生容器環(huán)境中的變化速度比在虛擬環(huán)境中要快得多。這種快速變化會(huì)嚴(yán)重影響監(jiān)測(cè)系統(tǒng)的正常運(yùn)行。

傳統(tǒng)系統(tǒng)的監(jiān)測(cè)通常需要根據(jù)軟件部署進(jìn)行手動(dòng)調(diào)整。這種調(diào)整可能是具體的，例如定義要捕獲的單個(gè)指標(biāo)，或者基于應(yīng)用程序在特定容器中的操作來(lái)配置要收集的數(shù)據(jù)。在小規(guī)模環(huán)境下（例如幾十個(gè)容器），我們可能可以接受這種手動(dòng)調(diào)整，但在大規(guī)模環(huán)境下就難以承受了。微服務(wù)的集中監(jiān)控必須能夠自動(dòng)地隨著彈性服務(wù)的增長(zhǎng)和縮減而調(diào)整，無(wú)需人工干預(yù)。

舉例來(lái)說(shuō)，如果 DevOps 團(tuán)隊(duì)必須手動(dòng)定義哪些服務(wù)需要監(jiān)控，那么他們很可能會(huì)失手，因?yàn)橄?Kubernetes 或 Mesos 這樣的平臺(tái)每天都會(huì)定期創(chuàng)建新的容器。同樣，如果在將代碼部署到生產(chǎn)環(huán)境時(shí)需要運(yùn)維團(tuán)隊(duì)安裝一個(gè)定制的狀態(tài)端點(diǎn)，這也會(huì)給開發(fā)人員從 Docker 倉(cāng)庫(kù)獲取基礎(chǔ)鏡像帶來(lái)更多的挑戰(zhàn)。

在生產(chǎn)環(huán)境中，建立面向跨越多個(gè)數(shù)據(jù)中心或多個(gè)云的復(fù)雜部署的監(jiān)控是一項(xiàng)挑戰(zhàn)。例如，如果服務(wù)跨越私有數(shù)據(jù)中心和 AWS，那么亞馬遜的 AWS CloudWatch 就很難實(shí)現(xiàn)這一點(diǎn)。因此，我們需要建立一個(gè)能夠跨不同地域的監(jiān)控系統(tǒng)，并能夠在動(dòng)態(tài)的原生容器環(huán)境下運(yùn)行。

監(jiān)控 API

在微服務(wù)環(huán)境中，API 接口是通用的，并且本質(zhì)上是將服務(wù)暴露給其他團(tuán)隊(duì)的唯一組件。事實(shí)上，API 的響應(yīng)和一致性可以看作是“內(nèi)部 SLA”，即使還沒(méi)有定義一個(gè)正式的 SLA（服務(wù)等級(jí)協(xié)議）。

因此，API 接口的監(jiān)控也是必不可少的。API 監(jiān)控可以采用不同的形式，但很顯然，它絕對(duì)不是簡(jiǎn)單的二進(jìn)制上下檢查。例如，了解像時(shí)間函數(shù)這樣的最常使用的端點(diǎn)是很有價(jià)值的。這使得團(tuán)隊(duì)可以看到服務(wù)使用的變化，無(wú)論是由于設(shè)計(jì)更改還是用戶的變化。

還可以記錄服務(wù)最慢的端點(diǎn)，這些可能會(huì)揭示出重大的問(wèn)題，或者至少指向需要在系統(tǒng)中進(jìn)行優(yōu)化的區(qū)域。

最后，跟蹤系統(tǒng)服務(wù)響應(yīng)的能力是另一個(gè)非常重要的能力，它主要是供開發(fā)者使用的，但也有助于你了解整體用戶體驗(yàn)。同時(shí)，將信息基于底層和應(yīng)用程序視角分成兩大部分也是很有幫助的。

將監(jiān)控映射到組織結(jié)構(gòu)

對(duì)于熟悉康威定律的人來(lái)說(shuō)，系統(tǒng)的設(shè)計(jì)是基于開發(fā)團(tuán)隊(duì)的組織結(jié)構(gòu)。創(chuàng)造更快、更敏捷的軟件推動(dòng)了團(tuán)隊(duì)重新思考他們的開發(fā)組織和管理規(guī)則。因此，如果他們想要從這種新的軟件架構(gòu)（微服務(wù)）中獲益，他們的團(tuán)隊(duì)必須將微服務(wù)映射到團(tuán)隊(duì)自身的結(jié)構(gòu)中。換句話說(shuō)，他們需要更小、更松散耦合的團(tuán)隊(duì)，這些團(tuán)隊(duì)可以自主選擇自己的方向，只要能夠滿足整體需求即可。在每個(gè)團(tuán)隊(duì)中，他們對(duì)于開發(fā)語(yǔ)言的使用、bug 提交甚至工作職責(zé)都會(huì)擁有更大的控制能力。