摘要：監(jiān)控告警是運(yùn)營(yíng)系統(tǒng)最核心的功能之一，騰訊內(nèi)部有一套很成熟的監(jiān)控告警平臺(tái)，而且開(kāi)發(fā)運(yùn)維同學(xué)已經(jīng)習(xí)慣這套平臺(tái)，如果我們針對(duì)容器再開(kāi)發(fā)一個(gè)監(jiān)控告警平臺(tái)，會(huì)花費(fèi)很多精力，而且沒(méi)有太大的意義。也是一款付費(fèi)監(jiān)控解決方案，計(jì)劃收費(fèi)方案是美分小時(shí)。

如今，越來(lái)越多的公司開(kāi)始使用 Docker 了，現(xiàn)在來(lái)給大家看幾組數(shù)據(jù)：

2 / 3 的公司在嘗試了 Docker 后最終使用了它

也就是說(shuō) Docker 的轉(zhuǎn)化率達(dá)到了 67%，而轉(zhuǎn)化市場(chǎng)也控制在 60 天內(nèi)。

越大型的公司越早開(kāi)始使用 Docker

研究發(fā)現(xiàn)主機(jī)數(shù)量越多的公司，越早開(kāi)始使用 Docker。而主機(jī)數(shù)量多，在這個(gè)研究里就默認(rèn)等同于是大型公司了。

那為什么 Docker 越來(lái)越火呢？一談起 Docker 總是會(huì)跟著讓人聯(lián)想到輕量這個(gè)詞，甚至?xí)幸环N通過(guò) Docker 啟動(dòng)一個(gè)服務(wù)會(huì)節(jié)省很多資源的錯(cuò)覺(jué)。然而 Docker 的「輕」也只是相對(duì)于傳統(tǒng)虛擬機(jī)而已。

傳統(tǒng)虛擬機(jī)和 Docker 的對(duì)比如圖：

從圖中可以看出 Docker 和 虛擬機(jī)的差異，虛擬機(jī)的 Guest OS 和 Hypervisor 層在 Docker 中被 Docker Engine 層所替代，Docker 有著比虛擬機(jī)更少的抽象層。

由于 Docker 不需要通過(guò) Hypervisor 層實(shí)現(xiàn)硬件資源虛擬化，運(yùn)行在 Docker 容器上的程序直接使用實(shí)際物理機(jī)的硬件資源。因此在 CPU、內(nèi)存利用率上 Docker 略勝一籌。

Docker利用的是宿主機(jī)的內(nèi)核，而不需要 Guest OS，因此，當(dāng)新建一個(gè)容器時(shí)，Docker 不需要和虛擬機(jī)一樣重新加載一個(gè)操作系統(tǒng)內(nèi)核，因此新建一個(gè) Docker 容器只需要幾秒鐘。

總結(jié)一下 Docker 容器相對(duì)于 VM 有以下幾個(gè)優(yōu)勢(shì)：?jiǎn)?dòng)速度快、資源利用率高、性能開(kāi)銷小。

那么，Docker 如何監(jiān)控呢？可能具體問(wèn)題要具體分析。但是似乎大家都在使用開(kāi)源的監(jiān)控方案，來(lái)解決 Docker監(jiān)控的問(wèn)題。

就拿騰訊游戲來(lái)說(shuō)吧，我們看看尹燁（騰訊互娛運(yùn)營(yíng)部高級(jí)工程師， 干貨 | 騰訊游戲是如何使用 Docker 的？ ）怎么說(shuō)：

容器的監(jiān)控問(wèn)題也花了我們很多精力。監(jiān)控、告警是運(yùn)營(yíng)系統(tǒng)最核心的功能之一，騰訊內(nèi)部有一套很成熟的監(jiān)控告警平臺(tái)，而且開(kāi)發(fā)運(yùn)維同學(xué)已經(jīng)習(xí)慣這套平臺(tái)，如果我們針對(duì) Docker 容器再開(kāi)發(fā)一個(gè)監(jiān)控告警平臺(tái)，會(huì)花費(fèi)很多精力，而且沒(méi)有太大的意義。所以，我們盡量去兼容公司現(xiàn)有的監(jiān)控告警平臺(tái)。每個(gè)容器內(nèi)部會(huì)運(yùn)行一個(gè)代理，從 /proc 下面獲取 CPU、內(nèi)存、IO 的信息，然后上報(bào)公司的監(jiān)控告警平臺(tái)。但是，默認(rèn)情況下，容器內(nèi)部的 proc 顯示的是 Host 信息，我們需要用 Host 上 cgroup 中的統(tǒng)計(jì)信息來(lái)覆蓋容器內(nèi)部的部分 proc 信息。我們基于開(kāi)源的 lxcfs，做了一些改造實(shí)現(xiàn)了這個(gè)需求。

