如今，越來越多的公司開始使用 docker 了，現在來給大家看幾組資料：
2 / 3 的公司在嘗試了 docker 後最終使用了它
也就是說 docker 的轉化率達到了 67%，而轉化時長也控制在 60 天内。
越大型的公司越早開始使用 docker
研究發現主機數量越多的公司，越早開始使用 docker。而主機數量多，在這個研究裡就預設等同于是大型公司了。
<a></a>
那為什麼 docker 越來越火呢？一談起 docker 總是會跟着讓人聯想到輕量這個詞，甚至會有一種通過 docker 啟動一個服務會節省很多資源的錯覺。然而 docker 的「輕」也隻是相對于傳統虛拟機而已。
傳統虛拟機和 docker 的對比如圖：
從圖中可以看出 docker 和 虛拟機的差異，虛拟機的 guest os 和 hypervisor 層在 docker 中被 docker engine 層所替代，docker 有着比虛拟機更少的抽象層。
由于 docker 不需要通過 hypervisor 層實作硬體資源虛拟化，運作在 docker 容器上的程式直接使用實際實體機的硬體資源。是以在 cpu、記憶體使用率上 docker 略勝一籌。
docker利用的是主控端的核心，而不需要 guest os，是以，當建立一個容器時，docker 不需要和虛拟機一樣重新加載一個作業系統核心，是以建立一個 docker 容器隻需要幾秒鐘。
總結一下 docker 容器相對于 vm 有以下幾個優勢：啟動速度快、資源使用率高、性能開銷小。
那麼，docker 如何監控呢？可能具體問題要具體分析。但是似乎大家都在使用開源的監控方案，來解決 docker監控的問題。
就拿騰訊遊戲來說吧，我們看看尹烨（騰訊互娛營運部進階工程師）怎麼說：
容器的監控問題也花了我們很多精力。監控、告警是營運系統最核心的功能之一，騰訊内部有一套很成熟的監控告警平台，而且開發運維同學已經習慣這套平台，如果我們針對 docker 容器再開發一個監控告警平台，會花費很多精力，而且沒有太大的意義。是以，我們盡量去相容公司現有的監控告警平台。每個容器内部會運作一個代理，從 /proc 下面擷取 cpu、記憶體、io 的資訊，然後上報公司的監控告警平台。但是，預設情況下，容器内部的 proc 顯示的是 host 資訊，我們需要用 host 上 cgroup 中的統計資訊來覆寫容器内部的部分 proc 資訊。我們基于開源的 lxcfs，做了一些改造實作了這個需求。
這些解決方案都是基于開源系統來實作的，當然，我們也會把我們自己覺得有意義的修改回饋給社群，我們給 docker、kubernetes 和 lxcfs 等開源項目貢獻了一些 patch。融入社群，與社群共同發展，這是一件很有意義的事情。
在沒有專業運維團隊來監控 docker 的情況下，并且還想加快 docker 監控的日程，怎麼辦呢？
為了能夠更精确的配置設定每個容器能使用的資源，我們想要實時擷取容器運作時使用資源的情況，怎樣對 docker 上的應用進行監控呢？docker 的結構會不會加大監控難度？
我們都了解， container 相當于小型 host，可以說存在于 hosts 與應用之間的監控盲區，無論是傳統的基礎元件監控還是應用性能監控的方式，都很難有效地監控 docker。了解了一下現有的 docker 相關監測 app 和服務，包括簡單的開源工具和複雜的企業整體解決方案，下面列舉其中的幾種作為參考：
谷歌的 container introspection 解決方案是 cadvisor，這是一個 docker 容器内封裝的實用工具，能夠搜集、集料、處理和導出運作中的容器的資訊。通過它可以看到 cpu 的使用率、記憶體使用率、網絡吞吐量以及磁盤空間使用率。然後，你可以通過點選在網頁頂部的 docker containers 連結，然後選擇某個容器來詳細了解它的使用情況。cadvisor 部署和使用簡單，但它隻可以監視在同一個 host 上運作的容器，對多節點部署不是太管用。
在我們列舉的幾個監控 docker 的服務或平台中，這是唯一一款國内産品。cloud insight 支援多種作業系統、雲主機、資料庫和中間件的監控，原理是在平台服務儀表盤和自定義儀表盤中，采集并處理 metric，對資料進行聚合與分組等計算，提供曲線圖、柱狀圖等多樣化的展現形式。優點是監控的名額很全，簡單易用，但目前正式版還未上線，可以期待一下。
scout 是一款監視服務，并不是一個獨立的開源項目。它有大量的插件，除了 docker 資訊還可以吸收其他有關部署的資料。是以 scout 算是一站式監控系統，無需對系統的各種資源來安裝各種不同的監控系統。 scout 的一個缺點是，它不顯示有關每個主機上單獨容器的詳細資訊。此外，每個監控的主機十美元這樣略微昂貴的價格也是是否選擇 scout 作為監控服務的一個考慮因素，如果運作一個有多台主機的超大部署，成本會比較高。
sematext 也是一款付費監控解決方案，計劃收費方案是3.5美分/小時。同樣也支援 docker 監控，還包括對容器級事件的監測（停止、開始等等）和管理容器産生的日志。
prometheus 由 soundcloud 發明，适合于監控基于容器的基礎架構。prometheus 特點是高次元資料模型，時間序列是通過一個路徑成本名字和一套鍵值對識别。靈活的查詢語言允許查詢和繪制資料。它采用了先進的度量标準類型像彙總summaries，從指定時間跨度的總數建構比率或者是在任何異常的時候報警并且沒有任何依賴，中斷期間使它成為一個可靠的系統進行調試。
prometheus 支援次元資料，你可以擁有全局和簡單的名額名像 <code>container_memory_usage_bytes</code> ，使用多個次元來辨別你服務的指定執行個體。
我已經建立了一個簡單的 <code>container-exporter</code> 來收集 docker 容器的名額以及輸出給 prometheus 來消費。這個輸出器使用容器的名字，id 和 鏡像作為次元。額外的 <code>per-exporter</code> 次元可以在 <code>prometheus.conf</code> 中設定。
如果你使用名額名字直接作為一個查詢表達式，它将傳回有這個使用這個名額名字作為标簽的所有時間序列。
<code>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</code>
<code></code>
<code>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</code>
<code>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"}</code>
<code>...</code>
如果你運作了許多容器，這個看起來像這樣：
為了幫助你使得這資料更有意義，你可以過濾filter and/or 聚合aggregate 這些名額。
使用 prometheus 的查詢語言，你可以對你想的任何次元的資料切片和切塊。如果你對一個給定名字的所有容器感興趣，你可以使用一個表達式像 <code>container_memory_usage_bytes{name="consul-server"}</code>，這個将僅僅顯示 <code>name == "consul-server"</code> 的時間序列。
像多元度的資料模型，來實作資料聚合、分組、過濾，不單單是 prometheus。opentsdb 和 influxdb 這些時間序列資料庫和系統監控工具的結合，讓系統監控這件事情變得更加的多元。
現在我們來對比 prometheus 和 cloud insight 在資料聚合、分組（切片）上的展現效果和功能。
資料聚合
根據不同的 container name 或 image name 對記憶體使用量或 memeory cache 進行聚合。
資料分組（切片）
根據不同的 container name 或 image name 對記憶體使用量或 memeory cache進行分組（切片）。
單方面監控 docker 可能并不太适合與業務挂鈎的應用，當業務量上漲，不單單是 docker 的負載上升，其他 jvm 名額也能也會出現上升的趨勢。
我們嘗試使用一個支援比較多中間件、資料庫、作業系統、容器的 cloud insight 來說明這個實際的場景。
acmeair 是一款由原 ibm 新技術架構部資深工程師 andrew spyker，利用 netflix 開源的 netflix oss 打造的開源電子商務應用。此應用具有如下特性：
模拟提供航班訂票服務。使用者可以通過移動裝置或者 web 浏覽器，完成新使用者注冊，使用者登入，航班查詢，訂票等操作。
acmeair 融入了 docker，微服務架構等理念。并采用 tomcat、node.js、websphere application server、websphere extreme scale、mongodb、cassandra 分别打造了不同版本的實作。
acmeair 利用 jmeter 模拟使用者行為。可通過動态調整使用者數量，模拟産生各種壓力的事物流量。并可在應用中預先植入錯誤代碼，模拟各種故障場景。該應用可做為壓力測試，終端使用者體驗異常檢測，故障診斷等各種測試場景的測試用例。
首先，我們要打開 cloud insight 監控，還好 cloud insight 安裝簡單，一條指令即可。接着，我們建立一個用于此次監控的儀表盤，依次将想要擷取的名額統統添加進去。比如，選中 <code>jvm.non_heap_memory</code> 這個名額，選擇按照 instance 分組。
我們添加以下名額：
<code>docker.cpu.user</code>
<code>docker.cpu.sysytem</code>
<code>docker.containers.running</code>
<code>jvm.heap_memory</code>
<code>jvm.non_heap_memory</code>
<code>jvm.gc.cms.count</code>
<code>jvm.heap_memory_max</code>
<code>jvm.gc.parnew.time</code>
添加後，由自定義儀表盤中的顯示效果如圖：
應用 acme 部署在四台 servers 上，我們開啟四台 servers, 然後用 jmeter 給應用加壓。
随着時間 jmeter 不斷給應用加壓，當 users 人數達到 188 時，我們再來看一下儀表盤的視圖。
如圖，性能資料發生了變化，根據 jmeter 裡的資料，cpu 占用和錯誤率都有所提升；與此同時，根據 cloud insight 裡的曲線顯示，在名額 <code>docker.cpu.user</code> 這幅圖中，藍色的線所代表的 container cpu 占用率已經超過 50%，逐漸接近 75%，系統剩餘的 cpu 資源逐漸下降。
而名額 <code>docker.cpu.system</code> 圖中同樣可以看到藍色的那條資料在 18：29 左右出現了一個波峰，代表系統 cpu 資源消耗突然增大。通過這兩幅圖，我們可以定位到 cpu 占用率過高的 container ，及時而主動地去了解性能瓶頸，進而優化性能，合理配置設定資源。
再看 <code>jvm.heap_memory</code> 名額，圖中幾條曲線在 18:20 之後逐漸升高，黃色曲線在 18：28 左右出現波峰，淺藍色曲線數值較高，用 <code>jvm.heap_memory</code> 的值去比左圖 <code>jvm.heap_memory_max</code> 的值，将能更清楚的反映 jvm 堆記憶體的消耗情況。
而 <code>jvm.gc.parnew.time</code> 圖中顯示了新生代并行 gc 的時間資料。gc 是需要時間和資源的，不好的 gc 會嚴重影響系統的系能，良好的 gc 是 jvm 高性能的保證。
無法被監控的軟體是很危險的，通過解讀這張 docker 儀表盤總覽圖，我們可以了解到 docker 實時性能狀況，精準定位到性能薄弱的環節，進而優化我們的應用。
docker 相容相比其他的資料庫、系統、中間件監控，要複雜一些。由于需要表征不同 container 的性能消耗，來了解不同應用的運作情況，是以資料的聚合、切片（分組）和過濾，在 docker 監控中成為了必備功能。
是以我們推薦使用了時間序列資料庫，或者類似設計邏輯的監控方案，如：prometheus 和 cloud insight。
而 docker 單方面的監控，可能不太滿足一些大型公司的需求，如果一個工具在監控 docker 同時能夠監控其他元件，那就更好了。
本文來自雲栖社群合作夥伴“linux中國”
原文釋出時間為：2013-04-02.