銀行云管平臺監(jiān)控最佳實踐

1、 銀行云管平臺監(jiān)控經(jīng)驗分享 | 最佳實踐 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc65363145 銀行云管平臺監(jiān)控經(jīng)驗分享 | 最佳實踐 PAGEREF _Toc65363145 h 1 HYPERLINK l _Toc65363146 1、VM監(jiān)控和KVM監(jiān)控實踐 PAGEREF _Toc65363146 h 3 HYPERLINK l _Toc65363147 1.1 通過使用 pyVmomi 采集 vSphere 監(jiān)控指標 PAGEREF _Toc65363147 h 3 HYPERLINK l _Toc65363148 2、OpenStack 監(jiān)控實踐

2、 PAGEREF _Toc65363148 h 8 HYPERLINK l _Toc65363149 3、PaaS與PaaS管理平臺K8S PAGEREF _Toc65363149 h 10 HYPERLINK l _Toc65363150 3.1 PaaS概述 PAGEREF _Toc65363150 h 10 HYPERLINK l _Toc65363151 3.3 Docker概述 PAGEREF _Toc65363151 h 12 HYPERLINK l _Toc65363152 3.4 Kubernetes概述 PAGEREF _Toc65363152 h 14 HYPERLINK

3、l _Toc65363153 4、Docker監(jiān)控與K8S監(jiān)控實踐 PAGEREF _Toc65363153 h 16 HYPERLINK l _Toc65363154 4.1 容器的監(jiān)控方案 PAGEREF _Toc65363154 h 16 HYPERLINK l _Toc65363155 4.2 K8S監(jiān)控 PAGEREF _Toc65363155 h 19 HYPERLINK l _Toc65363156 kubectl create -f node-exporter-deamonset.yaml PAGEREF _Toc65363156 h 22 HYPERLINK l _Toc65

4、363157 kubectl create -f prometheus-file-sd.yaml PAGEREF _Toc65363157 h 22 HYPERLINK l _Toc65363158 5、監(jiān)控容器上微服務(wù) PAGEREF _Toc65363158 h 24 HYPERLINK l _Toc65363159 實現(xiàn)方式 PAGEREF _Toc65363159 h 24 HYPERLINK l _Toc65363160 監(jiān)控指標 PAGEREF _Toc65363160 h 25 HYPERLINK l _Toc65363161 服務(wù)鏈路監(jiān)控 PAGEREF _Toc6536316

5、1 h 25 HYPERLINK l _Toc65363162 健康性檢查 PAGEREF _Toc65363162 h 26 HYPERLINK l _Toc65363163 日志監(jiān)控 PAGEREF _Toc65363163 h 26 HYPERLINK l _Toc65363164 6、云管監(jiān)控平臺與集中監(jiān)控平臺集成 PAGEREF _Toc65363164 h 27 HYPERLINK l _Toc65363165 7、展望未來 PAGEREF _Toc65363165 h 28【摘要】隨著云計算技術(shù)的發(fā)展，越來越多的云平臺和服務(wù)類型出現(xiàn)， 如VM 、 KVM 、 PaaS等，各大企業(yè)

6、都在紛紛建設(shè)自己私有云平臺包括 IaaS、PaaS，同時 IaaS也有自己的云管理平臺如OpenStack，另外PaaS也有自己的云管理平臺如 Kubernetes ， 但是如何有效的監(jiān)控VM 、 KVM 、 Openstack 、 Kubernetes和PaaS平臺上的微服務(wù) ，以及如何有效的將云管平臺監(jiān)控集成到現(xiàn)有的集中監(jiān)控平臺也是目前云管平臺建設(shè)過程中遇到的各種問題，本文將從以上幾個方面進行討論。1、VM監(jiān)控和KVM監(jiān)控實踐1.1 通過使用 pyVmomi 采集 vSphere 監(jiān)控指標vSphere需要監(jiān)控的內(nèi)容包含：1、ESXi 主機的狀態(tài) ；2、datastore 所有掛載的存儲，

7、要監(jiān)控他們的使用情況，剩余空間 。3、vm 通過 vSphere 來獲取租戶服務(wù)器的相關(guān)指標。如何將這些監(jiān)控數(shù)據(jù)從 vCenter 里取出來呢？pyVmomi是 VMware vSphere API 的一個 python sdk，我們可以利用它來與 vCenter 交互，獲取我們需要的信息，使用 pyVmomi 連接 vCenter 。在連接上 vCenter 之后，我們就可以開始獲取各項指標了。我們從 content 下的根目錄逐級開始遍歷，他的第一個 childEntity 就是我們的datacenter 。我們可以通過 ，獲取 datacenter 的名字，在組織數(shù)據(jù)上報的時候，可以作為

