DCOS監(jiān)控模塊設計

1、第 1 頁 共 13 頁DCOS 監(jiān)控模塊設計說明書初稿鄒能人 第 2 頁 共 13 頁目目 錄錄DCOS監(jiān)控系統(tǒng).1系統(tǒng)架構(gòu)設計說明書.1第一章第一章 現(xiàn)狀與需求分析現(xiàn)狀與需求分析 .51.1. 業(yè)務現(xiàn)狀.51.1.1. 業(yè)務背景.51.1.2. 主要建設目標與任務.51.2. 需求分析.61.2.1. 監(jiān)控需求.61.2.2. 需求綜合分析.8第二章第二章 總體設計總體設計.92.1. 技術(shù)選型.92.1.1. Docker Stats.92.1.2. Cadvisor.102.1.3. Sensu.112.1.4. Scout.112.1.5. Sematext.112.1.6. Pro

2、metheus .122.2. 監(jiān)控模塊架構(gòu)設計.132.2.1. 特性.132.2.2. 組件.132.2.3. 架構(gòu).13第三章第三章 監(jiān)控模塊功能與內(nèi)容監(jiān)控模塊功能與內(nèi)容.153.1. 目前監(jiān)控功能.153.1.1. 集中監(jiān)控管理.153.1.2. 統(tǒng)一監(jiān)控管理界面與告警功能 .153.1.3. 自定義告警策略.153.2. 接口設計.15第 3 頁 共 13 頁第一章第一章 現(xiàn)狀與需求分析現(xiàn)狀與需求分析1.1.業(yè)務現(xiàn)狀業(yè)務現(xiàn)狀1.1.1.業(yè)務背景業(yè)務背景隨著 DCOS 系統(tǒng)的逐漸成熟，DCOS 系統(tǒng)平臺上線業(yè)務逐漸增多，依靠過去人工巡檢系統(tǒng)的方式發(fā)現(xiàn)系統(tǒng)故障、潛在風險及安全隱患的方式效

3、率越來越低下且運維人員的工作強度及壓力也在不斷增加，為了提高發(fā)現(xiàn)系統(tǒng)故障的及時性、系統(tǒng)維護的專業(yè)性、規(guī)范化、科學性同時也能把運維人員從重復的工作中解放出來去做更多有意義的事情，因此我們亟需引入平臺級的監(jiān)控手段、工具來協(xié)助運維工程師解決當前的問題。建設以應用監(jiān)控為核心，集成集群監(jiān)控、主機監(jiān)控、彈性告警等功能的企業(yè)級監(jiān)控系統(tǒng)，在 DCOS 系統(tǒng)中采用統(tǒng)一技術(shù)手段實現(xiàn)應用的智能運行管理。1.1.2.主要建設目標與任務主要建設目標與任務為保證自有軟件平臺運行穩(wěn)定性，對 DCOS 系統(tǒng)平臺進行自動化監(jiān)控，合理設置監(jiān)控粒度及監(jiān)控對象。盡可能的把潛在問題在萌芽狀態(tài)解決及消除隱患，以此提高 DCOS 系統(tǒng)的安

4、全性與穩(wěn)定性。監(jiān)控模塊的最終目標如下所示：1. 及時發(fā)現(xiàn)潛在的問題化被動為主動維護；2. 為平臺性能優(yōu)化提供直觀參考依據(jù)；3. 提高系統(tǒng)維護的專業(yè)性和規(guī)范性；4. 提高用戶體驗，降低服務宕機時間。第 4 頁 共 13 頁1.2.需求分析需求分析1.2.1.監(jiān)控需求監(jiān)控需求.平臺監(jiān)控告警平臺監(jiān)控告警、集群監(jiān)控指標集群內(nèi)部組件的信息采集，下面只是事例，不局限于此：haproxy，采集 Haproxy 基礎(chǔ)狀態(tài)信息，比如 qcur、scur、rate 等nginx，采集 nginx 正常請求、異常請求、異常請求比例、請求平均響應時間、upstream 請求次數(shù)、平均響應時間等單臺物理機

