[[394227]]

應(yīng)用上云，應(yīng)關(guān)注哪些指標(biāo)?有無數(shù)的指標(biāo)需要監(jiān)控，某些指標(biāo)比其他指標(biāo)更重要。但是，沒有一刀切的策略，因為雖然一個指標(biāo)可能是一個應(yīng)用程序的關(guān)鍵，但它對另一個應(yīng)用程序可能完全毫無用處。

為了制定最佳戰(zhàn)略，企業(yè)需要首先確定其優(yōu)先事項。優(yōu)先級可防止IT團(tuán)隊被監(jiān)控用戶行為、資源可用性、延遲、響應(yīng)時間等的應(yīng)用性能數(shù)據(jù)流淹沒。

除了討論如何思考監(jiān)控指標(biāo)外，本文還討論關(guān)于云應(yīng)用管理主題的實(shí)際建議。例如，多租戶云環(huán)境的嘈雜鄰邦效應(yīng)是持續(xù)存在的憂慮，尤其是在應(yīng)用性能方面。

在云中運(yùn)行工作負(fù)載的一個關(guān)鍵優(yōu)勢是保證這些云資源始終運(yùn)行。監(jiān)控和管理云工作負(fù)載可能比較棘手。不過，這種努力是值得的，尤其是在支出方面。畢竟，使用云服務(wù)可能很昂貴。企業(yè)應(yīng)該知道每月的費(fèi)用會得到什么回報。

一云上應(yīng)用監(jiān)控重要指標(biāo)

錯誤率、計算成本、每分鐘請求數(shù)，云應(yīng)用監(jiān)控策略中有許多指標(biāo)需要查看，應(yīng)該優(yōu)先考慮哪些?

二十多年來，IT團(tuán)隊一直在部署應(yīng)用程序性能管理工具，以監(jiān)控和管理本地應(yīng)用和基礎(chǔ)設(shè)施。但是，當(dāng)組織遷移到云時，這些APM策略需要適應(yīng)。

云APM要求組織跟蹤比本地APM更多的指標(biāo)。在處理基于云的環(huán)境時，收集和分析指標(biāo)數(shù)據(jù)還需要權(quán)衡其他因素。

1云上APM有什么不同?

乍一看，就應(yīng)用監(jiān)控而言，云環(huán)境和本地環(huán)境似乎并沒有根本不同。云應(yīng)用程序仍然在服務(wù)器上運(yùn)行，并且以類似于本地應(yīng)用的方式處理事務(wù)。

可以在云中使用某些監(jiān)控方法。例如，RED方法強(qiáng)調(diào)收集與交易速率、錯誤和持續(xù)時間相關(guān)的指標(biāo)。

什么是RED方法?RED 方法定義了在架構(gòu)中應(yīng)衡量的每個微服務(wù)的三個關(guān)鍵指標(biāo)。這些指標(biāo)是：Rate：請求的數(shù)量，每秒，你的服務(wù)正在服務(wù)。Errors：每秒失敗請求的數(shù)量。Duration：分配每個請求所需的時間。

然而，云環(huán)境帶來了額外的挑戰(zhàn)。在規(guī)劃要監(jiān)控哪些指標(biāo)時，需要考慮以下因素：

· 分布式架構(gòu)：云環(huán)境更有可能包括數(shù)十臺甚至數(shù)百臺單個服務(wù)器，其應(yīng)用程序分布在它們之間。這使得不僅監(jiān)控單個服務(wù)器，而且監(jiān)控整個群集更為重要。云中最重要的是群集的健康狀況，而不是云中的每個服務(wù)器。

· 所有權(quán)有限：在云環(huán)境中，用戶通常不能完全控制主機(jī)服務(wù)器和操作系統(tǒng)，而這些服務(wù)器和操作系統(tǒng)由云提供商管理。這會使收集某些類型的數(shù)據(jù)更加困難。例如，無法從大多數(shù)基于云的無服務(wù)器計算服務(wù)中提取操作系統(tǒng)日志，因為無法訪問操作系統(tǒng)。

· 成本：過度分配的云環(huán)境可能會增加云計算費(fèi)用。這使得使用云監(jiān)控除了性能優(yōu)化之外，還有助于支持成本優(yōu)化。當(dāng)然，本地成本也很重要，但這方面過度提供問題較少，因為本地費(fèi)用大部分是資本支出造成的，而不是業(yè)務(wù)支出造成的。

· 延遲：實(shí)現(xiàn)低延遲應(yīng)該是任何類型的應(yīng)用的目標(biāo)。但是，在處理基于云的應(yīng)用時，延遲可能會帶來更大的挑戰(zhàn)。如果云可用區(qū)遠(yuǎn)離用戶，則延遲問題的風(fēng)險較高。