8、 tag打在 datastore 上，可以區(qū)分 datastore 來自哪個 datacenter 。datastore 的容量，類型等數(shù)據(jù)，則都在 datastore.summary 之中 。ESXi即我們 vSphere 集群中的主機信息，vSphere 中內(nèi)置了大量的性能指標，可以從perfManager.perfCounter 中獲取。1、content 就是連接 vCenter后返回的那個 content2、vchtime 當前的時間，用來計算查詢的時間范圍，可以通過 si.CurrentTime() 去拿 vCenter的當前時間，規(guī)避時間同步問題3、counterId 需要查詢的

9、 counter 所對應(yīng)的 ID 號4、instance 需要返回的實例，某些指標會有多個實例。比如網(wǎng)絡(luò)指標就對應(yīng)有多張網(wǎng)卡。*則表示全部返回5、entity 查詢的對象，比如 ESXi 主機或者某個 虛擬機6、interval 查詢的間隔，用來產(chǎn)生查詢的時間范圍。和我們上報監(jiān)控的 step 保持一致。使用perfManger 查詢性能時，需要給出查詢的時間范圍和查詢的顆粒度。我這里使用的顆粒度是 intervalId = 20，也就是 20 秒一個點。提供的時間范圍提前了 1 分鐘，避免太接近當前時間的點上查不到數(shù)據(jù)。類似的, vm 的數(shù)據(jù)都在 Datacenter.vmFolder 下面，

10、當然也會碰到Folder嵌套的問題。不過我們之所以遍歷 Folder 去獲取主機信息，主要是為了能夠在遍歷過程中，拿到主機上級的 Datacenter和Cluster等信息，作為數(shù)據(jù)的tag一同報送給監(jiān)控系統(tǒng)。我們可以通過更簡單的辦法拿到所有的 vm 清單 。VMware ESXi虛擬機監(jiān)控指標列表監(jiān)測點監(jiān)測指標指標含義CPUCPU使用率(%)CPU處理任務(wù)的繁忙程度CPU使用量(MHz)CPU處理任務(wù)時占用的兆赫茲數(shù)量內(nèi)存(這里指物理內(nèi)存)內(nèi)存使用率(%)內(nèi)存使用數(shù)和內(nèi)存總量的比值活動內(nèi)存(MB)正在使用的內(nèi)存數(shù)內(nèi)存總量(MB)物理內(nèi)存總數(shù)磁盤磁盤讀IO(次/20s)每20s磁盤讀的次數(shù)磁盤

11、寫IO(次/20s)每20s磁盤寫的次數(shù)磁盤讀速率(KBps)每秒磁盤讀的K字節(jié)數(shù)磁盤寫速率(KBps)每秒磁盤寫的K字節(jié)數(shù)網(wǎng)卡網(wǎng)絡(luò)接收速率(KBps)每秒網(wǎng)卡接收的K字節(jié)數(shù)網(wǎng)絡(luò)發(fā)送速率(KBps)每秒網(wǎng)卡發(fā)送的K字節(jié)數(shù)硬盤性能讀取滯后時間（毫秒）單個硬盤讀取滯后的時間寫入滯后時間（毫秒）單個硬盤寫入滯后的時間CPU核心已使用（毫秒）單個CPU核心的已使用時間閑置（毫秒）單個CPU核心的閑置時間虛擬機CPU使用率（%）虛擬機的CPU處理任務(wù)的繁忙程度CPU使用量（MHz）虛擬機的CPU處理任務(wù)時占用的兆赫茲數(shù)量內(nèi)存利用率（%）虛擬機內(nèi)存使用數(shù)和虛擬機內(nèi)存總量的比值活動內(nèi)存（MB）虛擬機正在使用

12、的內(nèi)存數(shù)內(nèi)存總量（MB）虛擬機的內(nèi)存總數(shù)硬盤讀速率（KBps）每秒虛擬機硬盤讀的K字節(jié)數(shù)硬盤寫速率（KBps）每秒虛擬機硬盤寫的K字節(jié)數(shù)硬盤讀IO（次/20s）虛擬機每20s硬盤讀的次數(shù)硬盤寫IO（次/20s）虛擬機每20s硬寫的次數(shù)網(wǎng)絡(luò)接收速率（KBps）虛擬機每秒網(wǎng)卡接收的K字節(jié)數(shù)網(wǎng)絡(luò)發(fā)送速率（KBps）虛擬機每秒網(wǎng)卡發(fā)送的K字節(jié)數(shù)數(shù)據(jù)存儲使用率(%)(總?cè)萘?剩余容量)/ 總?cè)萘靠側(cè)萘?GB)VMware數(shù)據(jù)存儲的總?cè)萘渴Ｓ嗳萘?GB)VMware數(shù)據(jù)存儲的剩余容量1.2 通過Libvirt-python監(jiān)控KVMKVM(Kernel-based Virtual Machine)作為一個

