過去的一年中，關於 docker 的話題從未斷過，而如今，從嘗試 docker 到最終決定使用 docker 的轉化率依然在逐步公升高，關於 docker 的討論更是有增無減。另一方面，大家的注意力也漸漸從 「docker 是什麼」轉移到「實踐 docker」與「監控 docker」上。
本文**劉斌博文「如何選擇 docker 監控方案 」，文中劉斌從技術的角度深入解釋了 docker 監控的資料採集原理，介紹了現有開源的監控方案，以及能夠對 docker 進行監控功能的主流 saas 服務工具。
劉斌，擁有 10 多年程式設計經驗，曾參與翻譯過「第一本 docker 書」、「github 入門與實踐」、「web 應用安全權威指南」等多本技術書籍，主講過「docker入門與實踐 」課程的 cloud insight 後台工程師。
作為一名工程師，我們要對自己系統的執行狀態瞭如指掌，有問題及時發現，而不是讓使用者先發現系統不能使用，打**找客服，再反映到開發。這個過程很長，而且對工程師來說，是一件比較沒面子的事情。
當領導問我們這個月的 mysql 併發什麼情況？slowsql 處於什麼水平，平均響應時間超過 200ms 的佔比有百分之多少的時候，回答不出來這個問題很尷尬。儘管你工作很辛苦，但是卻沒有拿得出來的成果。不能因為暫時沒出問題就掉以輕心，換位想想，站在領導的角度，領導什麼都不幹，你提案，他簽字，出了誰背鍋？
監控目的
減少宕機時間
擴充套件和效能管理
資源計畫
識別異常事件
故障排除、分析
為什麼需要監控我們的服務？其中有一些顯而易見的原因，比如需要監控工具來提醒服務故障，比如通過監控服務的負載來決定擴容或縮容。如果機器普遍負載不高，則可以考慮縮減一下機器規模，如果資料庫連線經常維持在乙個高位水平，則可以考慮一下是否可以進行拆庫處理，優化一下架構。
微服務 集群
全方位
容器為我們的開發和運維帶來了更多的方向和可能性，我們也需要一種現代的監控方案來應對這種變化。
隨著不可變基礎設施概念的普及，雲原生應用的興起，雲計算元件已經越來越像搭建玩具的積木塊。很多基礎設施生命週期變短，不光容器如此，雲主機、vm也是。
在雲計算出現之前，一台機器可能使用3、5年甚至更長都不需要重灌，主機名也不會變，而現在，可能公升級乙個版本，就要重建乙個雲主機或重新啟動乙個容器。監控物件動態變化，而且非常頻繁。即使全部實現自動化，也會在負載和複雜度方面帶來不利影響。
監控還有助於進行內部統制，尤其是對安全比較敏感的行業，比如**、銀行等。比如伺服器受到攻擊時，我們需要分析事件，找到根本原因，識別類似攻擊，發現未知的被攻擊系統，甚至完成取證等工作。
集群的出現，使應用的拓撲結構也變得複雜，不同應用的指標和日誌格式也不統一，再加上要考慮應對多租戶的問題，這些都給監控帶來了新挑戰。
傳統的監控內包括對主機、網路和應用的監控，但是docker出現之後，容器這一層很容易被忽略，成為三不管地區，即監控的盲點。
有人說，容器不就是個普通的os麼？裝個zabbix的探針不就行了麼？docker host和docker 容器都要裝 zabbix探針……其實問題很多。
除了容器內部看到的cpu記憶體情況不准之外，而且容器生命周期短，重啟之後host名，ip位址都會變，所以最好在docker host上安裝zabbix agent。
如果每個容器都像os那樣監控，則metric數量將會非常巨大，而且這些資料很可能幾分鐘之後就無效率了（容器已經停止）。容器生命週期短暫，一旦容器結束執行，之前收集的資料將不再有任何意義。
我們可以通過 docker stats 命令或者remote api以及linux的偽檔案系統來獲取容器的效能指標。
使用api的話需要注意一下，那就是不要給docker daemon帶來效能負擔。如果你一台主機有200個容器，如果非常頻繁的採集系統效能可能會大量佔據cpu時間。
最好的方式應該就是使用偽檔案系統。如果你只是想通過shell來採集效能資料，則 docker stats 可能是最簡單的方式了。
docker stats 命令
該命令預設以流式方式輸出，如果想列印出最新的資料並立即退出，可以使用 no-stream=true 引數。
檔案位置大概在（跟系統有關，這是 systemd 的例子）：
docker各個版本對這三種方式的支援程度不同，取得metric的方式和詳細程度也不同，其中網路metric是在1.6.1之後才能從偽檔案系統得到。
memory
記憶體的很多效能指標都來自於 memory.stat 檔案：
前面的不帶total的指標，表示的是該cgroup中的process所使用的、不包括子cgroup在內的記憶體量，而total開頭的指標則包含了這些程序使用的包括子cgroup資料。這裡我們看到的資料都是一樣的，由於這裡並沒有子cgroup。
兩個比較重要的指標：
程序的所有資料堆、棧和memory map等。rss可以進一步分類為active和inactive（activeanon and inactiveanon）。在記憶體不夠需要swap一部分到磁碟的時候，會選擇inactive 的rss進行swap 。
cpu
但是比較遺憾，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。
網路資料
針網路的監控要精確到介面級別，即網絡卡級別。每個容器在host上都有乙個對應的virtual ethernet，我們可以從這個裝置獲得tx和rx資訊。
不過找到容器在主機上對應的虛擬網絡卡比較麻煩。這時候可以在宿主機上通過 ip netns 命令從容器內部取得網路資料。
為了在容器所在網路命名空間中執行 ip netns 命令，我們首先需要找到這個容器程序的pid。
或者:
實際上docker的實現也是從偽檔案系統中讀取網路metric的：
超好用的監控軟體 cloud insight 不僅能監控 docker，還能對 nagios 進行更好的視覺化哦~
斌哥的 Docker 高階指南
過去的一年中，關於 docker 的話題從未斷過，而如今，從嘗試 docker 到最終決定使用 docker 的轉化率依然在逐步公升高，關於 docker 的討論更是有增無減。另一方面，大家的注意力也漸漸從 docker 是什麼 轉移到 實踐 docker 與 監控 docker 上。本文 劉斌博文...
Nmap的高階用法指南
很多人都只是簡單的用 o sv引數來探測，我把我的探測方法說一下。nmap p0 st vv n p80 script show tpversion.nse il c tp.txt on c vulnerable.txt sv version all 探測應用程式版本，使用最高強度探測 o ossc...
Nmap的高階用法指南
今用nmap的時侯發現nmap提示happy 10th birthday to nmap,may it live to be 110 它已經10周歲生日了，也許可以可以活到110歲 沒想到97年9月1日是它誕生的日子，10年磨一劍啊。為了紀念這個偉大的埠掃瞄器之王，另外網上流傳的幾個版本教程都是好幾...