35      阿裏雲  技術社區[雲棲]

使用 Elasticsearch 和 cAdvisor 監控 Docker 容器

如果你正在運行 Swarm 模式的集群，或者隻運行單台 Docker，你都會有下麵的疑問：

我如何才能監控到它們都在幹些什麼？

這個問題的答案是“很不容易”。

你需要監控下麵的參數：

1. 容器的數量和狀態。
2. 一台容器是否已經移到另一個節點了，如果是，那是在什麼時候，移動到哪個節點？
3. 給定節點上運行著的容器數量。
4. 一段時間內的通信峰值。
5. 孤兒卷和網絡（LCTT 譯注：孤兒卷就是當你刪除容器時忘記刪除它的卷，這個卷就不會再被使用，但會一直占用資源）。
6. 可用磁盤空間、可用 inode 數。
7. 容器數量與連接在 docker0 和 docker_gwbridge 上的虛擬網卡數量不一致（LCTT 譯注：當 docker 啟動時，它會在宿主機器上創建一個名為 docker0 的虛擬網絡接口）。
8. 開啟和關閉 Swarm 節點。
9. 收集並集中處理日誌。

本文的目標是介紹 Elasticsearch + Kibana + cAdvisor 的用法，使用它們來收集 Docker 容器的參數，分析數據並產生可視化報表。

閱讀本文後你可以發現有一個監控儀表盤能夠部分解決上述列出的問題。但如果隻是使用 cAdvisor，有些參數就無法顯示出來，比如 Swarm 模式的節點。

如果你有一些 cAdvisor 或其他工具無法解決的特殊需求，我建議你開發自己的數據收集器和數據處理器（比如Beats），請注意我不會演示如何使用 Elasticsearch 來集中收集 Docker 容器的日誌。

“你要如何才能監控到 Swarm 模式集群裏麵發生了什麼事情？要做到這點很不容易。” —— @fntlnz

我們為什麼要監控容器？

想象一下這個經典場景：你在管理一台或多台虛擬機，你把 tmux 工具用得很熘，用各種 session 事先設定好了所有基礎的東西，包括監控。然後生產環境出問題了，你使用 top、htop、iotop、jnettop 各種 top 來排查，然後你準備好修複故障。

現在重新想象一下你有 3 個節點，包含 50 台容器，你需要在一個地方查看整潔的曆史數據，這樣你知道問題出在哪個地方，而不是把你的生命浪費在那些字符界麵來賭你可以找到問題點。

什麼是 Elastic Stack ？

Elastic Stack 就一個工具集，包括以下工具：

• Elasticsearch
• Kibana
• Logstash
• Beats

我們會使用其中一部分工具，比如使用 Elasticsearch 來分析基於 JSON 格式的文本，以及使用 Kibana 來可視化數據並產生報表。

另一個重要的工具是 Beats，但在本文中我們還是把精力放在容器上，官方的 Beats 工具不支持 Docker，所以我們選擇原生兼容 Elasticsearch 的 cAdvisor。

cAdvisor 工具負責收集、整合正在運行的容器數據，並導出報表。在本文中，這些報表被到入到 Elasticsearch 中。

cAdvisor 有兩個比較酷的特性：

• 它不隻局限於 Docker 容器。
• 它有自己的 Web 服務器，可以簡單地顯示當前節點的可視化報表。

設置測試集群，或搭建自己的基礎架構

和我以前的文章一樣，我習慣提供一個簡單的腳本，讓讀者不用花很多時間就能部署好和我一樣的測試環境。你可以使用以下（非生產環境使用的）腳本來搭建一個 Swarm 模式的集群，其中一個容器運行著 Elasticsearch。

如果你有充足的時間和經驗，你可以搭建自己的基礎架構Bring Your Own Infrastructure，BYOI。

如果要繼續閱讀本文，你需要：