這些解決方案都是基于開(kāi)源系統(tǒng)來(lái)實(shí)現(xiàn)的，當(dāng)然，我們也會(huì)把我們自己覺(jué)得有意義的修改回饋給社區(qū)，我們給 Docker、Kubernetes 和 lxcfs 等開(kāi)源項(xiàng)目貢獻(xiàn)了一些 patch。融入社區(qū)，與社區(qū)共同發(fā)展，這是一件很有意義的事情。

在沒(méi)有專業(yè)運(yùn)維團(tuán)隊(duì)來(lái)監(jiān)控 Docker 的情況下，并且還想加快 Docker 監(jiān)控的日程，怎么辦呢？

為了能夠更精確的分配每個(gè)容器能使用的資源，我們想要實(shí)時(shí)獲取容器運(yùn)行時(shí)使用資源的情況，怎樣對(duì) Docker 上的應(yīng)用進(jìn)行監(jiān)控呢？Docker 的結(jié)構(gòu)會(huì)不會(huì)加大監(jiān)控難度？

我們都了解， container 相當(dāng)于小型 host，可以說(shuō)存在于 hosts 與應(yīng)用之間的監(jiān)控盲區(qū)，無(wú)論是傳統(tǒng)的基礎(chǔ)組件監(jiān)控還是應(yīng)用性能監(jiān)控的方式，都很難有效地監(jiān)控 Docker。了解了一下現(xiàn)有的 Docker 相關(guān)監(jiān)測(cè) App 和服務(wù)，包括簡(jiǎn)單的開(kāi)源工具和復(fù)雜的企業(yè)整體解決方案，下面列舉其中的幾種作為參考：

谷歌的 container introspection 解決方案是 cAdvisor，這是一個(gè) Docker 容器內(nèi)封裝的實(shí)用工具，能夠搜集、集料、處理和導(dǎo)出運(yùn)行中的容器的信息。通過(guò)它可以看到 CPU 的使用率、內(nèi)存使用率、網(wǎng)絡(luò)吞吐量以及磁盤(pán)空間利用率。然后，你可以通過(guò)點(diǎn)擊在網(wǎng)頁(yè)頂部的 Docker Containers 鏈接，然后選擇某個(gè)容器來(lái)詳細(xì)了解它的使用情況。cAdvisor 部署和使用簡(jiǎn)單，但它只可以監(jiān)視在同一個(gè) host 上運(yùn)行的容器，對(duì)多節(jié)點(diǎn)部署不是太管用。

在我們列舉的幾個(gè)監(jiān)控 Docker 的服務(wù)或平臺(tái)中，這是唯一一款國(guó)內(nèi)產(chǎn)品。Cloud Insight 支持多種操作系統(tǒng)、云主機(jī)、數(shù)據(jù)庫(kù)和中間件的監(jiān)控，原理是在平臺(tái)服務(wù)儀表盤(pán)和自定義儀表盤(pán)中，采集并處理 Metric，對(duì)數(shù)據(jù)進(jìn)行聚合與分組等計(jì)算，提供曲線圖、柱狀圖等多樣化的展現(xiàn)形式。優(yōu)點(diǎn)是監(jiān)控的指標(biāo)很全，簡(jiǎn)單易用，但目前正式版還未上線，可以期待一下。

