摘要：斌哥是誰(shuí)劉斌，擁有多年編程經(jīng)驗(yàn)，曾參與翻譯過(guò)第一本書入門與實(shí)踐應(yīng)用安全權(quán)威指南等多本技術(shù)書籍，主講過(guò)入門與實(shí)踐課程的后臺(tái)工程師。主要的解決方式就是以或者為單位進(jìn)行監(jiān)控通過(guò)等方式。

過(guò)去的一年中，關(guān)于 Docker 的話題從未斷過(guò)，而如今，從嘗試 Docker 到最終決定使用 Docker 的轉(zhuǎn)化率依然在逐步升高，關(guān)于 Docker 的討論更是有增無(wú)減。另一方面，大家的注意力也漸漸從 “Docker 是什么”轉(zhuǎn)移到“實(shí)踐 Docker”與“監(jiān)控 Docker”上。

本文轉(zhuǎn)自劉斌博文「如何選擇 Docker 監(jiān)控方案 」，文中劉斌從技術(shù)的角度深入解釋了 Docker 監(jiān)控的數(shù)據(jù)采集原理，介紹了現(xiàn)有開源的監(jiān)控方案，以及能夠?qū)?Docker 進(jìn)行監(jiān)控功能的主流 SaaS 服務(wù)工具。

劉斌，擁有 10 多年編程經(jīng)驗(yàn)，曾參與翻譯過(guò)「第一本 Docker 書」、「GitHub 入門與實(shí)踐」、「Web 應(yīng)用安全權(quán)威指南」等多本技術(shù)書籍，主講過(guò)「Docker入門與實(shí)踐 」課程的 Cloud Insight 后臺(tái)工程師。

作為一名工程師，我們要對(duì)自己系統(tǒng)的運(yùn)行狀態(tài)了如指掌，有問(wèn)題及時(shí)發(fā)現(xiàn)，而不是讓用戶先發(fā)現(xiàn)系統(tǒng)不能使用，打電話找客服，再反映到開發(fā)。這個(gè)過(guò)程很長(zhǎng)，而且對(duì)工程師來(lái)說(shuō)，是一件比較沒(méi)面子的事情。

當(dāng)領(lǐng)導(dǎo)問(wèn)我們這個(gè)月的 MySQL 并發(fā)什么情況？slowsql 處于什么水平，平均響應(yīng)時(shí)間超過(guò) 200ms 的占比有百分之多少的時(shí)候，回答不出來(lái)這個(gè)問(wèn)題很尷尬。盡管你工作很辛苦，但是卻沒(méi)有拿得出來(lái)的成果。不能因?yàn)闀簳r(shí)沒(méi)出問(wèn)題就掉以輕心，換位想想，站在領(lǐng)導(dǎo)的角度，領(lǐng)導(dǎo)什么都不干，你提案，他簽字，出了誰(shuí)背鍋？

監(jiān)控目的

減少宕機(jī)時(shí)間

擴(kuò)展和性能管理

資源計(jì)劃

識(shí)別異常事件

故障排除、分析

為什么需要監(jiān)控我們的服務(wù)？其中有一些顯而易見(jiàn)的原因，比如需要監(jiān)控工具來(lái)提醒服務(wù)故障，比如通過(guò)監(jiān)控服務(wù)的負(fù)載來(lái)決定擴(kuò)容或縮容。如果機(jī)器普遍負(fù)載不高，則可以考慮縮減一下機(jī)器規(guī)模，如果數(shù)據(jù)庫(kù)連接經(jīng)常維持在一個(gè)高位水平，則可以考慮一下是否可以進(jìn)行拆庫(kù)處理，優(yōu)化一下架構(gòu)。

Docker特點(diǎn)

像host但不是host

量大

生命周期短 監(jiān)控盲點(diǎn)（斷層）

微服務(wù) 集群

全方位

Host（VM） + Services + Containers + Apps

容器為我們的開發(fā)和運(yùn)維帶來(lái)了更多的方向和可能性，我們也需要一種現(xiàn)代的監(jiān)控方案來(lái)應(yīng)對(duì)這種變化。

