如何選擇Docker監控方案

大家好，非常高興來上海跟大家分享一下我們在Docker監控方面的一點點經驗。

今天我要跟大家享主題是《如何選擇Docker監控方案》。

這里我將主要對Docker監控的原理和常用工具以及主流的解決方案進行簡單介紹，如果大家正準備對Docker進行監控，希望這次分享能為大家帶來一些幫助，如果你們已經進行了對Docker的監控，我也希望能的大家交流一下經驗，跟大家互相學習一下。

同時，最后我也會安利一下SaaS這種商業模式，甚至是一種消費觀念。可以說，我這次代表的不是某具體廠商，而是代表我們同樣做類似服務的SaaS行業。

什么是監控

為什么監控，監控什么內容？

我們要對自己系統的運行狀態了如指掌，有問題及時發現，而不讓讓用戶先發現我們系統不能使用，打電話過來到客服，客服再反映到開發，這個過程很長，而且對工程師來說，是一件比較沒面子的事情。

我們也不能一問三不知，比如領導問我們這個月的MySQL并發到了什么情況？slowsql處于什么水平，平均響應時間超過200ms的占比有百分之多少？

回答不出來這個問題很尷尬，盡管你工作很辛苦，但是卻沒有拿得出來的成果。不要以為沒出問題就沒事了，你要換位想想，站在領導的角度，領導什么都不干，你提案，他簽字，出了問題領導責任也很大啊。

監控目的

• 減少宕機時間
• 擴展和性能管理
• 資源計劃
• 識別異常事件
• 故障排除、分析

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

此外，監控還可以幫助進行內部統制，尤其是對安全比較敏感的行業，比如證券銀行等。比如服務器受到攻擊時，我們需要分析事件，找到根本原因，識別類似攻擊，發現沒有發現的被攻擊的系統，甚至完成取證等工作。

Docker監控的挑戰

• Docker特點
  • 像host但不是host
  • 量大
  • 生命周期短
• 監控盲點（斷層）
• 微服務
• 集群
• 全方位
  • Host（VM） + Services + Containers + Apps

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

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

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

集群的出現，應用的拓撲結構也變得復雜，不同的應用的指標和日志格式也不統一，再加上如何應對多租戶，也給監控帶來了新挑戰。

傳統的監控內包括主機、網絡和應用，但是Docker出現了，容器這一層容易被忽略，成為三不管地區，監控的盲點。

有人說，容器不就是個普通的OS么？裝個Zabbix的探針不就行了么？

Docker host和Docker 容器都要裝Zabbix探針。。。其實問題很多。

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

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

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

Docker監控技術基礎

• docker stats
• Remote API
• 偽文件系統

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

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

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

docker stats命令

$ docker stats redis1 redis2
CONTAINER           CPU %               MEM USAGE/LIMIT     MEM %               NET I/O
redis1              0.07%               796 KB/64 MB        1.21%               788 B/648 B
redis2              0.07%               2.746 MB/64 MB      4.29%               1.266 KB/648 B

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

偽文件系統

• CPU、內存、磁盤
• 網絡

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

/sys/fs/cgroup/{memory,cpuacct,blkio}/system.slice/${docker ps --no-trunc}.scope

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

Memory

內存的很多性能指標都來自于 memory.stat 文件

... ...
cache 11492564992
rss 1930993664
swap 0
pgfault 728281223
... ...
total_cache 11492564992
total_rss 1930993664
total_pgpgin 406632648
total_pgpgout 403355412
total_swap 0
total_pgfault 728281223
... ...

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

兩個比較重要的指標：

• RSS： resident set size

進程的所有數據堆、棧和memory map等。rss可以進一步分類為active和inactive（active_anon and inactive_anon）。在內存不夠需要swap一部分到磁盤的時候，會選擇inactive 的rss進行swap 。

• cache memory

緩存到內存中的硬盤文件的大小。比如你讀寫文件的時候，或者使用mapped file的時候，這個內存都會增加。這類內存也可以再細分為active和inactive的cache，即active_file和inactive_file。如果系統需要更多內存，則inactive的cache會被優先重用。

CPU