• 運行 Docker 進程的一個或多個節點（docker 版本號大於等於 1.12）。
• 至少有一個獨立運行的 Elasticsearch 節點（版本號 2.4.X）。

重申一下，此 Elasticsearch 集群環境不能放在生產環境中使用。生產環境也不推薦使用單節點集群，所以如果你計劃安裝一個生產環境，請參考 Elastic 指南。

對喜歡嚐鮮的用戶的友情提示

我就是一個喜歡嚐鮮的人（當然我也已經在生產環境中使用了最新的 alpha 版本），但是在本文中，我不會使用最新的 Elasticsearch 5.0.0 alpha 版本，我還不是很清楚這個版本的功能，所以我不想成為那個引導你們出錯的關鍵。

所以本文中涉及的 Elasticsearch 版本為最新穩定版 2.4.0。

測試集群部署腳本

前麵已經說過，我提供這個腳本給你們，讓你們不必費神去部署 Swarm 集群和 Elasticsearch，當然你也可以跳過這一步，用你自己的 Swarm 模式引擎和你自己的 Elasticserch 節點。

執行這段腳本之前，你需要：

• Docker Machine – 最終版：在 DigitalOcean 中提供 Docker 引擎。
• DigitalOcean API Token: 讓 docker 機器按照你的意思來啟動節點。

創建集群的腳本

現在萬事俱備，你可以把下麵的代碼拷到 create-cluster.sh 文件中：

1. #!/usr/bin/env bash
2. #
3. # Create a Swarm Mode cluster with a single master and a configurable number of workers
5. workers=${WORKERS:-"worker1 worker2"}
7. #######################################
8. # Creates a machine on Digital Ocean
9. # Globals:
10. # DO_ACCESS_TOKEN The token needed to access DigitalOcean's API
11. # Arguments:
12. # $1 the actual name to give to the machine
13. #######################################
14. create_machine() {
15. docker-machine create \
16. -d digitalocean \
17. --digitalocean-access-token=$DO_ACCESS_TOKEN \
18. --digitalocean-size 2gb \
19. $1
20. }
22. #######################################
23. # Executes a command on the specified machine
24. # Arguments:
25. # $1 The machine on which to run the command
26. # $2..$n The command to execute on that machine
27. #######################################
28. machine_do() {
29. docker-machine ssh $@
30. }
32. main() {
34. if [ -z "$DO_ACCESS_TOKEN" ]; then
35. echo "Please export a DigitalOcean Access token: https://cloud.digitalocean.com/settings/api/tokens/new"
36. echo "export DO_ACCESS_TOKEN=<yourtokenhere>"
37. exit 1
38. fi
40. if [ -z "$WORKERS" ]; then
41. echo "You haven't provided your workers by setting the \$WORKERS environment variable, using the default ones: $workers"
42. fi
44. # Create the first and only master
45. echo "Creating the master"
47. create_machine master1
49. master_ip=$(docker-machine ip master1)
51. # Initialize the swarm mode on it
52. echo "Initializing the swarm mode"
53. machine_do master1 docker swarm init --advertise-addr $master_ip
55. # Obtain the token to allow workers to join
56. worker_tkn=$(machine_do master1 docker swarm join-token -q worker)
57. echo "Worker token: ${worker_tkn}"
59. # Create and join the workers
60. for worker in $workers; do
61. echo "Creating worker ${worker}"
62. create_machine $worker
63. machine_do $worker docker swarm join --token $worker_tkn $master_ip:2377
64. done
65. }
67. main $@

賦予它可執行權限：

1. chmod +x create-cluster.sh

創建集群

如文件名所示，我們可以用它來創建集群。默認情況下這個腳本會創建一個 master 和兩個 worker，如果你想修改 worker 個數，可以設置環境變量 WORKERS。

現在就來創建集群吧。

1. ./create-cluster.sh

你可以出去喝杯咖啡，因為這需要花點時間。

最後集群部署好了。