13、開源的系統(tǒng)虛擬化模塊，已經(jīng)成為虛擬機虛擬化技術(shù)的主流，在越來越多的Cloud環(huán)境中使用。為了保證Cloud環(huán)境的正常運行，需要在運維過程中對Cloud環(huán)境中的VM狀態(tài)進行監(jiān)控，比如CPU，內(nèi)存，Disk，Disk I/O，Network I/O等信息，可以利用這些信息及時的調(diào)整分配Cloud環(huán)境的資源，保證VM的正常運行。Libvirt是基于KVM的上層封裝，提供了操作KVM的原生層接口，可以實現(xiàn)對虛擬機的日常管理操作，如虛擬機的生命周期(創(chuàng)建，刪除，查看，管理)，開機，關(guān)機，重啟，網(wǎng)絡(luò)管理，存儲管理等。Libvirt提供一種虛擬機監(jiān)控程序不可知的 API 來安全管理運行于主機上的客戶操作系統(tǒng)

14、，是一種可以建立工具來管理客戶操作系統(tǒng)的 API。Libvirt 本身構(gòu)建于一種抽象的概念之上。它為受支持的虛擬機監(jiān)控程序?qū)崿F(xiàn)的常用功能提供通用的API，適用于包括基于KVM/QEMU, Xen, LXC, OpenVZ, Virtualbox, VMware, PowerVM等多種虛擬機化技術(shù)的虛擬機。Libvirt-python是基于libvirt API的python語言綁定工具包，通過該包，可以使用python對VM進行日常管理操作和監(jiān)控數(shù)據(jù)獲取。需要運行的Python監(jiān)控程序可以在KVM的HOST中運行，也可以在基于KVM虛擬機化的任意環(huán)境運行。利用Python調(diào)用API獲取 VM相

15、關(guān)監(jiān)控信息代碼如下：1.2.1 創(chuàng)建連接fromfutureimport print_functionimport sysimport libvirtconn = libvirt.open(qemu:/system)1.2.2 列出Domainsconn.listAllDomains(type)方法返回指定類型的domains列表，type參數(shù)可以設(shè)置以下類型2.2.3 獲取監(jiān)控數(shù)據(jù)VM的監(jiān)控信息主要是CPU使用率，內(nèi)存使用率，Disk使用率，Disk I/O，Network I/O。其中，CPU的使用率，Disk I/O，Network I/O并不能直接獲取，需要經(jīng)過計算獲得。另外 ， op

16、enstack的ceilometer組件也能實現(xiàn)KVM監(jiān)控 ，感謝的同學(xué)可以自己研究一下。2、OpenStack 監(jiān)控實踐OpenStack是由控制節(jié)點，計算節(jié)點，網(wǎng)絡(luò)節(jié)點，存儲節(jié)點四大部分組成。（這四個節(jié)點也可以安裝在一臺機器上，單機部署）其中：控制節(jié)點負責對其余節(jié)點的控制，包含虛擬機建立，遷移，網(wǎng)絡(luò)分配，存儲分配等等 ， 計算節(jié)點負責虛擬機運行 ， 網(wǎng)絡(luò)節(jié)點負責對外網(wǎng)絡(luò)與內(nèi)網(wǎng)絡(luò)之間的通信 ， 存儲節(jié)點負責對虛擬機的額外存儲管理等等 。在這里主要是探索了一下openstack的監(jiān)控，采用prometheus社區(qū)里面一個openstack-exporter ，需要根據(jù)自己實際的需求，從expo

17、rter里面暴露的眾多metrics進行展示。另外虛擬機也需要監(jiān)控，這里使用的openstack-exporter是通過客戶端api接入到openstack環(huán)境中對一些通用的參數(shù)進行采集，對于openstack自身的組件沒有監(jiān)控，對于kolla部署出來的openstack，需要監(jiān)控容器，這里也沒有涉及，對于虛擬機的內(nèi)部運行情況監(jiān)控，也需要規(guī)劃設(shè)計，這里也沒有涉及，如果要對openstack生產(chǎn)環(huán)境進行監(jiān)控，還有很多工作需要做。OpenStack exporter一個是：sum(nova_instancesinstance_state=ACTIVE) /總活動VM數(shù)一個是：sum(hypervi

18、sor_vcpus_used) by(hypervisor_hostname) /每臺物理機上已經(jīng)使用的vcpu數(shù)步驟1: 開啟一個線程默認每隔30秒輪詢:步驟1.1: openstack各組件api服務(wù)的狀態(tài)，步驟1.2: 獲取nova/neutron/cinder組件下面在每個host上具體服務(wù)的狀態(tài)步驟1.3: 獲取nova的hypervisor信息獲取上述的信息，分別建立存放在字典中步驟2: 開啟一個TCPServer服務(wù)器，監(jiān)聽9103端口，prometheus默認每隔60秒向prometheus-openstack-exporter服務(wù)發(fā)送請求，該請求會被上述TCPServer服務(wù)

