Docker數(shù)據(jù)采集的原理是什么

本篇內(nèi)容主要講解“Docker數(shù)據(jù)采集的原理是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Docker數(shù)據(jù)采集的原理是什么”吧!

成都創(chuàng)新互聯(lián)公司網(wǎng)站建設公司，提供成都網(wǎng)站建設、成都做網(wǎng)站，網(wǎng)頁設計，建網(wǎng)站，PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;可快速的進行網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展；專業(yè)做搜索引擎喜愛的網(wǎng)站，是專業(yè)的做網(wǎng)站團隊，希望更多企業(yè)前來合作!

監(jiān)控目的

1. 減少宕機時間

2. 擴展和性能管理

3. 資源計劃

4. 識別異常事件

5. 故障排除、分析

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

##Docker監(jiān)控面臨的挑戰(zhàn)

• Docker特點

• 像host但不是host

• 量大

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

• 微服務 集群

• 全方位

• Host（VM） + Services + Containers + Apps

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

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

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

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

集群的出現(xiàn)，使應用的拓撲結(jié)構(gòu)也變得復雜，不同應用的指標和日志格式也不統(tǒng)一，再加上要考慮應對多租戶的問題，這些都給監(jiān)控帶來了新挑戰(zhàn)。

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

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

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

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

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

##Docker 監(jiān)控技術基礎

• docker stats

• Remote API

• 偽文件系統(tǒng)

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

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

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

docker stats 命令

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

• 偽文件系統(tǒng)

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

• 網(wǎng)絡

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

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

Memory

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

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

兩個比較重要的指標：

• RSS： resident set size

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

• cache memory

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

CPU

• cpuacct.stat文件

• docker.cpu.system

• docker.cpu.user

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

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

Blkio

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

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

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

• iptables

• 偽文件系統(tǒng)

• 網(wǎng)絡設備接口

• Virtual Ethernet

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

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

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

或者:

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

到此，相信大家對“Docker數(shù)據(jù)采集的原理是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！

當前文章：Docker數(shù)據(jù)采集的原理是什么
網(wǎng)頁地址：http://muchs.cn/article0/pishoo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、標簽優(yōu)化、動態(tài)網(wǎng)站、網(wǎng)站排名、品牌網(wǎng)站建設、網(wǎng)站設計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)