5、的監(jiān)控信息目前所需如下：CPUuser 使用率、system 使用率、空閑率、總量Mem總量、使用率Swap總量、使用率Disk總量、使用率、IO 讀寫的數(shù)、量與時間Network網(wǎng)卡進出流量、進出包數(shù)、進出錯包數(shù)、丟棄包數(shù)主機進程/以及進程之間的關(guān)系拓撲CPU、Mem、耗時、狀態(tài)、用戶等數(shù)據(jù)FileSystem總量、使用率等容器監(jiān)控目前所需監(jiān)控信息如下：CPUuser 使用率、system 使用率、空閑率、總量Mem總量、使用率Disk總量、使用率、IO 讀寫的數(shù)、量與時間Network網(wǎng)卡進出流量、進出包數(shù)、進出錯包數(shù)、丟棄包數(shù)進程(容器內(nèi)一般都為單進程)CPU、Mem、耗時、狀態(tài)、用戶等

6、數(shù)據(jù)、集群數(shù)據(jù)聚合單臺機器的監(jiān)控指標難以反應整個集群的情況，我們需要把整個集群的機器（體現(xiàn)為某個 HostGroup 下的機器）綜合起來看。比如所有機器的 qps 加和才是整個集群的 qps，所有機器的 request_fail 數(shù)量 所有機器的 request_total 數(shù)量=整個集群的請求失敗率。同樣，單容器無法反應整個應用的情況，需要將應用所屬的所有容器綜合分析。、集群監(jiān)控配置集群配置 和 策略配置監(jiān)控集群的節(jié)點可操作，監(jiān)控策略可配置、監(jiān)控性能能夠支持的監(jiān)控集群大小以及采集間隔、平臺級告警第 5 頁 共 13 頁告警觸發(fā)條件可配、告警觸發(fā)事件可配、提供告警級別設置、告警提示方式(郵件、

7、短信等、最好有接口)等.二、應用監(jiān)控告警二、應用監(jiān)控告警以下所述為 web 應用實例，但應用監(jiān)控不僅限于此：1、應用拓撲2、應用健康度根據(jù)應用平均負載，應用平均訪問延時，告警數(shù)量等指標進行綜合評分后，計算出來的反映應用健康程度的分值。3、用戶訪問平均延時用戶訪問平均時延。4、數(shù)據(jù)庫概況總占用空間：目前存儲數(shù)據(jù)已使用的空間?？偛樵償?shù)：包括增，刪，改，查的總訪問量。慢查詢數(shù) ：導致慢查詢的訪問量。eplace 請求量 ：replace 請求的數(shù)量。insert 請求量 ：insert 請求的數(shù)量。delete 請求量 ：delete 請求的數(shù)量。select 請求量 ：select

8、請求的數(shù)量。update 請求量 ：update 請求的數(shù)量。當前連接數(shù) ：當前連接到該 mysql 實例的連接數(shù)。連接使用率 ：已建立的連接數(shù)占最大連接數(shù)的百分比，不同類型的實例的最大連接數(shù)不同5、緩存概況表空間 ： 分配給當前業(yè)務的總空間已使用空間 ： 當前業(yè)務實際使用的空間總記錄數(shù) ： 當前應用存儲的記錄條數(shù)，key-value 對數(shù) GET 次數(shù) ： 按 5 分鐘查詢時表示最近 5 分鐘內(nèi)的讀訪問量。按天查詢時取當天的峰值(次/秒)SET 次數(shù) ： 按 5 分鐘查詢時表示最近 5 分鐘內(nèi)的寫訪問量。按天查詢時取當天的峰值(次/秒)DELETE 次數(shù) ： 按 5 分鐘查詢時表示最近 5

9、分鐘內(nèi)的寫訪問量。按天查詢時取當天的峰值(次/秒)總次數(shù) ： 按 5 分鐘查詢時表示最近 5 分鐘內(nèi)的 GET/SET/DELETE 訪問量。按天查詢時取當天的峰值(次/秒)超時次數(shù) ： 按 5 分鐘查詢時表示最近 5 分鐘內(nèi)的 GET/SET/DELETE 超時次數(shù)。按天查詢時取當天的峰值(次/秒)6、流量監(jiān)控提供實時流量以及近期流量查詢、展示功能7、用戶體驗監(jiān)控訪問量、時延與頁面停留時長等第 6 頁 共 13 頁1.2.2.需求綜合分析需求綜合分析.需求邊界的界定需求邊界的界定需求邊界的界定主要是以上任務目標中的模塊的范圍內(nèi)，但不限于網(wǎng)絡通訊、網(wǎng)絡設置、服務器安置、客戶端訪問