· 負(fù)載平衡：雖然有時可能會為本地應(yīng)用程序使用負(fù)載平衡器，但在云中使用它來引導(dǎo)應(yīng)用程序多個實(shí)例之間的流量更為常見。這為網(wǎng)絡(luò)和流量監(jiān)控增加了另一層復(fù)雜性。

· 多云：如果使用多云或混合云架構(gòu)，則很難將APM工具鏈整合到單個工具集周圍。例如，如果將資源分散到多個云中，則不能單獨(dú)使用AWS CloudWatch來監(jiān)控所有資源。

所有這些差異都會影響團(tuán)隊監(jiān)控和管理云中應(yīng)用所需的方法。

2要跟蹤的關(guān)鍵云指標(biāo)

對于幾乎任何類型的云環(huán)境，需要跟蹤以下類型的指標(biāo)：

· 每分鐘請求次數(shù)：通過跟蹤云應(yīng)用程序每分鐘收到多少請求，將知道請求速率偏離歷史基線時的一天或一周中的天數(shù)。這使組織能夠更準(zhǔn)確地預(yù)測何時增加云資源的容量。還可以使用這種類型的指標(biāo)來幫助識別問題，如分布式拒絕服務(wù)(DDoS)攻擊。

· 平均確認(rèn)時間：跟蹤平均確認(rèn)時間(指基于云的應(yīng)用開始響應(yīng)請求所需的時間)可能會揭示與負(fù)載平衡器相關(guān)的問題，這些問題無法足夠快地轉(zhuǎn)發(fā)請求。確認(rèn)時間過慢也可能表明資源不足，并且正在努力處理其所有請求。

為了獲得最佳的可見性，請監(jiān)控和比較使用的每個云區(qū)域或單個云的確認(rèn)時間指標(biāo)，而不是僅是聚合分析它們。這將有助于確定可能特定于一個云區(qū)域或云的延遲問題。比較給定請求由內(nèi)容交付網(wǎng)絡(luò)(CDN)處理時的確認(rèn)時間也有助于了解如何最好地將延遲降至最低。

· 響應(yīng)持續(xù)時間：響應(yīng)持續(xù)時間，或應(yīng)用程序完成對請求的響應(yīng)所需的總時間，也是應(yīng)用程序是否有足夠的資源來處理針對它的流量的指標(biāo)。此外，響應(yīng)持續(xù)時間的問題可能表明應(yīng)用程序本身存在錯誤或內(nèi)部通信問題，如一個微服務(wù)無法與另一個微服務(wù)有效通信。響應(yīng)持續(xù)時間還應(yīng)按區(qū)域和每云跟蹤，以便最大限度地了解延遲。

· 錯誤率：請求多久導(dǎo)致一次錯誤?哪些類型的錯誤最常見?這些指標(biāo)可進(jìn)一步了解應(yīng)用的整體健康狀況以及托管它的云環(huán)境。錯誤可能反映了應(yīng)用程序問題，但它們也可能表明云環(huán)境本身存在問題，例如云服務(wù)不可用(這通常是云提供商需要解決的問題)或在云環(huán)境中運(yùn)行的服務(wù)配置不當(dāng)?shù)脑L問憑據(jù)。

· 可用服務(wù)器/節(jié)點(diǎn)：對于分布式云環(huán)境，應(yīng)該跟蹤群集中有多少服務(wù)器或節(jié)點(diǎn)已上線，作為已部署服務(wù)器器的可用百分比。雖然云編排和自動化工具可以很好地在服務(wù)器出現(xiàn)問題時自動將工作負(fù)載從一個節(jié)點(diǎn)重新分配到另一個節(jié)點(diǎn)，但他們只能在運(yùn)行健康服務(wù)器之前這樣做。需要知道可用服務(wù)器的數(shù)量是否會減少到總部署的90%以上，這可能表明云服務(wù)器實(shí)例存在嚴(yán)重問題。

· 平均計算成本：在給定時期內(nèi)跟蹤基于云的計算資源(如虛擬機(jī)或無服務(wù)器計算)的總平均成本將有助于控制成本。計算成本的激增無法解釋為應(yīng)用需求的相應(yīng)增長，這可能預(yù)示著過度分配，在糾正之前會浪費(fèi)金錢。

· 平均存儲成本：還可以跟蹤云存儲資源的平均成本，包括數(shù)據(jù)庫、對象存儲和塊存儲。同樣，與實(shí)際應(yīng)用需求相關(guān)的存儲成本增加可能表明存在問題，例如數(shù)據(jù)生命周期管理不當(dāng)或數(shù)據(jù)存儲層使用效率低下。

3需要考慮的其他云指標(biāo)

根據(jù)應(yīng)用部署和管理方式，可能還需要考慮以下類型的指標(biāo)，以幫助監(jiān)控云應(yīng)用程序并優(yōu)化最終用戶體驗：