Scout 是一款監(jiān)視服務(wù)，并不是一個(gè)獨(dú)立的開(kāi)源項(xiàng)目。它有大量的插件，除了 Docker 信息還可以吸收其他有關(guān)部署的數(shù)據(jù)。因此 Scout 算是一站式監(jiān)控系統(tǒng)，無(wú)需對(duì)系統(tǒng)的各種資源來(lái)安裝各種不同的監(jiān)控系統(tǒng)。 Scout 的一個(gè)缺點(diǎn)是，它不顯示有關(guān)每個(gè)主機(jī)上多帶帶容器的詳細(xì)信息。此外，每個(gè)監(jiān)控的主機(jī)十美元這樣略微昂貴的價(jià)格也是是否選擇 Scout 作為監(jiān)控服務(wù)的一個(gè)考慮因素，如果運(yùn)行一個(gè)有多臺(tái)主機(jī)的超大部署，成本會(huì)比較高。

Sematext 也是一款付費(fèi)監(jiān)控解決方案，計(jì)劃收費(fèi)方案是3.5美分/小時(shí)。同樣也支持 Docker 監(jiān)控，還包括對(duì)容器級(jí)事件的監(jiān)測(cè)（停止、開(kāi)始等等）和管理容器產(chǎn)生的日志。

我們先來(lái)說(shuō)說(shuō)一套開(kāi)源的 Docker 監(jiān)控方案：Prometheus；而此篇文字的原文地址：Monitor Docker Containers with Prometheus。

Prometheus 由 SoundCloud 發(fā)明，適合于監(jiān)控基于容器的基礎(chǔ)架構(gòu)。Prometheus 特點(diǎn)是高維度數(shù)據(jù)模型，時(shí)間序列是通過(guò)一個(gè)度量值名字和一套鍵值對(duì)識(shí)別。靈活的查詢語(yǔ)言允許查詢和繪制數(shù)據(jù)。它采用了先進(jìn)的度量標(biāo)準(zhǔn)類型像匯總（summaries），從指定時(shí)間跨度的總數(shù)構(gòu)建比率或者是在任何異常的時(shí)候報(bào)警并且沒(méi)有任何依賴，中斷期間使它成為一個(gè)可靠的系統(tǒng)進(jìn)行調(diào)試。

Prometheus 支持維度數(shù)據(jù)，你可以擁有全局和簡(jiǎn)單的指標(biāo)名像 container_memory_usage_bytes ，使用多個(gè)維度來(lái)標(biāo)識(shí)你服務(wù)的指定實(shí)例。

我已經(jīng)創(chuàng)建了一個(gè)簡(jiǎn)單的 container-exporter 來(lái)收集 Docker 容器的指標(biāo)以及輸出給 Prometheus 來(lái)消費(fèi)。這個(gè)輸出器使用容器的名字，id 和 鏡像作為維度。額外的 per-exporter 維度可以在 prometheus.conf 中設(shè)置。

如果你使用指標(biāo)名字直接作為一個(gè)查詢表達(dá)式，它將返回有這個(gè)使用這個(gè)指標(biāo)名字作為標(biāo)簽的所有時(shí)間序列。

container_memory_usage_bytes{env="prod",id="23f731ee29ae12fef1ef6726e2fce60e5e37342ee9e35cb47e3c7a24422f9e88",instance="http://1.2.3.4:9088/metrics",job="container-exporter",name="haproxy-exporter-int",image="prom/haproxy-exporter:latest"}    11468800.000000  

container_memory_usage_bytes{env="prod",id="57690ddfd3bb954d59b2d9dcd7379b308fbe999bce057951aa3d45211c0b5f8c",instance="http://1.2.3.5:9088/metrics",job="container-exporter",name="haproxy-exporter",image="prom/haproxy-exporter:latest"}    16809984.000000 
 
container_memory_usage_bytes{env="prod",id="907ac267ebb3299af08a276e4ea6fd7bf3cb26632889d9394900adc832a302b4",instance="http://1.2.3.2:9088/metrics",job="container-exporter",name="node-exporter",image="prom/container-exporter:latest"}  

...
...

如果你運(yùn)行了許多容器，這個(gè)看起來(lái)像這樣：

為了幫助你使得這數(shù)據(jù)更有意義，你可以過(guò)濾（filter） and/or 聚合（aggregate） 這些指標(biāo)。

