摘要：系統監控容器數量容器監控應用監控每個主機監控數量主機監控項以主機為中心的監控體系容器作為主機，以主機為中心將有兩個問題無法解決容器作為主機，因為容器生命周期非常短暫，所以監控系統會認為一半主機在頻發故障。

導讀：容器對于物理機和虛擬機，單從監控上看就不是一個數量級的，但監控又是至關重要的，沒有監控如同閉眼開車。

本次分享邀請數人云運維總監龐錚，本文將從以下幾個方面聊聊容器監控的相關思考：

容器監控面臨問題-容器設計及運營復雜性的挑戰；

容器的三種監控收集指標；

容器性能監控能力把控及報警調查。

為什么要使用Docker

需要一個可靠可擴展的基礎設施平臺

大量的流量和用戶

大量的內部服務

不需要改造基礎設施：負載均衡、HTTP服務、日志系統、數據庫、監控系統等

抽象標準基礎設施服務，如 HaproxyMongodbEs等

提供快速的更新部署能力

簡介

容器對于物理機和虛擬機，單從監控上看就不是一個數量級的。但是監控又是至關重要的，如果沒有監控，如同閉著眼開車。先看下傳統監控解決的問題：

對于應用層：應用層的性能監控將找到代碼的瓶頸和錯誤。

對于基礎設施：收集基礎設施層的資源指標，如CPUMEM。

而使用容器則在于資源層和應用層之間，應用監控和基礎設施監控無法起作用，造成了監控系統的盲點。

容器的設計

原始初衷：安全

容器最開始設計就是為了提供運行時的安全隔離，且沒有虛擬化的資源開銷。容器提供了一種孤立運行軟件的方法，既不是進程也不是主機，而存在于兩者之間。

現在

現在使用容器主要有兩個重要原因：

提供了一個規模的標準

如果軟件是微服務架構，在 KubernetesMesos 等容器平臺上進行無停機的擴縮和升級等系統操作。

擺脫對于軟件系統的依賴

一直以來使用 Lib直接編譯成二進制可執行文件是最好的，但 Lib 的增加，為了避免內存的過度消耗，導致運行時共享 Lib 的出現。為了解決軟件依賴的問題，創建了很多方法如：Apt、Yum、Rvm、V1irtualenv 等，但這會導致拖慢發布周期，而容器直接解決了這個問題。

容器挑戰：運營的巨大復雜性

可以將每個容器看成一個迷你的主機，但它與主機的操作并不是很相同。

上圖顯示了15年的系統演進過程。

15年前還是主機天下。

7年前引進虛擬化技術，而虛擬化技術帶來的是更好的資源利用率，但對于工程師來說沒有什么變化。

而今天 Datadog 的數據顯示從收到了數十萬的主機數據中，越來越多的主機開始運行容器。

2016年開始使用 Docker 的用戶增長率為 40%。

運行容器實例主機占總主機數量的 15%。

大型企業使用容器的用戶更多（超過500臺主機集群）占 60%，另一方面說明了容器對于規模性和擺脫軟件依賴的對于大型企業的用處更高，數人云的核心業務是幫客戶把已有的系統容器化，再將其應用搬到調度系統上，以及開發一些周邊系統，接觸的客戶也反映了這一點。

有 40% 的用戶將容器運行在類似 Mesos 和 Kubernetes 等容器集群軟件中。

使用容器用戶中在第一個月到第十個月的九個月中，容器數量增長了 5 倍，并且數據非常線性。

運行應用統計比例。

在使用容器的公司中，每個主機運行容器實例為 7 個左右，而 25% 的公司每個主機運行容器實例為14個左右。

容器的生命周期為 2.5 天，在自動化平臺的更短為不到 1 天，主要因為自動修復原因，而非自動平臺則 5.5 天。

監控的爆炸性增長

在沒有容器以前，監控數量如：

使用容器后公式：假設每個容器收集 50 個度量，再加上應用收集 50 個度量。

系統監控   （容器數量*（容器監控 應用監控））= 每個主機監控數量100         （4 *（50 50））= 500/主機監控項

以主機為中心的監控體系

容器作為主機，以主機為中心將有兩個問題無法解決：

容器作為主機，因為容器生命周期非常短暫，所以監控系統會認為一半主機在頻發故障。

如果不監控容器，那么從主機到應用之間的監控是空白的，產生監控黑洞。

簡化監控體系

如圖采用分層監控架構，更符合現有監控體系。主機層和應用層保持不變使用傳統的 Apm 和主機層監控，而容器層使用新的監控模式。

容器類似主機

它有一個迷你主機該有的一切，包含常駐程序、CPU、MEM、IO 和網絡資源。但容器不能報告和主機完全相同的 Cgroup 指標。

容器監控資源

cpu