10、地點、客戶個性化使用習慣等。項目需求的邊界的界定，其主要功能范圍有以下內(nèi)容：1、 監(jiān)控數(shù)據(jù)的采集與發(fā)送，確保及時性與準確性2、 監(jiān)控數(shù)據(jù)的分析以及更新相關(guān)數(shù)據(jù)模型為其他模塊提供數(shù)據(jù)信息3、 可以進行歷史數(shù)據(jù)的查詢與維護工作4、 人機界面的友好操作5、 提供 RestApi 訪問接口，便于客戶端訪問6、 可以為其他系統(tǒng)提供實時數(shù)據(jù)、事項數(shù)據(jù)、歷史數(shù)據(jù)等各類查詢操作接口7、 保證系統(tǒng)的健壯性與可靠性8、 告警參數(shù)的可配置9、 數(shù)據(jù)的備份與恢復第 7 頁 共 13 頁第二章第二章 總體設計總體設計2.1.技術(shù)選型技術(shù)選型這一章節(jié)我們來比較監(jiān)控容器的常用工具。將基于以下標準評估這些工具： 1、易于部署

11、2、信息呈現(xiàn)的詳細度3、整個部署過程中日志的聚集程度4、數(shù)據(jù)報警能力5、是否可以監(jiān)控非 Docker 的資源6、成本2.1.1.Docker Stats我將討論的第一個工具是 Docker 本身。你可能不知道 Docker 客戶端已經(jīng)提供了基本的命令行工具來檢查容器的資源消耗。想要查看容器統(tǒng)計信息只需運行 docker stats CONTAINER_NAME。這樣就可以查看每個容器的 CPU 利用率、內(nèi)存的使用量以及可用內(nèi)存總量。請注意，如果你沒有限制容器內(nèi)存，那么該命令將顯示您的主機的內(nèi)存總量。但它并不意味著你的每個容器都能訪問那么多的內(nèi)存。另外，還可以看啊都容器通過網(wǎng)絡發(fā)送和接收的數(shù)據(jù)總

12、量。 $ docker stats determined_shockley determined_wozniak prickly_hypatiaCONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/Odetermined_shockley 0.00% 884 KiB/1.961 GiB 0.04% 648 B/648 Bdetermined_wozniak 0.00% 1.723 MiB/1.961 GiB 0.09% 1.266 KiB/648 Bprickly_hypatia 0.00% 740 KiB/1.961 GiB 0.04% 1.898 KiB/

13、648 B如果想要看到更為詳細的容器屬性，還可以通過 netcat，使用 Docker 遠程 API 來查看（見下文）。發(fā)送一個 HTTP GET 請求/containers/CONTAINER_NAME，其中CONTAINER_NAME 是你想要統(tǒng)計的容器名稱。在上述的例子中你會得到緩存、交換空間以及內(nèi)存的詳細信息。 總體評價：1. 易于部署程度： 2. 信息詳細程度： 3. 集成度：無 4. 生成警報的能力：無 第 8 頁 共 13 頁5. 監(jiān)測非 Docker 的資源的能力：無 6. 成本：免費 2.1.2. Cadvisor我們可以使用 docker stats 命令和遠程 API 來

14、獲取容器的狀態(tài)信息。但是，如果你想要在圖形界面中直接查看這些信息，那你就需要諸如 CAdvisor 這類的工具。CAdvisor 提供了早 docker stats 命令所顯示的數(shù)據(jù)的可視化界面。運行以下 Docker 命令，并在瀏覽器里訪問 http:/<your-hostname:8080/可以看到 CAdvisor 的界面。你將看到 CPU 的使用率、內(nèi)存使用率、網(wǎng)絡吞吐量以及磁盤空間利用率。然后，你可以通過點擊在網(wǎng)頁頂部的 Docker Containers 鏈接，然后選擇某個容器來詳細了解它的使用情況。 docker run -volume=/:/rootfs:ro -

