容器監控的工具和流程

【編者的話】在容器和微服務場景中，監控解決方案有很多種，包括Docker原生的Stats API和命令、cAdvisor，還有Prometheus和Sysdig這樣相對複雜和功能強大的工具，除此之外還有很多供應商提供的解決方案。

隨著容器和微服務的引入，監控解決方案必須處理比以往任何時候都要更多的短生命周期服務和服務實例。雖然基礎設施的場景發生了變化，運維團隊仍然需要在中央處理器（CPU）、隨機存取存儲器（RAM）、硬碟驅動器（HDD）、網路利用率以及應用程序節點的可用性等方面監控相同的信息。

雖然您可以為傳統的基礎設施使用舊工具或現有的監控服務，現在有更新的基於雲的服務可以確保在服務被構建和監控時監控解決方案是可伸縮的。許多基於雲的和自託管的工具都是為容器而設計的。不管您使用什麼解決方案或服務，你仍然需要知道如何收集你正想監控的度量指標。

當從你的容器收集度量標準時，有相當多的選項。本文考察了一些對於容器監控有用的軟體和服務。我們已經引入了一個混合了自託管的開源解決方案以及商業的雲服務的方式，以反映當前的場景。然而，重要的是要記住，與各種各樣的可用的解決方案相比，我們引入的還是相對少量的例子。這些例子的目的是展示幾種不同的方法來解決收集度量指標的問題。

Docker

Docker Engine本身就提供了訪問大部分的我們正想收集的可以作為原生監控功能的核心度量指標的能力。運行docker stats命令可以訪問運行在你的主機上的所有容器的CPU、內存、網路和磁碟利用率。



圖1：運行docker stats命令

如果你需要在任何給定的時刻獲得有關容器的快速概況，那麼數據是自動流動的並且是有用的，比如您可以添加一些flag：

• flag -all 顯示你停止了容器，儘管你看不到任何度量指標

• flag -no-stream顯示第一個運行的輸出，然後停止度量指標的數據流

這種方式有一些缺點，第一個就是數據沒有在任何地方存儲——你不能回溯並審查度量指標。另外就是會非常乏味地在沒有參考點的情況下看著一個個不斷刷新的端點，很難定位數據中有什麼奧秘。

幸運的是，docker stats命令實際上是一個對於stats應用程序介面（API）端點的命令行界面，stats API暴露了stats命令所有的信息甚至更多。要親自查看，請運行以下命令：

curl --unix-socket /var/run/docker.sock http:/containers/container_name/stats

正如你從輸出中看到的，會有更多的返回信息，它們都是以JSON Array封裝的並且可以被第三方工具所接納。

cAdvisor

cAdvisor是來自Google的原生支持Docker容器的監控工具，這是一個收集、整合、處理以及輸出當前運行容器信息的守護進程，cAdvisor其實就是如果你運行docker stats -all命令所獲得的信息的圖形化版本，這也是理解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

cAdvisor容易啟動和運行，因為它是在一個容器里交付的。你所需要做的只是運行上述的命令就可以啟動cAdvisor容器並在埠8080上公開web界面。

一旦啟動之後，cAdvisor會在運行在宿主機上的Docker Daemon里打入一個它自身的鉤子並且立即開始收集你所有的正運行的容器的度量指標，包括cAdvisor容器自身在內 。在瀏覽器中打開http://localhost:8080/ 將會帶你直接到web界面。



圖2：訪問本地的web界面

正如你從圖2中看到的，裡邊有著一分鐘的實時數據流，然而，鑒於這個只是cAdvisor的標準安裝，你不能觀察到更多深入的度量指標。幸運的是，Google已經通過引入一些選項來從cAdvisor導出數據到時間序列資料庫比如Elasticsearch、influxDB、BigQueery和Prometheus。

總而言之，cAdvisor是一個很棒的快速洞悉正在運行的容器所發生的一切的工具，它安裝非常簡單，並能賦予你比開箱即用的Docker更細粒度的度量指標。它也可以作為一個其它工具的監控代理，同樣的方式在過去Zabbix或Nagios代理也使用過的。

Prometheus

