本文是Sysdig公司產(chǎn)品團(tuán)隊(duì)成員之一的Apurva Dave寫的一篇客座文章,。

我們已經(jīng)與數(shù)百名客戶合作，為他們的環(huán)境構(gòu)建了監(jiān)控棧,，所以我們已經(jīng)了解什么是可行的,，什么是不可行的。這些合作的結(jié)果可能會讓你大吃一驚,，比如我們發(fā)現(xiàn)在監(jiān)控的時(shí)候,，儀器和應(yīng)用程序其實(shí)是一樣重要的。

本文將介紹如何建立一個(gè)橫向擴(kuò)展,、高度可靠的監(jiān)控系統(tǒng)來處理數(shù)萬個(gè)容器所需要的細(xì)節(jié),，并且還將分享一下基礎(chǔ)架構(gòu)，設(shè)計(jì)選擇和權(quán)衡,。我將介紹的五個(gè)方面如下：

1. 系統(tǒng)測量,；

2. 將數(shù)據(jù)與應(yīng)用程序，主機(jī)和容器相關(guān)聯(lián),；

3. 利用協(xié)調(diào)器；

4. 決定要存儲的數(shù)據(jù),；

5. 如何在集裝箱化環(huán)境中啟用故障排除,；

首先你得了解，Sysdig是一家做容器監(jiān)控的公司,。開源項(xiàng)目允許您看到單個(gè)主機(jī)上的每個(gè)系統(tǒng)調(diào)用過程,、參數(shù)、有效負(fù)載和連接,。 商業(yè)產(chǎn)品將所有這些數(shù)據(jù)轉(zhuǎn)化為數(shù)千個(gè)指標(biāo),，為每個(gè)容器和主機(jī)提供數(shù)據(jù)，并匯總所有數(shù)據(jù),，并為您提供儀表板,，報(bào)警和類似htop的環(huán)境。

我們從容器對監(jiān)控系統(tǒng)的影響開始,，深入了解一些細(xì)節(jié),。

容器的功能非常強(qiáng)大，特點(diǎn)如下：

1. 簡單性：典型的單個(gè)進(jìn)程,；

2. 體積?。后w積是VM大小的1/10，表示它們是便攜式的,；

3. 無依賴性：組件之間無依賴性,；

4. 動態(tài)性：快速的啟動時(shí)間,；

保持容器的簡單性是其價(jià)值主張的核心，也是微服務(wù)的重要構(gòu)建塊,。但是這種簡單性是有代價(jià)的,。從ops的角度來看，您需要在容器內(nèi)進(jìn)行深入的可視性,，而不僅僅是知道某些容器存在,。

您的容器也很可能由一個(gè)編配系統(tǒng)管理(想想Kubernetes或swarm)，如果您正在運(yùn)行PaaS,，那么您的開發(fā)人員可能會在任何時(shí)候推動新的應(yīng)用程序,，而不通知平臺團(tuán)隊(duì)。

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

在靜態(tài)或虛擬環(huán)境中,，讓代理在主機(jī)上運(yùn)行很簡單,，并根據(jù)相關(guān)應(yīng)用程序配置代理。 然而,，在集裝箱化的環(huán)境中,，這種方法并不起作用：

1. 不能將代理放在每個(gè)容器中（不破壞容器的鍵值）；

2. 隨著應(yīng)用程序的出現(xiàn)和運(yùn)行,，開發(fā)者不能手動配置代理插件來收集相關(guān)的應(yīng)用級別指標(biāo),；

所以我們試圖使儀器的功能必須盡可能透明，盡可能少的人為干預(yù),。 基礎(chǔ)設(shè)施指標(biāo),，應(yīng)用指標(biāo)，服務(wù)響應(yīng)時(shí)間,，自定義指標(biāo)和資源/網(wǎng)絡(luò)利用率應(yīng)該在容器內(nèi)不需要任何消耗的情況下就可以完成,。 它當(dāng)然不應(yīng)該要求每個(gè)附加容器的自旋向上。