• cpuacct.stat文件
• docker.cpu.system
• docker.cpu.user

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

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

Blkio

優先從CFQ（Completely Fair Queuing 完全公平的排隊）拿數據，拿不到從這兩個文件拿：

blkio.throttle.io_service_bytes，讀寫字節數 blkio.throttle.io_serviced，讀寫次數

Throttle這個單純可能有誤導，實際這些都不是限制值，而是實際值。

每個文件的第一個字段是 major:minor 這樣格式的device ID。

網絡數據

• iptables
• 偽文件系統

• 網絡設備接口

• Virtual Ethernet

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

不過找到容器在主機上對應的虛擬網卡比較麻煩。這時候可以在宿主機上通過 ip netns 命令從容器內部取得網絡數據。

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

$ CONTAINER_PID=`docker inspect -f '' $CONTAINER_ID`
$ mkdir -p /var/run/netns
$ ln -sf /proc/$CONTAINER_PID/ns/net /var/run/netns/$CONTAINER_ID
$ ip netns exec $CONTAINER_ID netstat -i

或者：

$ CONTAINER_PID=`docker inspect -f '' nginx `
$ cat /proc/$CONTAINER_PID/net/dev

實際上Docker的實現也是從偽文件系統中讀取網絡metric的：

$ pwd
/sys/class/net/veth559b656/statistics

$ ls
collisions     rx_crc_errors   rx_frame_errors   rx_packets         tx_compressed   tx_heartbeat_errors
multicast      rx_dropped      rx_length_errors  tx_aborted_errors  tx_dropped      tx_packets
rx_bytes       rx_errors       rx_missed_errors  tx_bytes           tx_errors       tx_window_errors
rx_compressed  rx_fifo_errors  rx_over_errors    tx_carrier_errors  tx_fifo_errors

Docker監控方案實現

• 自己動手 + 開源軟件
• SaaS

評價標準

• 功能
  • 滿足
  • 信息詳細程度
  • 查詢的靈活程度
  • 報警 + API
• 靈活性
  • 定制
• 成本
  • 學習、開發
  • 維護
• 運維
  • 部署復雜程度
• 高可用

需要考慮的基本要素如上所示，不多述。

自己動手

• 靈活性強
• 成本高

這里的成本包括開發成本，開發成本可能包括招人和培訓，開發時間和填坑時間。開發完了還需要維護成本，而且隨著Docker的升級，可能還需要對metric的采集實現進行升級，以及各種bugfix。

自己動手打造監控方案

• 采集
• 存儲
• 展示
• 報警（動作）

StatsD 是 Flickr 公司首先提出來的，后來由 Esty 公司發揚光大的一個輕量級的指標采集模塊。

簡單來講，StatsD 就是一個簡單的網絡守護進程，基于 Node.js 平臺（Esty實現，其實也有其他語言版本），通過 UDP 或者 TCP 方式偵聽各種統計信息，包括計數器和定時器，可以用來采集操作系統、不同數據庫、中間件的數據指標，進行緩存、聚合，并發送到Graphite 等存儲和可視化系統中。

StatsD 具有以下優點：

• 簡單

首先安裝部署簡單，且StatsD 協議是基于文本的，可以直接寫入和讀取，方便實現各種客戶端和SDK。

Cloud Insight的探針也是采用這些方式，我們有些SDK也是基于StatsD的，目前有Ruby、Python和Java的，在GitHub上可以看到。

• 低耦合性

StatsD 守護進程采取 UDP 這種無狀態的協議，收集指標和應用程序本身之間沒有依賴，不會阻塞應用，不管StatsD的狀態是運行中，還是沒在運行，都不會影響應用程序，應用程序也不關心StatsD是否收到數據。

• 易集成

StatsD非常容易整合其他組件，可以自己編寫采集業務邏輯，發送到StatsD守護進程即可。也就是說用戶的工作很簡單，只需要按定義好的規則采集數據發送到Stats，然后用Graphite存儲、展示，通過使用Riemann進行報警。

Tcollector

• 來源于OpenTSDB

Tcollector 是一個采集指標數據并保存到OpenTSDB的框架，你可以使用該框架自己編寫采集的業務邏輯。類似StatsD，運行在客戶端，收集本地的metric信息，推送到OpenTSDB。

