Docker 監控實戰

現在，愈來愈多的公司開始使用 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 容器再開發一個監控告警平臺，會花費不少精力，並且沒有太大的意義。因此，咱們儘可能去兼容公司現有的監控告警平臺。每一個容器內部會運行一個代理，從 /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 監控，還包括對容器級事件的監測（中止、開始等等）和管理容器產生的日誌。

Docker 監控實踐

Prometheus

咱們先來講說一套開源的 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 這些時間序列數據庫和系統監控工具的結合，讓系統監控這件事情變得更加的多元。

接下來，咱們爲你們介紹國內一家一樣提供該功能的監控方案：Cloud Insight。有關其數據聚合的功能能夠閱讀：數據聚合 & 分組：新一代系統監控的核心功能。

如今咱們來對比 Prometheus 和 Cloud Insight 在數據聚合、分組（切片）上的展示效果和功能。

數據聚合

根據不一樣的 Container Name 或 Image Name 對內存使用量或 Memeory Cache 進行聚合。

數據分組（切片）

根據不一樣的 Container Name 或 Image Name 對內存使用量或 Memeory Cache進行分組（切片）。

Docker 監控實戰

單方面監控 Docker 可能並不太適合與業務掛鉤的應用，當業務量上漲，不僅僅是 Docker 的負載上升，其餘 JVM 指標也能也會出現上升的趨勢。

咱們嘗試使用一個支持比較多中間件、數據庫、操做系統、容器的 Cloud Insight 來講明這個實際的場景。

Cloud Insight

Cloud Insight 因爲是一個 SaaS 監控方案，相對來講它的安裝和部署都比較簡單。在此次監控實戰中，咱們以 AcmeAir 爲實驗對象：一個能夠模擬壓力的電子商務類應用。ac

AcmeAir 是一款由原 IBM 新技術架構部資深工程師 Andrew Spyker，利用 Netflix 開源的 Netflix OSS 打造的開源電子商務應用。此應用具備以下特性：

1. 模擬提供航班訂票服務。用戶能夠經過移動設備或者 web 瀏覽器，完成新用戶註冊，用戶登陸，航班查詢，訂票等操做。
2. AcmeAir 融入了 Docker，微服務架構等理念。並採用 tomcat，node.js , WebSphere application server, WebSphere extreme scale, mongodb, cassandra 分別打造了不一樣版本的實現。
3. AcmeAir 利用 JMeter 模擬用戶行爲。可經過動態調整用戶數量，模擬產生各類壓力的事物流量。並可在應用中預先植入錯誤代碼，模擬各類故障場景。該應用可作爲壓力測試，終端用戶體驗異常檢測，故障診斷等各類測試場景的測試用例。

首先，咱們要打開 Cloud Insight 監控，還好 Cloud Insight 安裝簡單，一條命令便可。接着，咱們新建一個用於這次監控的儀表盤，依次將想要獲取的指標通通添加進去。好比，選中 jvm.non_heap_memory 這個指標，選擇按照 instance 分組。

咱們添加如下指標：

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 佔用和錯誤率都有所提高；與此同時，根據 Cloud Insight 裏的曲線顯示，在指標 docker.cpu.user 這幅圖中，藍色的線所表明的 Container CPU 佔用率已經超過 50%，逐漸接近 75%，系統剩餘的 CPU 資源逐漸降低。

而指標 docker.cpu.system 圖中一樣能夠看到藍色的那條數據在 18：29 左右出現了一個波峯，表明系統 CPU 資源消耗忽然增大。經過這兩幅圖，咱們能夠定位到 CPU 佔用率太高的 Container ，及時而主動地去了解性能瓶頸，從而優化性能，合理分配資源。

再看 jvm.heap_memory 指標，圖中幾條曲線在 18:20 以後逐漸升高，黃色曲線在 18：28 左右出現波峯，淺藍色曲線數值較高，用 jvm.heap_memory 的值去比左圖 jvm.heap_memory_max 的值，將能更清楚的反映 JVM 堆內存的消耗狀況。

而 jvm.gc.parnew.time 圖中顯示了新生代並行 GC 的時間數據。GC 是須要時間和資源的，很差的 GC 會嚴重影響系統的系能，良好的 GC 是 JVM 高性能的保證。

沒法被監控的軟件是很危險的，經過解讀這張 Docker 儀表盤總覽圖，咱們能夠了解到 Docker 實時性能情況，精準定位到性能薄弱的環節，從而優化咱們的應用。

總結

Docker 兼容相比其餘的數據庫、系統、中間件監控，要複雜一些。因爲須要表徵不一樣 Container 的性能消耗，來了解不一樣應用的運行狀況，因此數據的聚合、切片（分組）和過濾，在 Docker 監控中成爲了必備功能。

因此咱們推薦使用了時間序列數據庫，或者相似設計邏輯的監控方案，如：Prometheus 和 Cloud Insight。

而 Docker 單方面的監控，可能不太知足一些大型公司的需求，若是一個工具在監控 Docker 同時可以監控其餘組件，那就更好了。

國外出現了 Graphite、Grafana 和 Host Graphite，可以讓用戶將不一樣數據來源都集中在同一個地方進行展示；而國內 Cloud Insight 彷佛也是這樣的思路。