對大規模容器進行監控所面臨的挑戰

1608919218 8年前發布 | 38K 次閱讀 Docker 運維技術

Docker在2013年三月實現了開源發布，它的出現讓軟件開發行業對于現代化應用的打包以及部署方式發生了巨大的變化。緊隨著Docker的發布，各種具有競爭性、致敬性以及支持性的容器技術紛紛涌現，為這一領域帶來了極大的關注度，同時也引起了人們的反思。這一系列文章將解答讀者的各種困惑，對如何在企業中實際使用容器進行分析。

這一系列文章首先將對容器背后的核心技術進行觀察，了解開發者目前如何使用容器，隨后將分析在企業中部署容器的核心挑戰，例如如何將容器技術與持續集成和持續交付管道進行集成，并對監控方式進行改進，以支持不斷變化的負載，以及使用短期容器的潛在需求。本系列文章的總結部分將對容器技術的未來進行分析，并探討無核化技術（unikernels）目前在處于技術前沿的組織中所扮演的角色。

本文是本系列文章“ 實際應用中的容器 —— 遠離炒作 ”中的其中一篇。你可以通過RSS訂閱該系列文章，以獲取更新的通知。

對容器技術的實施，以及因此產生的對創建微服務的渴望為應用監控這一領域帶來了一種范式上的轉換。應用程序的功能正在變得越來越細粒度，具有更好的獨立擴展能力以及彈性，而這對于傳統的監控方案提出了一個巨大的挑戰。如果微服務架構中的某個單一組件產生了故障，也不會對業務造成影響，因此，警告的嚴重性也應符合這一事實。傳統工具的監控方式是檢測某個組件處于“運行”狀態還是“故障”狀態，而這種方式已不符合我們的需求。正因如此，某些組織已經開始構建自主的監控系統。

容器具有短期性的特性，這也為監控工作帶來了新的挑戰，尤其是隨著一些調度與編排系統（例如 Kubernetes 、 Mesos 和 AWS ECS ）的流行度不斷提高而顯得愈加明顯。專家們在座談會上表示，現代化的監控方案應當能夠與這些平臺進行集成，并以容器視圖以及聚合服務視圖的方式展現數據。視圖的結合是唯一一種能夠有效地找到問題并加以解決的方法。

隨著在一個應用系統中所運行的服務，以及額外的底層基礎設施組件的數量的上升，系統生成了大量的數據。由于數據量是如此之大，讓監控工作成為了一種“大數據”方面的問題。因此，下一代監控工具必須能夠提供某種級別的人工智能功能，為所生成的數據提供可理解的見解，并最終提供相應的操作建議（包括不進行任何操作）。

InfoQ近期與幾位容器監控方面的專家進行了一次訪談，對監控的挑戰及其他內容進行了探討。所涉及的主題包括現代化監控系統的設計、為運維人員及系統管理員提供如何進行操作的見解的方法、以及監控工具的未來發展。

InfoQ：嗨，感謝各位今天能夠抽空接受InfoQ的采訪，能否請各位做一個簡單的自我介紹？

Chris Crane：嗨，感謝你的邀請！我名叫Chris Crane，是Sysdig的產品VP，這是一家提供容器原生可視化服務的公司。

Kevin McGuire：嗨，我名叫Kevin McGuire，是New Relic的首席產品經理與運維分析師。我負責設定運維以及基礎設施監控方面的策略。最近，我致力于開展云監控的產品與工程方面的工作，包括在Docker與Amazon EC2上開發及發布我們的監控解決方案的Beta版本。

Ilan Rabinovitch：很高興加入這次訪談！我名叫Ilan Rabinovitch，我是Datadog的技術社區主管及傳教士。在加入Datadog之前，我曾在Ooyala和Edmunds.com等大型web組織工作了很多年，負責領導基礎設施與可靠性工程團隊。

Alois Reitbauer：大家好，我名叫Alois Reitbauer，在Dynatrace和Ruxit擔任首席技術戰略師。我在職業生涯的大部分時間內都在從事與監控與性能有關的工作。我現在的主要工作方向是研究如何更好地對大規模環境進行監控，例如使用微服務、容器和IOT的環境，并研究如何讓人們更方便地與監控系統進行交互。