Collectd

• System statistics collection daemon
• 存儲到RRD
• 插件機制（input/output）
• 簡單報警功能

Collectd即是一個守護進程，也是一個框架，類似StatsD，它性能非常好，采用C語言編寫。Collectd不直接支持從Docker中取數據，但是我們可以自己編寫插件來采集性能指標數據。

Collectd有強大的插件機制，已經實現了包括amqp、rrdtool、graphite、http、kafka、redis、mongodb、OpenTSDB以及CSV文件等在內的各種插件。

在4.3版本之后還支持簡單的基于閾值檢查的報警機制。

cAdvisor（Container Advisor）

cAdvisor是一個用于收集、聚合處理和輸出容器運行指標的守護進程。而且cAdvisor基本算是一個獲取Docker性能數據的標配了吧。

sudo 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

一句命令就可以啟動cAdvisor容器，訪問8080端口即可看到性能指標數據。cAdvisor可以通過storage_driver參數將數據存到influxdb，同時也可以將metric輸出為Prometheus的格式，所以很多自定義Docker監控系統都會采取cAdvisor + Prometheus 的組合。

存儲TSDB

• OpenTSDB
• Influxdb
• RRDTool
• Graphite

關于時序列數據庫，可以看附錄中相關的介紹文章。推薦使用OpenTSDB或者Influxdb，簡單對比一下各自特點如下：

• OpenTSDB
  • Java & HBase
  • 易擴展（集群功能強大）
  • 機器多，運維稍顯麻煩
• Influxdb
  • Golang
  • 集群功能不太成熟
  • 有類SQL的查詢語句
  • 單臺即可工作

這兩者都支持自由模式和多維度，非常適合用于采用tag機制的數據模式建模。

開源可視化工具

• Graphite
• Influxdb + Grafana
• Prometheus

光有數據是不夠的，raw data沒有任何意義，我們需要良好的可視化組件來展示數據和數據的內在意義，發揮數據的作用。

我們也可以將數據存儲和展示交給其他開源軟件。

如果你的數據采集和存儲都是自己來完成的，只想使用一個外部的圖形化界面的話，選Grafana應該沒錯，Grafana展現形式非常豐富，配置也很靈活。

開源方案

• cAdvisor（經典）+ InfluxDB + Grafana
• Zabbix/Nagios/Hawkular
• Fluentd
• Prometheus
• Riemann
• ATSD（Axibase Time Series Database）

Hawkular 是一個來自于RedHat開源的監控解決方案，也包括報警等系統，可以說功能非常強大。

Hawkular基于Cassandra存儲，它認為這雖然增加了運維的復雜程度，但是擴展變得容易（參考前面關于OpenTSDB和Influxdb的對比）。

Zabbix

• 最經典（SaaS軟件的最大敵人）
• 架構簡單、清晰
• 文檔豐富
• 包括采集、觸發、告警
• Agent支持用戶自定義監控項
• 通過SNMP、ssh、telnet、IPMI、JMX監控
• 一套HTTP + JSON的接口

現在Zabbix已經實現了探針的自動注冊，也支持了基于角色的監控對象自動發現，但是你還是需要管理這些自動配置的項目。而且監控的服務多了，Zabbix探針在監控對象上運行的腳本也會變多，需要更多的進程，可能會對正常業務產生影響。

在Zabbix中支持Docker，可以使用 Zabbix Docker Monitoring ，首先需要下載兩個xml的模板文件，導入到管理界面，然后在docker host，也就是zabbix的agent的機器上，安裝zabbix模塊（.so），然后還得在Docker主機上啟動cadvisor容器。

Graphite

主要功能：

• 存儲數值型時序列數據
• 根據請求對數據進行可視化（畫圖）

Graphite是一個經典的時序列數據存儲，容易擴展，提供了功能強大的畫圖Web API以及大量的函數和輸出方式。Graphite有自己的可視化實現，也可以支持Grafana。

Graphite本身不帶數據采集功能，你需要選擇其他第三方插件，比如Collectd等。