19、器處理。請求處理見步驟3步驟3: 遍歷緩存結(jié)果，獲取每個緩存名稱對應(yīng)的結(jié)果列表(是數(shù)組)，步驟3.1: 對該緩存結(jié)果列表遍歷，對每個緩存結(jié)果(是字典), 調(diào)用prometheus_client的方法設(shè)置監(jiān)控項名稱，監(jiān)控項對應(yīng)的值，以及標簽列表步驟3.2: 最后調(diào)用prometheus_client.generate_latest(registry)方法產(chǎn)生最終結(jié)果(是一個字符串)并返回對上述每個緩存結(jié)果產(chǎn)生的字符串進行拼接，最終做為一個大字符串返回給prometheus。3、PaaS與PaaS管理平臺K8S目前很多的容器云平臺通過Docker及Kubernetes等技術(shù)提供應(yīng)用運行平臺，從而實

20、現(xiàn)運維自動化，快速部署應(yīng)用、彈性伸縮和動態(tài)調(diào)整應(yīng)用環(huán)境資源，提高研發(fā)運營效率。從宏觀到微觀（從抽象到具體）的思路來理解：云計算PaaS App EngineXAEXXX App Engine （XAE泛指一類應(yīng)用運行平臺，例如GAE、SAE、BAE等）。3.1 PaaS概述3.1.1 PaaS概念1、PaaS(Platform as a service)，平臺即服務(wù)，指將軟件研發(fā)的平臺（或業(yè)務(wù)基礎(chǔ)平臺）作為一種服務(wù)，以SaaS的模式提交給用戶。2、PaaS是云計算服務(wù)的其中一種模式，云計算是一種按使用量付費的模式的服務(wù)，類似一種租賃服務(wù)，服務(wù)可以是基礎(chǔ)設(shè)施計算資源（IaaS），平臺（PaaS）

21、，軟件（SaaS）。租用IT資源的方式來實現(xiàn)業(yè)務(wù)需要，如同水力、電力資源一樣，計算、存儲、網(wǎng)絡(luò)將成為企業(yè)IT運行的一種被使用的資源，無需自己建設(shè)，可按需獲得。3、PaaS的實質(zhì)是將互聯(lián)網(wǎng)的資源服務(wù)化為可編程接口，為第三方開發(fā)者提供有商業(yè)價值的資源和服務(wù)平臺。簡而言之，IaaS就是賣硬件及計算資源，PaaS就是賣開發(fā)、運行環(huán)境，SaaS就是賣軟件。3.1.2 PaaS的特點（三種層次）特點說明平臺即服務(wù)PaaS提供的服務(wù)就是個基礎(chǔ)平臺，一個環(huán)境，而不是具體的應(yīng)用平臺及服務(wù)不僅提供平臺，還提供對該平臺的技術(shù)支持、優(yōu)化等服務(wù)平臺級服務(wù)“平臺級服務(wù)”即強大穩(wěn)定的平臺和專業(yè)的技術(shù)支持團隊，保障應(yīng)用的穩(wěn)定

22、使用3.2 容器云平臺技術(shù)棧功能組成部分使用工具應(yīng)用載體Docker編排工具Kubernetes配置管理Etcd網(wǎng)絡(luò)管理Flannel存儲管理Ceph底層實現(xiàn)Linux內(nèi)核的Namespace資源隔離和CGroups資源控制Namespace資源隔離 Namespaces機制提供一種資源隔離方案。PID,IPC,Network等系統(tǒng)資源不再是全局性的，而是屬于某個特定的Namespace。每個namespace下的資源對于其他namespace下的資源都是透明，不可見的。CGroups資源控制 CGroup（control group）是將任意進程進行分組化管理的Linux內(nèi)核功能。CGrou

23、p本身是提供將進程進行分組化管理的功能和接口的基礎(chǔ)結(jié)構(gòu)，I/O或內(nèi)存的分配控制等具體的資源管理功能是通過這個功能來實現(xiàn)的。CGroups可以限制、記錄、隔離進程組所使用的物理資源（包括：CPU、memory、IO等），為容器實現(xiàn)虛擬化提供了基本保證。CGroups本質(zhì)是內(nèi)核附加在程序上的一系列鉤子（hooks），通過程序運行時對資源的調(diào)度觸發(fā)相應(yīng)的鉤子以達到資源追蹤和限制的目的。3.3 Docker概述3.3.1 Docker介紹1、Docker - Build, Ship, and Run Any App, Anywhere2、Docker是一種Linux容器工具集，它是為“構(gòu)建（Build

