成人无码视频,亚洲精品久久久久av无码,午夜精品久久久久久毛片,亚洲 中文字幕 日韩 无码

資訊專欄INFORMATION COLUMN

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

韓冰 / 2711人閱讀

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

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

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

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

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

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

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

為什么要使用Docker

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

大量的流量和用戶

大量的內(nèi)部服務

不需要改造基礎設施：負載均衡、HTTP服務、日志系統(tǒng)、數(shù)據(jù)庫、監(jiān)控系統(tǒng)等

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

提供快速的更新部署能力

簡介

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

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

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

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

容器的設計

原始初衷：安全

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

現(xiàn)在

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

提供了一個規(guī)模的標準

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

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

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

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

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

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

15年前還是主機天下。

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

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

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

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

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

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

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

運行應用統(tǒng)計比例。

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

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

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

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

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

系統(tǒng)監(jiān)控   （容器數(shù)量*（容器監(jiān)控 應用監(jiān)控））= 每個主機監(jiān)控數(shù)量100         （4 *（50 50））= 500/主機監(jiān)控項

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

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

容器作為主機，因為容器生命周期非常短暫，所以監(jiān)控系統(tǒng)會認為一半主機在頻發(fā)故障。

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

簡化監(jiān)控體系

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

如何監(jiān)控容器

容器類似主機

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

容器監(jiān)控資源

cpu

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

內(nèi)存

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

rss

屬于進程的數(shù)據(jù)，如 Stacks、Heaps 等?？梢员贿M一步分解為

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

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

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

cache

緩存存儲器存儲當前保存在內(nèi)存中的磁盤數(shù)據(jù)?？梢赃M一步分解為

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

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

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

swap 使用量

io

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

讀取

寫入

同步

異步

網(wǎng)絡

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

如何收集容器指標

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

Sysfs 中的 Pseudo-files

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

收集位置

假定偽文件在操作系統(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 #進程占用  464.09s     system 22162 #系統(tǒng)調(diào)用占用 221.62s

CPU 每核使用量

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

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

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

# 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 # 總使用時間，單位納秒(12.12s)

內(nèi)存獲取方法

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

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

# 總物理內(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ù)值代表容器實例并沒有限制，如果想增加限制
  $ 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)不同可能會有更多的指標文件，然而大部分的文件返回值是零。這種情況下通常還有兩個可以工作的文件。

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

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

# 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)絡

網(wǎng)絡從 1.6.1版本以后才支持，和以上的路徑有所不同，獲取使用容器Pid獲取，注意Host模式獲取的是主機網(wǎng)絡數(shù)據(jù)，所以 host 模式無法從容器數(shù)據(jù)統(tǒng)計網(wǎng)絡數(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)控指標，1.9.0 以后指標包含磁盤io

cpu stats

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

內(nèi)存 stats

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

io stats

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

網(wǎng)絡 stats

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

api

和 docker stats 命令一樣，但是提供更多的細節(jié)。守護進程監(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)控都需要有什么能力

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

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

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

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

報警和調(diào)查

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

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

參考

The Docker monitoring problem

datadog

Runtime metrics

QA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q：Docker啟動Kafka集群的問題，有沒有控制內(nèi)存方面的經(jīng)驗呢？

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

Q：Promethues有沒有做高可用？

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

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

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

轉載請注明本文地址：http://m.hztianpu.com/yun/26977.html

相關文章

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

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

    AaronYuan 評論0 收藏0

  • 云計算宕機時我們該何去何從

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

    dadong 評論0 收藏0

  • Vuex 升級入坑小記

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

    ziwenxie 評論0 收藏0

發(fā)表評論

0條評論

閱讀需要支付1元查看
<