翻譯自 https://www.oreilly.com/ideas/monitoring-cloud-native-applications

云原生應(yīng)用在商業(yè)領(lǐng)域使用率逐漸升高，現(xiàn)在不僅僅是Netflix、Amazon和Gilt這樣的公司在打造高擴(kuò)展性和動(dòng)態(tài)應(yīng)用架構(gòu)，每隔一兩個(gè)星期我就聽(tīng)說(shuō)一些傳統(tǒng)領(lǐng)域的公司（像金融和保險(xiǎn)）在將他們的技術(shù)架構(gòu)逐漸更新為云原生架構(gòu)。云原生應(yīng)用的逐漸增多深刻的影響了應(yīng)用的監(jiān)控手段，簡(jiǎn)單來(lái)看你可能以為這不過(guò)是一類新的被監(jiān)控對(duì)象，然而深入分析后你會(huì)發(fā)現(xiàn)這不僅僅是一系列新技術(shù)，而是圍繞應(yīng)用構(gòu)建、管理和運(yùn)維的一系列改變，過(guò)去五年的最佳監(jiān)控實(shí)踐變成了反面教材。
一些反面教材和對(duì)應(yīng)的最佳實(shí)踐如下：

• 嚴(yán)格按照計(jì)劃進(jìn)行產(chǎn)品發(fā)布是保障軟件質(zhì)量的最佳實(shí)踐，然而現(xiàn)在的公司為了或得更好的靈活性，會(huì)在一天之內(nèi)進(jìn)行多次產(chǎn)品部署升級(jí)
• 容量管理是一項(xiàng)重要的戰(zhàn)略規(guī)劃，試圖預(yù)測(cè)未來(lái)，然而現(xiàn)在容量管理變?yōu)榱艘豁?xiàng)特定的流程，會(huì)根據(jù)實(shí)時(shí)數(shù)據(jù)及時(shí)調(diào)整系統(tǒng)容量，進(jìn)而節(jié)省成本

在我們深入了解這種新的監(jiān)控方式帶來(lái)的影響之前，讓我們定義一下什么是云原生應(yīng)用。

什么是云原生應(yīng)用？

與云原生應(yīng)用的名字不同，云原生應(yīng)用不僅僅是關(guān)于“云”。事實(shí)上，這里的“云”代表了一系列應(yīng)用構(gòu)建和管理的方式，我們可以將其細(xì)分為幾個(gè)關(guān)鍵環(huán)節(jié)：

• 可編程基礎(chǔ)設(shè)施 云原生應(yīng)用可以簡(jiǎn)單的通過(guò)一個(gè)API實(shí)現(xiàn)基礎(chǔ)設(shè)施資源（像計(jì)算資源和網(wǎng)絡(luò)資源）的編排，而不需要實(shí)際操作物理設(shè)備（像插接網(wǎng)線）。云計(jì)算供應(yīng)商現(xiàn)在甚至提供像數(shù)據(jù)庫(kù)這種完整的應(yīng)用服務(wù)，它們已近通過(guò)網(wǎng)絡(luò)訪問(wèn)的方式進(jìn)行了分發(fā)和共享。
• 微服務(wù) 微服務(wù)架構(gòu)已經(jīng)成為新的應(yīng)用構(gòu)建標(biāo)準(zhǔn)，根本的原因在于其支持的局部業(yè)務(wù)模塊簡(jiǎn)易部署大大加快了整個(gè)業(yè)務(wù)系統(tǒng)的部署速度，同時(shí)它給予了研發(fā)團(tuán)隊(duì)在技術(shù)選型上更多的自由。研發(fā)團(tuán)隊(duì)可以根據(jù)需求特點(diǎn)選擇不同的技術(shù)，類似于在后端使用Java、在API使用Node.js、在一些后臺(tái)任務(wù)使用Python。
• 持續(xù)交付 持續(xù)集成和交付（CI/CD）是云原生應(yīng)用的核心，雖然云計(jì)算并不要求CI/CD，但是云原生架構(gòu)需要全自動(dòng)（理論上）的交付流水線來(lái)支持研發(fā)人員快速發(fā)布代碼至生產(chǎn)環(huán)境。

云原生應(yīng)用監(jiān)控為什么不同于傳統(tǒng)方式？

圍繞應(yīng)用交付如此多的變化對(duì)監(jiān)控方式產(chǎn)生了哪些影響？我們是否還可以繼續(xù)使用原來(lái)的好的監(jiān)控手段？云原生應(yīng)用帶來(lái)了哪些變化和不同？從10000英尺高空的視角來(lái)看并沒(méi)有太多的概念，我們?nèi)栽诒O(jiān)控基礎(chǔ)設(shè)施和應(yīng)用。但是細(xì)節(jié)是魔鬼，通過(guò)對(duì)已經(jīng)采用云原生應(yīng)用架構(gòu)公司的調(diào)研，我們發(fā)現(xiàn)了如下的內(nèi)容。