Graphite架構自下而上分為3個模塊：

• whisper：創建、更新RRD文件
• carbon：以守護進程的形式運行，接收數據寫入請求
  • carbon-cache：數據存儲
  • carbon-relay：分區和復制，位于carbon-cache之前，類似carbon-cache的負載均衡
  • carbon-aggregator：數據集計，用于減輕carbon-cache的負載
• graphite-web：用于讀取、展示數據的Web應用

Whisper使用了類似RRDtool的RRD文件格式，不像C/S結構的軟件，whisper沒有服務進程，只是作為library來使用，直接對文件進行create/update/fetch等操作。

Prometheus

• 一體化、儀表盤和告警
• 多維度
• 靈活查詢語言
• 非分布式、單機自治
• 基于HTTP的pull模式（push需要中間網關）
• LevelDB

Prometheus是一個全套監控和預測方案，包括數據采集、存儲、查詢和可視化，以及報警功能。由社交音樂平臺SoundCloud在2012年開發，最近也非常火。

在集群流行的時候，很少有軟件專為單機、本地存儲而設計。Prometheus就是這樣一個軟件，它采用了基于LevelDB的本地存儲，并沒有使用成熟的面向列的數據庫。不過Prometheus 也在實驗將數據存儲到OpenTSDB。

Prometheus 采用了pull模式，即服務器通過探針端的exporter來主動拉取數據，而不是探針主導上報。

Prometheus部署和運維起來可能比較麻煩，需要很多組件單獨安裝，比如dashboard（PromDash），雖然這雖然顯得更加開放和包容。不過使用Docker的話將會簡單很多，通過一個Docker Compose配置文件就能建立全功能的Prometheus監控環境，網上有很多這樣的例子。

Heapster

• 經典組合：heapster + Influxdb + grafana
• Sink：Kafka、stdout、gcm（Google Cloud Monitoring）、hawkular、monasca、riemann、opentsdb

Heapster是k8s的一個子項目，用于獲取集群的性能數據。現在Heapster原生支持k8s和CoreOS，也可以很容易擴展來支持其他集群管理軟件。

Heapster除了支持，基本的metric之外，還支持事件類型的數據，比如容器生命周期事件。

Riemann

• 事件處理
• Clojure實現

Riemann 是一個分布式監控（數據處理）系統，但它做的事情其實非常簡單，就是接收事件->按定義規則處理->轉發或存儲到外部系統。

我們可以將Riemann 與時間序列數據庫，或者基于 StastD 的方案集成使用，來彌補其他方案在報警、事件流處理這方面上的不足。

Riemann采用Clojure語言編寫，這是一門Lisp方言，函數式編程語言，對于大多數習慣于過程式或者面向對象的現代人來說，理解起來有一定難度，有一定的學習曲線。

開源軟件的問題點

• 靈活性受限于upstream
• 維護成本高
• 定制難度大
• 技術棧

要選擇自己熟悉或者能投入精力去熟悉的技術棧產品，否則有問題沒人調查，監控產品將淪為擺設。

SaaS

• turnkey解決方案
• 維護成本 ~ Zero
• 適合中小企業

對于中小型企業尤其創業公司來說，自主開發或者直接利用現有的開源工具進行監控都有一些問題，主要是成本和風險的問題。對于中小企業，應該先把精力集中在發展核心業務，能外包的就先不自己做。而且很多中小公司大家都是全棧，沒有專門的運維人員，都是臨時抱佛腳，隨時都會變成救火隊員。

SaaS最大的優點是什么？那就是免運維，開箱即用，修改的代碼少甚至不需要修改代碼，或者只需要簡單的安裝一個agent就可以工作了。很多SaaS軟件的開場白都是運行一條 yum install ，然后倒上一杯咖啡等幾分鐘，就能看到數據了。

你的初期投入非常少，上手非常快，而且成本比較低（如果你的公司已經有數百上千服務器了，則這部分成本可能會變高，就跟是自建機房還是用云主機的對比一樣）。

SaaS

• 傳統APM
  • New Relic
  • AppDynamics
  • Dynatrace（Ruxit）
• 基礎設施監控
  • Datadog
  • SysDig
  • Cloud Insight
  • clusterup
  • Scout