InfoQ：在你們看來，對容器的監控目前所面臨的最大挑戰是什么，能否為我們分享一下你們的想法？

Crane：容器以及基于容器技術的微服務的出現，讓軟件應用的開發與部署產生了一種范式變換。正如之前幾次新范式的出現一樣，我們看到了一個由各種支持性技術打造的生態系統正在冉冉升起，而這些支持性技術都是基于新的平臺完全重新打造的。包括安全性、網絡、存儲，當然還包括監控與可視化。

這種“全新的開始”的方式對于監控工作尤為重要，這就產生了容器可視化的核心挑戰：早期的監控工作是為了VM的應用而設計的，可將用于監控的agent部署在與應用的監控相同的地方。而這一方式已不適用于容器環境。

容器的核心原則要求他們必須保持輕量級、可再生，并且不受agent的影響。因此，如果監控方案真的打算做到對容器的原生支持，那么必須以一種可兼容每個容器的不可變性、可移植性以及可再生性的方造進行打造。如果你仍希望能夠從容器中獲得完整的應用可見性，那么實現這種方案是非常困難的，而這種可見性往往是監控的關鍵。

McGuire：隨著人們不斷深入探索微服務的益處，我們發現容器正在用于小型的、生存時間較短的工作。與此同時，容器也在用于大型的、運行時間較長的服務，這一點可視為對使用VM方式的優化。對于前一種情況來說，它需要以一種不同的方式對于容器進行監控，而這兩者的同時存在就意味著以一種單一的方式進行監控無法滿足這些完全不同的使用場景的需求。舉例來說，監控工具應當能夠提供應用程序的可見性以及每個容器的資源指標，同時還需要提供鏡像級別的資源占用的匯總情況，這更適合短期容器的狀況。

每個容器內都包含一個應用，但監控API往往專注于資源層面的信息。從host的角度來說，這是可以接受的。但最終，你總是需要能夠從容器內部以及跨容器這兩種角度來分析應用的性能。

最后，隨著容器越來越小，數量越來越多，要了解這些容器之間的相互依賴、維護大規模環境中的運維健康情況，并且進行根本原因的分析也變得很有挑戰性。

Rabinovitch：許多人在對容器監控時所遇到的最大挑戰是高頻率的變動，這就很難定義什么是“正常”情況，并對非正常情況發出警告。對于AWS、OpenStack和其他虛擬化解決方案來說，這個問題已經出現了很多年，但對于發展時間較短的容器技術來說，這一問題顯得尤為嚴重。

我在此可以為你分析一下這些系統的規模與變更頻率，我們近期對于 Docker的使用與實施情況進行了一些調查，發現大多數主機傾向于并行地運行4個容器，每個容器的生命周期都小于主機生命周期的1/4。這就意味著我們的監控工具不能再向以往一樣，將主機作為進行監控的主要單位了。

我們接下來又問了幾個問題：“Redis集群或是NGINX服務器目前運行在哪里？Kubernetes是否出于可用資源的原因將其遷移至另一個主機，還是說出現了故障情況？”

如果你的監控方式是以主機為中心的，那么你的世界看起來就像是托勒密天文學理論（即地心說）一樣復雜。如果你想將行星的移動與地球關聯起來，將很難推導出他們的移動規律。而如果你將太陽作為太陽系的中心，整個計算就變得簡單許多。這意味著你或許應當依賴于你的調度器的服務發現中的數據，以及容器相關標簽以定義各種查詢與監控問題。這樣一來，無論在系統的任一時刻，服務運行在哪個主機或端口上都不會影響分析的結果。

Reitbauer：以我們在大多數企業中的工作經驗來看，容器對于我們構建軟件的方式產生了一種實際的范式轉換，這也導致了大量挑戰的出現。而大規模化很顯然是其中的一種挑戰，實施了容器技術的公司在大多數情況下會同時選擇遷移至微服務架構。通常來說，當一體性應用被分解為服務時，所牽涉到的實體數量會大大提高。以我在Java開發方面的經驗來看，通常在微服務環境中所運行的JVM數量比之以往提高了10至20倍。這也意味著一個合理大小的系統卻需要這些工具管理“web規模”的系統。

