導(dǎo)讀：容器對于物理機(jī)和虛擬機(jī)，單從監(jiān)控上看就不是一個數(shù)量級的，但監(jiān)控又是至關(guān)重要的，沒有監(jiān)控如同閉眼開車。

本次分享邀請數(shù)人云運(yùn)維總監(jiān)龐錚，本文將從以下幾個方面聊聊容器監(jiān)控的相關(guān)思考：

1. 容器監(jiān)控面臨問題-容器設(shè)計(jì)及運(yùn)營復(fù)雜性的挑戰(zhàn)；
2. 容器的三種監(jiān)控收集指標(biāo)；
3. 容器性能監(jiān)控能力把控及報(bào)警調(diào)查。

容器監(jiān)控的問題

為什么要使用Docker

• 需要一個可靠可擴(kuò)展的基礎(chǔ)設(shè)施平臺
• 大量的流量和用戶
• 大量的內(nèi)部服務(wù)
• 不需要改造基礎(chǔ)設(shè)施：負(fù)載均衡、HTTP服務(wù)、日志系統(tǒng)、數(shù)據(jù)庫、監(jiān)控系統(tǒng)等
• 抽象標(biāo)準(zhǔn)基礎(chǔ)設(shè)施服務(wù)，如 Haproxy\Mongodb\Es等
• 提供快速的更新\部署能力

簡介

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

Markdown

• 對于應(yīng)用層：應(yīng)用層的性能監(jiān)控將找到代碼的瓶頸和錯誤。
• 對于基礎(chǔ)設(shè)施：收集基礎(chǔ)設(shè)施層的資源指標(biāo)，如CPU\MEM。

而使用容器則在于資源層和應(yīng)用層之間，應(yīng)用監(jiān)控和基礎(chǔ)設(shè)施監(jiān)控?zé)o法起作用，造成了監(jiān)控系統(tǒng)的盲點(diǎn)。

容器的設(shè)計(jì)

• 原始初衷：安全

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

Markdown

• 現(xiàn)在

現(xiàn)在使用容器主要有兩個重要原因：

• 提供了一個規(guī)模的標(biāo)準(zhǔn)

如果軟件是微服務(wù)架構(gòu)，在 Kubernetes\Mesos 等容器平臺上進(jìn)行無停機(jī)的擴(kuò)縮和升級等系統(tǒng)操作。

• 擺脫對于軟件系統(tǒng)的依賴

  一直以來使用 Lib直接編譯成二進(jìn)制可執(zhí)行文件是最好的，但 Lib 的增加，為了避免內(nèi)存的過度消耗，導(dǎo)致運(yùn)行時(shí)共享 Lib 的出現(xiàn)。為了解決軟件依賴的問題，創(chuàng)建了很多方法如：Apt、Yum、Rvm、V1irtualenv 等，但這會導(dǎo)致拖慢發(fā)布周期，而容器直接解決了這個問題。

容器挑戰(zhàn)：運(yùn)營的巨大復(fù)雜性

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

Markdown

上圖顯示了15年的系統(tǒng)演進(jìn)過程。

• 15年前還是主機(jī)天下。
• 7年前引進(jìn)虛擬化技術(shù)，而虛擬化技術(shù)帶來的是更好的資源利用率，但對于工程師來說沒有什么變化。
• 而今天 Datadog 的數(shù)據(jù)顯示從收到了數(shù)十萬的主機(jī)數(shù)據(jù)中，越來越多的主機(jī)開始運(yùn)行容器。
• 2016年開始使用 Docker 的用戶增長率為 40%。

Markdown

• 運(yùn)行容器實(shí)例主機(jī)占總主機(jī)數(shù)量的 15%。

Markdown

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

Markdown

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

Markdown

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

Markdown

• 運(yùn)行應(yīng)用統(tǒng)計(jì)比例。

Markdown

• 在使用容器的公司中，每個主機(jī)運(yùn)行容器實(shí)例為 7 個左右，而 25% 的公司每個主機(jī)運(yùn)行容器實(shí)例為14個左右。

• 容器的生命周期為 2.5 天，在自動化平臺的更短為不到 1 天，主要因?yàn)樽詣有迯?fù)原因，而非自動平臺則 5.5 天。

Markdown

監(jiān)控的爆炸性增長

在沒有容器以前，監(jiān)控?cái)?shù)量如：

Markdown

使用容器后公式：假設(shè)每個容器收集 50 個度量，再加上應(yīng)用收集 50 個度量。

系統(tǒng)監(jiān)控   （容器數(shù)量*（容器監(jiān)控 應(yīng)用監(jiān)控））= 每個主機(jī)監(jiān)控?cái)?shù)量100         （4 *（50 50））= 500/主機(jī)監(jiān)控項(xiàng)

Markdown

以主機(jī)為中心的監(jiān)控體系

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

• 容器作為主機(jī)，因?yàn)槿萜魃芷诜浅６虝海员O(jiān)控系統(tǒng)會認(rèn)為一半主機(jī)在頻發(fā)故障。