實(shí)現(xiàn)這一目標(biāo)有兩種可能方法,。首先是pods,，這是Kubernetes創(chuàng)造的一個(gè)概念。pod是一組共享公共名稱空間的容器,。因此,，一個(gè)容器內(nèi)的容器可以看到相同容器中的其他容器正在做什么,。對于監(jiān)視代理，這通常被稱為“sidecar”容器,。

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

第二種模式是每個(gè)主機(jī),，透明的儀器,。 這個(gè)透明的儀器利用單個(gè)測試點(diǎn)捕獲所有應(yīng)用程序，容器,，統(tǒng)計(jì)信息和主機(jī)指標(biāo),，利用內(nèi)核中的跟蹤點(diǎn)設(shè)備，并將其發(fā)送到每個(gè)主機(jī)的容器進(jìn)行處理和傳輸,。 這消除了將所有內(nèi)容變成統(tǒng)計(jì)數(shù)據(jù)的需求,，這是我們看到許多人所追求的。 與sidecar模型不同,，每個(gè)主機(jī)代理極大地減少了監(jiān)視代理的資源消耗，并且不需要修改應(yīng)用程序代碼,。但是,，它確實(shí)需要一個(gè)特權(quán)容器和一個(gè)內(nèi)核模塊。

ContainerVision是讓Sysdig如此不同的一個(gè)重要因素,，所以讓我們花點(diǎn)時(shí)間去了解一下它是怎么運(yùn)行的吧,。這一部分我將重點(diǎn)講一下開源項(xiàng)目是如何運(yùn)作的。你們中的大多數(shù)人可能會成為第一批使用這個(gè)版本的,，所以讀完這篇文章以后,，你應(yīng)該會有更深刻的理解。

Sysdig的架構(gòu)和libpcap/tcpdump/wireshark非常相似（這不是巧合,，因?yàn)镾ysdig是由wireshark的共同創(chuàng)建者之一創(chuàng)建的）,。首先是由sysdig-probe這么一個(gè)小型驅(qū)動器在內(nèi)核中去捕獲事件，它使用的內(nèi)核工具是tracepoints,。tracepoints使得可以安裝從內(nèi)核中的特定功能調(diào)用的“處理程序”,。 目前,，sysdig注冊進(jìn)入和退出的系統(tǒng)調(diào)用的跟蹤點(diǎn)以及進(jìn)程調(diào)度事件。 Sysdig-probe對這些事件的處理程序是非常簡單的 - 它僅限于將事件詳細(xì)信息復(fù)制到共享緩沖區(qū)中,，以供以后使用,。 保持處理程序簡單的原因可以想像，是性能,，因?yàn)樵嫉膬?nèi)核執(zhí)行被“凍結(jié)”,，直到處理程序返回。,。

驅(qū)動器就是負(fù)責(zé)做這些事的,，其它的不可思議的事情是發(fā)生在User層。

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

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

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

開源故障排除工具既為用戶提供了命令行界面,，也提供了針對單個(gè)主機(jī)基于curses的所有數(shù)據(jù)(如下所見)的接口。

對于我們的監(jiān)控產(chǎn)品,，我們使用同樣的系統(tǒng)進(jìn)行調(diào)用,，進(jìn)而從堆棧中提取相關(guān)的指標(biāo)，并在分布式環(huán)境中創(chuàng)建一個(gè)類似htop的界面,。

然而我們相信,，如果處理容器的話，僅僅靠衡量標(biāo)準(zhǔn)就不夠了,。 因此讓我們談一談這一切的意義,。