我們所注意到的另一個變化就是對基于Mesos、Marathon或Kubernetes打造的編排層的應用。其結果就是應用程序架構具有極高的動態性，可迅速地進行向上或向下伸縮。對于這種動態性的理解是掌握系統的關鍵，而許多傳統的監控工具并沒有準備好應對這種需求。除了對這些環境的動態性的理解之外，還有大量的問題也浮出水面，例如如何在這些環境中進行日志的管理，以及基礎設施的監控工具應當扮演怎樣的角色，及采用怎樣的方式。

至于最關鍵的挑戰是什么，這取決于公司對于容器的應用達到了什么階段。動態的編排能力仍然是一個高端領域，人們還在逐步地探索這一領域。而與之相比，應對web規模的環境是一旦應用容器后立即就需要著手實施的。

InfoQ：Adrian Cockcroft曾經說過，監控系統比起受監控的系統要做到更好的可用性以及可伸縮性，這句話也經常被人引用。你認為，對于當前負責設計與實現基于容器的微服務應用的人來說，這一點是否切實可行？

Crane：Adrian Cockcroft的說法是正確的。如果你已經完成了新的面向微服務的應用，卻嘗試用一個一體性的舊式工具進行監控，它是無法勝任監控的需求的，這正是最糟糕的情形。在Sysdig公司，我們將這應對這種挑戰的解決方案稱做“監控即微服務”，它的思想是你的監控方案應當能夠和你的所有微服務一樣方便地進行部署以及擴展。你的監控方案必須盡可能做到自動化、自服務、以及自動復原，并且集成自動服務發現的概念。如果你的監控工具本身就是按照微服務原生、容器原生的架構打造的，那么它更有可能跟上你的需求。不過，如果你做不到這一點，那么很不幸，Adrian的想法就是非常不實際的。

McGuire：監控系統的高可用性是非常重要的。如今的DevOps實踐越來越依賴于通過監控系統對問題所發出的警告，因此監控系統就成了一道不可或缺的安全網。這也是為什么我們認為基于SaaS的監控方案是正確的選擇，因為同時運行及維護一個監控系統以及一個需要進行監控的系統使得某個問題在你未留意的情況下影響整個系統的可能性被放大了。

微服務增加了監控系統的規模以及復雜性，但它也提供了各種能夠增加可用性的實踐，例如將相同的容器部署在不同主機，或是在相同的主機中部署不同容器的能力，并提供了各種應用模式。

Rabinovitch：Adrian的說法可謂一針見血。你必須理解一點：負責檢測應用故障時間的系統必須保證在線及可用性。

但是，雖然這是一個明確的需求，但實現它要克服各種挑戰，這也是為什么我們認為SaaS方案是最佳的選擇。根據我們的調查來看，一個Linux主機平均會生成大約100個關鍵的操作系統級別的指標，而你的應用還會增加大約50個指標。隨著每個主機中所運行的容器數量的提高，這些指標的數量會快速地上升。

這就給我們出了一個難題，如何才能夠保存你的應用與基礎設施每天所生成的幾十億指標數據呢？在很多情況下，這個問題的回答與你的核心應用的基礎設施同樣復雜，甚至是更為復雜。現代化的監控系統本質上就是一種“大數據”問題，這也意味著你需要管理這些復雜的分布式數據的存儲，以及支持這些存儲系統的大型計算基礎設施。

Reitbauer：其實這已經不是什么新鮮的概念了。監控系統的主要目的就是當你的應用當機時向你發送通知，而這就要求這些系統基本上保持始終正常運行。為此，我們創建了一種全新的架構，以保證最大的在線時間。所有的組件都能夠支持實時的故障轉移，我們還創建了一個自動化管理層，以檢測有問題的組件，并自動替換這些組件。為了支持實時故障轉移，以及實時應對負載峰值，我們在集群中保留了三分之一的計算資源。

很顯然，這與基于單一服務器的傳統監控工具的概念是完全不同的。

InfoQ：監控系統如何為運維人員提供對系統的洞察力，而不是簡單的指標或數據？