使用 Prometheus 的查詢語(yǔ)言，你可以對(duì)你想的任何維度的數(shù)據(jù)切片和切塊。如果你對(duì)一個(gè)給定名字的所有容器感興趣，你可以使用一個(gè)表達(dá)式像 container_memory_usage_bytes{name="consul-server"}，這個(gè)將僅僅顯示 name == "consul-server" 的時(shí)間序列。

像多維度的數(shù)據(jù)模型，來(lái)實(shí)現(xiàn)數(shù)據(jù)聚合、分組、過(guò)濾，不單單是 Prometheus。OpenTSDB 和 InfluxDB 這些時(shí)間序列數(shù)據(jù)庫(kù)和系統(tǒng)監(jiān)控工具的結(jié)合，讓系統(tǒng)監(jiān)控這件事情變得更加的多元。

接下來(lái)，我們?yōu)榇蠹医榻B國(guó)內(nèi)一家同樣提供該功能的監(jiān)控方案：Cloud Insight。有關(guān)其數(shù)據(jù)聚合的功能可以閱讀：數(shù)據(jù)聚合 & 分組：新一代系統(tǒng)監(jiān)控的核心功能。

現(xiàn)在我們來(lái)對(duì)比 Prometheus 和 Cloud Insight 在數(shù)據(jù)聚合、分組（切片）上的展現(xiàn)效果和功能。

數(shù)據(jù)聚合

根據(jù)不同的 Container Name 或 Image Name 對(duì)內(nèi)存使用量或 Memeory Cache 進(jìn)行聚合。

數(shù)據(jù)分組（切片）

根據(jù)不同的 Container Name 或 Image Name 對(duì)內(nèi)存使用量或 Memeory Cache進(jìn)行分組（切片）。

單方面監(jiān)控 Docker 可能并不太適合與業(yè)務(wù)掛鉤的應(yīng)用，當(dāng)業(yè)務(wù)量上漲，不單單是 Docker 的負(fù)載上升，其他 JVM 指標(biāo)也能也會(huì)出現(xiàn)上升的趨勢(shì)。

我們嘗試使用一個(gè)支持比較多中間件、數(shù)據(jù)庫(kù)、操作系統(tǒng)、容器的 Cloud Insight 來(lái)說(shuō)明這個(gè)實(shí)際的場(chǎng)景。

Cloud Insight 由于是一個(gè) SaaS 監(jiān)控方案，相對(duì)來(lái)說(shuō)它的安裝和部署都比較簡(jiǎn)單。在這次監(jiān)控實(shí)戰(zhàn)中，我們以 AcmeAir 為實(shí)驗(yàn)對(duì)象：一個(gè)可以模擬壓力的電子商務(wù)類應(yīng)用。ac

AcmeAir 是一款由原 IBM 新技術(shù)架構(gòu)部資深工程師 Andrew Spyker，利用 Netflix 開(kāi)源的 Netflix OSS 打造的開(kāi)源電子商務(wù)應(yīng)用。此應(yīng)用具有如下特性：

模擬提供航班訂票服務(wù)。用戶可以通過(guò)移動(dòng)設(shè)備或者 web 瀏覽器，完成新用戶注冊(cè)，用戶登錄，航班查詢，訂票等操作。

AcmeAir 融入了 Docker，微服務(wù)架構(gòu)等理念。并采用 tomcat，node.js , WebSphere application server, WebSphere extreme scale, mongodb, cassandra 分別打造了不同版本的實(shí)現(xiàn)。

AcmeAir 利用 JMeter 模擬用戶行為?？赏ㄟ^(guò)動(dòng)態(tài)調(diào)整用戶數(shù)量，模擬產(chǎn)生各種壓力的事物流量。并可在應(yīng)用中預(yù)先植入錯(cuò)誤代碼，模擬各種故障場(chǎng)景。該應(yīng)用可做為壓力測(cè)試，終端用戶體驗(yàn)異常檢測(cè)，故障診斷等各種測(cè)試場(chǎng)景的測(cè)試用例。