RancherLab公司有人寫了篇文章，本講稿的最后有鏈接，大家可以參考下。這篇文章名為《Comparing Seven Monitoring Options for Docker》，即對比了七種不同的監控Docker的方案，包括使用 docker stats 命令, cAdvisor, Prometheus ，Sensu，以及saas服務 Scout, Sysdig Cloud and DataDog等方案，作為結論作者覺得Datadog是這其中最優秀的方案。

RancherLab有一個產品叫RancheOS，是一個專門為了運行Docker準備的微型Linux版本，它的口號是“The perfect place to run Docker”。跟CoreOS類似，但是貌似功能不如CoreOS多，也沒有CoreOS有名，也沒有CoreOS中fleet、flannel和etcd這樣的組件，尤其是etcd，可以說是CoreOS的副產品，但是幾乎成了Docker業界標準的kv store和服務發現組件了。

Datadog

• 國外最好
• 功能很強大
• 安裝很簡單

國外最流行的SaaS解決方案是Datadog，國內可能比較成熟、規模較大的應該算是Cloud Insight了。

這類服務用戶只需要注冊一個賬號，按照安裝過程通過一條命令來安裝探針即可在web展示端看到數據。

要說到Datadog的不足，那就是在國外，網絡延遲需要考慮，萬一哪天不科學了也需要有所準備。

價格方面Datadog也比較貴。免費plan支持5臺機器，而且只保留一天的數據，而且沒有報警功能。收費版15美元一臺主機，支持報警功能，數據存儲13個月。

說道SaaS，不得不提客服，直接面對非母語客服人員交流起來肯定會有諸多不順吧。

Cloud Insight

• 實時數據
• 歷史數據
• 儀表盤
• 混合監控
• 報警功能

當然，最便宜的還是Cloud Insight，有多便宜呢，官方定價的話3個探針以下是免費的，支持超過3臺主機的話，平均每天1快錢。

這只是官方定價，實際上還會便宜，貌似聯系客服就可以知道有多便宜了。

Cloud Insight還支持ChatOps集成，包括國內的 BearyChat 和簡聊。隨著devops文化的普及，相信這些工具的重要性也會與日俱增。

Cloud Insight的圖表功能也很豐富，能對任何指標以圖表的方式展示，還能在圖表上疊加事件，比如報警通知、服務啟動停止等，能在觀察到metric變動趨勢的同時，看到相應的時間，了解metric發生變動的原因。比如CPU load超過一定值時，可能觸發報警，這時你能在圖表上看到相應的事件，同樣，如果CPU load一直不是很低，但是從某一時間點開始變低了，你可能也能從一次新的代碼部署中了解原因。

Sysdig

• 免費工具
• SaaS服務 Sysdig Cloud
• 拓撲可視化

可以認為sysdig是strace + tcpdump + htop + iftop + lsof + 眾多linux常用的系統監控命令的合體。

如果你熟悉tcpdump，那么你知道它能還原整個網絡流量，而sysdig則是操作系統級別的監控工具，能捕捉到所有OS事件和數據。

而且sysdig原生支持Linux container，包括Docker和LXC，提供了基本的指標監控信息。除了性能指標，sysdig還能采集trace等日志信息，用于以后的問題分析和解決。

Sysdig Cloud是sisdig的SaaS版，除了基本的單機sysdig功能之外，還提供了跨平臺跨基礎設施的組件間依賴關系的可視化。

Librato

• 數據聚合平臺
• 簡單探針
• 圖表和報警
• 價格不貴

Librato是一個數據聚合平臺，而不是嚴格意義的監控系統。

Librato很容易從AWS CloudWatch和Heroku獲得數據，如果是自己監控主機或者Docker，需要使用Collectd框架。它也有很多插件，可以從StatsD、Riemann等數據源采集數據。

Librato的探針雖然功能不是強大，但是他提供了豐富的實時在線數據處理功能，用戶可以使用DSL對任意時間序列數據組合進行數學運算，比如加減乘除、比率導數等。還支持和時間窗口滑動功能，即跟過去某一段時間進行比較。

