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

2、 PAGEREF _Toc65363148 h 8 HYPERLINK l _Toc65363149 3、PaaS與PaaS管理平臺(tái)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)控實(shí)踐 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 實(shí)現(xiàn)方式 PAGEREF _Toc65363159 h 24 HYPERLINK l _Toc65363160 監(jiān)控指標(biāo) 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)控平臺(tái)與集中監(jiān)控平臺(tái)集成 PAGEREF _Toc65363164 h 27 HYPERLINK l _Toc65363165 7、展望未來(lái) PAGEREF _Toc65363165 h 28【摘要】隨著云計(jì)算技術(shù)的發(fā)展，越來(lái)越多的云平臺(tái)和服務(wù)類(lèi)型出現(xiàn)， 如VM 、 KVM 、 PaaS等，各大企業(yè)

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

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

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

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

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

11、寫(xiě)IO(次/20s)每20s磁盤(pán)寫(xiě)的次數(shù)磁盤(pán)讀速率(KBps)每秒磁盤(pán)讀的K字節(jié)數(shù)磁盤(pán)寫(xiě)速率(KBps)每秒磁盤(pán)寫(xiě)的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ù)硬盤(pán)性能讀取滯后時(shí)間（毫秒）單個(gè)硬盤(pán)讀取滯后的時(shí)間寫(xiě)入滯后時(shí)間（毫秒）單個(gè)硬盤(pán)寫(xiě)入滯后的時(shí)間CPU核心已使用（毫秒）單個(gè)CPU核心的已使用時(shí)間閑置（毫秒）單個(gè)CPU核心的閑置時(shí)間虛擬機(jī)CPU使用率（%）虛擬機(jī)的CPU處理任務(wù)的繁忙程度CPU使用量（MHz）虛擬機(jī)的CPU處理任務(wù)時(shí)占用的兆赫茲數(shù)量?jī)?nèi)存利用率（%）虛擬機(jī)內(nèi)存使用數(shù)和虛擬機(jī)內(nèi)存總量的比值活動(dòng)內(nèi)存（MB）虛擬機(jī)正在使用

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

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

14、，是一種可以建立工具來(lái)管理客戶操作系統(tǒng)的 API。Libvirt 本身構(gòu)建于一種抽象的概念之上。它為受支持的虛擬機(jī)監(jiān)控程序?qū)崿F(xiàn)的常用功能提供通用的API，適用于包括基于KVM/QEMU, Xen, LXC, OpenVZ, Virtualbox, VMware, PowerVM等多種虛擬機(jī)化技術(shù)的虛擬機(jī)。Libvirt-python是基于libvirt API的python語(yǔ)言綁定工具包，通過(guò)該包，可以使用python對(duì)VM進(jìn)行日常管理操作和監(jiān)控?cái)?shù)據(jù)獲取。需要運(yùn)行的Python監(jiān)控程序可以在KVM的HOST中運(yùn)行，也可以在基于KVM虛擬機(jī)化的任意環(huán)境運(yù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)方法返回指定類(lèi)型的domains列表，type參數(shù)可以設(shè)置以下類(lèi)型2.2.3 獲取監(jiān)控?cái)?shù)據(jù)VM的監(jiān)控信息主要是CPU使用率，內(nèi)存使用率，Disk使用率，Disk I/O，Network I/O。其中，CPU的使用率，Disk I/O，Network I/O并不能直接獲取，需要經(jīng)過(guò)計(jì)算獲得。另外 ， op

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

34、示界面上只能顯示1分鐘左右的趨勢(shì)，所以歷史的數(shù)據(jù)還是不能看到，但它也提供不同的持久化存儲(chǔ)后端，比如influxdb等，同時(shí)也可以根據(jù)業(yè)務(wù)的需求，只利用cAdvisor提供的api接口，定時(shí)去獲取數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)中，然后定制自己的界面。2、如需要通過(guò)cAdvisor查看某臺(tái)主機(jī)上某個(gè)容器的性能數(shù)據(jù)只需要調(diào)用：http:/:4194/v1.3/subcontainers/docker/3、cAdvisor的api接口返回的數(shù)據(jù)結(jié)構(gòu)可以分別計(jì)算出 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ù)寫(xiě)入InfluxDB ；InfluxDB ：時(shí)序數(shù)據(jù)庫(kù)，提供數(shù)據(jù)的存儲(chǔ)，存儲(chǔ)在指定的目錄下 。cAdivsor雖然能采集到監(jiān)控?cái)?shù)據(jù)，也有很好的界面展示，但是并不能顯示跨主機(jī)的監(jiān)控?cái)?shù)據(jù)，當(dāng)主機(jī)多的情況，需要有一種集中式的管理方法將數(shù)據(jù)進(jìn)行匯總展示，最經(jīng)典的方案就是 cAdvisor+ Influxdb+grafana，可以在每臺(tái)主機(jī)上運(yùn)行一個(gè)cAdvisor容器負(fù)責(zé)數(shù)據(jù)采集，再將采集后的數(shù)據(jù)都存到時(shí)序型數(shù)據(jù)庫(kù)influxdb中，再通過(guò)圖形展示工具grafana定制展示面板。在上面的安裝步驟中，先是啟動(dòng)influxdb容器，然后進(jìn)行到容器

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

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

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

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

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

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

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

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

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

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