24、）、交付（Ship）和運行（Run）”分布式應(yīng)用而設(shè)計的。3、Docker相當于把應(yīng)用以及應(yīng)用所依賴的環(huán)境完完整整地打成了一個包，這個包拿到哪里都能原生運行。因此可以在開發(fā)、測試、運維中保證環(huán)境的一致性。4、Docker的本質(zhì)：Docker=LXC(Namespace+CGroups)+Docker Images，即在Linux內(nèi)核的Namespace資源隔離和CGroups資源控制技術(shù)的基礎(chǔ)上通過鏡像管理機制來實現(xiàn)輕量化設(shè)計。3.3.2 Docker的基本概念 鏡像Docker 鏡像就是一個只讀的模板，可以把鏡像理解成一個模子（模具），由模子（鏡像）制作的成品（容器）都是一樣的（除非在生成時

25、加額外參數(shù)），修改成品（容器）本身并不會對模子（鏡像）產(chǎn)生影響（除非將成品提交成一個模子），容器重建時，即由模子（鏡像）重新制作成一個成品（容器），與其他由該模子制作成的成品并無區(qū)別。例如：一個鏡像可以包含一個完整的 ubuntu 操作系統(tǒng)環(huán)境，里面僅安裝了 Apache 或用戶需要的其它應(yīng)用程序。鏡像可以用來創(chuàng)建 Docker 容器。Docker 提供了一個很簡單的機制來創(chuàng)建鏡像或者更新現(xiàn)有的鏡像，用戶可以直接從其他人那里下載一個已經(jīng)做好的鏡像來直接使用。 容器Docker 利用容器來運行應(yīng)用。容器是從鏡像創(chuàng)建的運行實例。它可以被啟動、開始、停止、刪除。每個容器都是相互隔離的、保證安全的平臺

26、?？梢园讶萜骺醋鍪且粋€簡易版的 Linux 環(huán)境（包括root用戶權(quán)限、進程空間、用戶空間和網(wǎng)絡(luò)空間等）和運行在其中的應(yīng)用程序。 倉庫倉庫是集中存放鏡像文件的場所。有時候會把倉庫和倉庫注冊服務(wù)器（Registry）混為一談，并不嚴格區(qū)分。實際上，倉庫注冊服務(wù)器上往往存放著多個倉庫，每個倉庫中又包含了多個鏡像，每個鏡像有不同的標簽（tag）。3.3.3 Docker的優(yōu)勢1、容器的快速輕量容器的啟動，停止和銷毀都是以秒或毫秒為單位的，并且相比傳統(tǒng)的虛擬化技術(shù)，使用容器在CPU、內(nèi)存，網(wǎng)絡(luò)IO等資源上的性能損耗都有同樣水平甚至更優(yōu)的表現(xiàn)。2、一次構(gòu)建，到處運行當將容器固化成鏡像后，就可以非?？焖俚?/p>

27、加載到任何環(huán)境中部署運行。而構(gòu)建出來的鏡像打包了應(yīng)用運行所需的程序、依賴和運行環(huán)境，這是一個完整可用的應(yīng)用集裝箱，在任何環(huán)境下都能保證環(huán)境一致性。3、完整的生態(tài)鏈容器技術(shù)并不是Docker首創(chuàng)，但是以往的容器實現(xiàn)只關(guān)注于如何運行，而Docker站在巨人的肩膀上進行整合和創(chuàng)新，特別是Docker鏡像的設(shè)計，完美地解決了容器從構(gòu)建、交付到運行，提供了完整的生態(tài)鏈支持。3.4 Kubernetes概述3.4.1 Kubernetes介紹Kubernetes是Google開源的容器集群管理系統(tǒng)。它構(gòu)建Docker技術(shù)之上，為容器化的應(yīng)用提供資源調(diào)度、部署運行、服務(wù)發(fā)現(xiàn)、擴容縮容等整一套功能，本質(zhì)上可看

28、作是基于容器技術(shù)的Micro-PaaS平臺，即第三代PaaS的代表性項目。3.4.2 Kubernetes的基本概念 PodPod是若干個相關(guān)容器的組合，是一個邏輯概念，Pod包含的容器運行在同一個宿主機上，這些容器使用相同的網(wǎng)絡(luò)命名空間、IP地址和端口，相互之間能通過localhost來發(fā)現(xiàn)和通信，共享一塊存儲卷空間。在Kubernetes中創(chuàng)建、調(diào)度和管理的最小單位是Pod。一個Pod一般只放一個業(yè)務(wù)容器和一個用于統(tǒng)一網(wǎng)絡(luò)管理的網(wǎng)絡(luò)容器。 Replication ControllerReplication Controller是用來控制管理Pod副本(Replica，或者稱實例)，Repl

