如今，越來越多的公司開始使用 Docker 了，現在來給大家看幾組數據：2 / 3 的公司在嘗試了 Docker 后最終使用了它，也就是說 Docker 的轉化率達到了 67%，而且轉化時長也控制在 60 天內。
越大型的公司越早開始使用 Docker
研究發現主機數量越多的公司，越早開始使用 Docker。而主機數量多，在這個研究里就默認等同于是大型公司了。
Docker 優勢
那為什么 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 監控是不是也該提上日程？或許具體問題要具體分析，但是似乎大家都在使用開源的監控方案，來解決 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 和服務，包括簡單的開源工具和復雜的企業整體解決方案，下面列舉其中的幾種作為參考：
1. cAdvisor
谷歌的 container introspection 解決方案是 cAdvisor，這是一個 Docker 容器內封裝的工具，能夠采集、處理和導出運行中的容器的數據。通過它可以看到 CPU 的使用率、內存使用率、網絡吞吐量以及磁盤空間利用率等。同時，你還可以通過點擊在網頁頂部的 Docker Containers 鏈接，選擇某個容器來詳細了解它的使用情況。cAdvisor 部署和使用簡單，但它只可以監視在同一個 host 上運行的容器，對多節點部署不是太管用。
2. Cloud Insight
在我們列舉的幾個監控 Docker 的服務或平臺中，這是唯一一款國內產品。 Cloud Insight支持多種操作系統、云主機、數據庫和中間件的監控，原理是在平臺服務儀表盤和自定義儀表盤中，采集并處理 Metric，對數據進行聚合與分組等計算，提供曲線圖、柱狀圖等多樣化的展現形式。優點是監控的指標很全，簡單易用，可以期待一下。
3. Scout
Scout 是一款監視服務，并不是一個獨立的開源項目。它有大量的插件，除了 Docker 信息還可以吸收其他有關部署的數據。因此 Scout 算是一站式監控系統，無需對系統的各種資源來安裝各種不同的監控系統。 Scout 的一個缺點是，它不顯示有關每個主機上單獨容器的詳細信息。此外，每個監控的主機十美元這樣略微昂貴的價格也是是否選擇 Scout 作為監控服務的一個考慮因素，如果運行一個有多臺主機的超大部署，成本會比較高。
4. Sematext
Sematext 也是一款付費監控解決方案，計劃收費方案是3.5美分/小時。同樣也支持 Docker 監控，還包括對容器級事件的監測（停止、開始等等）和管理容器產生的日志。
5. Prometheus
Prometheus 由 SoundCloud 發明，適合于監控基于容器的基礎架構。支持監控容器的資源和運行特性，支持多維度查詢，能聚合 Docker 監控數據。
Docker 監控實踐
數據的聚合&分組，是運維2.0時代的重頭戲，因此我們重點選取其中比較有這個方面代表性的兩個監控方案來看看具體的 Docker 監控過程。
先借鑒「Monitor Docker Containers with Prometheus](http://5pi.de/2015/01/26/monitor-docker-container」一文中的介紹，來說說這套開源的 Docker 監控方案：Prometheus；而此篇文字的原文地址：Monitor Docker Containers with Prometheus。
Prometheus 由 SoundCloud 發明，可用于監控基于容器的基礎架構。Prometheus 特點是高維度數據模型，時間序列是通過一個度量值名字和一套鍵值對識別。靈活的查詢語言允許查詢和繪制數據。它采用了先進的度量標準類型像匯總（summaries），從指定時間跨度的總數構建比率或者是在任何異常的時候報警并且沒有任何依賴，中斷期間使它成為一個可靠的系統進行調試。
Prometheus 支持維度數據，你可以擁有全局和簡單的指標名像 container_memory_usage_bytes ，使用多個維度來標識你服務的指定實例。
可以創建一個簡單的 container-exporter 來收集 Docker 容器的指標以及輸出給 Prometheus 來消費。這個輸出器使用容器的名字，id 和 鏡像作為維度。額外的 per-exporter 維度可以在 prometheus.conf 中設置。
如果你使用指標名字直接作為一個查詢表達式，它將返回有這個使用這個指標名字作為標簽的所有時間序列。
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"}
...
...
如果你運行了許多容器，這個看起來像這樣：
為了幫助你使得這數據更有意義，你可以過濾（filter） and/or 聚合（aggregate） 這些指標。
使用 Prometheus 的查詢語言，你可以對你想的任何維度的數據切片和切塊。如果你對一個給定名字的所有容器感興趣，你可以使用一個表達式像 container_memory_usage_bytes{name="consul-server"}，這個將僅僅顯示 name == "consul-server" 的時間序列。
像多維度的數據模型，來實現數據聚合、分組、過濾，不單單是 Prometheus。OpenTSDB 和 InfluxDB 這些時間序列數據庫和系統監控工具的結合，讓系統監控這件事情變得更加的多元。
如果你是阿里云的用戶，或者使用過 Zabbix，那么你會明顯感受到一個痛點：沒有辦法對數據做聚合，只能挨個查看主機的性能指標，更不用說有管理的功能。正因為如此我們才對數據聚合&分組抱有極大興趣。如果想更多地了解數據聚合和分組的相關內容也可以閱讀一下數據聚合 &分組：新一代系統監控的核心功能這篇文章。
現在我們來對比 Prometheus 和 Cloud Insight 在數據聚合、分組（切片）上的展現效果和功能。
數據聚合
根據不同的 Container Name 或 Image Name 對內存使用量或 Memeory Cache 進行聚合。
數據分組（切片)
根據不同的 Container Name 或 Image Name 對內存使用量或 Memeory Cache進行分組（切片）。
單方面監控 Docker 可能并不太適合與業務掛鉤的應用，當業務量上漲，不單單是 Docker 的負載上升，其他 JVM 指標也能也會出現上升的趨勢。如果我們利用 Acme 模擬真實應用環境，再通過 Cloud Insight 進行監控的話，需要新建一個用于此次監控的儀表盤，依次將想要獲取的指標統統添加進去。
可以添加以下指標：
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
應用 Acme 部署在四臺 servers 上，我們開啟四臺 servers, 然后用 JMeter 給應用加壓。隨著時間 JMeter 不斷給應用加壓，當 users 人數達到 188 時，我們來看一下儀表盤的視圖。
根據 JMeter 里的數據，CPU 占用和錯誤率都有所提升；與此同時，在指標 docker.cpu.user 這幅圖中，藍色的線所代表的 Container CPU 占用率已經超過 50%，逐漸接近 75%，系統剩余的 CPU 資源逐漸下降。
而指標 docker.cpu.system 圖中同樣可以看到藍色的那條數據在 18：29 左右出現了一個波峰，代表系統 CPU 資源消耗突然增大。通過這兩幅圖，我們可以定位到 CPU 占用率過高的 Container ，及時而主動地去了解性能瓶頸，從而優化性能，合理分配資源。
用 jvm.heap_memory 的值去比左圖 jvm.heap_memory_max 的值，將能清楚的反映 JVM 堆內存的消耗情況。而 jvm.gc.parnew.time 圖中顯示了新生代并行 GC 的時間數據。GC 是需要時間和資源的，不好的 GC 會嚴重影響系統的系能，良好的 GC 是 JVM 高性能的保證。
無法被監控的軟件是很危險的，通過解讀這張 Docker 儀表盤總覽圖，我們也許可以了解到 Docker 實時性能狀況，精準定位到性能薄弱的環節，從而優化我們的應用。
總結
Docker 兼容相比其他的數據庫、系統、中間件監控，要復雜一些。由于需要表現不同 Container 的性能消耗，來了解不同應用的運行情況，所以數據的聚合、切片（分組）和過濾，在 Docker 監控中成為了必備功能。
所以推薦大家使用時間序列數據庫，或者類似設計邏輯的監控方案，如Prometheus等。而 Docker 單方面的監控，可能不太滿足一些大型公司的需求，如果一個工具在監控 Docker 同時能夠監控其他組件，那就更好了。國外的 Graphite、Grafana 和 Host Graphite，以及國內的 Cloud Insight，都是能夠讓用戶將不同數據來源都集中在同一個地方進行展現，大家頁可以對比和試用一下。
京公網安備 11010502049343號