從監控容器和業務流程上學會的五件事

譯者註：作者是Sysdig公司的成員之一，本文講述了作者從開發監控容器過程中所遇到的一些問題及其決策，還有相關經驗的分享。以下為譯文

本文是Sysdig公司產品團隊成員之一的Apurva Dave寫的一篇客座文章。

我們已經與數百名客戶合作，為他們的環境構建了監控棧，所以我們已經了解什麼是可行的，什麼是不可行的。這些合作的結果可能會讓你大吃一驚，比如我們發現在監控的時候，儀器和應用程序其實是一樣重要的。

本文將介紹如何建立一個橫向擴展、高度可靠的監控系統來處理數萬個容器所需要的細節，並且還將分享一下基礎架構，設計選擇和權衡。我將介紹的五個方面如下：

系統測量；

將數據與應用程序，主機和容器相關聯；

利用協調器；

決定要存儲的數據；

如何在集裝箱化環境中啟用故障排除；

首先你得了解，Sysdig是一家做容器監控的公司。開源項目允許您看到單個主機上的每個系統調用過程、參數、有效負載和連接。 商業產品將所有這些數據轉化為數千個指標，為每個容器和主機提供數據，並匯總所有數據，並為您提供儀錶板，報警和類似htop的環境。

我們從容器對監控系統的影響開始，深入了解一些細節。

為什麼說容器改變了監控的規則

容器的功能非常強大，特點如下：

簡單性：典型的單個進程；

體積小：體積是VM大小的1/10，表示它們是攜帶型的；

無依賴性：組件之間無依賴性；

動態性：快速的啟動時間；

保持容器的簡單性是其價值主張的核心，也是微服務的重要構建塊。但是這種簡單性是有代價的。從ops的角度來看，您需要在容器內進行深入的可視性，而不僅僅是知道某些容器存在。

您的容器也很可能由一個編配系統管理(想想Kubernetes或swarm)，如果您正在運行PaaS，那麼您的開發人員可能會在任何時候推動新的應用程序，而不通知平台團隊。

好了，現在我們知道正在處理這些小的黑盒子，它們出現，死亡，並且被你的編配系統的突發奇想所感動。您的開發人員可以自由地添加和修改他們的應用程序。你的工作是確保公司的應用程序運行正常，更不要說有數據來解決問題。讓我們開始打破監控的挑戰。

儀器需要透明

在靜態或虛擬環境中，讓代理在主機上運行很簡單，並根據相關應用程序配置代理。 然而，在集裝箱化的環境中，這種方法並不起作用：

不能將代理放在每個容器中（不破壞容器的鍵值）；

隨著應用程序的出現和運行，開發者不能手動配置代理插件來收集相關的應用級別指標；

所以我們試圖使儀器的功能必須儘可能透明，儘可能少的人為干預。 基礎設施指標，應用指標，服務響應時間，自定義指標和資源/網路利用率應該在容器內不需要任何消耗的情況下就可以完成。 它當然不應該要求每個附加容器的自旋向上。

實現這一目標有兩種可能方法。首先是pods，這是Kubernetes創造的一個概念。pod是一組共享公共名稱空間的容器。因此，一個容器內的容器可以看到相同容器中的其他容器正在做什麼。對於監視代理，這通常被稱為「sidecar」容器。

好處之一是在Kubernetes中，這是相對容易的事情。然而，缺點是:如果機器上有很多的pods，資源消耗就會很高——這有點像每個進程都有一個監控代理，而且您還創建了依賴項，以及在這個pod中附加的攻擊表面。這意味著，如果您的監視sidecar具有性能、穩定性或安全性問題，它就會對您的應用程序造成嚴重破壞。

第二種模式是每個主機，透明的儀器。 這個透明的儀器利用單個測試點捕獲所有應用程序，容器，統計信息和主機指標，利用內核中的跟蹤點設備，並將其發送到每個主機的容器進行處理和傳輸。 這消除了將所有內容變成統計數據的需求，這是我們看到許多人所追求的。 與sidecar模型不同，每個主機代理極大地減少了監視代理的資源消耗，並且不需要修改應用程序代碼。但是，它確實需要一個特權容器和一個內核模塊。

核心設備是如何運作的

ContainerVision是讓Sysdig如此不同的一個重要因素，所以讓我們花點時間去了解一下它是怎麼運行的吧。這一部分我將重點講一下開源項目是如何運作的。你們中的大多數人可能會成為第一批使用這個版本的，所以讀完這篇文章以後，你應該會有更深刻的理解。