你的監(jiān)控手段需要改變嗎？
取決于你所在團(tuán)隊(duì)的成熟程度，你的監(jiān)控手段可能已經(jīng)足夠成熟。基礎(chǔ)設(shè)施監(jiān)控滿足了對(duì)主機(jī)和網(wǎng)絡(luò)的監(jiān)控，應(yīng)用監(jiān)控滿足了應(yīng)用服務(wù)級(jí)別的監(jiān)控（像錯(cuò)誤率和響應(yīng)時(shí)間），真實(shí)用戶監(jiān)控滿足了終端用戶響應(yīng)時(shí)間和錯(cuò)誤率，用戶行為監(jiān)控和日志監(jiān)控也已經(jīng)進(jìn)行了很長(zhǎng)時(shí)間，這一切構(gòu)成了一個(gè)混合監(jiān)控平臺(tái)。這些監(jiān)控?cái)?shù)據(jù)對(duì)于云原生應(yīng)用同樣也很重要。
所以從整體角度來(lái)看監(jiān)控手段并不需要改變，需要改變的地方藏在細(xì)節(jié)的地方。如果你的監(jiān)控手段還沒(méi)有覆蓋上面提到的各個(gè)環(huán)節(jié)，仍有一些缺失，你需要完善整個(gè)運(yùn)維監(jiān)控體系。對(duì)于傳統(tǒng)數(shù)據(jù)中心，由于基礎(chǔ)設(shè)施的維護(hù)是運(yùn)維團(tuán)隊(duì)的責(zé)任，研發(fā)團(tuán)隊(duì)完全不需要關(guān)心基礎(chǔ)設(shè)施狀態(tài)。然而，在云原生的場(chǎng)景下，研發(fā)團(tuán)隊(duì)需要端到端的承擔(dān)圍繞應(yīng)用各個(gè)環(huán)節(jié)的責(zé)任，包括健康運(yùn)轉(zhuǎn)的基礎(chǔ)設(shè)施。

多語(yǔ)言開(kāi)發(fā)需要多語(yǔ)言監(jiān)控
多語(yǔ)言開(kāi)發(fā)代表研發(fā)團(tuán)隊(duì)可以根據(jù)需求使用多種類型的編程語(yǔ)言和數(shù)據(jù)庫(kù)。傳統(tǒng)的手段，公司會(huì)要求整個(gè)公司使用共同的技術(shù)體系，Java EE是其中最典型的代表。數(shù)據(jù)庫(kù)也類似，一個(gè)公司很少同時(shí)使用多種類型的數(shù)據(jù)庫(kù)。在現(xiàn)代話的環(huán)境下，這種標(biāo)準(zhǔn)被研發(fā)團(tuán)隊(duì)內(nèi)部自治取代，如果一個(gè)團(tuán)隊(duì)認(rèn)為Node.js比Java更適合來(lái)實(shí)現(xiàn)API，他們就會(huì)做出這個(gè)決定。這種趨勢(shì)增加了監(jiān)控環(huán)境的復(fù)雜度，以往我們很容易學(xué)習(xí)應(yīng)用管理的專業(yè)知識(shí)，現(xiàn)在在云原生的場(chǎng)景下，這些專業(yè)知識(shí)分散在了很多不同專業(yè)領(lǐng)域的團(tuán)隊(duì)中，比如搜索團(tuán)隊(duì)、支付團(tuán)隊(duì)、優(yōu)惠計(jì)算團(tuán)隊(duì)和用戶管理團(tuán)隊(duì)。
這種情況就需要能夠覆蓋更多技術(shù)場(chǎng)景的監(jiān)控手段，同時(shí)也需要標(biāo)準(zhǔn)化的方式來(lái)描述和管理監(jiān)控?cái)?shù)據(jù)，StatsD就是一種可選的方案。

網(wǎng)絡(luò)規(guī)模IT（web-scale）越來(lái)越常見(jiàn)
網(wǎng)絡(luò)規(guī)模IT（web-scale）已經(jīng)成為Facebook、Google等公司等獨(dú)特標(biāo)記，事實(shí)上，我們很少會(huì)真正打造Twitter和Facebook這樣級(jí)別的應(yīng)用，然而微服務(wù)架構(gòu)的出現(xiàn)導(dǎo)致更小體量的應(yīng)用同樣表現(xiàn)出類似的復(fù)雜性。過(guò)去的三級(jí)架構(gòu)應(yīng)用現(xiàn)在可能會(huì)變成超過(guò)100個(gè)彼此調(diào)用的服務(wù)模塊，這些服務(wù)模塊會(huì)同時(shí)存在多個(gè)版本而且以一種“混沌”的模式升級(jí)。
這樣的復(fù)雜性就需要監(jiān)控手段及工具更加自動(dòng)化，并且能夠以可視化的方式呈現(xiàn)包含大量應(yīng)用實(shí)體的業(yè)務(wù)系統(tǒng)的整體健康狀態(tài)。