首先，我們要打開(kāi) Cloud Insight 監(jiān)控，還好 Cloud Insight 安裝簡(jiǎn)單，一條命令即可。接著，我們新建一個(gè)用于此次監(jiān)控的儀表盤(pán)，依次將想要獲取的指標(biāo)統(tǒng)統(tǒng)添加進(jìn)去。比如，選中 jvm.non_heap_memory 這個(gè)指標(biāo)，選擇按照 instance 分組。

我們添加以下指標(biāo)：

docker.cpu.user
docker.cpu.sysytem
docker.containers.running
jvm.heap_memory
jvm.non_heap_memory
jvm.gc.cms.count
jvm.heap_memory_max
jvm.gc.parnew.time

添加后，由自定義儀表盤(pán)中的顯示效果如圖：

應(yīng)用 Acme 部署在四臺(tái) servers 上，我們開(kāi)啟四臺(tái) servers, 然后用 JMeter 給應(yīng)用加壓。

隨著時(shí)間 JMeter 不斷給應(yīng)用加壓，當(dāng) users 人數(shù)達(dá)到 188 時(shí)，我們?cè)賮?lái)看一下儀表盤(pán)的視圖。

如圖，性能數(shù)據(jù)發(fā)生了變化，根據(jù) JMeter 里的數(shù)據(jù)，CPU 占用和錯(cuò)誤率都有所提升；與此同時(shí)，根據(jù) Cloud Insight 里的曲線顯示，在指標(biāo) docker.cpu.user 這幅圖中，藍(lán)色的線所代表的 Container CPU 占用率已經(jīng)超過(guò) 50%，逐漸接近 75%，系統(tǒng)剩余的 CPU 資源逐漸下降。

而指標(biāo) docker.cpu.system 圖中同樣可以看到藍(lán)色的那條數(shù)據(jù)在 18：29 左右出現(xiàn)了一個(gè)波峰，代表系統(tǒng) CPU 資源消耗突然增大。通過(guò)這兩幅圖，我們可以定位到 CPU 占用率過(guò)高的 Container ，及時(shí)而主動(dòng)地去了解性能瓶頸，從而優(yōu)化性能，合理分配資源。

再看 jvm.heap_memory 指標(biāo)，圖中幾條曲線在 18:20 之后逐漸升高，黃色曲線在 18：28 左右出現(xiàn)波峰，淺藍(lán)色曲線數(shù)值較高，用 jvm.heap_memory 的值去比左圖 jvm.heap_memory_max 的值，將能更清楚的反映 JVM 堆內(nèi)存的消耗情況。

而 jvm.gc.parnew.time 圖中顯示了新生代并行 GC 的時(shí)間數(shù)據(jù)。GC 是需要時(shí)間和資源的，不好的 GC 會(huì)嚴(yán)重影響系統(tǒng)的系能，良好的 GC 是 JVM 高性能的保證。

無(wú)法被監(jiān)控的軟件是很危險(xiǎn)的，通過(guò)解讀這張 Docker 儀表盤(pán)總覽圖，我們可以了解到 Docker 實(shí)時(shí)性能狀況，精準(zhǔn)定位到性能薄弱的環(huán)節(jié)，從而優(yōu)化我們的應(yīng)用。

Docker 兼容相比其他的數(shù)據(jù)庫(kù)、系統(tǒng)、中間件監(jiān)控，要復(fù)雜一些。由于需要表征不同 Container 的性能消耗，來(lái)了解不同應(yīng)用的運(yùn)行情況，所以數(shù)據(jù)的聚合、切片（分組）和過(guò)濾，在 Docker 監(jiān)控中成為了必備功能。

所以我們推薦使用了時(shí)間序列數(shù)據(jù)庫(kù)，或者類似設(shè)計(jì)邏輯的監(jiān)控方案，如：Prometheus 和 Cloud Insight。

而 Docker 單方面的監(jiān)控，可能不太滿足一些大型公司的需求，如果一個(gè)工具在監(jiān)控 Docker 同時(shí)能夠監(jiān)控其他組件，那就更好了。

國(guó)外出現(xiàn)了 Graphite、Grafana 和 Host Graphite，能夠讓用戶將不同數(shù)據(jù)來(lái)源都集中在同一個(gè)地方進(jìn)行展現(xiàn)；而國(guó)內(nèi) Cloud Insight 似乎也是這樣的思路。