[[394227]]

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

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

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

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

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

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

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

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

1云上APM有什么不同?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

無(wú)論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)的性能和成本問(wèn)題。

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

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

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

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

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

1吵鬧的鄰居的影響

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

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

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

2嘈雜的鄰居和容器

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

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

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

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

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

3調(diào)低音量

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

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

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

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

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

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

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

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

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

需要一個(gè)合理合理的SLA來(lái)決定應(yīng)用程序的可用性，這一切都始于了解應(yīng)用的復(fù)雜性。例如，一個(gè)簡(jiǎn)單的靜態(tài)網(wǎng)站可以很容易地期望實(shí)現(xiàn)四個(gè)九或更多的正常運(yùn)行時(shí)間，因?yàn)楹苌儆袧撛诘墓收宵c(diǎn)。

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

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

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

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

參考文檔：

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/