斌哥的 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 官方博客