所有人都需要關(guān)注監(jiān)控
所有人都需要能夠查看監(jiān)控?cái)?shù)據(jù)，尤其是那些采用DevOps模式的團(tuán)隊(duì)。然而在很多團(tuán)隊(duì)中，運(yùn)維工作仍舊僅僅被分配給一些專門的人員，他們使用高度定制化的儀表盤來(lái)滿足需求。在云原生環(huán)境下，每一個(gè)業(yè)務(wù)團(tuán)隊(duì)都需要能夠以自定義化的方式查看監(jiān)控?cái)?shù)據(jù)。類似于響應(yīng)時(shí)間、錯(cuò)誤率、負(fù)載和日志文件這樣簡(jiǎn)單的監(jiān)控指標(biāo)通常很容易實(shí)現(xiàn)這些目標(biāo)，然而監(jiān)控指標(biāo)應(yīng)當(dāng)不僅僅局限于這些，技術(shù)團(tuán)隊(duì)往往還需要一些信息來(lái)了解A/B測(cè)試對(duì)產(chǎn)品功能的影響或者數(shù)據(jù)緩存策略對(duì)技術(shù)選型的影響。
監(jiān)控界面需要更加直觀，監(jiān)控工具需要預(yù)置好各種各樣監(jiān)控配置，因?yàn)槿藗兤毡槿狈ε渲帽O(jiān)控工具的技能和時(shí)間。

持續(xù)交付提高了異常檢測(cè)的鳳霞
異常檢測(cè)現(xiàn)在是運(yùn)維領(lǐng)域一個(gè)很火的話題，這是有原因的。因?yàn)榻桓蹲兊迷絹?lái)越頻繁，同時(shí)掌握系統(tǒng)變化變得越來(lái)越困難，系統(tǒng)部件越來(lái)越多，甚至整個(gè)系統(tǒng)的具體表現(xiàn)也變得不好理解。
異常檢測(cè)之所以被重視，正是因?yàn)樗峁┝艘环N自動(dòng)分析系統(tǒng)運(yùn)行狀態(tài)的手段，同時(shí)它還會(huì)自動(dòng)評(píng)估系統(tǒng)變更帶來(lái)的影響。

基礎(chǔ)設(shè)施生命周期變得短暫
“健康的靈魂或在健康的身體中”，很長(zhǎng)一段時(shí)間這對(duì)于運(yùn)維監(jiān)控也是正確的，如果基礎(chǔ)設(shè)施不健康，應(yīng)用系統(tǒng)也會(huì)受到影響。雖然現(xiàn)在這仍是正確的，但是系統(tǒng)在處理異?；A(chǔ)設(shè)施時(shí)會(huì)采用完全不同的方式—異常節(jié)點(diǎn)在系統(tǒng)運(yùn)行過(guò)程中會(huì)被直接替換掉，這使得系統(tǒng)具備了一定的彈性。云原生應(yīng)用通過(guò)定期監(jiān)控CPU或訪問(wèn)健康狀態(tài)接口來(lái)自動(dòng)監(jiān)控節(jié)點(diǎn)健康狀態(tài)，如果監(jiān)控發(fā)現(xiàn)異常，類似于自動(dòng)伸縮集群和Mesos這樣的集群管理平臺(tái)會(huì)自動(dòng)替換異常節(jié)點(diǎn)。
監(jiān)控策略需要適應(yīng)這種彈性，以基礎(chǔ)設(shè)施為中心的監(jiān)控工具難以適配這種場(chǎng)景，監(jiān)控所關(guān)注的中心需要由基礎(chǔ)設(shè)施變化為應(yīng)用本身。CPU和內(nèi)存指標(biāo)與應(yīng)用健康之間的關(guān)聯(lián)變得很小，系統(tǒng)資源不足時(shí)自動(dòng)擴(kuò)展策略會(huì)自動(dòng)添加新的節(jié)點(diǎn)。
更重要的監(jiān)控指標(biāo)是應(yīng)用及應(yīng)用內(nèi)每個(gè)獨(dú)立服務(wù)的響應(yīng)時(shí)間及錯(cuò)誤率，這些指標(biāo)代表了這些服務(wù)是否真正在提供它們所需要提供的服務(wù)。APM工具天生就是用來(lái)提供這些信息的，因?yàn)樗鼈兊氖滓P(guān)注對(duì)象正是應(yīng)用本身。
然而，這并不代表基礎(chǔ)設(shè)施監(jiān)控指標(biāo)完全失去了它們的重要性，它們?cè)诠收细蛟\斷和容量規(guī)劃方面發(fā)揮重要的作用，應(yīng)用健康狀態(tài)最好還是通過(guò)與應(yīng)用直接相關(guān)的指標(biāo)來(lái)衡量。