Prometheus是一個開源的監控系統和時間序列資料庫，最初是由SoundCloud搭建的，目前這是由雲原生計算基金會（CNCF）託管的，同樣的項目還有K8S和OpenTracing。在閱讀服務描述時，可能聽起來很像傳統的服務和代理設置，然而，Prometheus的工作方式是不同的，它從主機上的數據節點刮取數據並存儲到它自己的時間序列資料庫而不是它自己的代理。

在2016年10月底，一個在Docker Engine本身內部公開度量指標端點的pull request被合併了。這可能意味著即將發布的Docker新版本將會開箱即用的支持Prometheus刮取容器度量指標的功能，然而在新版本發布之前，你仍然需要使用中介服務諸如cAdvisor。截止到1.13版本，Docker Engine支持可選的「/metrics」Prometheus端點。目前重要的是要注意，這會暴露內部的Docker度量指標而不是容器度量指標。目前正在進行的討論是將其擴展到涵蓋容器度量指標，甚至可能完全取代Stats API。

Prometheus最大的優勢是可以作為數據源。你可以在前面用Prometheus與Grafana刮取數據，其中Grafana在2015年年中就開始支持Prometheus了，現在是Prometheus推薦的前置系統。類似於大多數我們看到的工具，Grafana也可以作為容器啟動。

一旦啟動並運行后，唯一需要的配置是添加你的Prometheus URL作為數據源，然後導入一個預定義的Prometheus Dashboard。



圖3：度量指標存儲在Prometheus中並用Grafana中顯示

圖3的Dashboard顯示了來自於cAdvisor並存儲在Prometheus用Grafana渲染的超過一個多小時信息，Prometheus基本上是以當前cAdvisor的狀態作為快照的，它也記錄了早已刪除的容器的度量指標。

Prometheus還具有告警功能，通過使用內置的上報語言，你可以創建如下的告警：