容器 CPU 會給出以下數據而不會有和主機一樣的全數據，如 IdleIowaitIrq。

內存

使用內存區別

rss

屬于進程的數據，如 Stacks、Heaps 等。可以被進一步分解為

活動內存（active_anon）

非活動內存（inactive_anon）

必要時，非活動內存可以被交換到磁盤

cache

緩存存儲器存儲當前保存在內存中的磁盤數據。可以進一步分解為

活動內存（active_file）

非活動內存（inactive_file）

必要時，首先回收非活動內存

swap 使用量

io

容器對于每個塊設別匯報4個指標，這種情況下，在主機監控層面跟蹤主機隊列和服務時間是個好辦法，如果同塊的隊列和服務時間增長，那么因同塊 IO 是共享的，所以容器 IO 也受到影響。

讀取

寫入

同步

異步

網絡

和普通主機一樣，分為接收和發送的多個度量數據。

容器有三種指標收集方法，但標準并不一樣：

Sysfs 中的 Pseudo-files

默認情況下，通過Sysfs中的偽文件可以得到容器的度量指標，且不需要 Root 權限。這個方法是最快最清亮的方法。如果需要監控很多主機，速度可能是一個很重要的指標。但無法用這個方法收集到所有指標，如 IO 和網絡指標會受到限制。

收集位置

假定偽文件在操作系統目錄中的 /sys/fs/cgroup 中，某些系統可能在 /cgroup 中。訪問路徑包含容器ID。

CONTAINER_ID=$(docker run [OPTIONS] IMAGE [COMMAND] [ARG...] )

CPU 獲取方法

cd /sys/fs/cgroupu/docker/&& ll

-rw-r--r-- 1 root root 0 5月  31 10:17 cgroup.clone_children
  --w--w--w- 1 root root 0 5月  31 10:17 cgroup.event_control
  -rw-r--r-- 1 root root 0 5月  31 10:17 cgroup.procs
  -r--r--r-- 1 root root 0 5月  31 10:17 cpuacct.stat
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpuacct.usage
  -r--r--r-- 1 root root 0 5月  31 10:17 cpuacct.usage_percpu
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.cfs_period_us
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.cfs_quota_us
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.rt_period_us
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.rt_runtime_us
  -rw-r--r-- 1 root root 0 5月  31 10:17 cpu.shares
  -r--r--r-- 1 root root 0 5月  31 10:17 cpu.stat
  -rw-r--r-- 1 root root 0 5月  31 10:17 notify_on_release
  -rw-r--r-- 1 root root 0 5月  31 10:17 tasks

CPU 使用（單位是10毫秒）

# cat $CONTAINER_ID/cpuacct.stat     user 46409 #進程占用  464.09s     system 22162 #系統調用占用 221.62s

CPU 每核使用量

可以幫助識別每個核心的壓力

# cat $CONTAINER_ID/cpuacct.usage_percpu         362316789800  #自啟動以來占用，單位納秒         360108180815

如果想要得到對于服務器匯總的cpu指標

# cat $CONTAINER_ID/cpuacct.usage
    722473378982

CPU 節流

如果對 CPU 使用做了限制，可以從下面的方法中查看

$ cat /sys/fs/cgroup/cpu/docker/$CONTAINER_ID/cpu.stat
    nr_periods 565 # 已經執行間隔數
    nr_throttled 559 # 被組抑制的次數
    throttled_time 12119585961 # 總使用時間，單位納秒(12.12s)

內存獲取方法

ll /sys/fs/cgroup/memory/docker/$CONTAINER_ID/
  
  # 沒有 total 標簽，不包含于子cgroup組
  cache 2015232
  rss 15654912
  rss_huge 0
  mapped_file 131072
  swap 0
  pgpgin 22623
  pgpgout 18309
  pgfault 27855
  pgmajfault 7
  inactive_anon 12148736
  active_anon 3506176
  inactive_file 2011136
  active_file 4096
  unevictable 0
  hierarchical_memory_limit 9223372036854775807
  hierarchical_memsw_limit 9223372036854775807
  
  # 有 total 標簽，包含于子cgroup組
  total_cache 2015232
  total_rss 15654912
  total_rss_huge 0
  total_mapped_file 131072
  total_swap 0
  total_pgpgin 22623
  total_pgpgout 18309
  total_pgfault 27855
  total_pgmajfault 7
  total_inactive_anon 12148736
  total_active_anon 3506176
  total_inactive_file 2011136
  total_active_file 4096
  total_unevictable 0

可以通過特定命令直接獲取一些指標：

# 總物理內存占用 cached + rss ，單位為字節 
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.usage_in_bytes

  # 總物理內存+swap 占用 ，單位為字節 
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.memsw.usage_in_bytes

  # 內存使用次數限制
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.failcnt

  # cgroup 內存限制，單位為字節 
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.limit_in_bytes
  注意如果最終返回的是一個很長的數值代表容器實例并沒有限制，如果想增加限制
  $ docker run -m 500M IMAGE [COMMAND] [ARG...]

