如何使用cAdvisor和Wavefront监控容器
生活随笔
收集整理的這篇文章主要介紹了
如何使用cAdvisor和Wavefront监控容器
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
本文講的是如何使用cAdvisor和Wavefront監控容器【編者的話】本文對容器的可視化做了一些研究與探討,揭示了容器資源指標監控的重要性。
據說僅僅在過去一年里Docker的使用量就翻了一倍,那么對容器監控的需求越來越急迫也在情理之中。雖然使用容器帶來了很多好處,但是它在幫助我們簡化很多工作的同時也帶了額外的粒度和依賴性管理。這就是為什么可視化運行態容器很重要的原因。
更令人驚訝的是,直到目前為止,仍然沒有用來監控Docker容器資源指標的直觀方法。
Docker 1.5中引入的Docker Stats API帶來了從容器中輸出資源指標(CPU和內存使用量)的能力。而且也有很多開源的項目致力于容器的監控,這其中就包括Google的 cAdvisor 。從cAdvisor這個項目的 GitHub 上可以了解到cAdvisor這個工具是:
一個收集、聚合、處理以及導出運行態容器相關信息的后臺進程。它為每個容器保留了隔離資源的參數、歷史資源使用量、所有歷史資源用量的矩形圖以及網絡統計。這些數據是由容器以及服務器導出的。
docker?run?\ --volume=/:/rootfs:ro?\ --volume=/var/run:/var/run:rw?\ --volume=/sys:/sys:ro?\ --volume=/var/lib/docker/:/var/lib/docker:ro?\ --publish=8080:8080?\ --detach=true?\ --name=cadvisor?\ google/cadvisor:latest?\ -storage_driver=statsd?\ -storage_driver_host=your_statsd_host:8125?\ -storage_driver_db=docker001
通過上面的命令,cAdvisor就可以立即輸出指標到StatsD服務器上。這些指標已下面的命令格式創建:
stats.gauges.<storage_driver_db>.<container?name>.<metric?name>
Storage_driver_db是你的Docker主機傳送給cAdvisor的任意一個名字。在這個案例里,我們使用了 docker001 :
cAdvisor也提供存儲相關的資源指標,但是當你有掛載的數據卷的時候,監控起來就很困難。
在遷移后很短的時間內,我們給這個應用加了一些Twitter的賬戶。這讓它每秒處理的tweets增加到超過8個,有40倍的增長。毫無意外地,這樣地增長給資源用來帶來了很大的影響。
只要運行cAdvisor就可以得到這些信息,無需其他操作。如果你用容器隔離應用,你可以很明顯地從CPU、內存和吞吐量看出你的改變帶來的影響。在這里我們只看了CPU,但是其他的資源指標都展現了類似的行為。
上面的圖表表明CPU使用量和Tweet處理量是線性相關的。通過這條線,我們可以預測在CPU使用量達到100%之前,這個服務器能夠處理的tweets上限。
以前,發現數據之間的關系意味著手頭要有比較準確的統計數字,甚至一些代碼。在Wavefront里,只需要點兩下鼠標就可以了。
原文鏈接:How to Monitor Containers with cAdvisor and Wavefront(翻譯:Lambert Sun)
===========================================================
譯者介紹
據說僅僅在過去一年里Docker的使用量就翻了一倍,那么對容器監控的需求越來越急迫也在情理之中。雖然使用容器帶來了很多好處,但是它在幫助我們簡化很多工作的同時也帶了額外的粒度和依賴性管理。這就是為什么可視化運行態容器很重要的原因。
更令人驚訝的是,直到目前為止,仍然沒有用來監控Docker容器資源指標的直觀方法。
Docker 1.5中引入的Docker Stats API帶來了從容器中輸出資源指標(CPU和內存使用量)的能力。而且也有很多開源的項目致力于容器的監控,這其中就包括Google的 cAdvisor 。從cAdvisor這個項目的 GitHub 上可以了解到cAdvisor這個工具是:
一個收集、聚合、處理以及導出運行態容器相關信息的后臺進程。它為每個容器保留了隔離資源的參數、歷史資源使用量、所有歷史資源用量的矩形圖以及網絡統計。這些數據是由容器以及服務器導出的。
運行cAdvisor
cAdvisor最棒的一點在于它運行起來非常簡單。因為它本身就是運行在容器里,所以你可以像運行其他任何容器一樣把它運行起來,運行的結果是可預知并且始終一致的。它也可以和一些在容器外的 storage driver 打包使用。當你指定了storage driver參數的時候,它會自動把資源指標導出到對應的storage driver上。比如,下面的命令會在任意一個Docker主機上創建一個cAdvisor實例,然后把資源指標導出到一個StatsD服務器上:docker?run?\ --volume=/:/rootfs:ro?\ --volume=/var/run:/var/run:rw?\ --volume=/sys:/sys:ro?\ --volume=/var/lib/docker/:/var/lib/docker:ro?\ --publish=8080:8080?\ --detach=true?\ --name=cadvisor?\ google/cadvisor:latest?\ -storage_driver=statsd?\ -storage_driver_host=your_statsd_host:8125?\ -storage_driver_db=docker001
在Wavefront中查看容器指標
最近,我們把之前用來做演示的服務以及相關功能整合到新的服務器上。當我們開始做這件事時,我們想要用Docker重新部署。通過把每個服務隔離在容器中,我們可以簡化部署和擴展的流程。我們也能夠用cAdvisor隔離每個容器的資源指標。當你在同一個主機上運行多個容器的時候,這就特別有用,和我們的情況一樣。通過上面的命令,cAdvisor就可以立即輸出指標到StatsD服務器上。這些指標已下面的命令格式創建:
stats.gauges.<storage_driver_db>.<container?name>.<metric?name>
Storage_driver_db是你的Docker主機傳送給cAdvisor的任意一個名字。在這個案例里,我們使用了 docker001 :
cAdvisor也提供存儲相關的資源指標,但是當你有掛載的數據卷的時候,監控起來就很困難。
對比容器資源使用量
我們遷移的其中一個服務是Twitter流處理應用。這個Twitter流處理應用(下圖中的“twittermentionstream”)只從少量support賬戶處理tweets。在Twitter流量高峰時間段時,它處理的tweets每秒也不到0.2個。但是,它在我們的容器中仍然是消耗CPU最多的:在遷移后很短的時間內,我們給這個應用加了一些Twitter的賬戶。這讓它每秒處理的tweets增加到超過8個,有40倍的增長。毫無意外地,這樣地增長給資源用來帶來了很大的影響。
只要運行cAdvisor就可以得到這些信息,無需其他操作。如果你用容器隔離應用,你可以很明顯地從CPU、內存和吞吐量看出你的改變帶來的影響。在這里我們只看了CPU,但是其他的資源指標都展現了類似的行為。
用容器指標規劃產能
舉個例子,當我們想給這個流處理應用增加更多Twitter賬戶時,我們可以從上面的圖表里面知道這個應用每秒處理8個tweets時使用了服務器將近40%的CPU。因此,我們會想要評估一下CPU使用量和Tweet處理量之前的相關性。上面的圖表表明CPU使用量和Tweet處理量是線性相關的。通過這條線,我們可以預測在CPU使用量達到100%之前,這個服務器能夠處理的tweets上限。
以前,發現數據之間的關系意味著手頭要有比較準確的統計數字,甚至一些代碼。在Wavefront里,只需要點兩下鼠標就可以了。
結論
選用容器是大的趨勢,我們從未看見這個趨勢變緩。我們會繼續評估容器可視化的趨勢以及開發工作,然后以博客的形式發出來,因為越來越多的人在詢問相關的事情。Google的cAdvisor提供了一個非常快速而且簡單有效的方法來從容器獲取資源指標到Wavefront。原文鏈接:How to Monitor Containers with cAdvisor and Wavefront(翻譯:Lambert Sun)
===========================================================
譯者介紹
Lambert Sun,趨勢科技DevOps Lead,敏捷開發實踐者。
原文發布時間為:2016-06-19
本文作者:Lambert Sun
本文來自云棲社區合作伙伴Dockerone.io,了解相關信息可以關注Dockerone.io。
原文標題:如何使用cAdvisor和Wavefront監控容器
總結
以上是生活随笔為你收集整理的如何使用cAdvisor和Wavefront监控容器的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 24微信小程序开发2
- 下一篇: java 解析3层xml_java实战之