隨著不可變基礎(chǔ)設(shè)施概念的普及，云原生應(yīng)用的興起，云計(jì)算組件已經(jīng)越來(lái)越像搭建玩具的積木塊。很多基礎(chǔ)設(shè)施生命周期變短，不光容器如此，云主機(jī)、VM也是。

在云計(jì)算出現(xiàn)之前，一臺(tái)機(jī)器可能使用3、5年甚至更長(zhǎng)都不需要重裝，主機(jī)名也不會(huì)變，而現(xiàn)在，可能升級(jí)一個(gè)版本，就要重建一個(gè)云主機(jī)或重新啟動(dòng)一個(gè)容器。監(jiān)控對(duì)象動(dòng)態(tài)變化，而且非常頻繁。即使全部實(shí)現(xiàn)自動(dòng)化，也會(huì)在負(fù)載和復(fù)雜度方面帶來(lái)不利影響。

監(jiān)控還有助于進(jìn)行內(nèi)部統(tǒng)制，尤其是對(duì)安全比較敏感的行業(yè)，比如證券、銀行等。比如服務(wù)器受到攻擊時(shí)，我們需要分析事件，找到根本原因，識(shí)別類似攻擊，發(fā)現(xiàn)未知的被攻擊系統(tǒng)，甚至完成取證等工作。

集群的出現(xiàn)，使應(yīng)用的拓?fù)浣Y(jié)構(gòu)也變得復(fù)雜，不同應(yīng)用的指標(biāo)和日志格式也不統(tǒng)一，再加上要考慮應(yīng)對(duì)多租戶的問(wèn)題，這些都給監(jiān)控帶來(lái)了新挑戰(zhàn)。

傳統(tǒng)的監(jiān)控內(nèi)包括對(duì)主機(jī)、網(wǎng)絡(luò)和應(yīng)用的監(jiān)控，但是Docker出現(xiàn)之后，容器這一層很容易被忽略，成為三不管地區(qū)，即監(jiān)控的盲點(diǎn)。

有人說(shuō)，容器不就是個(gè)普通的OS么？裝個(gè)Zabbix的探針不就行了么？Docker host和Docker 容器都要裝 Zabbix探針……其實(shí)問(wèn)題很多。

除了容器內(nèi)部看到的cpu內(nèi)存情況不準(zhǔn)之外，而且容器生命周期短，重啟之后host名，ip地址都會(huì)變，所以最好在Docker host上安裝Zabbix agent。

如果每個(gè)容器都像OS那樣監(jiān)控，則metric數(shù)量將會(huì)非常巨大，而且這些數(shù)據(jù)很可能幾分鐘之后就無(wú)效率了（容器已經(jīng)停止）。容器生命周期短暫，一旦容器結(jié)束運(yùn)行，之前收集的數(shù)據(jù)將不再有任何意義。

主要的解決方式就是以App或者Service為單位進(jìn)行監(jiān)控（通過(guò)Tag等方式）。

docker stats

Remote API

偽文件系統(tǒng)

我們可以通過(guò) docker stats 命令或者Remote API以及Linux的偽文件系統(tǒng)來(lái)獲取容器的性能指標(biāo)。

使用API的話需要注意一下，那就是不要給Docker daemon帶來(lái)性能負(fù)擔(dān)。如果你一臺(tái)主機(jī)有200個(gè)容器，如果非常頻繁的采集系統(tǒng)性能可能會(huì)大量占據(jù)CPU時(shí)間。

最好的方式應(yīng)該就是使用偽文件系統(tǒng)。如果你只是想通過(guò)shell來(lái)采集性能數(shù)據(jù)，則 docker stats 可能是最簡(jiǎn)單的方式了。

docker stats 命令

該命令默認(rèn)以流式方式輸出，如果想打印出最新的數(shù)據(jù)并立即退出，可以使用 no-stream=true 參數(shù)。

偽文件系統(tǒng)

CPU、內(nèi)存、磁盤

網(wǎng)絡(luò)