現在為了驗證 Swarm 模式集群已經正常運行，我們可以通過 ssh 登錄進 master：

1. docker-machine ssh master1

然後列出集群的節點：

1. docker node ls

1. ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
2. 26fi3wiqr8lsidkjy69k031w2 * master1 Ready Active Leader
3. dyluxpq8sztj7kmwlzs51u4id worker2 Ready Active
4. epglndegvixag0jztarn2lte8 worker1 Ready Active

安裝 Elasticsearch 和 Kibana

注意，從現在開始所有的命令都運行在主節點 master1 上。

在生產環境中，你可能會把 Elasticsearch 和 Kibana 安裝在一個單獨的、大小合適的實例集合中。但是在我們的實驗中，我們還是把它們和 Swarm 模式集群安裝在一起。

為了將 Elasticsearch 和 cAdvisor 連通，我們需要創建一個自定義的網絡，因為我們使用了集群，並且容器可能會分布在不同的節點上，我們需要使用 overlay 網絡（LCTT 譯注：overlay 網絡是指在不改變現有網絡基礎設施的前提下，通過某種約定通信協議，把二層報文封裝在 IP 報文之上的新的數據格式，是目前最主流的容器跨節點數據傳輸和路由方案）。

也許你會問，“為什麼還要網絡？我們不是可以用 link 嗎？” 請考慮一下，自從引入用戶定義網絡後，link 機製就已經過時了。

以下內容摘自 Docker 文檔：

在 Docker network 特性出來以前，你可以使用 Docker link 特性實現容器互相發現、安全通信。而在 network 特性出來以後，你還可以使用 link，但是當容器處於默認橋接網絡或用戶自定義網絡時，它們的表現是不一樣的。

現在創建 overlay 網絡，名稱為 monitoring：

1. docker network create monitoring -d overlay

Elasticsearch 容器

1. docker service create --network=monitoring \
2. --mount type=volume,target=/usr/share/elasticsearch/data \
3. --constraint node.hostname==worker1 \
4. --name elasticsearch elasticsearch:2.4.0

注意 Elasticsearch 容器被限定在 worker1 節點，這是因為它運行時需要依賴 worker1 節點上掛載的卷。

Kibana 容器

1. docker service create --network=monitoring --name kibana -e ELASTICSEARCH_URL="https://elasticsearch:9200" -p 5601:5601 kibana:4.6.0

如你所見，我們啟動這兩個容器時，都讓它們加入 monitoring 網絡，這樣一來它們可以通過名稱（如 Kibana）被相同網絡的其他服務訪問。

現在，通過 routing mesh 機製，我們可以使用瀏覽器訪問服務器的 IP 地址來查看 Kibana 報表界麵。

獲取 master1 實例的公共 IP 地址：

1. docker-machine ip master1

打開瀏覽器輸入地址：https://[master1 的 ip 地址]:5601/status

所有項目都應該是綠色：

讓我們接下來開始收集數據！

收集容器的運行數據

收集數據之前，我們需要創建一個服務，以全局模式運行 cAdvisor，為每個有效節點設置一個定時任務。

這個服務與 Elasticsearch 處於相同的網絡，以便於 cAdvisor 可以推送數據給 Elasticsearch。

1. docker service create --network=monitoring --mode global --name cadvisor \
2. --mount type=bind,source=/,target=/rootfs,readonly=true \
3. --mount type=bind,source=/var/run,target=/var/run,readonly=false \
4. --mount type=bind,source=/sys,target=/sys,readonly=true \
5. --mount type=bind,source=/var/lib/docker/,target=/var/lib/docker,readonly=true \
6. google/cadvisor:latest \
7. -storage_driver=elasticsearch \
8. -storage_driver_es_host="https://elasticsearch:9200"

注意：如果你想配置 cAdvisor 選項，參考這裏。