29、ication Controller確保任何時候Kubernetes集群中有指定數(shù)量的Pod副本在運行，如果少于指定數(shù)量的Pod副本，Replication Controller會啟動新的Pod副本，反之會殺死多余的以保證數(shù)量不變。另外Replication Controller是彈性伸縮、滾動升級的實現(xiàn)核心。 ServiceService是真實應(yīng)用服務(wù)的抽象，定義了Pod的邏輯集合和訪問這個Pod集合的策略，Service將代理Pod對外表現(xiàn)為一個單一訪問接口，外部不需要了解后端Pod如何運行，這給擴展或維護帶來很大的好處，提供了一套簡化的服務(wù)代理和發(fā)現(xiàn)機制。 LabelLabel是用于區(qū)分

30、Pod、Service、Replication Controller的Key/Value鍵值對，實際上Kubernetes中的任意API對象都可以通過Label進行標識。每個API對象可以有多個Label，但是每個Label的Key只能對應(yīng)一個Value。Label是Service和Replication Controller運行的基礎(chǔ)，它們都通過Label來關(guān)聯(lián)Pod，相比于強綁定模型，這是一種非常好的松耦合關(guān)系。 NodeKubernets屬于主從的分布式集群架構(gòu)，Kubernets Node（簡稱為Node，早期版本叫做Minion）運行并管理容器。Node作為Kubernetes的操作

31、單元，將用來分配給Pod（或者說容器）進行綁定，Pod最終運行在Node上，Node可以認為是Pod的宿主機。3.4.3 Kubernetes架構(gòu)4、Docker監(jiān)控與K8S監(jiān)控實踐4.1 容器的監(jiān)控方案4.1.1 單臺主機容器監(jiān)控（1）docker stats1、 單臺主機上容器的監(jiān)控實現(xiàn)最簡單的方法就是使用命令Docker stats，就可以顯示所有容器的資源使用情況.2、 這樣就可以查看每個容器的CPU利用率、內(nèi)存的使用量以及可用內(nèi)存總量。請注意，如果你沒有限制容器內(nèi)存，那么該命令將顯示您的主機的內(nèi)存總量。但它并不意味著你的每個容器都能訪問那么多的內(nèi)存。另外，還可以看到容器通過網(wǎng)絡(luò)發(fā)送和

32、接收的數(shù)據(jù)總量3、 雖然可以很直觀地看到每個容器的資源使用情況，但是顯示的只是一個當前值，并不能看到變化趨勢。（2）Google的 cAdvisor 是另一個知名的開源容器監(jiān)控工具:只需在宿主機上部署cAdvisor容器，用戶就可通過Web界面或REST服務(wù)訪問當前節(jié)點和容器的性能數(shù)據(jù)(CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤、文件系統(tǒng)等等)，非常詳細。它的運行方式也有多種：a.直接下載命令運行1、 下載地址：/google/cadvisor/releases/latest2、 格式: nohup /root/cadvisor -port=10000 &/var/log/kubernetes/cadvisor

33、.log &3、 訪問：http:/ip:10000/b.以容器方式運行docker pull /googlelib/cadvisorc.kubelet選項：1） 在啟動kubelete時候，啟動cadvisor2） cAdvisor當前都是只支持http接口方式，被監(jiān)控的容器應(yīng)用必須提供http接口，所以能力較弱。在Kubernetes的新版本中已經(jīng)集成了cAdvisor，所以在 Kubernetes架構(gòu)下，不需要單獨再去安裝cAdvisor，可以直接使用節(jié)點的IP加默認端口4194就可以直接訪問cAdvisor的監(jiān)控面板。UI界面如下：1、因為cAdvisor默認是將數(shù)據(jù)緩存在內(nèi)存中，在顯

34、示界面上只能顯示1分鐘左右的趨勢，所以歷史的數(shù)據(jù)還是不能看到，但它也提供不同的持久化存儲后端，比如influxdb等，同時也可以根據(jù)業(yè)務(wù)的需求，只利用cAdvisor提供的api接口，定時去獲取數(shù)據(jù)存儲到數(shù)據(jù)庫中，然后定制自己的界面。2、如需要通過cAdvisor查看某臺主機上某個容器的性能數(shù)據(jù)只需要調(diào)用：http:/:4194/v1.3/subcontainers/docker/3、cAdvisor的api接口返回的數(shù)據(jù)結(jié)構(gòu)可以分別計算出 CPU、內(nèi)存、網(wǎng)絡(luò)等資源的使用或者占用情況。4.2 K8S監(jiān)控1.容器的監(jiān)控在Kubernetes監(jiān)控生態(tài)中，一般是如下的搭配使用：（1）Cadvisor