文件位置大概在（跟系統(tǒng)有關(guān)，這是 Systemd 的例子）：

Docker各個(gè)版本對(duì)這三種方式的支持程度不同，取得metric的方式和詳細(xì)程度也不同，其中網(wǎng)絡(luò)metric是在1.6.1之后才能從偽文件系統(tǒng)得到。

Memory

內(nèi)存的很多性能指標(biāo)都來(lái)自于 memory.stat 文件：

前面的不帶total的指標(biāo)，表示的是該cgroup中的process所使用的、不包括子cgroup在內(nèi)的內(nèi)存量，而total開頭的指標(biāo)則包含了這些進(jìn)程使用的包括子cgroup數(shù)據(jù)。這里我們看到的數(shù)據(jù)都是一樣的，由于這里并沒(méi)有子cgroup。

兩個(gè)比較重要的指標(biāo)：

RSS： resident set size

進(jìn)程的所有數(shù)據(jù)堆、棧和memory map等。rss可以進(jìn)一步分類為active和inactive（activeanon and inactiveanon）。在內(nèi)存不夠需要swap一部分到磁盤的時(shí)候，會(huì)選擇inactive 的rss進(jìn)行swap 。

cache memory

緩存到內(nèi)存中的硬盤文件的大小。比如你讀寫文件的時(shí)候，或者使用mapped file的時(shí)候，這個(gè)內(nèi)存都會(huì)增加。這類內(nèi)存也可以再細(xì)分為active和inactive的cache，即activefile和inactivefile。如果系統(tǒng)需要更多內(nèi)存，則inactive的cache會(huì)被優(yōu)先重用。

CPU

cpuacct.stat文件

docker.cpu.system

docker.cpu.user

但是比較遺憾，Docker 不會(huì)報(bào)告nice，idle和iowait等事件。

System也叫kernel時(shí)間，主要是系統(tǒng)調(diào)用所耗費(fèi)的部分，而user則指自己程序的耗費(fèi)CPU，如果User時(shí)間高，則需要好好檢查下自己的程序是否有問(wèn)題，可能需要進(jìn)行優(yōu)化。

Blkio

優(yōu)先從CFQ（Completely Fair Queuing 完全公平的排隊(duì)）拿數(shù)據(jù)，拿不到從這兩個(gè)文件拿： · blkio.throttle.ioservicebytes，讀寫字節(jié)數(shù) · blkio.throttle.io_serviced，讀寫次數(shù)

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

網(wǎng)絡(luò)數(shù)據(jù)

iptables

偽文件系統(tǒng)

網(wǎng)絡(luò)設(shè)備接口

Virtual Ethernet

針網(wǎng)絡(luò)的監(jiān)控要精確到接口級(jí)別，即網(wǎng)卡級(jí)別。每個(gè)容器在host上都有一個(gè)對(duì)應(yīng)的virtual Ethernet，我們可以從這個(gè)設(shè)備獲得tx和rx信息。

不過(guò)找到容器在主機(jī)上對(duì)應(yīng)的虛擬網(wǎng)卡比較麻煩。這時(shí)候可以在宿主機(jī)上通過(guò) ip netns 命令從容器內(nèi)部取得網(wǎng)絡(luò)數(shù)據(jù)。

為了在容器所在網(wǎng)絡(luò)命名空間中執(zhí)行 ip netns 命令，我們首先需要找到這個(gè)容器進(jìn)程的PID。

或者:

實(shí)際上Docker的實(shí)現(xiàn)也是從偽文件系統(tǒng)中讀取網(wǎng)絡(luò)metric的：

以上，是不是意猶未盡呢？ 下一部分，斌哥將為大家介紹： 《Docker 監(jiān)控方案的實(shí)現(xiàn)》

超好用的監(jiān)控軟件 Cloud Insight 不僅能監(jiān)控 Docker，還能對(duì) Nagios 進(jìn)行更好的可視化哦~

閱讀更多技術(shù)文章，請(qǐng)?jiān)L問(wèn) OneAPM 官方博客。
本文轉(zhuǎn)自 OneAPM 官方博客