現在 cAdvisor 在發送數據給 Elasticsearch，我們通過定義一個索引模型來檢索 Kibana 中的數據。有兩種方式可以做到這一點：通過 Kibana 或者通過 API。在這裏我們使用 API 方式實現。

我們需要在一個連接到 monitoring 網絡的正在運行的容器中運行索引創建命令，你可以在 cAdvisor 容器中拿到 shell，不幸的是 Swarm 模式在開啟服務時會在容器名稱後麵附加一個唯一的 ID 號，所以你需要手動指定 cAdvisor 容器的名稱。

拿到 shell：

1. docker exec -ti <cadvisor-container-name> sh

創建索引：

1. curl -XPUT http://elasticsearch:9200/.kibana/index-pattern/cadvisor -d '{"title" : "cadvisor*", "timeFieldName": "container_stats.timestamp"}'

如果你夠懶，可以隻執行下麵這一句：

1. docker exec $(docker ps | grep cadvisor | awk '{print $1}' | head -1) curl -XPUT http://elasticsearch:9200/.kibana/index-pattern/cadvisor -d '{"title" : "cadvisor*", "timeFieldName": "container_stats.timestamp"}'

把數據匯總成報表

你現在可以使用 Kibana 來創建一份美觀的報表了。但是不要著急，我為你們建了一份報表和一些圖形界麵來方便你們入門。

訪問 Kibana 界麵 => Setting => Objects => Import，然後選擇包含以下內容的 JSON 文件，就可以導入我的配置信息了：