35、+InfluxDB+Grafana：Cadvisor：將數(shù)據(jù)寫入InfluxDB ；InfluxDB ：時序數(shù)據(jù)庫，提供數(shù)據(jù)的存儲，存儲在指定的目錄下 。cAdivsor雖然能采集到監(jiān)控數(shù)據(jù)，也有很好的界面展示，但是并不能顯示跨主機的監(jiān)控數(shù)據(jù)，當主機多的情況，需要有一種集中式的管理方法將數(shù)據(jù)進行匯總展示，最經(jīng)典的方案就是 cAdvisor+ Influxdb+grafana，可以在每臺主機上運行一個cAdvisor容器負責數(shù)據(jù)采集，再將采集后的數(shù)據(jù)都存到時序型數(shù)據(jù)庫influxdb中，再通過圖形展示工具grafana定制展示面板。在上面的安裝步驟中，先是啟動influxdb容器，然后進行到容器

36、內(nèi)部配置一個數(shù)據(jù)庫給cadvisor專用，然后再啟動cadvisor容器，容器啟動的時候指定把數(shù)據(jù)存儲到influxdb中，最后啟動grafana容器，在展示頁面里配置grafana的數(shù)據(jù)源為influxdb，再定制要展示的數(shù)據(jù)，一個簡單的跨多主機的監(jiān)控 系統(tǒng)就構(gòu)建成功了。（2）KubernetesHeapster+InfluxDB+Grafana：Heapster：在k8s集群中獲取metrics和事件數(shù)據(jù)，寫入InfluxDB，heapster收集的數(shù)據(jù)比cadvisor多，卻全，而且存儲在influxdb的也少。InfluxDB：時序數(shù)據(jù)庫，提供數(shù)據(jù)的存儲，存儲在指定的目錄下。Grafa

37、na：提供了WEB控制臺，自定義查詢指標，從InfluxDB查詢數(shù)據(jù)，并展示。Heapster是一個收集者，將每個Node上的cAdvisor的數(shù)據(jù)進行匯總，然后導(dǎo)到InfluxDB。Heapster的前提是使用cAdvisor采集每個node上主機和容器資源的使用情況，再將所有node上的數(shù)據(jù)進行聚合，這樣不僅可以看到Kubernetes集群的資源情況，還可以分別查看每個node/namespace及每個node/namespace下pod的資源情況。這樣就可以從cluster，node，pod的各個層面提供詳細的資源使用情況。2、kubernetes中主機監(jiān)控方案：（1） 部署node-e