· 每周(或一天)部署數(shù)量：如果使用CI/CD流水線將應(yīng)用程序持續(xù)部署到云中，則衡量每周或每天完成多少部署(如果特別頻繁地部署)將有助于了解 CI/CD 操作的整體健康狀況。

· 功能發(fā)布的時間：按照類似的思路，跟蹤團(tuán)隊從想法到部署需要多長時間才能獲得新功能，這為了解 CI/CD 流水線的效率提供了可見性。

· 平均解決時間：解決指標(biāo)的平均時間(衡量工程師對環(huán)境中發(fā)生的事件的反應(yīng)需要多長時間)對于在任何類型的環(huán)境中進(jìn)行跟蹤都很重要。但是，鑒于云環(huán)境的復(fù)雜性，在處理基于云的應(yīng)用時，它們尤其重要。

在每個類別中收集的具體指標(biāo)將取決于使用的云服務(wù)類型及其暴露的指標(biāo)。這些指標(biāo)因云平臺而異，但通常由云提供商提供充分記錄。

無論APM工具中攝入什么特定的云指標(biāo)，重點(diǎn)應(yīng)該是收集有助于了解復(fù)雜分布式云環(huán)境狀態(tài)的信息。

還應(yīng)努力關(guān)聯(lián)不同類型的數(shù)據(jù)，并比較不同云和服務(wù)的數(shù)據(jù)。這樣，可以全面了解云中可能出現(xiàn)的性能和成本問題。

當(dāng)詳細(xì)了解正在發(fā)生的事情時，將處于更好的位置，以防止復(fù)雜情況并提高云部署的性能。

二多租戶環(huán)境是否仍會創(chuàng)建嘈雜的鄰居?

吵鬧的鄰居不僅僅是一個現(xiàn)實(shí)世界的問題。了解吵鬧的鄰居如何影響工作負(fù)載性能，以及公有云如何更改以解決此問題。

每個人都有一個嘈雜的鄰居故事，比如居住在郊區(qū)的人，他在周末早上6：30修剪草坪。不幸的是，這個問題并不只保留給那些彼此住得很近的人。云用戶有時會處理類似的挫折感。

在公有云的早期，共享資源的概念是新的，供應(yīng)商尚未制定出防止性能下降的難題。今天，這個喧鬧的鄰居大部分是歷史，但它仍然是時不時地可能出現(xiàn)的東西。

1吵鬧的鄰居的影響

吵鬧的鄰居被定義為一方在多租戶環(huán)境中壟斷共享空間，這個問題對于IT團(tuán)隊來說已經(jīng)司空見慣。

在嘈雜的鄰邦情景中，一方根據(jù)多租戶環(huán)境中的預(yù)期需求和工作負(fù)載行為過度提供計算、網(wǎng)絡(luò)和存儲基礎(chǔ)設(shè)施。一切都按計劃執(zhí)行，直到工作量激增，并開始消耗超出其典型行為的資源容量。因此，共享相同容量的其他工作負(fù)載可能會受到性能影響。

這個問題自大型機(jī)問世以來就一直存在，隨著企業(yè)向公有云飛奔，這個問題也隨之而來。每個IT組織都有這個問題，不同的是，有些計劃比其他組織更好。

2嘈雜的鄰居和容器

嘈雜的鄰居問題已經(jīng)為主要云供應(yīng)商解決了。多年來，他們越來越有能力管理運(yùn)營、轉(zhuǎn)移負(fù)載和快速應(yīng)對性能問題。此外，對于超大規(guī)模提供商，用戶可以訪問許多專門選項，以最大限度地減少這些問題，包括虛擬專用云和專用連接。其他強(qiáng)大的資源，如較大的實(shí)例類型和自動縮放工具，如果工作負(fù)載需要它們，也很容易獲得。

也許某些地區(qū)的其他規(guī)模較小的提供商可能會有這種嘈雜的鄰居問題，但就超大規(guī)模提供商而言，在過去兩年中，最終用戶表示過這種擔(dān)憂。

例如，雖然對多租戶環(huán)境的傳統(tǒng)關(guān)注集中在壟斷帶寬或 CPU 周期的實(shí)體上，但容器的廣泛采用可能會改變這些擔(dān)憂。

與VM模型不同，使用容器時，操作系統(tǒng)是虛擬化的。因此，操作系統(tǒng)的切片專用于多個租戶，這帶來了一系列挑戰(zhàn)，特別是在安全方面。

然而，長期缺乏對容器的可見性意味著IT運(yùn)維和技術(shù)團(tuán)隊可能無法識別多租戶環(huán)境中嘈雜的鄰居問題。

3調(diào)低音量