隨著環(huán)境復(fù)雜性的增加,，基于元數(shù)據(jù)過濾、分段和分組度量的能力是至關(guān)重要的,。標(biāo)記可以幫助用戶展示出應(yīng)用程序體系結(jié)構(gòu)的邏輯藍(lán)圖,，但是不包括容器運(yùn)行的物理現(xiàn)實(shí)。例如,，您可以通過dev/prod,、service、pod或其它的來進(jìn)行劃分,。

您應(yīng)該能夠動態(tài)地選擇或在指標(biāo)上進(jìn)行標(biāo)記——以層次結(jié)構(gòu)命名的,、點(diǎn)分隔的指標(biāo)名稱和預(yù)定義的聚合正在逐漸消失。動態(tài)選擇使您能夠快速回答有關(guān)服務(wù)性能的問題,，或者深入到名稱空間甚至容器中,。

可以想到有兩種方式可以用來標(biāo)記指標(biāo)：顯式標(biāo)簽（要存儲的屬性）vs隱式標(biāo)簽（協(xié)調(diào)器）,。您應(yīng)該有機(jī)制和最佳做法來添加明確的標(biāo)簽,，以便團(tuán)隊(duì)中的任何人都可以根據(jù)各自的需求進(jìn)行添加。但是默認(rèn)情況下應(yīng)該捕獲隱式標(biāo)記,。后面的一點(diǎn)非常重要,，因?yàn)樗窍乱粋€(gè)觀點(diǎn)的重要組成部分。 隨著產(chǎn)品的發(fā)展，我們發(fā)現(xiàn)發(fā)現(xiàn)默認(rèn)情況下,，通常會添加12-25個(gè)標(biāo)簽,。 有的用戶可能會用更多。 將每個(gè)獨(dú)特的標(biāo)簽組合視為一個(gè)單獨(dú)的指標(biāo),，您需要根據(jù)需要對用戶進(jìn)行存儲,，處理和調(diào)用。 這有一些相當(dāng)重大的影響,，我們在下面的“決定要存儲的內(nèi)容”中討論,。

從根本上改變了容器的調(diào)度管理方法，并在此過程中影響了用戶的監(jiān)視策略,。無論是Kubernetes,、Swarm還是Mesos，您都將看到與監(jiān)視方法類似的變化,。單個(gè)容器變得不那么重要,，而服務(wù)的性能變得更重要。該服務(wù)由許多容器組成,，更重要的是,，協(xié)調(diào)器可以根據(jù)需要移動這些容器，以滿足性能和健康需求,。具體來說,，對于監(jiān)控系統(tǒng)有兩個(gè)含義:

監(jiān)控系統(tǒng)必須根據(jù)協(xié)調(diào)器的元數(shù)據(jù)，隱式地標(biāo)記所有指標(biāo),。這適用于系統(tǒng)度量,、容器度量、應(yīng)用程序組件度量,，甚至是定制的度量,。

自定義度量需要重復(fù):您的開發(fā)人員應(yīng)該能夠簡單地輸出定制的度量，而監(jiān)視系統(tǒng)應(yīng)該保持狀態(tài),，關(guān)于度量來自何處,。如果您依賴于“最佳實(shí)踐”來進(jìn)行標(biāo)記，那么當(dāng)您真正需要解決問題的時(shí)候,，您的度量標(biāo)準(zhǔn)將是無用的,。更多關(guān)于這個(gè)話題。

名義上有兩種方法:依賴于協(xié)調(diào)器發(fā)出的事件來標(biāo)記容器,，或者根據(jù)容器的試探來確定應(yīng)用程序,。后者在你的監(jiān)控系統(tǒng)中需要更多的智能，但會產(chǎn)生更可靠的結(jié)果,。這是因?yàn)槟南到y(tǒng)調(diào)用不會說謊—您可以輕松地將它們與運(yùn)行中的應(yīng)用程序聯(lián)系起來,。考慮到我們的儀表，你可以猜測Sysdig選擇了后一種方法,。

要了解更多關(guān)于Kubernetes和Kubernetes的信息,，請點(diǎn)擊“監(jiān)視Kubernetes:詳細(xì)的指南”