Sysdig的架構和libpcap/tcpdump/wireshark非常相似（這不是巧合，因為Sysdig是由wireshark的共同創建者之一創建的）。首先是由sysdig-probe這麼一個小型驅動器在內核中去捕獲事件，它使用的內核工具是tracepoints。tracepoints使得可以安裝從內核中的特定功能調用的「處理程序」。 目前，sysdig註冊進入和退出的系統調用的跟蹤點以及進程調度事件。 Sysdig-probe對這些事件的處理程序是非常簡單的 - 它僅限於將事件詳細信息複製到共享緩衝區中，以供以後使用。 保持處理程序簡單的原因可以想像，是性能，因為原始的內核執行被「凍結」，直到處理程序返回。。

驅動器就是負責做這些事的，其它的不可思議的事情是發生在User層。

Event Buffer被內存映射到用戶空間，這樣就不需要任何副本即可進行訪問，從而最大限度地減少CPU使用率和緩存。libscap和libsinsp這兩個lib提供了讀取、解碼和解析事件的支持。具體來說，libscap提供了跟蹤文件管理功能，而libsinsp包含複雜的狀態跟蹤功能(例如，您可以使用文件名而不是FD號)，還可以過濾事件解碼，Lua JIT編譯器來運行chisels等等。最後，sysdig把它作為一個簡單的包裝器放在這些庫中。

但是，如果sysdig，libsinsp或libscap不夠快，無法跟上來自內核的事件流呢？sysdig會像strace那樣導致系統變慢嗎（聰明的讀者會問）？當然不可能。在這種情況下，事件緩衝區會被填滿，sysdig-probe開始遺漏傳入的事件。 所以你會丟失一些跟蹤信息，但機器和運行的其他進程不會減慢。

這是如果sysdig架構的關鍵優勢，因為這不僅意味著可以預測跟蹤的開銷，還意味著在生產環境中運行，情況也會比較樂觀，而且chisels不需要像DTraces的D腳本那樣經過仔細的優化。除此之外，chisels還可以利用為Lua編寫lib(想要將chisels的數據傳遞到Redis？用這個lib就可以做到！)。想在這個問題上稍微深入一點，可以閱讀DTrace vs strace vs sysdig: A technical discussion。

開源故障排除工具既為用戶提供了命令行界面，也提供了針對單個主機基於curses的所有數據(如下所見)的介面。

對於我們的監控產品，我們使用同樣的系統進行調用，進而從堆棧中提取相關的指標，並在分布式環境中創建一個類似htop的界面。

然而我們相信，如果處理容器的話，僅僅靠衡量標準就不夠了。 因此讓我們談一談這一切的意義。

如何將數據關聯到應用，主機，容器和Orchestrators

隨著環境複雜性的增加，基於元數據過濾、分段和分組度量的能力是至關重要的。標記可以幫助用戶展示出應用程序體系結構的邏輯藍圖，但是不包括容器運行的物理現實。例如，您可以通過dev/prod、service、pod或其它的來進行劃分。

您應該能夠動態地選擇或在指標上進行標記——以層次結構命名的、點分隔的指標名稱和預定義的聚合正在逐漸消失。動態選擇使您能夠快速回答有關服務性能的問題，或者深入到名稱空間甚至容器中。

可以想到有兩種方式可以用來標記指標：顯式標籤（要存儲的屬性）vs隱式標籤（協調器）。您應該有機制和最佳做法來添加明確的標籤，以便團隊中的任何人都可以根據各自的需求進行添加。但是默認情況下應該捕獲隱式標記。後面的一點非常重要，因為它是下一個觀點的重要組成部分。 隨著產品的發展，我們發現發現默認情況下，通常會添加12-25個標籤。 有的用戶可能會用更多。 將每個獨特的標籤組合視為一個單獨的指標，您需要根據需要對用戶進行存儲，處理和調用。 這有一些相當重大的影響，我們在下面的「決定要存儲的內容」中討論。

Leveraging Orchestrators

從根本上改變了容器的調度管理方法，並在此過程中影響了用戶的監視策略。無論是Kubernetes、Swarm還是Mesos，您都將看到與監視方法類似的變化。單個容器變得不那麼重要，而服務的性能變得更重要。該服務由許多容器組成，更重要的是，協調器可以根據需要移動這些容器，以滿足性能和健康需求。具體來說，對於監控系統有兩個含義:

監控系統必須根據協調器的元數據，隱式地標記所有指標。這適用於系統度量、容器度量、應用程序組件度量，甚至是定製的度量。

自定義度量需要重複:您的開發人員應該能夠簡單地輸出定製的度量，而監視系統應該保持狀態，關於度量來自何處。如果您依賴於「最佳實踐」來進行標記，那麼當您真正需要解決問題的時候，您的度量標準將是無用的。更多關於這個話題。

名義上有兩種方法:依賴於協調器發出的事件來標記容器，或者根據容器的試探來確定應用程序。後者在你的監控系統中需要更多的智能，但會產生更可靠的結果。這是因為您的系統調用不會說謊—您可以輕鬆地將它們與運行中的應用程序聯繫起來。考慮到我們的儀錶，你可以猜測Sysdig選擇了後一種方法。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！