首先，客戶要積極監(jiān)控在公有云中運(yùn)行的任何應(yīng)用程序的性能。云提供商保證可用性SLA，但如果用戶注意到性能下滑，則提出了危險信號。

如果是公司內(nèi)部網(wǎng)使用的應(yīng)用，用戶可能并不擔(dān)心性能略有變化。但是，如果它是一個電子商務(wù)網(wǎng)站，這些變化可能是一個大問題，將支持使用專用或獨(dú)立的機(jī)器的論點(diǎn)。

但是，它可能不僅僅是一個計算問題。需要查看正在使用何種共享資源。例如，可以有一個專用的服務(wù)器，物理或虛擬共享亞馬遜S3存儲。在這種情況下，如果有人在做S3重壓力工作，吵鬧的鄰居可能還是個問題。

如果發(fā)現(xiàn)有問題，建議與您的云提供商合作，了解訪問不同類型的專用基礎(chǔ)設(shè)施需要什么，在那里不必?fù)?dān)心云中任何潛在的嘈雜鄰居。較小的公司，甚至網(wǎng)絡(luò)托管公司，有時提供專用的基礎(chǔ)設(shè)施，公有云廠商也提供裸金屬服務(wù)。

三如何選擇云上合適的高可用性?

自己的云應(yīng)用真正需要多少個"九"?高可用性仍然是云SLA中的一個重要因素，但每個服務(wù)和公司的正常運(yùn)行時間需求各不相同。

當(dāng)談到云計算的高可用性時，企業(yè)往往喜歡不切實(shí)際。云供應(yīng)商在營銷SLA時列出了三、四和五個"九"，因此 IT 團(tuán)隊可能很難確定他們實(shí)際需要為自己的應(yīng)用程序提供多少上線時間。

谷歌、亞馬遜和微軟的付費(fèi)服務(wù)都有至少99.9%的服務(wù)級協(xié)議(SLA)，但不超過99.99%(4個9)。從這個角度來看，99.9%的可用性意味著一年內(nèi)只有不到9小時的停機(jī)時間，99.99% 的可用性意味著一年內(nèi)停機(jī)時間少于 1 小時。

主要的云提供商可以滿足這些協(xié)議中相對較高的標(biāo)準(zhǔn)，盡管涉及復(fù)雜性，這要?dú)w功于大量才華橫溢的工程師和數(shù)十年的既定流程。

需要一個合理合理的SLA來決定應(yīng)用程序的可用性，這一切都始于了解應(yīng)用的復(fù)雜性。例如，一個簡單的靜態(tài)網(wǎng)站可以很容易地期望實(shí)現(xiàn)四個九或更多的正常運(yùn)行時間，因為很少有潛在的故障點(diǎn)。

現(xiàn)在，考慮一個更復(fù)雜、更單一的 Web 應(yīng)用程序。雖然四個九可能仍然是可能的，但實(shí)現(xiàn)它的壓力會隨著向組合添加組件(如數(shù)據(jù)庫和緩存服務(wù)器或?qū)ο蟠鎯?而增加。將應(yīng)用分解為微服務(wù)，潛在故障點(diǎn)的數(shù)量也會增加。

隨著應(yīng)用程序復(fù)雜性的增加，在可用性指標(biāo)中丟失 9 的風(fēng)險也會增加。雖然你總是可以拋出更多的冗余的問題，你也會增加你的成本，并創(chuàng)造復(fù)雜的工程挑戰(zhàn)。畢竟，保持?jǐn)?shù)據(jù)庫的多個副本同步并不是一個微不足道的問題。

手頭的所有信息，你可以做什么，以實(shí)現(xiàn)不同的可用性水平，下一步是找出失去一個九在你的SLA的后果。例如，如果有54 分鐘的停機(jī)時間與 540 分鐘或 5，400 分鐘的停機(jī)時間，客戶會有什么反應(yīng)?在每個級別上，將損失多少客戶?

這些是制作 SLA 時必須考慮的問題類型。高可用性在云計算中很重要，但它不應(yīng)該消耗所有的資源。而五九(99.999%)對于草坪護(hù)理電子商務(wù)巨頭來說，正常工作時間可能令人印象深刻，其客戶對停機(jī)時間的容忍度可能遠(yuǎn)高于緊急服務(wù)提供商。確保不會在不必要事情上花費(fèi)過多的時間和精力。

參考文檔：

1. https://searchcloudcomputing.techtarget.com/feature/Metrics-that-matter-in-cloud-application-monitoring

2. https://searchcloudcomputing.techtarget.com/tip/Do-multi-tenant-environments-still-create-noisy-neighbors

3. https://searchcloudcomputing.techtarget.com/answer/How-much-cloud-uptime-do-you-need

4. https://www.weave.works/blog/the-red-method-key-metrics-for-microservices-architecture/