ALERT InstanceDownIF up == 0FOR 5mLABELS { severity = "page" }ANNOTATIONS {summary = "Instance {{ $labels.instance }} down",description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",}

一旦告警已經寫完並在Prometheus伺服器上部署，你可以使用Prometheus Alertmanager來路由你的告警。上面的例子中，我們已經指定了一個標籤severity = 「page」，Alertmanager將會攔截告警並轉發告警到一個服務比如PagerDuty、OpsGenie、一個Slack或者HipChat channel，或者任意數量的不同端點。

Prometheus是一個強大的平台，並且作為不同技術的中間人表現優異。它可以非常容易從類似於上述的一個基本的安裝開始起步，然後進行擴展，賦予一個單一的窗格視圖可以同時獲得你的容器和宿主機實例信息。

無代理的系統爬蟲

無代理的系統爬蟲（ASC）是一個來自於IBM的支持容器的雲監控工具。它從運行的容器收集監控信息，包括度量指標、系統狀態和配置信息。ASC提供了對於容器的深度可見性，不僅僅是利用率和性能指標，還有安全和配置分析。它被設計成一個管道，用於為容器構建收集插件，為動態的數據聚合或分析提供功能插件，以及為目標監控和分析端點提供輸出插件。提供的插件包括了傳統的數據收集功能比如利用率指標、容器內運行的進程及監聽的埠，還有與配置文件和應用包相關的數據。

ASC可以部署作為一個Python包或者作為一個單獨的具備特權的容器，例如，ASC可以與Docker Daemon、容器cgroup和namespace交互，這裡是如何以容器方式方式啟動ASC：

docker run \ --privileged \ --net=host \ --pid=host \ -v /cgroup:/cgroup:ro \ -v /var/lib/docker:/var/lib/docker:ro \ -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ -v /var/run/docker.sock:/var/run/docker.sock \ -it crawler --crawlmode OUTCONTAINER ${CRAWLER_ARGS}

一旦運行后，它就會向Docker Daemon訂閱事件並周期性地監控系統內運行的所有容器。ASC可以非常容易地利用插件為定製化數據收集進行擴展，有助於收集容器和環境的信息。每一個插件都可以為一個特定的監控功能簡單地導出一個crawl()方法，ASC迭代每一個被在部署配置中啟用的收集插件實現的crawl()方法。ASC當前可以被配置為導出數據到Kafka、Graphite、文件系統和控制台端點以及允許額外的輸出插件。圖4展示了一個從ASC配置的視圖例子，將容器數據導出到一個Graphite/Grafana端點。



圖4：ASC藉助於Graphite/Grafana監控容器的視圖

ASC的一個使用案例就是獲得更深層次的容器執行的信息，下面的例子顯示了當配置為除了基礎度量指標之外還收集容器的進程和連接特性時的ASC的基本輸出幀。基於這個幀，我們可以看到這是一個CPU佔用率為100%的容器，其中有一個Python進程監聽5000埠。

metadata "metadata" {"id":"ef0fc187dc0a4b85a3cb", …}cpu "cpu-0" {… ,"cpu_util":100.0}process "python/1" {"cmd":"python web.py",..."python","pid":74, …}connection "74/127.0.0.1/5000"...{"pid":74,…,"connstatus":"LISTEN"}

這使用戶能夠將監控與系統狀態耦合，更好地了解容器的行為，並推動額外的分析。比如，我們可以更加深入挖掘容器中使用的Python進程，並在本例中通過啟用另外一個功能插件「python-package」來追蹤應用使用的底層Python包，該插件賦予了我們額外的可以洞悉應用中已使用的包和版本的信息的能力：

python-package "click" {"ver":"6.6","pkgname":"click"}python-package "Flask" {"ver":"0.11.1","pkgname":"Flask"}python-package "itsdangerous"{"ver":"0.24",..."pkgname":"itsdangerous"}python-package "Jinja2" {"ver":"2.8","pkgname":"Jinja2"}python-package "pip" {"ver":"8.1.2","pkgname":"pip"}python-package "setuptools" {"ver":"20.8.0",..."pkgname":"setuptools"}python-package "Werkzeug" {"ver":"0.11.11",..."pkgname":"Werkzeug"}

總之，ASC是一個易於安裝和使用的工具，類似於cAdvisor來獲得當前運行的容器內部的信息。除了基本的監控度量指標外，ASC還把重點放在了容器狀態和配置的深度可見性方面，從而啟用了監控、安全和其它的分析解決方案。它為數據收集的可擴展性和不同端點的支持提供了一個簡單的、基於插件的方式。

Sysdig

Sysdig有兩個不同的版本，第一個是在宿主機上安裝了一個內核模塊的開源版本，第二個是名為Sysdig Cloud的雲和本地解決方案，其使用開源版本並且將收集的度量指標流向到Sysdig自己的伺服器。

開源Sysdig

Sysdig的開源版本就像運行docker stats命令，服務會在宿主機內核打鉤，這意味著它完全不用依賴從Docker Damon來獲得度量指標。

使用Csysdig這個內置的基於ncurses的命令行介面，你可以查看你的宿主機的各種各樣的信息。舉例來說，運行csysdig -vcontainers命令可以獲得圖5的視圖。



圖5：使用Sysdig的命令行介面

正如您可以看到的，這裡展示了宿主機上運行的所有容器，你還可以進入容器內部來查看單個進程所消耗的資源。就像運行docker stats命令和使用cAdvisor一樣，Sysdig的開源版本也是可以獲得你的容器的實時視圖的，然而，你可以使用如下的命令來記錄和回放系統活動：

• sysdig -w trace.scap命令記錄系統活動到一個跟蹤文件。

• csysdig -r trace.scap命令回放跟蹤文件。

Sysdig的開源版本不是傳統監控工具，它允許你深入你的容器，獲得更廣泛的信息。它還允許你通過直接在你的編排系統打鉤來添加編排上下文環境，從而允許你對Pod、集群、namespace以及其它方面進行故障排除。

Sysdig Cloud

Sysdig Cloud獲得開源版本抓取的所有數據后並用強大的Dashboard展示出來，該Dashboard具備告警功能。在圖6中，你可以看到一個顯示容器使用率實時視圖的Dashboard，你也可以深入到單獨的進程。



圖6：Sysdig Cloud中的Dashboard視圖

舉例來說，使用Docker Compose運行WordPress會啟動兩個容器：一個運行Apache及WordPress的PHP代碼，另外一個運行MySql資料庫。使用Sysdig Cloud，你可以應用過濾器來深入探討資料庫是如何執行的，允許你定位一些狀況，比如較慢的查詢或者哪些查詢運行的最多。

最常見的服務也有類似的過濾器，比如Nginx、PHP-FPM、PostgreSQL、MongoDB和Apache Tomcat。這些過濾器和度量指標告警可以在任何時刻添加。這些告警在觸發時可以被分發到諸如Slack或者PagerDuty這樣的服務，並且會自動生成系統活動記錄。當需要調查故障時，有一個詳細信息級別的快照是非常有價值的。

收集數據的其它工具

如前所述，有相當多的服務可以收集、核對和上報來自容器和宿主機實例的度量指標，我們已經創建了其他可用工具的概述，在容器監控目錄中列出了更多。

供應商：CoScale

解決方案描述：CoScale是一個全棧的監控雲服務，其可以監控應用程序的響應能力。它用特定應用程序的性能 指標整合了伺服器和容器資源指標，其輕量級的代理是幾乎沒有開銷的。

供應商：Datadog

解決方案描述：Datadog對於IT運維和開發團隊是一個全棧的雲監控和告警服務，它具有容器化的代理可以監控容器環境。

供應商：Dynatrace

解決方案描述：Dynatrace在立足於Ruxit技術的基礎之上具有一套新的監控工具，可以針對容器監控和告警。它的代理是注入到一個容器里的，在其中可以重新發現新的運行在宿主機上的服務並從Docker API中獲取數據。Dynatrace也正在開發人工智慧來幫助進行根本原因的分析。

供應商：Elastic

解決方案描述：Beats是一個專用的數據交付工具，它安裝為一個輕量級的代理並且從機器發送數據到Logstash或者Elasticssearch。Dockerbeat是針對Docker容器的交付工具。如同大多數的Elasticsearch安裝，你可以在數據前部使用Kibana Dashboard。X-Pack是一個全棧的監控訂閱，其增加了額外的功能比如告警上報到Elastic Stack（以前稱之為ELK Stack）。

供應商：influxData

解決方案描述：Telegraf是一個開源的代理，其通過Docker插件來收集度量指標。它是堆棧的一部分，influxData被創建出來收集和分析度量指標，這些度量指標發送到了influxDB或者多種輸出渠道。

供應商：New Relic

解決方案描述：New Relic已經圍繞它們的數字化智能平台為應用和基礎設施性能更新了產品系列。它的基於代理的方式特別適合定位分析應用程序與代碼相關的性能問題。

供應商：Sematext

解決方案描述：Sematext有一個Docker原生的監控和日誌收集代理，其可以為所有的集群節點和自動發現的容器收集和處理Docker度量指標、事件和日誌。它有自己的日誌管理解決方案以及性能監控服務。

供應商：SignalFx

解決方案描述：SignalFx的collectd-docker插件使用Docker的stats API來抓取有關CPU、內存、網路和磁碟的度量指標。SignalFx有一個內置的Docker監控Dashboard，其會引導你按照屬性添加維度（tag）元數據到聚合、過濾以及分組度量指標中。

結論

我們所涵蓋的所有工具將能夠讓您能夠開啟容器可見性和監控。它將由你決定需要組合什麼樣的工具來收集信息，這將有助於您監控和優化應用程序和系統。我們涵蓋了每個人都需要知道的基本知識，包括使用Docker的Stats API原生功能和cAdvisor。要向用戶介紹基本的容器監控必需品還需要很長的路要走。我們還引入了更新的解決方案比如Prometheus和Sysdig。

有很多種方法來監控容器，並且解決方案供應商對於這些問題都有他們自己的固執己見的解決方法。你可能會認為是從開源和SaaS解決方案中選擇一個，但是更多的還是需要尋找一個適合你的工作負載的混合解決方案。無論你如何最終構建監控堆棧，你仍然需要知道如何收集你想監控的度量指標。

如需了解零空信息更多資訊及最新進展，敬請關注公眾號：零空科技&魔法隧道