Librato也支持報警，基于metric和條件，設置報警信息。

Librato是按照metric的個數和時間分辨率來收費的，在官網的主頁上有一個大概的估算，如果你有20個metric，并且時間間隔為60秒，則一臺服務器的價格只有2美元1個月，這比datadog要便宜。

Axibase（ATSD）

• 非開源TSDB
• 支持報警
• 預測功能

作為TSDB，ATSD支持長時間存儲高精度的metric數據。ATSD支持多種數據采集工具和協議，比如tcollector, Collectd，當然ATSD也支持從多臺Docker主機手機指標數據，并長期保存，進行可視化和分析。

除了傳統的時間序列數據，ATSD還支持屬性（Properties）和消息這兩種類型的數據。屬性一般用于保存meta data，這有點類似標簽。

和OpenTSDB一樣，ATSD也支持tag，我們可以使用這些tag進行過濾和聚合。

ATSD內置了自動回歸推斷算法（holt-winters，arima），可以提早預測故障。預測功能的準確性取決于數據的采集頻率，保存時間（也就是數據量大小）和算法。

最大的遺憾，就是ATSD不是開源，也不是免費的軟件，不過他們提供了一個社區版可以免費使用，但是你只能在一個節點上安裝ATSD，而且不能用于盈利性服務，也不能對軟件進行修改以及再發布。

如果我們只是評估一下，或者想自己構建監控方案，它的產品設計還是非常值得我們來借鑒一下。

SaaS的挑戰

• 數據敏感性

采用SaaS，意味著你的數據都將會保存到公網，可能會帶來心理不安全感。實際上SaaS反而會更安全些，尤其是對中小公司沒有專門的安全運維團隊的情況下。

• 成本（遷移和使用成本）

一般來說這是一個一次性投入成本。

• 內部抵抗（觀念、個人愛好）

來自技術人員自身的抵抗，不是每個人都喜歡自己變得輕松，使用SaaS可能會給一些人帶來工作上的不充實感。

趨勢

• 標簽機制

一種觀點：監控服務狀態勝過監控個別容器，通過tag機制對服務整體的性能指標進行聚合。

Tag可以是任何維度，比如BU，地區，服務，甚至個別容器。

Docker和Kubernetes等都支持label機制，即tag機制。

• docker daemon –label com.example.group=“webserver”
• docker run –label com.example.group=“webserver”

• Dockerfile: LABEL com.example.group=“webserver”

• 通過API打通

通過API化實現共贏。開源軟件比如fluentd、Collectd等，都支持插件功能。包括Docker本身，也在1.11版本中，采用了runC作為容器運行時，在上面通過containerD來統一控制，來支持符合OCI標準的容器。

• Total解決方案

包括從探針到展示、告警，就是現在類似Datadog和Cloud Insight這樣的產品，以及支持中間件的詳細程度，就像一個大市場，什么都能買到，不管你用什么軟件，平臺都能提供監控。

這就像是去了酒吧突然想吃碗拉面，然后竟然酒吧能給你做出來的那種感覺。

另一個層面就是從RUEM（實時用戶體驗管理）到基礎設施層的 打通 。比如你看到某URL的用戶HTTP響應較慢，如果不能跟后端的APM打通，你盡管能識別出問題，但是你不知道如何解決。如果和后端的APM以及基礎設施監控打通，你就能定位到HTTP響應慢時，相應的后端代碼的位置，并根據后端代碼的位置從而進一步找到MySQL的監控數據以及系統異常事件，立刻知道問題的根本原因所在并解決問題，可以說效率應該能提高幾個數量級。

系統監控工具如果能夠做到 All in One，真的對解決人力和時間成本上有非常大的幫助。

• 拓撲可視化

跨組件、跨基礎設施和應用，自動識別組件以及組件之間的依賴關系，以幫助更好的發現問題和解決問題。

• Weave Scope
• Ruxit
• Sysdig

參考：

• 本次分享全部資料
• Comparing Seven Monitoring Options for Docker
• How to collect Docker metrics
• 時序列數據庫武斗大會
• Fluentd Docker Metrics Input Plugin
• Docker Runtime metrics

來自：liubin