斌哥的 Docker 進階指南

過去的一年中，關於 Docker 的話題從未斷過，而現在，從嘗試 Docker 到最終決定使用 Docker 的轉化率依然在逐步升高，關於 Docker 的討論更是有增無減。另外一方面，你們的注意力也漸漸從 「Docker 是什麼」轉移到「實踐 Docker」與「監控 Docker」上。

本文轉自劉斌博文「如何選擇 Docker 監控方案 」，文中劉斌從技術的角度深刻解釋了 Docker 監控的數據採集原理，介紹了現有開源的監控方案，以及可以對 Docker 進行監控功能的主流 SaaS 服務工具。

##斌哥是誰? 劉斌，擁有 10 多年編程經驗，曾參與翻譯過「第一本 Docker 書」、「GitHub 入門與實踐」、「Web 應用安全權威指南」等多本技術書籍，主講過「Docker入門與實踐 」課程的 Cloud Insight 後臺工程師。

##爲何監控，監控什麼內容？ 做爲一名工程師，咱們要對本身系統的運行狀態瞭如指掌，有問題及時發現，而不是讓用戶先發現系統不能使用，打電話找客服，再反映到開發。這個過程很長，並且對工程師來講，是一件比較沒面子的事情。

當領導問咱們這個月的 MySQL 併發什麼狀況？slowsql 處於什麼水平，平均響應時間超過 200ms 的佔比有百分之多少的時候，回答不出來這個問題很尷尬。儘管你工做很辛苦，可是卻沒有拿得出來的成果。不能由於暫時沒出問題就掉以輕心，換位想一想，站在領導的角度，領導什麼都不幹，你提案，他簽字，出了誰背鍋？

監控目的

1. 減小宕機時間

2. 擴展和性能管理

3. 資源計劃

4. 識別異常事件

5. 故障排除、分析

爲何須要監控咱們的服務？其中有一些顯而易見的緣由，好比須要監控工具來提醒服務故障，好比經過監控服務的負載來決定擴容或縮容。若是機器廣泛負載不高，則能夠考慮縮減一下機器規模，若是數據庫鏈接常常維持在一個高位水平，則能夠考慮一下是否能夠進行拆庫處理，優化一下架構。

##Docker監控面臨的挑戰

• Docker特色

  • 像host但不是host
  • 量大
  • 生命週期短 監控盲點（斷層）

• 微服務 集羣

• 全方位

  • Host（VM） + Services + Containers + Apps

容器爲咱們的開發和運維帶來了更多的方向和可能性，咱們也須要一種現代的監控方案來應對這種變化。

隨着不可變基礎設施概念的普及，雲原生應用的興起，雲計算組件已經愈來愈像搭建玩具的積木塊。不少基礎設施生命週期變短，不光容器如此，雲主機、VM也是。

在雲計算出現以前，一臺機器可能使用三、5年甚至更長都不須要重裝，主機名也不會變，而如今，可能升級一個版本，就要重建一個雲主機或從新啓動一個容器。監控對象動態變化，並且很是頻繁。即便所有實現自動化，也會在負載和複雜度方面帶來不利影響。

監控還有助於進行內部統制，尤爲是對安全比較敏感的行業，好比證券、銀行等。好比服務器受到攻擊時，咱們須要分析事件，找到根本緣由，識別相似攻擊，發現未知的被攻擊系統，甚至完成取證等工做。

集羣的出現，使應用的拓撲結構也變得複雜，不一樣應用的指標和日誌格式也不統一，再加上要考慮應對多租戶的問題，這些都給監控帶來了新挑戰。

傳統的監控內包括對主機、網絡和應用的監控，可是Docker出現以後，容器這一層很容易被忽略，成爲三無論地區，即監控的盲點。

有人說，容器不就是個普通的OS麼？裝個Zabbix的探針不就好了麼？Docker host和Docker 容器都要裝 Zabbix探針……其實問題不少。

除了容器內部看到的cpu內存狀況不許以外，並且容器生命週期短，重啓以後host名，ip地址都會變，因此最好在Docker host上安裝Zabbix agent。

