亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專欄INFORMATION COLUMN

解惑|你是否為容器監(jiān)控操碎了心？

韓冰 / 2710人閱讀

摘要：系統(tǒng)監(jiān)控容器數(shù)量容器監(jiān)控應(yīng)用監(jiān)控每個(gè)主機(jī)監(jiān)控?cái)?shù)量主機(jī)監(jiān)控項(xiàng)以主機(jī)為中心的監(jiān)控體系容器作為主機(jī)，以主機(jī)為中心將有兩個(gè)問題無法解決容器作為主機(jī)，因?yàn)槿萜魃芷诜浅６虝?，所以監(jiān)控系統(tǒng)會認(rèn)為一半主機(jī)在頻發(fā)故障。

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

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

容器監(jiān)控面臨問題-容器設(shè)計(jì)及運(yùn)營復(fù)雜性的挑戰(zhàn)；

容器的三種監(jiān)控收集指標(biāo)；

容器性能監(jiān)控能力把控及報(bào)警調(diào)查。

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

為什么要使用Docker

需要一個(gè)可靠可擴(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ù)，如 HaproxyMongodbEs等

提供快速的更新部署能力

簡介

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

對于應(yīng)用層：應(yīng)用層的性能監(jiān)控將找到代碼的瓶頸和錯(cuò)誤。

對于基礎(chǔ)設(shè)施：收集基礎(chǔ)設(shè)施層的資源指標(biāo)，如CPUMEM。

而使用容器則在于資源層和應(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ī)，而存在于兩者之間。

現(xiàn)在

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

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

如果軟件是微服務(wù)架構(gòu)，在 KubernetesMesos 等容器平臺上進(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ā)布周期，而容器直接解決了這個(gè)問題。

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

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

上圖顯示了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%。

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

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

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

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

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

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

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

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

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

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

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

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

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

容器作為主機(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)控體系

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

如何監(jiān)控容器

容器類似主機(jī)

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

容器監(jiān)控資源

cpu

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

內(nèi)存

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

rss

屬于進(jìn)程的數(shù)據(jù)，如 Stacks、Heaps 等?？梢员贿M(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

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

讀取

寫入

同步

異步

網(wǎng)絡(luò)

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

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

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

Sysfs 中的 Pseudo-files

默認(rèn)情況下，通過Sysfs中的偽文件可以得到容器的度量指標(biāo)，且不需要 Root 權(quán)限。這個(gè)方法是最快最清亮的方法。如果需要監(jiān)控很多主機(jī)，速度可能是一個(gè)很重要的指標(biāo)。但無法用這個(gè)方法收集到所有指標(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 每核使用量

可以幫助識別每個(gè)核心的壓力

# 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
  注意如果最終返回的是一個(gè)很長的數(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)文件，然而大部分的文件返回值是零。這種情況下通常還有兩個(gè)可以工作的文件。

blkio.throttle.io_service_bytes #io 操作字節(jié)，實(shí)際操作而非限制，前面兩個(gè)用冒號分割的數(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 占用百分比，多個(gè)實(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

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

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

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

從每個(gè) 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)簽聚合能力可以很好的解決這個(gè)問題。

需要通過圖形得之哪些服務(wù)超載，哪些服務(wù)導(dǎo)致其他服務(wù)失敗，哪些服務(wù)流量太多

還可以監(jiān)控其他非 Docker 服務(wù)，如 Haproxy、MongoDB、Es等等。

報(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)查排錯(cuò)的。

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

參考

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)然靠采集程序了。起停這個(gè)一般通過監(jiān)控Docker的事件來實(shí)現(xiàn)，采集工具也能收。

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

A：這個(gè)分兩種，一種是靠底層的繪圖引擎，將數(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)控體系，比如InfluxdbPrometheus等，Zabbix還可以沿用作為主機(jī)的，只是Docker多帶帶分離出來，這樣基礎(chǔ)建設(shè)可以復(fù)用。

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

A：Pod應(yīng)該是Kubernetes的概念，和容器其實(shí)關(guān)系不大，這個(gè)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個(gè)人的開源項(xiàng)目，都是Google套路，唯獨(dú)存儲是個(gè)問題，這塊還需要看他們未來如何處理，現(xiàn)在單機(jī)存儲雖然性能上還可以，但是擴(kuò)展能力比較差。

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

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

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

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

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

A：這個(gè)問題問的好，現(xiàn)在比較通用的監(jiān)控基本上走的是兩條路，一個(gè)是監(jiān)控性能，一個(gè)是監(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>

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

Q：Promethues有沒有做高可用？

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

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

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/26977.html

相關(guān)文章

  • 快收藏！52篇25萬字，微服務(wù)、云原生、容器、K8S、Serverless精華文章集錦

    摘要：正在走遠(yuǎn)，新年之初，小數(shù)精選過去一年閱讀量居高的技術(shù)干貨，從容器到微服務(wù)云原生，匯集成篇精華集錦，充分反映了這一年的技術(shù)熱點(diǎn)走向。此文值得收藏，方便隨時(shí)搜索和查看。，小數(shù)將繼續(xù)陪伴大家，為朋友們奉獻(xiàn)更有逼格的技術(shù)內(nèi)容。 2017正在走遠(yuǎn)，新年之初，小數(shù)精選過去一年閱讀量居高的技術(shù)干貨，從容器、K8S 到微服務(wù)、云原生、Service Mesh，匯集成52篇精華集錦，充分反映了這一年的技...

    AaronYuan 評論0 收藏0

  • 云計(jì)算宕機(jī)時(shí)我們該何去何從

    摘要：亞馬遜月日亞馬遜宕機(jī)，影響了相當(dāng)多的網(wǎng)站和應(yīng)用長達(dá)五個(gè)小時(shí)的時(shí)間。亞馬遜花了兩個(gè)小時(shí)找出問題所在，然后又花了三個(gè)小時(shí)進(jìn)行修復(fù)。此外這次事件還影響到了亞馬遜上的語音服務(wù)助手。 市面上主流的云服務(wù)提供商都強(qiáng)調(diào)自己服務(wù)具有高可靠性，然而商業(yè)宣傳總是美好的，但企業(yè)有自己的一套替補(bǔ)方案不失為一個(gè)好主意。如果你覺得最近云服務(wù)出現(xiàn)問題的消息不斷傳出，那么恭喜你還沒有被云計(jì)算沖昏頭腦。上個(gè)月很多用戶都受到了...

    dadong 評論0 收藏0

  • Vuex 升級入坑小記

    摘要：升級入坑小記場景描述引入的版本為，開啟調(diào)試工具默認(rèn)升級后可以調(diào)試。遂升級，發(fā)現(xiàn)大量使用失效，報(bào)，的中文文檔，沒有及時(shí)更新。機(jī)票訂單和用戶信息。 Vuex 升級入坑小記 場景描述 引入Vuex的版本為0.3，開啟調(diào)試工具默認(rèn)升級后可以調(diào)試Vuex。給作者一個(gè)大大的贊。為提高開發(fā)體驗(yàn)也是操碎了心 (??????)?? (8。安利下(Vue Devtools）。 Vue Devtools ...

    ziwenxie 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<