• 如果不監(jiān)控容器，那么從主機(jī)到應(yīng)用之間的監(jiān)控是空白的，產(chǎn)生監(jiān)控黑洞。

簡化監(jiān)控體系

Markdown

如圖采用分層監(jiān)控架構(gòu)，更符合現(xiàn)有監(jiān)控體系。主機(jī)層和應(yīng)用層保持不變使用傳統(tǒng)的 Apm 和主機(jī)層監(jiān)控，而容器層使用新的監(jiān)控模式。

Markdown

如何監(jiān)控容器

容器類似主機(jī)

它有一個迷你主機(jī)該有的一切，包含常駐程序、CPU、MEM、IO 和網(wǎng)絡(luò)資源。但容器不能報(bào)告和主機(jī)完全相同的 Cgroup 指標(biāo)。

容器監(jiān)控資源

cpu

容器 CPU 會給出以下數(shù)據(jù)而不會有和主機(jī)一樣的全數(shù)據(jù)，如 Idle\Iowait\Irq。

Markdown

內(nèi)存

Markdown

使用內(nèi)存區(qū)別

• rss

屬于進(jìn)程的數(shù)據(jù)，如 Stacks、Heaps 等。可以被進(jìn)一步分解為

• 活動內(nèi)存（active_anon）
• 非活動內(nèi)存（inactive_anon）

必要時(shí)，非活動內(nèi)存可以被交換到磁盤

• cache

緩存存儲器存儲當(dāng)前保存在內(nèi)存中的磁盤數(shù)據(jù)。可以進(jìn)一步分解為

• 活動內(nèi)存（active_file）
• 非活動內(nèi)存（inactive_file）

必要時(shí)，首先回收非活動內(nèi)存

• swap 使用量

io

Markdown

容器對于每個塊設(shè)別匯報(bào)4個指標(biāo)，這種情況下，在主機(jī)監(jiān)控層面跟蹤主機(jī)隊(duì)列和服務(wù)時(shí)間是個好辦法，如果同塊的隊(duì)列和服務(wù)時(shí)間增長，那么因同塊 IO 是共享的，所以容器 IO 也受到影響。

• 讀取
• 寫入
• 同步
• 異步

網(wǎng)絡(luò)

和普通主機(jī)一樣，分為接收和發(fā)送的多個度量數(shù)據(jù)。

Markdown

如何收集容器指標(biāo)

容器有三種指標(biāo)收集方法，但標(biāo)準(zhǔn)并不一樣：

Sysfs 中的 Pseudo-files

• 默認(rèn)情況下，通過Sysfs中的偽文件可以得到容器的度量指標(biāo)，且不需要 Root 權(quán)限。這個方法是最快最清亮的方法。如果需要監(jiān)控很多主機(jī)，速度可能是一個很重要的指標(biāo)。但無法用這個方法收集到所有指標(biāo)，如 IO 和網(wǎng)絡(luò)指標(biāo)會受到限制。

收集位置

• 假定偽文件在操作系統(tǒng)目錄中的 /sys/fs/cgroup 中，某些系統(tǒng)可能在 /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 #進(jìn)程占用  464.09s     system 22162 #系統(tǒng)調(diào)用占用 221.62s

CPU 每核使用量

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

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

• 如果想要得到對于服務(wù)器匯總的cpu指標(biāo)

# cat $CONTAINER_ID/cpuacct.usage
    722473378982

• CPU 節(jié)流
• 如果對 CPU 使用做了限制，可以從下面的方法中查看

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

內(nèi)存獲取方法

ll /sys/fs/cgroup/memory/docker/$CONTAINER_ID/
  
  # 沒有 total 標(biāo)簽，不包含于子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 標(biāo)簽，包含于子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

可以通過特定命令直接獲取一些指標(biāo)：

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

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

  # 內(nèi)存使用次數(shù)限制
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.failcnt

  # cgroup 內(nèi)存限制，單位為字節(jié) 
  $ cat /sys/fs/cgroup/memory/docker/$CONTAINER_ID/memory.limit_in_bytes
  注意如果最終返回的是一個很長的數(shù)值代表容器實(shí)例并沒有限制，如果想增加限制
  $ 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

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

• blkio.throttle.io_service_bytes #io 操作字節(jié)，實(shí)際操作而非限制，前面兩個用冒號分割的數(shù)字是-主設(shè)備id:次要設(shè)備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 操作次數(shù)，實(shí)際操作而非限制。

   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

想查看設(shè)備之間的關(guān)系可以使用：

# 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  /

網(wǎng)絡(luò)

網(wǎng)絡(luò)從 1.6.1版本以后才支持，和以上的路徑有所不同，獲取使用容器Pid獲取，注意Host模式獲取的是主機(jī)網(wǎng)絡(luò)數(shù)據(jù)，所以 host 模式無法從容器數(shù)據(jù)統(tǒng)計(jì)網(wǎng)絡(luò)數(shù)據(jù)。

$ 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 會不斷的接收監(jiān)控指標(biāo)，1.9.0 以后指標(biāo)包含磁盤io