IO

ll /sys/fs/cgroup/blkio/docker/$CONTAINER_ID
  
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_merged
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_merged_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_queued
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_queued_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_service_bytes
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_service_bytes_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_serviced
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_serviced_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_service_time
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_service_time_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_wait_time
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.io_wait_time_recursive
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.leaf_weight
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.leaf_weight_device
  --w------- 1 root root 0 5月  31 10:17 blkio.reset_stats
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.sectors
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.sectors_recursive
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.io_service_bytes
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.io_serviced
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.read_bps_device
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.read_iops_device
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.write_bps_device
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.throttle.write_iops_device
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.time
  -r--r--r-- 1 root root 0 5月  31 10:17 blkio.time_recursive
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.weight
  -rw-r--r-- 1 root root 0 5月  31 10:17 blkio.weight_device
  -rw-r--r-- 1 root root 0 5月  31 10:17 cgroup.clone_children
  --w--w--w- 1 root root 0 5月  31 10:17 cgroup.event_control
  -rw-r--r-- 1 root root 0 5月  31 10:17 cgroup.procs
  -rw-r--r-- 1 root root 0 5月  31 10:17 notify_on_release
  -rw-r--r-- 1 root root 0 5月  31 10:17 tasks

根據系統不同可能會有更多的指標文件，然而大部分的文件返回值是零。這種情況下通常還有兩個可以工作的文件。

blkio.throttle.io_service_bytes #io 操作字節，實際操作而非限制，前面兩個用冒號分割的數字是-主設備id:次要設備Id。

8:0 Read 2080768
  8:0 Write 0
  8:0 Sync 0
  8:0 Async 2080768
  8:0 Total 2080768
  253:0 Read 2080768
  253:0 Write 0
  253:0 Sync 0
  253:0 Async 2080768
  253:0 Total 2080768
  Total 4161536

blkio.throttle.io_serviced #io 操作次數，實際操作而非限制。

   8:0 Read 226
  8:0 Write 0
  8:0 Sync 0
  8:0 Async 226
  8:0 Total 226
  253:0 Read 226
  253:0 Write 0
  253:0 Sync 0
  253:0 Async 226
  253:0 Total 226
  Total 452

想查看設備之間的關系可以使用：

# lsblk
  NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
  sda               8:0    0   50G  0 disk
  ├─sda1            8:1    0  500M  0 part /boot
  ├─sda2            8:2    0 29.5G  0 part
  │ ├─centos-root 253:0    0 46.5G  0 lvm  /
  │ └─centos-swap 253:1    0    3G  0 lvm  [SWAP]
  └─sda3            8:3    0   20G  0 part
       └─centos-root 253:0    0 46.5G  0 lvm  /

網絡

網絡從 1.6.1版本以后才支持，和以上的路徑有所不同，獲取使用容器Pid獲取，注意Host模式獲取的是主機網絡數據，所以 host 模式無法從容器數據統計網絡數據。

$ CONTAINER_PID=`docker inspect -f "{{ .State.Pid }}" $CONTAINER_ID`
  $ cat /proc/$CONTAINER_PID/net/dev 
  
  Inter-|   Receive                                                |  Transmit
  face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth0:    9655      90    0    0    0     0          0         0    31435      78    0    0    0     0       0          0
  lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

cli 的 stats

使用 docker stats 會不斷的接收監控指標，1.9.0 以后指標包含磁盤io

cpu stats

cpu 占用百分比，多個實例占用cpu會根據分配進行占用峰值，如果設定強制規約，那么cpu只能占設定的數值，比如20%

內存 stats

如果沒有明確內存限制，則限制為主機內存限制。如果主機上還有其他使用內存進程，那么會在到達限制前耗盡內存。

io stats

1.9.0 版本后支持，顯示總讀寫字節

網絡 stats

顯示總進/出流量字節

api

和 docker stats 命令一樣，但是提供更多的細節。守護進程監聽 unix:///var/run/docker.sock，只允許本地連接。使用 nc 調用方法：

echo "" | nc -U /var/run/docker.sock 例子 echo -ne "GET /containers/$CONTAINER_ID/stats HTTP/1.1

" | sudo nc -U /var/run/docker.sock

監控都需要有什么能力

從每個 Docker 容器收集CPU、內存、IO、網絡指標，并可以通過人和標簽或者標簽聚合做成指標，用來提供高分辨率資源指標。

微服務體系結構中，服務可以直接通訊或者使用隊列進行通訊，沒有中央負載均衡很難進行計量，通過標簽聚合能力可以很好的解決這個問題。