另一種說法就是“收集所有的數(shù)據(jù)”，是所有的數(shù)據(jù),，沒有過濾過的,，沒經(jīng)過任何處理的。

你得承認(rèn)這樣一個(gè)事實(shí),，那就是隨著你的系統(tǒng)變得越來越復(fù)雜,，軟件變得越來越分布式，需要收集的數(shù)據(jù)也越來越多,。標(biāo)記就是最好的例子：它們的數(shù)量是那些必須要存儲的指標(biāo)的數(shù)倍,。

當(dāng)然，如果僅僅只存儲節(jié)點(diǎn)應(yīng)用程序Kubernetes部署的平均值/最小值/最大值/ 95th百分位這些,，指標(biāo)的數(shù)量應(yīng)該也會降下來,。它能很明顯地減少指標(biāo)收集，存儲和計(jì)算,。

但是隨著基礎(chǔ)的內(nèi)容越來越復(fù)雜,，存儲所有數(shù)據(jù)的重要性也就越來越高，并以一種允許進(jìn)行臨時(shí)分析和故障排除的方式進(jìn)行存儲,。例如,，如果在之前提到的那個(gè)節(jié)點(diǎn)應(yīng)用程序中有間歇性緩慢的響應(yīng)時(shí)間，該怎么辦呢?你怎么知道這是代碼中的系統(tǒng)性問題,，或是frtiz的容器問題,，還是AWS的問題?通過部署來聚合所有這些信息，將不會給您足夠的解決方案,。

當(dāng)然,，這種方法產(chǎn)生的問題并不令人驚訝:您需要收集大量的數(shù)據(jù)。還需要收集指標(biāo)和事件,。你必須堅(jiān)持,，使用戶可以隨時(shí)訪問。在這里,，我們也做了一些重大的設(shè)計(jì)決策:

我們認(rèn)為,，在每個(gè)服務(wù)或每個(gè)應(yīng)用程序環(huán)境中部署較小的、隔離的后端是不合理的,。

對我們來說,，這似乎不是一種可管理的方法來運(yùn)行(在云環(huán)境中)，或者讓客戶管理(在我們的軟件的內(nèi)部部署中),。如果您想知道為什么這是一個(gè)需要考慮的問題,，那么您將看到像普羅米修斯這樣的開源項(xiàng)目實(shí)際上是默認(rèn)的后端模型，因此通過迫使更多的管理工作向用戶提供更多的管理工作,，從而引發(fā)了對可伸縮性的關(guān)注,。相反，我們希望構(gòu)建一個(gè)水平可伸縮的后端,，我們的應(yīng)用程序可以根據(jù)用戶或服務(wù)來隔離數(shù)據(jù),、指示板、警報(bào)等,。

為了提供沒有時(shí)間限制的保留,，我們決定在一段時(shí)間內(nèi)滾動數(shù)據(jù)。我們將完整的解析數(shù)據(jù)存儲6個(gè)小時(shí),，然后在此之后開始聚合數(shù)據(jù),。(我們還有一個(gè)解決方案，可以在警報(bào)的周圍存儲完整的分辨率數(shù)據(jù),。請參閱下一節(jié),。)

雖然我們的后端繼續(xù)發(fā)展，但今天它由水平可伸縮的Cassandra(指標(biāo)),、彈性搜索(事件)和Redis(服務(wù)代理)組成,。基于這些組件的構(gòu)建提供了很高的可靠性和規(guī)模,，可以存儲多年的數(shù)據(jù)來進(jìn)行長期趨勢分析和分析,。所有數(shù)據(jù)都可以通過REST API訪問。整個(gè)后端可以通過sys挖苦的云服務(wù)來使用,，也可以在私有云中部署,，以獲得更大的安全性和隔離性。該設(shè)計(jì)允許您避免運(yùn)行一個(gè)系統(tǒng)來監(jiān)視和另一個(gè)系統(tǒng)進(jìn)行長期分析或數(shù)據(jù)保留,。