Crane：監控系統的主要目的就是提供洞察力，不是嗎？我認為這里的關鍵在于為每個指標與數字提供適當的上下文。舉例來說，容器生態系統的一大發展趨勢就是采用各種調度、編排以及管理工具，例如Kubernetes、Mesos，以及Docker自主設計的Swarm等等。這些工具為你的底層容器提供了一層額外的抽象，他們真正地促進了向基于容器的微服務的遷移。

編排系統會使監控與可視化增加很大的復雜度。系統的最終表現不再是一個經過良好組織的VM或容器集群，而是一個具有高度可伸縮性、分布式、分散的容器集合，他們在一個共享的資源池中以混合方式存在。如果你的監控方案只是簡單地獲取這種環境中的指標，哪怕是基于容器的指標，這種方案也沒有很大的實用性。你的監控方案需要理解編排系統為容器產生的語義上下文。換句話說，你需要查看的是應用或微服務層面上的性能指標，甚至提供這些微服務的容器存在于多個不同的底層節點上。這就是洞察力的來源。

McGuire：從本質上說，這就是數據與信息的不同之處。僅有原始的指標數據是不夠的，需要為他們提供上下文加以解釋。因此，我們設計了一種展現客戶所需了解的信息的UI，專注于那些需要我們展開相應行動的數據。對于設計和實用性的專注可幫助我們忽略那些無意義的數據，讓運維人員快速地進行正確地判斷，并迅速地進行重要的決策。

Rabinovitch：一般來說，監控系統依賴于運維人員定義什么是“正常的”行為。由于現今的動態環境會受到自動擴展以及調度的基礎設施的影響而不斷產生變化，對這種正常行為的定義就成為了一種挑戰。目前為止，監控服務的社區在自動收集指標，并對于那些預定義的閥值發出警告這方面做得很好。我們現在需要的是專注于通過算法檢測那些有問題的部分或反常情況，并發出這方面的警告。

Reitbauer：讓我換一種方式描述這個問題，“監控工具如何為公司里每個需要某些信息的人提供洞察力”。DevOps與微服務的崛起產生了許多端到端的團隊，他們負責應用的整個生命周期，從開發直至監控階段。因此，每個人都必須了解這些監控數據。這也是為什么我們花費了大量時間以創建自解釋的信息圖表，讓每個人都能夠其中的意義。

另一個關鍵需求是對異常情況的檢測。由于系統的巨大規模，沒有任何人能夠做到手動查看所有數字。因此，監控系統必須了解什么是正常的行為，并當系統的行為出現異常時進行提示。

最后一個方面在于具備上下文的語義信息。舉例來說，監控系統需要“理解”指標所代表的意義，以及它與其他指標的關聯。我們需要了解整個應用中的所有依賴，將這此信息用于問題的分析。

InfoQ：基于容器的系統的未來將會怎樣發展（例如IaaS、PaaS、裸機還是VM等等），這對于監控會帶來怎樣的影響？

Crane：無論是在公有云、私有云或是數據中心環境中，在VM的基礎上部署容器的方式目前來說似乎是最流行的方式。不過在我看來，無論這個市場選擇哪種方式進行大規模實施，可以說每種方式都有適合它的大量用例。未來的發展結果或許會類似于這些年來混合云方式在企業中的逐漸發展，這種混合云是公有云、私有云、OpenStack、虛擬數據中心和裸機等方式的組合。我對此結果不會感到吃驚。對于監控來說，這就意味著你的可視化解決方案必須是與具體的技術棧無關的。誰都不希望在不同環境中來回切換，也沒有人希望只為了嘗試新的環境（還沒到開始遷移的過程）就必須切換不同的供應商。

McGuire：我認為容器與PaaS之間存在著某種共性，他們都能夠讓開發者從基礎設施的管理中解放出來，讓他們專注于能夠實際帶來價值的東西，即應用程序本身。這是他們的商業價值所在。

