[[394227]]

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

為了制定最佳戰略，企業需要首先確定其優先事項。優先級可防止IT團隊被監控用戶行為、資源可用性、延遲、響應時間等的應用性能數據流淹沒。

除了討論如何思考監控指標外，本文還討論關于云應用管理主題的實際建議。例如，多租戶云環境的嘈雜鄰邦效應是持續存在的憂慮，尤其是在應用性能方面。

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

一云上應用監控重要指標

錯誤率、計算成本、每分鐘請求數，云應用監控策略中有許多指標需要查看，應該優先考慮哪些?

二十多年來，IT團隊一直在部署應用程序性能管理工具，以監控和管理本地應用和基礎設施。但是，當組織遷移到云時，這些APM策略需要適應。

云APM要求組織跟蹤比本地APM更多的指標。在處理基于云的環境時，收集和分析指標數據還需要權衡其他因素。

1云上APM有什么不同?

乍一看，就應用監控而言，云環境和本地環境似乎并沒有根本不同。云應用程序仍然在服務器上運行，并且以類似于本地應用的方式處理事務。

可以在云中使用某些監控方法。例如，RED方法強調收集與交易速率、錯誤和持續時間相關的指標。

什么是RED方法?RED 方法定義了在架構中應衡量的每個微服務的三個關鍵指標。這些指標是：Rate：請求的數量，每秒，你的服務正在服務。Errors：每秒失敗請求的數量。Duration：分配每個請求所需的時間。

然而，云環境帶來了額外的挑戰。在規劃要監控哪些指標時，需要考慮以下因素：

· 分布式架構：云環境更有可能包括數十臺甚至數百臺單個服務器，其應用程序分布在它們之間。這使得不僅監控單個服務器，而且監控整個群集更為重要。云中最重要的是群集的健康狀況，而不是云中的每個服務器。

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

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

· 延遲：實現低延遲應該是任何類型的應用的目標。但是，在處理基于云的應用時，延遲可能會帶來更大的挑戰。如果云可用區遠離用戶，則延遲問題的風險較高。

· 負載平衡：雖然有時可能會為本地應用程序使用負載平衡器，但在云中使用它來引導應用程序多個實例之間的流量更為常見。這為網絡和流量監控增加了另一層復雜性。

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

所有這些差異都會影響團隊監控和管理云中應用所需的方法。

2要跟蹤的關鍵云指標

對于幾乎任何類型的云環境，需要跟蹤以下類型的指標：

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

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

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

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

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

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

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

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

3需要考慮的其他云指標

根據應用部署和管理方式，可能還需要考慮以下類型的指標，以幫助監控云應用程序并優化最終用戶體驗：

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

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

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

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

無論APM工具中攝入什么特定的云指標，重點應該是收集有助于了解復雜分布式云環境狀態的信息。

還應努力關聯不同類型的數據，并比較不同云和服務的數據。這樣，可以全面了解云中可能出現的性能和成本問題。

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

二多租戶環境是否仍會創建嘈雜的鄰居?

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

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

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

1吵鬧的鄰居的影響

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

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

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

2嘈雜的鄰居和容器

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

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

例如，雖然對多租戶環境的傳統關注集中在壟斷帶寬或 CPU 周期的實體上，但容器的廣泛采用可能會改變這些擔憂。

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

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

3調低音量

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

如果是公司內部網使用的應用，用戶可能并不擔心性能略有變化。但是，如果它是一個電子商務網站，這些變化可能是一個大問題，將支持使用專用或獨立的機器的論點。

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

如果發現有問題，建議與您的云提供商合作，了解訪問不同類型的專用基礎設施需要什么，在那里不必擔心云中任何潛在的嘈雜鄰居。較小的公司，甚至網絡托管公司，有時提供專用的基礎設施，公有云廠商也提供裸金屬服務。

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

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

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

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

主要的云提供商可以滿足這些協議中相對較高的標準，盡管涉及復雜性，這要歸功于大量才華橫溢的工程師和數十年的既定流程。

需要一個合理合理的SLA來決定應用程序的可用性，這一切都始于了解應用的復雜性。例如，一個簡單的靜態網站可以很容易地期望實現四個九或更多的正常運行時間，因為很少有潛在的故障點。

現在，考慮一個更復雜、更單一的 Web 應用程序。雖然四個九可能仍然是可能的，但實現它的壓力會隨著向組合添加組件(如數據庫和緩存服務器或對象存儲)而增加。將應用分解為微服務，潛在故障點的數量也會增加。

隨著應用程序復雜性的增加，在可用性指標中丟失 9 的風險也會增加。雖然你總是可以拋出更多的冗余的問題，你也會增加你的成本，并創造復雜的工程挑戰。畢竟，保持數據庫的多個副本同步并不是一個微不足道的問題。

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

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

參考文檔：

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/