1. [
2. {
3. "_id": "cAdvisor",
4. "_type": "dashboard",
5. "_source": {
6. "title": "cAdvisor",
7. "hits": 0,
8. "description": "",
9. "panelsJSON": "[{\"id\":\"Filesystem-usage\",\"type\":\"visualization\",\"panelIndex\":1,\"size_x\":6,\"size_y\":3,\"col\":1,\"row\":1},{\"id\":\"Memory-[Node-equal->Container]\",\"type\":\"visualization\",\"panelIndex\":2,\"size_x\":6,\"size_y\":4,\"col\":7,\"row\":4},{\"id\":\"memory-usage-by-machine\",\"type\":\"visualization\",\"panelIndex\":3,\"size_x\":6,\"size_y\":6,\"col\":1,\"row\":4},{\"id\":\"CPU-Total-Usage\",\"type\":\"visualization\",\"panelIndex\":4,\"size_x\":6,\"size_y\":5,\"col\":7,\"row\":8},{\"id\":\"Network-RX-TX\",\"type\":\"visualization\",\"panelIndex\":5,\"size_x\":6,\"size_y\":3,\"col\":7,\"row\":1}]",
10. "optionsJSON": "{\"darkTheme\":false}",
11. "uiStateJSON": "{}",
12. "version": 1,
13. "timeRestore": false,
14. "kibanaSavedObjectMeta": {
15. "searchSourceJSON": "{\"filter\":[{\"query\":{\"query_string\":{\"query\":\"*\",\"analyze_wildcard\":true}}}]}"
16. }
17. }
18. },
19. {
20. "_id": "Network",
21. "_type": "search",
22. "_source": {
23. "title": "Network",
24. "description": "",
25. "hits": 0,
26. "columns": [
27. "machine_name",
28. "container_Name",
29. "container_stats.network.name",
30. "container_stats.network.interfaces",
31. "container_stats.network.rx_bytes",
32. "container_stats.network.rx_packets",
33. "container_stats.network.rx_dropped",
34. "container_stats.network.rx_errors",
35. "container_stats.network.tx_packets",
36. "container_stats.network.tx_bytes",
37. "container_stats.network.tx_dropped",
38. "container_stats.network.tx_errors"
39. ],
40. "sort": [
41. "container_stats.timestamp",
42. "desc"
43. ],
44. "version": 1,
45. "kibanaSavedObjectMeta": {
46. "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"analyze_wildcard\":true,\"query\":\"*\"}},\"highlight\":{\"pre_tags\":[\"@kibana-highlighted-field@\"],\"post_tags\":[\"@/kibana-highlighted-field@\"],\"fields\":{\"*\":{}},\"fragment_size\":2147483647},\"filter\":[]}"
47. }
48. }
49. },
50. {
51. "_id": "Filesystem-usage",
52. "_type": "visualization",
53. "_source": {
54. "title": "Filesystem usage",
55. "visState": "{\"title\":\"Filesystem usage\",\"type\":\"histogram\",\"params\":{\"addLegend\":true,\"addTimeMarker\":false,\"addTooltip\":true,\"defaultYExtents\":false,\"mode\":\"stacked\",\"scale\":\"linear\",\"setYExtents\":false,\"shareYAxis\":true,\"times\":[],\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.filesystem.usage\",\"customLabel\":\"USED\"}},{\"id\":\"2\",\"type\":\"terms\",\"schema\":\"split\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\",\"row\":false}},{\"id\":\"3\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.filesystem.capacity\",\"customLabel\":\"AVAIL\"}},{\"id\":\"4\",\"type\":\"terms\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.filesystem.device\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}}],\"listeners\":{}}",
56. "uiStateJSON": "{\"vis\":{\"colors\":{\"Average container_stats.filesystem.available\":\"#E24D42\",\"Average container_stats.filesystem.base_usage\":\"#890F02\",\"Average container_stats.filesystem.capacity\":\"#3F6833\",\"Average container_stats.filesystem.usage\":\"#E24D42\",\"USED\":\"#BF1B00\",\"AVAIL\":\"#508642\"}}}",
57. "description": "",
58. "version": 1,
59. "kibanaSavedObjectMeta": {
60. "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"analyze_wildcard\":true,\"query\":\"*\"}},\"filter\":[]}"
61. }
62. }
63. },
64. {
65. "_id": "CPU-Total-Usage",
66. "_type": "visualization",
67. "_source": {
68. "title": "CPU Total Usage",
69. "visState": "{\"title\":\"CPU Total Usage\",\"type\":\"area\",\"params\":{\"shareYAxis\":true,\"addTooltip\":true,\"addLegend\":true,\"smoothLines\":false,\"scale\":\"linear\",\"interpolate\":\"linear\",\"mode\":\"stacked\",\"times\":[],\"addTimeMarker\":false,\"defaultYExtents\":false,\"setYExtents\":false,\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.cpu.usage.total\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"auto\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"terms\",\"schema\":\"group\",\"params\":{\"field\":\"container_Name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}},{\"id\":\"4\",\"type\":\"terms\",\"schema\":\"split\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\",\"row\":true}}],\"listeners\":{}}",
70. "uiStateJSON": "{}",
71. "description": "",
72. "version": 1,
73. "kibanaSavedObjectMeta": {
74. "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"query\":\"*\",\"analyze_wildcard\":true}},\"filter\":[]}"
75. }
76. }
77. },
78. {
79. "_id": "memory-usage-by-machine",
80. "_type": "visualization",
81. "_source": {
82. "title": "Memory [Node]",
83. "visState": "{\"title\":\"Memory [Node]\",\"type\":\"area\",\"params\":{\"shareYAxis\":true,\"addTooltip\":true,\"addLegend\":true,\"smoothLines\":false,\"scale\":\"linear\",\"interpolate\":\"linear\",\"mode\":\"stacked\",\"times\":[],\"addTimeMarker\":false,\"defaultYExtents\":false,\"setYExtents\":false,\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.memory.usage\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"auto\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"terms\",\"schema\":\"group\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}}],\"listeners\":{}}",
84. "uiStateJSON": "{}",
85. "description": "",
86. "version": 1,
87. "kibanaSavedObjectMeta": {
88. "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"query\":\"*\",\"analyze_wildcard\":true}},\"filter\":[]}"
89. }
90. }
91. },
92. {
93. "_id": "Network-RX-TX",
94. "_type": "visualization",
95. "_source": {
96. "title": "Network RX TX",
97. "visState": "{\"title\":\"Network RX TX\",\"type\":\"histogram\",\"params\":{\"addLegend\":true,\"addTimeMarker\":true,\"addTooltip\":true,\"defaultYExtents\":false,\"mode\":\"stacked\",\"scale\":\"linear\",\"setYExtents\":false,\"shareYAxis\":true,\"times\":[],\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.network.rx_bytes\",\"customLabel\":\"RX\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"s\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.network.tx_bytes\",\"customLabel\":\"TX\"}}],\"listeners\":{}}",
98. "uiStateJSON": "{\"vis\":{\"colors\":{\"RX\":\"#EAB839\",\"TX\":\"#BF1B00\"}}}",
99. "description": "",
100. "savedSearchId": "Network",
101. "version": 1,
102. "kibanaSavedObjectMeta": {
103. "searchSourceJSON": "{\"filter\":[]}"
104. }
105. }
106. },
107. {
108. "_id": "Memory-[Node-equal->Container]",
109. "_type": "visualization",
110. "_source": {
111. "title": "Memory [Node=>Container]",
112. "visState": "{\"title\":\"Memory [Node=>Container]\",\"type\":\"area\",\"params\":{\"shareYAxis\":true,\"addTooltip\":true,\"addLegend\":true,\"smoothLines\":false,\"scale\":\"linear\",\"interpolate\":\"linear\",\"mode\":\"stacked\",\"times\":[],\"addTimeMarker\":false,\"defaultYExtents\":false,\"setYExtents\":false,\"yAxis\":{}},\"aggs\":[{\"id\":\"1\",\"type\":\"avg\",\"schema\":\"metric\",\"params\":{\"field\":\"container_stats.memory.usage\"}},{\"id\":\"2\",\"type\":\"date_histogram\",\"schema\":\"segment\",\"params\":{\"field\":\"container_stats.timestamp\",\"interval\":\"auto\",\"customInterval\":\"2h\",\"min_doc_count\":1,\"extended_bounds\":{}}},{\"id\":\"3\",\"type\":\"terms\",\"schema\":\"group\",\"params\":{\"field\":\"container_Name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\"}},{\"id\":\"4\",\"type\":\"terms\",\"schema\":\"split\",\"params\":{\"field\":\"machine_name\",\"size\":5,\"order\":\"desc\",\"orderBy\":\"1\",\"row\":true}}],\"listeners\":{}}",
113. "uiStateJSON": "{}",
114. "description": "",
115. "version": 1,
116. "kibanaSavedObjectMeta": {
117. "searchSourceJSON": "{\"index\":\"cadvisor*\",\"query\":{\"query_string\":{\"query\":\"* NOT container_Name.raw: \\\\\\\"/\\\\\\\" AND NOT container_Name.raw: \\\\\\\"/docker\\\\\\\"\",\"analyze_wildcard\":true}},\"filter\":[]}"
118. }
119. }
120. }
121. ]

這裏還有很多東西可以玩，你也許想自定義報表界麵，比如添加內存頁錯誤狀態，或者收發包的丟包數。如果你能實現開頭列表處我沒能實現的項目，那也是很好的。

總結

正確監控需要大量時間和精力，容器的 CPU、內存、IO、網絡和磁盤，監控的這些參數還隻是整個監控項目中的滄海一粟而已。

我不知道你做到了哪一階段，但接下來的任務也許是：

• 收集運行中的容器的日誌
• 收集應用的日誌
• 監控應用的性能
• 報警
• 監控健康狀態

最後更新：2017-06-06 16:02:33

  上一篇：  如何運用 Python 建立你的第一個 Slack 聊天機器人？

  下一篇：  揭秘 Twitter 背後的基礎設施：效率與優化篇