對于基礎設施的管理是需要投入成本的，你所能做的就是通過更高的效率與更好的可靠性進行成本優化。IaaS能夠為你減少一部分這樣的成本，因為你無需對物理基礎設施進行維護，但你仍然要對服務進行管理，以確保你以最優的方式進行使用，并及時地響應變更。監控在此處的作用就是為服務的使用情況提供深度的可視化情形，由于這與應用程序的性能密切相關，你可以根據其結果調整系統的效率、可靠性與可用性。在云計算環境中，缺少效率就意味著賬單上數字的增加。因此，成本即是最終的性能指標。

在理想的情況下，監控系統應當提供與你所要解決問題處于同一概念級別的可見性。當你的系統遷移至微服務架構時，“應用程序”的概念也變得模糊起來了。這就意味著你需要一些高層次的視圖，從中了解高于個別的容器這一層次的信息，從總體上觀察他們的表現。

我們未來將看到“計算即服務”這一概念的不斷發展，它超越了IaaS與PaaS的概念。Docker容器已經通過微服務涉及了這一領域，而AWSLambda已處于概念的發展前沿。最終的挑戰在于理解這一發展趨勢對于監控計算的意義。

Rabinovitch：變更的頻繁還將持續提高，包括來自調度器以和自動伸縮工具產生的變更，以及基于這些技術進行部署的速率的變更。這一趨勢將繼續驅動監控系統更好地與平臺和調度方案進行集成，使監控系統能夠在這些變更發生時以更自動化的方式進行響應。與之類似，我相信未來會看到這方面一些通用模式的產生，通過這些模式使監控系統直接將反饋信息發送至IaaS、PaaS以及調度方案中，使我們得以構建更自動化的響應，以及更緊湊的反饋循環。這將繼續驅使監控與警告系統提高他們的實時性。

Reitbauer：對基礎設施的關注已經開始減少。由于容器的使用，我們對于底層基礎設施的具體情況的關注度也在不斷減少。在很多場景中，同樣的應用可能會部分運行在IaaS、另一部分運行在裸機上，這只是其中一種可能的情況。這對監控工作的最大影響在于其專注點已經轉移至應用程序這一層面。由于故障節點會被自動替換，因此基礎設施的故障其嚴重性已經在逐漸降低。監控工具的主要關注點轉變化實際的服務與其質量，我所關心的是服務的響應時間以及故障率。老實說，如果你的監控工具主要的關注點是基礎設施，那么就無法有效地獲得運行基于容器的服務所必需的信息。

關于受訪者

Chris Crane 是Sysdig的產品VP，主要負責為容器以及微服務這一新型生態系統創建監控以及可視化工具。他對于創建能夠解決實際生活問題的強大技術充滿了熱情。在加入Sysdig之前，他曾在其他一些創業公司，例如Aardvark和Compass進行產品、市場和BD方面的工作，也曾在Bain&Co以及Bain Capital Ventures就職。而在很久很久之前，在一個遙遠的星系中，他曾是一個真正的web開發者。Chris在耶魯大學主修電機工程專業。

Kevin McGuire 是New Relic的首席產品經理與運維分析師，負責設定公司在運維以及基礎設施監控方面的策略。在這之前，他曾擔任New Relic基礎設施團隊的工程總監以及產品經理，負責服務器以及插件產品，該團隊最近發布了Docker監控工具，并率先對AWS的監控進行了重定義。

在加入New Relic之前，他曾在微軟擔任架構師與產品經理。除此之外，他也在IBM擔任各種技術與管理角色，曾是Eclipse項目的第一批開發者。

Ilan Rabinovitch 是Datadog的技術社區主管。在加入Datadog之前，他曾在Ooyala與Edmunds.com等公司就任多年，負責領導基礎設施與可靠性工程團隊。目前，除了在Datadog任職之外，他在開源與DevOps社區也相當活躍，擔任SCALE、Texas Linux Fest、DevOpsDay LA和DevOpsDays Silicon Valley的組織者之一。

Alois Reitbaue 在Dynatrace擔任首席技術戰略師以及創新實驗室的主管。他在職業生涯的大部分時間內的工作是創建監控工具，并對應用程序的影響進行微調。他經常在技術會議上進行演講，也是一位博客作者和作家，同時也是壽司的狂熱愛好者。Alois目前主要在林茨（奧地利）、波士頓和舊金山開展專業工作。