38、xporter容器node-exporter 要在集群的每臺主機上部署，使用主機網(wǎng)絡(luò)，端口是9100 如果有多個K8S集群，則要在多個集群上部署，部署node-exporter的命令如下：kubectl create -f node-exporter-deamonset.yaml獲取metrics數(shù)據(jù) http:/ip:9100/metrics ， 返回的數(shù)據(jù)結(jié)構(gòu)不是json格式，如果要使用該接口返回的數(shù)據(jù)，可以通過正則匹配，匹配出需要的數(shù)據(jù)，然后在保存到數(shù)據(jù)庫中。（2） 部署Prometheus和GrafanaPrometheus 通過配置文件發(fā)現(xiàn)新的節(jié)點，文件路徑是/sd/*.json,可

39、以通過修改已有的配置文件，添加新的節(jié)點納入監(jiān)控，命令如下：kubectl create -f prometheus-file-sd.yaml（3）查看Prometheus監(jiān)控的節(jié)點Prometheus 的訪問地址是：http:/ xxx.xxx .xxx.xxx:31330通過網(wǎng)頁查看監(jiān)控的節(jié)點Status Targets 使用metric-server收集數(shù)據(jù)給k8s集群內(nèi)使用，如kubectl,hpa,scheduler等 使用prometheus-operator部署prometheus，存儲監(jiān)控數(shù)據(jù) 使用kube-state-metrics收集k8s集群內(nèi)資源對象數(shù)據(jù) 使用node_e

40、xporter收集集群中各節(jié)點的數(shù)據(jù) 使用prometheus收集apiserver，scheduler，controller-manager，kubelet組件數(shù)據(jù) 使用alertmanager實現(xiàn)監(jiān)控報警 使用grafana實現(xiàn)數(shù)據(jù)可視化prometheus-operator是一個整合prometheus和operator的項目，prometheus是一個集數(shù)據(jù)收集存儲，數(shù)據(jù)查詢，數(shù)據(jù)圖表顯示于一身的開源監(jiān)控組件。operator是由coreos開源一套在k8s上管理應(yīng)用的軟件，通過operator可以方便的實現(xiàn)部署，擴容，刪除應(yīng)用等功能。prometheus-operator利用k8s的

41、CustomResourceDefinitions功能實現(xiàn)了只需要像寫原生kubectl支持的yaml文件一樣，輕松收集應(yīng)用數(shù)據(jù)，配置報警規(guī)則等，包含如下CRDs ： Prometheus用于部署Prometheus 實例 ServiceMonitor 用于配置數(shù)據(jù)收集，創(chuàng)建之后會根據(jù)DNS自動發(fā)現(xiàn)并收集數(shù)據(jù) PrometheusRule 用于配置Prometheus 規(guī)則，處理規(guī)整數(shù)據(jù)和配置報警規(guī)則5、監(jiān)控容器上微服務(wù)微服務(wù)由于服務(wù)眾多 ， 微服務(wù)關(guān)系交錯復(fù)雜，微服務(wù)部署種類多樣 ，所以業(yè)務(wù)的監(jiān)控是必不可少的，主要做了幾個方面的監(jiān)控 ： metrics監(jiān)控 trace監(jiān)控 健康性監(jiān)控 日志監(jiān)

42、控實現(xiàn)方式 通過springboot配合micrometer進行使用，底層存儲使用prometheus來進行存儲 prometheus從eureka上面獲取服務(wù)節(jié)點信息，并且每天晚上更新一次監(jiān)控指標 服務(wù)qps 服務(wù)分位數(shù) 服務(wù)錯誤返回數(shù) 服務(wù)接口請求次數(shù)的top 服務(wù)接口95%請求時間top cpu使用率 cpu個數(shù)和負載 jvm堆內(nèi)存/非堆內(nèi)存 jvm線程 jvm的類數(shù) gc的暫停時間和次數(shù) tomcat的活躍線程 數(shù)據(jù)庫連接數(shù) 日志行數(shù) 業(yè)務(wù)通過api自己上報的業(yè)務(wù)數(shù)據(jù)服務(wù)鏈路監(jiān)控 微服務(wù)架構(gòu)是一個分布式架構(gòu)，它按業(yè)務(wù)劃分服務(wù)單元，一個分布式系統(tǒng)往往有很多個服務(wù)單元。由于服務(wù)單元數(shù)量眾多

43、，業(yè)務(wù)的復(fù)雜性，如果出現(xiàn)了錯誤和異常，很難去定位。主要體現(xiàn)在，一個請求可能需要調(diào)用很多個服務(wù)，而內(nèi)部服務(wù)的調(diào)用復(fù)雜性，決定了問題難以定位。所以微服務(wù)架構(gòu)中，必須實現(xiàn)分布式鏈路追蹤，去跟進一個請求到底有哪些服務(wù)參與，參與的順序又是怎樣的，從而達到每個請求的步驟清晰可見，出了問題，很快定位。 鏈路追蹤組件有Google的Dapper，Twitter 的Zipkin，以及阿里的Eagleeye （鷹眼）等，它們都是非常優(yōu)秀的鏈路追蹤開源組件，國內(nèi)商用的產(chǎn)品有聽云、博瑞。 分布式跟蹤系統(tǒng)可以幫助收集時間數(shù)據(jù)，解決在microservice架構(gòu)下的延遲問題；它管理這些數(shù)據(jù)的收集和查找；Zipkin的設(shè)計

44、是基于谷歌的Google Dapper論文。每個應(yīng)用程序向Zipkin報告定時數(shù)據(jù)，Zipkin UI呈現(xiàn)了一個依賴圖表來展示多少跟蹤請求經(jīng)過了每個應(yīng)用程序；如果想解決延遲問題，可以過濾或者排序所有的跟蹤請求，并且可以查看每個跟蹤請求占總跟蹤時間的百分比。健康性檢查 通過從 Spring Cloud Eureka 獲取服務(wù)節(jié)點，并且從服務(wù)請求數(shù)據(jù)和狀態(tài) 如果服務(wù)狀態(tài)不健康，進行報警通知 通過接口查看錯誤碼，錯誤碼達到一定比率，進行報警通知日志監(jiān)控 通過 ELK 來監(jiān)控error日志或者通過其他監(jiān)控產(chǎn)品自帶的日志產(chǎn)品進行關(guān)鍵字監(jiān)控，感興趣的同學(xué)可以自行研究ELK 。6、云管監(jiān)控平臺與集中監(jiān)控平臺

45、集成目前一般企業(yè)都有集中事件管理平臺 ， 但是如何將新建的云管平臺監(jiān)控系統(tǒng)與現(xiàn)有事件管理平臺集成呢 ？可以使用 Alertmanager 模塊的Webhook Receiver ，將其設(shè)置為 snmpnotifier ， SNMP Notifier接收來自AlertManager的告警然后將告警轉(zhuǎn)發(fā)給SNMP Traps poller。Prometheus Alertmanager 在其HTTP API 上向 SNMP 通知程序發(fā)送警報。然后，SNMP notifier 在給定警報的標簽中查找OID。每個陷阱都帶有一個唯一的 ID 發(fā)送，如果警報更新或一旦解決，則允許發(fā)送具有更新狀態(tài)和數(shù)據(jù)的其他Trap。Alertmanager 配置 如下 ：receivers:name: snmp_notifierwebhook_configs:send_resolved: trueurl:http:/snmp.notifier.service:9464/alerts同時snmp_notifier配置如下：usage: snmp_notifier A tool to relay P