15、volume=/var/run:/var/run:rw -volume=/sys:/sys:ro -volume=/var/lib/docker/:/var/lib/docker:ro -publish=8080:8080 -detach=true -name=cadvisor google/cadvisor:latestCAdvisor 是一個易于設置并且非常有用的工具，我們不用非要 SSH 到服務器才能查看資源消耗，而且它還給我們生成了圖表。此外，當集群需要額外的資 源時，壓力表（pressure gauges ）提供了快速預覽。而且，與本文中的其他的工具不一樣的是 CAdvisor是免費

16、的，并且還開源。另外，它的資源消耗也比較低。但是，它有它的局限性，它 只能監(jiān)控一個 Docker 主機。因此，如果你是多節(jié)點的話，那就比較麻煩了，你得在所有的主機上都安裝一個 CAdvisor，者肯定特別不方便。值得注意 的是，如果你使用的是Kubernetes，你可以使用 heapster 來 監(jiān)控多節(jié)點集群。另外，在圖表中的數(shù)據(jù)僅僅是時長一分鐘的移動窗口，并沒有方法來查看長期趨勢。如果資源使用率在危險水平，它卻沒有生成警告的機制。如果 在 Docker 節(jié)點的資源消耗方面，你沒有任何可視化界面，那么CAdvisor 是一個不錯的開端來帶你步入容器監(jiān)控，然而如果你打算在你的容器中運行任 何關(guān)

17、鍵任務，那你就需要一個更強大的工具或者方法。 總體評價：第 9 頁 共 13 頁1. 易于部署程度： 2. 信息詳細程度： 3. 集成度： 4. 生成警報的能力：無 5. 監(jiān)測非 Docker 的資源的能力：無 6. 成本：免費 2.1.3. SensuScout 和 Datadog 提供集中監(jiān)控和報警系統(tǒng)，然而他們都是被托管的服務，大規(guī)模部署的話成本會很突出。要運行 Sensu 服務器可以使用容器。這個容器會安裝 sensu-server、uchiwa Web 界面、Redis、rabbitmq-server 以及 sensu-api。不幸的是 sensu 不支持Docker。但是，使用插件

18、系統(tǒng)，您可以配置支持容器指標以及狀態(tài)檢查。 Sensu 支持我們所有的評價標準，你可以對我們 Docker 容器和主機收集盡可能多的細節(jié)。此外，你能夠聚合所有主機的值到一個地方，并對這些檢查發(fā)出 警報。這些警報并沒有 DataDog 或 Scout 的先進，因為你僅能夠提醒單獨的主機上檢查失敗。然而，Sensu 的大缺點是部署的難度。雖然我 已經(jīng)使用 Docker 容器自動部署許多步驟，Sensu 仍然是一個需要我們安裝，啟動和分開維護 Redis、RabitMQ、Sensu API、uchiwa 與 Sensu Core 的復雜系統(tǒng)。此外，你將需要更多的工具，如 Graphite 來呈現(xiàn)指標

19、值以及生產(chǎn)部署需要定制容器，今天我已經(jīng)使用了一個容器為了密碼的安全以及 自定義的 SSL 證書。除了您重啟容器后才能添加更多的檢查，你將不得不重新啟動 Sensu 服務，因為這是它開始收集新的標準的唯一途徑。由于這些原因，我 對 Sensu 的在易于部署的評價相當?shù)牡汀?評分：1、易于部署程度： 2、信息詳細程度： 3、集成度： 4、生成警報的能力：支持但有限 5、監(jiān)測非 Docker 的資源的能力： 6、成本：免費 2.1.4. ScoutScout 是一款監(jiān)視服務，并不是一個獨立的開源項目。它有大量的插件，除了 Docker 信息還可以吸收其他有關(guān)部署的數(shù)據(jù)。因此 Scout 算是一站式監(jiān)

20、控系統(tǒng)，無需對系統(tǒng)的各種資源來安裝各種不同的監(jiān)控系統(tǒng)。 Scout 的一個缺點是，它不顯示有關(guān)每個主機上單獨容器的詳細信息。此外，每個監(jiān)控的主機十美元這樣略微昂貴的價格也是是否選擇 Scout 作為監(jiān)控服務的一個考慮因素，如果運行一個有多臺主機的超大部署，成本會比較高。2.1.5. SematextSematext 也是一款付費監(jiān)控解決方案，計劃收費方案是 3.5 美分/小時。同樣也支持 Docker 監(jiān)控，還包括對容器級事件的監(jiān)測（停止、開始等等）和管理容器產(chǎn)生的日志。第 10 頁 共 13 頁2.1.6. Prometheus Prometheus 由 SoundCloud 發(fā)明，適合于監(jiān)