若是每一個容器都像OS那樣監控，則metric數量將會很是巨大，並且這些數據極可能幾分鐘以後就無效率了（容器已經中止）。容器生命週期短暫，一旦容器結束運行，以前收集的數據將再也不有任何意義。

主要的解決方式就是以App或者Service爲單位進行監控（經過Tag等方式）。

##Docker 監控技術基礎

• docker stats

• Remote API

• 僞文件系統

咱們能夠經過 docker stats 命令或者Remote API以及Linux的僞文件系統來獲取容器的性能指標。

使用API的話須要注意一下，那就是不要給Docker daemon帶來性能負擔。若是你一臺主機有200個容器，若是很是頻繁的採集系統性能可能會大量佔據CPU時間。

最好的方式應該就是使用僞文件系統。若是你只是想經過shell來採集性能數據，則 docker stats 多是最簡單的方式了。

docker stats 命令

該命令默認以流式方式輸出，若是想打印出最新的數據並當即退出，可使用 no-stream=true 參數。

• 僞文件系統
• CPU、內存、磁盤
• 網絡

文件位置大概在（跟系統有關，這是 Systemd 的例子）：

Docker各個版本對這三種方式的支持程度不一樣，取得metric的方式和詳細程度也不一樣，其中網絡metric是在1.6.1以後才能從僞文件系統獲得。

Memory

內存的不少性能指標都來自於 memory.stat 文件：

前面的不帶total的指標，表示的是該cgroup中的process所使用的、不包括子cgroup在內的內存量，而total開頭的指標則包含了這些進程使用的包括子cgroup數據。這裏咱們看到的數據都是同樣的，因爲這裏並無子cgroup。

兩個比較重要的指標：

• RSS： resident set size

進程的全部數據堆、棧和memory map等。rss能夠進一步分類爲active和inactive（activeanon and inactiveanon）。在內存不夠須要swap一部分到磁盤的時候，會選擇inactive 的rss進行swap 。

• cache memory

緩存到內存中的硬盤文件的大小。好比你讀寫文件的時候，或者使用mapped file的時候，這個內存都會增長。這類內存也能夠再細分爲active和inactive的cache，即activefile和inactivefile。若是系統須要更多內存，則inactive的cache會被優先重用。

CPU

• cpuacct.stat文件
• docker.cpu.system
• docker.cpu.user

可是比較遺憾，Docker 不會報告nice，idle和iowait等事件。

System也叫kernel時間，主要是系統調用所耗費的部分，而user則指本身程序的耗費CPU，若是User時間高，則須要好好檢查下本身的程序是否有問題，可能須要進行優化。

Blkio

優先從CFQ（Completely Fair Queuing 徹底公平的排隊）拿數據，拿不到從這兩個文件拿： · blkio.throttle.ioservicebytes，讀寫字節數 · blkio.throttle.io_serviced，讀寫次數

Throttle這個單純可能有誤導，實際這些都不是限制值，而是實際值。每一個文件的第一個字段是 major:minor 這樣格式的device ID。

網絡數據

• iptables
• 僞文件系統
• 網絡設備接口
• Virtual Ethernet

針網絡的監控要精確到接口級別，即網卡級別。每一個容器在host上都有一個對應的virtual Ethernet，咱們能夠從這個設備得到tx和rx信息。

不過找到容器在主機上對應的虛擬網卡比較麻煩。這時候能夠在宿主機上經過 ip netns 命令從容器內部取得網絡數據。

爲了在容器所在網絡命名空間中執行 ip netns 命令，咱們首先須要找到這個容器進程的PID。

或者:

實際上Docker的實現也是從僞文件系統中讀取網絡metric的：

以上，是否是意猶未盡呢？ 下一部分，斌哥將爲你們介紹： 《Docker 監控方案的實現》

超好用的監控軟件 Cloud Insight 不只能監控 Docker，還能對 Nagios 進行更好的可視化哦~

閱讀更多技術文章，請訪問 OneAPM 官方博客。 本文轉自 OneAPM 官方博客