容量規(guī)劃變得實(shí)時(shí)化
以往容量規(guī)劃往往需要在一開(kāi)始就做好，添加新的硬件需要花費(fèi)很長(zhǎng)時(shí)間，然而通過(guò)云計(jì)算，現(xiàn)在只需要一次簡(jiǎn)單的API調(diào)用，這有助于實(shí)現(xiàn)按需擴(kuò)容和縮容，同時(shí)也對(duì)監(jiān)控工具提出了新的要求。
過(guò)去監(jiān)控工具通常被用來(lái)分析是否有太多計(jì)算資源被使用，現(xiàn)在它們需要報(bào)告何時(shí)容量過(guò)于冗余。由于云計(jì)算是按需付費(fèi)的，及時(shí)關(guān)閉資源有助于節(jié)省費(fèi)用。CIO們已經(jīng)不再僅僅關(guān)注服務(wù)的SLA質(zhì)量，同時(shí)也開(kāi)始關(guān)心容量使用情況，以便盡可能節(jié)省資金。

編排平臺(tái)也是軟件，也有可能出錯(cuò)
基礎(chǔ)設(shè)施平臺(tái)需要自動(dòng)化，類似于Marathon、Mesos、Kubernetes之類的應(yīng)用編排平臺(tái)使用越來(lái)越普及。我們發(fā)現(xiàn)很多人使用這些平臺(tái)，卻忘記了監(jiān)控它們，然而當(dāng)它們出現(xiàn)問(wèn)題時(shí)，平臺(tái)將失去自動(dòng)化運(yùn)行能力，而需要非常困難的手動(dòng)管理。
所以監(jiān)控工具同樣需要監(jiān)控這些應(yīng)用編排平臺(tái)，雖然這些平臺(tái)后面有強(qiáng)大的開(kāi)發(fā)社區(qū)，它們?nèi)允悄贻p的軟件并且人們普遍缺乏管理經(jīng)驗(yàn)。

基礎(chǔ)設(shè)施可能會(huì)實(shí)時(shí)變化
我的業(yè)務(wù)系統(tǒng)是什么樣子的，我能把它畫(huà)在白板上嗎？這是運(yùn)維大型系統(tǒng)時(shí)的關(guān)鍵問(wèn)題。配置管理平臺(tái)（CMDB）通過(guò)提供統(tǒng)一可信的配置和部署信息來(lái)解決此類問(wèn)題，然而事實(shí)上這從來(lái)不是一種可行的方式。關(guān)鍵障礙在于這些信息需要手動(dòng)從不同的來(lái)源錄入CMDB，由于維護(hù)困難，CMDB中的信息總是會(huì)出現(xiàn)延遲，分析管理復(fù)雜業(yè)務(wù)系統(tǒng)的需求還是沒(méi)有得以解決。當(dāng)也需系統(tǒng)模塊化后搜集相關(guān)配置數(shù)據(jù)變得更加困難，基礎(chǔ)設(shè)施和網(wǎng)絡(luò)隨時(shí)都在改變，很有可能你永遠(yuǎn)都沒(méi)有辦法保持配置管理信息實(shí)時(shí)更新。
監(jiān)控工具通常包含很多配置相關(guān)信息，他們?cè)诓僮飨到y(tǒng)層面運(yùn)行并且具備應(yīng)用級(jí)別洞察能力。由于監(jiān)控?cái)?shù)據(jù)是實(shí)時(shí)的，它們可以自動(dòng)實(shí)時(shí)維護(hù)應(yīng)用基礎(chǔ)設(shè)施配置關(guān)系，通過(guò)在監(jiān)控工具中添加類似于CMDB的功能，手動(dòng)數(shù)據(jù)維護(hù)工作可以消失了。通過(guò)監(jiān)控工具和CMDB的結(jié)合，數(shù)據(jù)得以實(shí)時(shí)更新，配置管理的意義變得更高，因?yàn)樗梢蕴峁┮恍┖苡袃r(jià)值的信息，類似于“哪個(gè)服務(wù)正在訪問(wèn)數(shù)據(jù)庫(kù)，從上次部署發(fā)生了哪些變化”。

重新思考你的監(jiān)控策略
以上這些對(duì)監(jiān)控意味著什么？絕大多數(shù)情況下你并不需要完全放棄已經(jīng)構(gòu)建的監(jiān)控體系，你需要開(kāi)始思考在采用云原生架構(gòu)后監(jiān)控策略如何演進(jìn)，監(jiān)控絕對(duì)不能成為事后才考慮的事情。