21、控基于容器的基礎(chǔ)架構(gòu)。Prometheus 特點是高維度數(shù)據(jù)模型，時間序列是通過一個度量值名字和一套鍵值對識別。靈活的查詢語言允許查詢和繪制數(shù)據(jù)。它采用了先進的度量標準類型像匯總（summaries），從指定時間跨度的總數(shù)構(gòu)建比率或者是在任何異常的時候報警并且沒有任何依賴，中斷期間使它成為一個可靠的系統(tǒng)進行調(diào)試。Prometheus 支持維度數(shù)據(jù)，你可以擁有全局和簡單的指標名像container_memory_usage_bytes ，使用多個維度來標識你服務的指定實例。我已經(jīng)創(chuàng)建了一個簡單的 container-exporter 來收集 Docker 容器的指標以及輸出給 Prometheu

22、s 來消費。這個輸出器使用容器的名字，id 和 鏡像作為維度。額外的 per-exporter 維度可以在 prometheus.conf 中設置。如果你使用指標名字直接作為一個查詢表達式，它將返回有這個使用這個指標名字作為標簽的所有時間序列。使用 Prometheus 的查詢語言，你可以對你想的任何維度的數(shù)據(jù)切片和切塊。如果你對一個給定名字的所有容器感興趣，你可以使用一個表達式像container_memory_usage_bytesname=consul-server ，這個將僅僅顯示 name = consul-server 的時間序列。像多維度的數(shù)據(jù)模型，來實現(xiàn)數(shù)據(jù)聚合、分組、過濾，不

23、單單是 Prometheus。OpenTSDB 和 InfluxDB 這些時間序列數(shù)據(jù)庫和系統(tǒng)監(jiān)控工具的結(jié)合，讓系統(tǒng)監(jiān)控這件事情變得更加的多元。特性：1、高維度數(shù)據(jù)模型2、自定義查詢語言3、可視化數(shù)據(jù)展示4、高效的存儲策略5、易于運維6、提供各種客戶端開發(fā)庫7、警告和報警8、數(shù)據(jù)導出Docker 兼容相比其他的數(shù)據(jù)庫、系統(tǒng)、中間件監(jiān)控，要復雜一些。由于需要表征不同 Container 的性能消耗，來了解不同應用的運行情況，所以數(shù)據(jù)的聚合、切片（分組）和過濾，在 Docker 監(jiān)控中成為了必備功能。 除了監(jiān)控 Docker 以外，DCOS 系統(tǒng)還需監(jiān)第 11 頁 共 13 頁控其他組件，如果一個

24、工具在監(jiān)控 Docker 同時能夠監(jiān)控其他組件，那就更好了，根據(jù)以上的對比，選擇 Prometheus 與 Cadvisor 進行 DCOS 監(jiān)控。2.2.監(jiān)控模塊監(jiān)控模塊架構(gòu)設計架構(gòu)設計Prometheus 是一個開源的系統(tǒng)監(jiān)控和報警的工具包，最初由 SoundCloud 發(fā)布。2.2.1. 特性Prometheus 的主要特點是：1、多維數(shù)據(jù)模型（有 metric 名稱和鍵值對確定的時間序列）2、靈活的查詢語言3、不依賴分布式存儲4、通過 pull 方式采集時間序列，通過 http 協(xié)議傳輸5、支持通過中介網(wǎng)關(guān)的 push 時間序列的方式6、監(jiān)控數(shù)據(jù)通過服務或者靜態(tài)配置來發(fā)現(xiàn)7、支持圖表和 dashboard 等多種方式2.2.2. 組件Prometheus 包含多個組件，其中有許多是可選的：1、Prometheus 主服務器，用來收集和存儲時間序列數(shù)據(jù)2、應用程序 client 代碼庫3、短時 jobs 的 push gateway4、基于 Rails