需要通過圖形得之哪些服務超載，哪些服務導致其他服務失敗，哪些服務流量太多

還可以監控其他非 Docker 服務，如 Haproxy、MongoDB、Es等等。

內部網絡流量變化作為最重要的指標來觸發報警而不會引起報警洪水。因此聚合和分解服務級別流量可見性是至關重要的。此外，即使在測量交叉異常閥值前，報警系統也可以提醒網絡流量變化。而其余的資源指標是用來調查排錯的。

The Docker monitoring problem

datadog

Runtime metrics

Q：有對Docker本身做什么監控么？

A：可以認為 Docker 監控是類主機監控，只不過是縮小版，基本上分為4部分：CPU、內存、磁盤、網絡。

Q：使用的整套監控工具是哪些？容器CPU內存網絡 如何監控？容器事件比如起停如何監控。

A：整套工具數人云使用的是Cadvisor + Prometheus + Grafana ,當然中間的組件是可以替換的，但基本上圍繞著采集、存儲計算、展現來做。采集也可以使用自己的，比如文章說的自己寫代理去拿。容器的監控數據當然靠采集程序了。起停這個一般通過監控Docker的事件來實現，采集工具也能收。

Q：分享的監控圖片，有數據的，是使用什么監控工具達成的？

A：這個分兩種，一種是靠底層的繪圖引擎，將數據從存儲里讀出來自己繪制，一種就是用類Grafana的程序。

Q：如果用Zabbix監控，是否需要定義容器的的歷史數據保留時間和趨勢數據存儲周期，我設定的時歷史數據保留7天，趨勢數據14天，這樣是否合理？

A：我認為Zabbix 是上一代監控體系，或者以主機為中心的監控體系，如果是容器監控，建議還是考慮時序類的監控體系，比如InfluxdbPrometheus等，Zabbix還可以沿用作為主機的，只是Docker多帶帶分離出來，這樣基礎建設可以復用。

Q：建不建議通過Pod中放一個監控容器來監控應用容器，比如Zabbix客戶端的監控容器在Pod中，如果這么做 優缺點哪些？

A：Pod應該是Kubernetes的概念，和容器其實關系不大，這個Kubernetes自己應該會提供數據，具體不是很清楚。但是Abbix還是建議保留在主機層面使用，除非大改，否則即使靠拆分數據庫什么的解決，未來維護和性能也是運維大坑。

Q：Cadvisor Heapster 和 Prometheus 哪種好用一些，各自優缺點有哪些。

A: Heapster不熟悉， Prometheus很好，Google個人的開源項目，都是Google套路，唯獨存儲是個問題，這塊還需要看他們未來如何處理，現在單機存儲雖然性能上還可以，但是擴展能力比較差。

Q：監控工具推薦哪個？對于容器生命周期短，有何策略應對？如何實現快速監控策略？

A：監控工具推薦剛才已經說了，可以參考數人云的方案然后自己摸索出適合自己的。至于容器生命周期短的問題，這個不就是容器設計嘛，很正常，多起幾個相同的服務頂上。

Q：容器的一大特點是IP或者ID信息變化頻繁，這就會導致時間序列數據庫存儲的監控數據量增長和vm相比大上不少，這塊有什么應對方案嗎？嘗試過固定ID的，但是效果不佳。

A：這塊確實沒有什么好辦法，不過可以換個角度，可以將底層的實例抽象一個維度，比如起了1個服務10個容器，把容器編號0-9，對應掛掉的容器，新啟動繼承這個編號。從時序上用這個作為標記，就能看比較直觀的顯示了。此功能數人云Swan （歡迎Star&Fork）實現了，可以考慮。

Q：容器的安全如何做監控？

A：這個問題問的好，現在比較通用的監控基本上走的是兩條路，一個是監控性能，一個是監控業務，安全層面監控，到現在我覺得還是要靠網絡層來監控比較靠譜。

Q：Docker啟動Kafka集群的問題，有沒有控制內存方面的經驗呢？

A：Kafka集群，性能監控的話，可以沿用原來的Kafka集群監控軟件，當然如果想做數據匯聚，也可以使用開源軟件將數據匯聚到一個數據存儲，然后在匯聚出來。關于Docker內存的超出被殺問題，這個主要是看自身對于容器內存設置的容忍度問題，這里可以把容器當成一個機器，看到底給這個機器插多少內存合適。

Q：Promethues有沒有做高可用？

A：如果存儲高可用的話，可以考慮使用兩臺Prometheus同時抓，這樣數據完全一樣，也沒啥壓力。

分享人龐錚，數人云運維總監。15 年以上運維工作經驗。就職過宏碁戲谷、第三波、SQUARE ENIX CO, LTD 等。2015年加入數人云，從事數人云平臺運維管理，在容器技術及SRE實踐方面有深入研究。