容器設(shè)計(jì)時(shí)都是小巧輕便的,。 這對于可部署性和可重復(fù)性都是非常好的，但也會影響您對容器進(jìn)行故障排除的方式,。

還記得你的老朋友ssh,、top、ps,、ifconfig等嗎?你可能不會把它們放在你的容器里,。如果您在一個(gè)受控的PaaS環(huán)境中運(yùn)行，即使這些工具是可用的,，您也可能無法訪問它,，并且……我們提到的容器有的可能已經(jīng)不存在了?如果協(xié)調(diào)器正在執(zhí)行它的工作，那么在您進(jìn)行故障排除之前,，這個(gè)容器可能已經(jīng)很久了,。

簡而言之,，獲取所需要的信息將會變得很復(fù)雜。除此之外,，從協(xié)調(diào)器中獲得適當(dāng)?shù)纳舷挛氖侵陵P(guān)重要的,。因此，讓開發(fā)人員能夠獲得這些深入的信息是非常必要的,，理想情況下不會破壞生產(chǎn)環(huán)境,。必須解決這個(gè)問題，因?yàn)槲覀冋J(rèn)為簡化故障排除和對容器工作負(fù)載進(jìn)行監(jiān)控一樣重要,。

這就是開源Sysdig的容器故障排除工具,。 它捕獲主機(jī)上的每個(gè)單一系統(tǒng)調(diào)用的能力可以深入了解應(yīng)用程序，容器,，主機(jī)和網(wǎng)絡(luò)的運(yùn)行情況,。

能夠與業(yè)務(wù)流程管理對接，也就意味著它可以收集相關(guān)的元數(shù)據(jù),，以便您可以捕獲分布式系統(tǒng)的上下文和狀態(tài),，而不僅僅是單個(gè)機(jī)器的狀態(tài)。 最后,，Sysdig將所有內(nèi)容全部捕獲到文件中的功能意味著您可以從prod捕獲數(shù)據(jù),，但可以在筆記本電腦上進(jìn)行故障排除。 你可以在容器不在的時(shí)候做很久,，當(dāng)你的處境并不是非常緊急的時(shí)候,，你可以做一個(gè)正確的事后分析。

例如,，由于您在特定容器上看到大量的網(wǎng)絡(luò)連接而收到警報(bào),， 我們的監(jiān)控服務(wù)中的警報(bào)可以觸發(fā)捕獲，在該主機(jī)上記錄所有系統(tǒng)調(diào)用一段時(shí)間,。 探索在cSysdig中,，您可以獲取正確的容器上下文，然后深入其網(wǎng)絡(luò)連接：

要了解開源sysdig可以做什么,，請查看Kubernetes DNS服務(wù)的工作原理（https:///blog/understanding-how-kubernetes-services-dns-work/）,。

構(gòu)建一套高度可伸縮的分布式監(jiān)控系統(tǒng)并不是一件容易的事情。不管你是選擇自己做還是利用別人的系統(tǒng),，我相信您將不得不做出許多與我們一樣的選擇,。

總的來說：

1. 如何測量系統(tǒng)?

2. 如何與協(xié)調(diào)器對接？

3. 如何簡化數(shù)據(jù)與自定義指標(biāo),？

4. 決定保留什么,？

5. 是否能夠在動態(tài)的、短暫的環(huán)境中進(jìn)行故障排除,？

希望這篇文章對你有用,。它討論了構(gòu)建一個(gè)集裝箱監(jiān)控系統(tǒng)的過程中會遇到哪些問題,。當(dāng)然，光說不練假把式,，所以如果你想讓用Docker容器監(jiān)控試用版（https:///docker-monitoring/） ,，你自己可以看看這些設(shè)計(jì)決策是如何發(fā)揮作用的。