• cpu stats

cpu 占用百分比，多個實(shí)例占用cpu會根據(jù)分配進(jìn)行占用峰值，如果設(shè)定強(qiáng)制規(guī)約，那么cpu只能占設(shè)定的數(shù)值，比如20%

• 內(nèi)存 stats

如果沒有明確內(nèi)存限制，則限制為主機(jī)內(nèi)存限制。如果主機(jī)上還有其他使用內(nèi)存進(jìn)程，那么會在到達(dá)限制前耗盡內(nèi)存。

• io stats

1.9.0 版本后支持，顯示總讀寫字節(jié)

• 網(wǎng)絡(luò) stats

顯示總進(jìn)/出流量字節(jié)

• api

和 docker stats 命令一樣，但是提供更多的細(xì)節(jié)。守護(hù)進(jìn)程監(jiān)聽 unix:///var/run/docker.sock，只允許本地連接。使用 nc 調(diào)用方法：

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

Markdown

如何監(jiān)控Docker的性能

監(jiān)控都需要有什么能力

• 從每個 Docker 容器收集CPU、內(nèi)存、IO、網(wǎng)絡(luò)指標(biāo)，并可以通過人和標(biāo)簽或者標(biāo)簽聚合做成指標(biāo)，用來提供高分辨率資源指標(biāo)。
• 微服務(wù)體系結(jié)構(gòu)中，服務(wù)可以直接通訊或者使用隊(duì)列進(jìn)行通訊，沒有中央負(fù)載均衡很難進(jìn)行計(jì)量，通過標(biāo)簽聚合能力可以很好的解決這個問題。
• 需要通過圖形得之哪些服務(wù)超載，哪些服務(wù)導(dǎo)致其他服務(wù)失敗，哪些服務(wù)流量太多
• 還可以監(jiān)控其他非 Docker 服務(wù)，如 Haproxy、MongoDB、Es等等。

Markdown

Markdown

報(bào)警和調(diào)查

內(nèi)部網(wǎng)絡(luò)流量變化作為最重要的指標(biāo)來觸發(fā)報(bào)警而不會引起報(bào)警洪水。因此聚合和分解服務(wù)級別流量可見性是至關(guān)重要的。此外，即使在測量交叉異常閥值前，報(bào)警系統(tǒng)也可以提醒網(wǎng)絡(luò)流量變化。而其余的資源指標(biāo)是用來調(diào)查排錯的。

數(shù)人云容器監(jiān)控實(shí)踐

Markdown

Markdown

Markdown

參考

The Docker monitoring problem

datadog

Runtime metrics

QA

Q：有對Docker本身做什么監(jiān)控么？

A：可以認(rèn)為 Docker 監(jiān)控是類主機(jī)監(jiān)控，只不過是縮小版，基本上分為4部分：CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)。

Q：使用的整套監(jiān)控工具是哪些？容器CPU內(nèi)存網(wǎng)絡(luò) 如何監(jiān)控？容器事件比如起停如何監(jiān)控。

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

Q：分享的監(jiān)控圖片，有數(shù)據(jù)的，是使用什么監(jiān)控工具達(dá)成的？

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

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

A：我認(rèn)為Zabbix 是上一代監(jiān)控體系，或者以主機(jī)為中心的監(jiān)控體系，如果是容器監(jiān)控，建議還是考慮時(shí)序類的監(jiān)控體系，比如Influxdb\Prometheus等，Zabbix還可以沿用作為主機(jī)的，只是Docker單獨(dú)分離出來，這樣基礎(chǔ)建設(shè)可以復(fù)用。

Q：建不建議通過Pod中放一個監(jiān)控容器來監(jiān)控應(yīng)用容器，比如Zabbix客戶端的監(jiān)控容器在Pod中，如果這么做 優(yōu)缺點(diǎn)哪些？

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

Q：Cadvisor Heapster 和 Prometheus 哪種好用一些，各自優(yōu)缺點(diǎn)有哪些。

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

Q：監(jiān)控工具推薦哪個？對于容器生命周期短，有何策略應(yīng)對？如何實(shí)現(xiàn)快速監(jiān)控策略？

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

Q：容器的一大特點(diǎn)是IP或者ID信息變化頻繁，這就會導(dǎo)致時(shí)間序列數(shù)據(jù)庫存儲的監(jiān)控?cái)?shù)據(jù)量增長和vm相比大上不少，這塊有什么應(yīng)對方案嗎？嘗試過固定ID的，但是效果不佳。

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

Q：容器的安全如何做監(jiān)控？

A：這個問題問的好，現(xiàn)在比較通用的監(jiān)控基本上走的是兩條路，一個是監(jiān)控性能，一個是監(jiān)控業(yè)務(wù)，安全層面監(jiān)控，到現(xiàn)在我覺得還是要靠網(wǎng)絡(luò)層來監(jiān)控比較靠譜。

Q：Docker啟動Kafka集群的問題，有沒有控制內(nèi)存方面的經(jīng)驗(yàn)?zāi)兀?/strong>