基于Kubernetes的微服務(wù)監(jiān)控體系是怎么樣的

今天就跟大家聊聊有關(guān)基于Kubernetes的微服務(wù)監(jiān)控體系是怎么樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

監(jiān)控系統(tǒng)是運維體系乃至整個軟件產(chǎn)品生命周期中最重要的一環(huán)，完善的監(jiān)控可以幫助我們事前及時發(fā)現(xiàn)故障，事后快速追查定位問題。而在以微服務(wù)為代表的云原生架構(gòu)體系中，系統(tǒng)分為多個層次，服務(wù)之間調(diào)用鏈路復(fù)雜，系統(tǒng)中需要監(jiān)控的目標非常多，如果沒有一個完善的監(jiān)控系統(tǒng)就難以保證整體服務(wù)的持續(xù)穩(wěn)定。

監(jiān)控對象及分層

在實際場景中監(jiān)控系統(tǒng)按照監(jiān)控的對象及系統(tǒng)層次結(jié)構(gòu)，從底向上可以依次劃分為基礎(chǔ)層、中間層、應(yīng)用層、業(yè)務(wù)層等多個層面的監(jiān)控。具體可如圖所示：

基礎(chǔ)層監(jiān)控就是對主機服務(wù)器(包括宿主機、容器)及其底層資源進行監(jiān)控，以保證應(yīng)用程序運行所依賴的基礎(chǔ)環(huán)境的穩(wěn)定運行。基礎(chǔ)層監(jiān)控主要有兩個方向：

• 資源利用：是對像I/O利用率、CPU利用率、內(nèi)存使用率、磁盤使用率、網(wǎng)絡(luò)負載等這樣的硬件資源進行監(jiān)控。避免因應(yīng)用程序本身或其它特殊情況引起的硬件資源耗盡而出現(xiàn)的服務(wù)故障。

• 網(wǎng)絡(luò)通信：是對服務(wù)器之間的網(wǎng)絡(luò)狀態(tài)進行監(jiān)控。網(wǎng)絡(luò)通信是互聯(lián)網(wǎng)的重要基石，如果主機之間的網(wǎng)絡(luò)出現(xiàn)如延遲過大、丟包率高這樣的網(wǎng)絡(luò)問題，將會嚴重影響業(yè)務(wù)。

需要說明的是，在基于Kubernetes容器化技術(shù)的新型云原生基礎(chǔ)設(shè)施中，基礎(chǔ)層的監(jiān)控不僅要對宿主機本身進行監(jiān)控，也要對Kubernetes集群狀態(tài)及其容器資源使用情況進行監(jiān)控。這在后面我們構(gòu)建基于Kubernetes的基礎(chǔ)層監(jiān)控體系時將會具體介紹。

中間層監(jiān)控主要是指對諸如Nginx、Redis、MySQL、RocketMQ、Kafka等應(yīng)用服務(wù)所依賴的中間件軟件的監(jiān)控，它們的穩(wěn)定也是保證應(yīng)用程序持續(xù)可用的關(guān)鍵。一般來說特定的中間件軟件都會根據(jù)自身特點構(gòu)建針對性的監(jiān)控體系。

應(yīng)用層監(jiān)控這里就是指對業(yè)務(wù)性服務(wù)程序的監(jiān)控，一般來說我們對應(yīng)用程序監(jiān)控的關(guān)注點主要體現(xiàn)在以下幾個方面：

• HTTP接口請求訪問。包括接口響應(yīng)時間、吞吐量等;

• JVM監(jiān)控指標。對于Java服務(wù)，還會重點關(guān)注GC時間、線程數(shù)、FGC/YGC耗時等JVM性能相關(guān)的指標;

• 資源消耗。應(yīng)用程序部署后會消耗一定的資源，例如應(yīng)用程序?qū)?nèi)存、CPU的消耗情況;

• 服務(wù)的健康狀態(tài)。例如當前服務(wù)是否存活，運行是否穩(wěn)定等;

調(diào)用鏈路。在微服務(wù)架構(gòu)中，由于調(diào)用鏈路變長，還需要重點監(jiān)控服務(wù)之間的調(diào)用關(guān)系和調(diào)用情況，避免局部上下游服務(wù)之間的鏈路故障引發(fā)系統(tǒng)全局性雪崩;

業(yè)務(wù)層監(jiān)控也是監(jiān)控系統(tǒng)所關(guān)注的一個重要內(nèi)容，在實際場景中如果你只是讓應(yīng)用程序穩(wěn)定運行那肯定是遠遠不夠的。因此，我們常常會對具體業(yè)務(wù)產(chǎn)生的數(shù)據(jù)進行監(jiān)控，例如網(wǎng)站系統(tǒng)所關(guān)注的PV、UV等參數(shù);后端如交易之類的系統(tǒng)我們則會關(guān)注訂單量、成功率等。

業(yè)務(wù)指標也是體現(xiàn)系統(tǒng)穩(wěn)定性的核心要素。任何系統(tǒng)，如果出現(xiàn)了問題，最先受到影響的肯定是業(yè)務(wù)指標。對于核心業(yè)務(wù)指標的設(shè)定因具體的業(yè)務(wù)和場景而異，所以對于業(yè)務(wù)層的監(jiān)控需要構(gòu)建具備業(yè)務(wù)特點的業(yè)務(wù)監(jiān)控系統(tǒng)。

常見的監(jiān)控指標類型

在指標類監(jiān)控系統(tǒng)中，通過統(tǒng)計指標可以感性地認識到整個系統(tǒng)的運行情況。出現(xiàn)問題后，各個指標會首先出現(xiàn)波動，這些波動會反映出系統(tǒng)是那些方面出了問題，從而可以據(jù)此排查出現(xiàn)問題的原因。下面我們分別來看下統(tǒng)計指標到底有哪些類型，以及常見的統(tǒng)計指標都有哪些，它是我們進一步理解指標類監(jiān)控系統(tǒng)的基礎(chǔ)。

從整體上看，常見的Metrics指標類型主要有：計數(shù)器(Counter)、測量儀(Gauge)、直方圖(Histogram)、摘要(Summary)這四類。它們的特點分別如下：

1. 計數(shù)器(Counter)

計數(shù)器是一種具有累加特性的指標類型，一般這個值為Double或者Long類型。例如常見的統(tǒng)計指標QPS、TPS等的值就是通過計數(shù)器的形式，然后配合一些統(tǒng)計函數(shù)計算得出的。

2. 測量儀(Gauge)

表示某個時間點，對某個數(shù)值的測量。測量儀和計數(shù)器都可以用來查詢某個時間點的固定內(nèi)容的數(shù)值，但和計數(shù)器不同，測量儀的值可以隨意變化，可以增加也可以減少。比如獲取Java線程池中活躍的線程數(shù)，使用的是ThreadPoolExecutor中的getActiveCount方法;此外，還有比較常見的CPU使用率、內(nèi)存占用量等具體指標都是通過測量儀獲取的。

3. 直方圖(Histogram)

直方圖是一種將多個數(shù)值聚合在一起的數(shù)據(jù)結(jié)構(gòu)，可以表示數(shù)據(jù)的分布情況。比如以常見的響應(yīng)耗時舉例，可以把響應(yīng)耗時數(shù)據(jù)分為多個桶(Bucket),每個桶代表一個耗時區(qū)間，例如0～100毫秒、100～500毫秒，以此類推。通過這樣的形式，可以直觀地看到一個時間段內(nèi)的請求耗時分布，這將有助于我們理解耗時情況分布。

4. 摘要(Summary)

摘要與直方圖類似，表示的也是一段時間內(nèi)的數(shù)據(jù)結(jié)果，但是摘要反應(yīng)的數(shù)據(jù)內(nèi)容不太一樣。摘要一般用于標識分位值，分位值其實就是我們常說的TP90、TP99等。例如有100個耗時數(shù)值，將所有的數(shù)值從低到高排列，取第90%的位置，這個位置的值就是TP90的值，如果這個桶對應(yīng)的值假設(shè)是80ms，那么就代表小于等于90%位置的請求都≤80ms。

Kubernetes微服務(wù)監(jiān)控體系

前面我們從整體上描述了監(jiān)控系統(tǒng)分層以及理解指標類監(jiān)控系統(tǒng)所需要掌握的幾類常見的指標類型。接下來我們重點探討基于Kubernetes的微服務(wù)監(jiān)控體系。

從監(jiān)控對象及系統(tǒng)分層的角度看，監(jiān)控系統(tǒng)需要監(jiān)控的范圍是非常廣泛的，但從微服務(wù)監(jiān)控的角度來說，如果你的微服務(wù)部署完全是基于Kubernetes云原生環(huán)境的，那么我們需要關(guān)注的監(jiān)控對象主要就是Kubernetes集群本身以及運行其中的微服務(wù)應(yīng)用容器。例如對容器資源使用情況，如CPU使用率、內(nèi)存使用率、網(wǎng)絡(luò)、I/O等指標的監(jiān)控。

當然，這并不是說像基礎(chǔ)層的物理機、虛擬機設(shè)備或者中間層軟件的監(jiān)控我們不需要關(guān)注，只是這部分工作一般會有專門的人員去維護。而如果使用的是云服務(wù)，那么云服務(wù)廠商大都已經(jīng)為我們提供了監(jiān)控支持。此外，對于基礎(chǔ)物理層及大部分中間軟件的監(jiān)控并不是本文所要表達的重點，所以也就不再做過多的實踐，大家對此有個全局的認識即可。

而回到以Kubernetes為載體的微服務(wù)監(jiān)控體系，雖然曾經(jīng)Kubernetes項目的監(jiān)控體系非常復(fù)雜，社區(qū)中也有很多方案。但是這套體系發(fā)展到今天，已經(jīng)完全演變成了以Prometheus項目為核心的一套統(tǒng)一方案。在本節(jié)的內(nèi)容中我們就將演示如何圍繞Prometheus來構(gòu)建針對Kubernetes的微服務(wù)監(jiān)控系統(tǒng)。

1. Prometheus簡介

經(jīng)過行業(yè)多年的實踐和沉淀，目前監(jiān)控系統(tǒng)按實現(xiàn)方式主要可以分為四類：1)、基于時間序列的Metrics(度量指標)監(jiān)控;2)、基于調(diào)用鏈的Tracing(鏈路)監(jiān)控;3)、基于Logging(日志)的監(jiān)控;4)、健康性檢查(Healthcheck)。而在上述幾種監(jiān)控方式中Metrics監(jiān)控是其中最主要的一種監(jiān)控方式。

簡單理解Metrics的表現(xiàn)形式，就是在離散的時間點上產(chǎn)生的數(shù)值點[Time,Value],由某個指標組成的一組[Time,Value]數(shù)值點序列也被稱為時間序列，所以Metrics監(jiān)控也常常被稱為時間序列監(jiān)控。

如上所述，我們簡單闡述了指標系統(tǒng)的基本特點，而接下來要介紹的Prometheus就是一款基于時間序列的開源Metrics類型的監(jiān)控系統(tǒng)，它可以很方便地進行統(tǒng)計指標的存儲、查詢和告警。從整體上看Prometheus的系統(tǒng)結(jié)構(gòu)，如下圖所示：

從上圖中可以看出，Prometheus工作的核心，主要是使用Pull(拉取)的模式去收集被監(jiān)控對象的Metrics數(shù)據(jù)(監(jiān)控指標數(shù)據(jù))，然后由Prometheus服務(wù)器將收到的指標數(shù)據(jù)進行聚合后存儲到TSDB(時間序列數(shù)據(jù)庫，例如OpenTSDB、InfluxDB)中，以便后續(xù)根據(jù)時間自由檢索。

有了這套核心機制，Prometheus剩下的組件就主要是用來配合這套機制運行的了。比如PushGateway，它可以允許被監(jiān)控對象以Push的方式向Prometheus推送Metrics數(shù)據(jù)。而Alertmanager，則可以根據(jù)Metrics信息靈活地設(shè)置報警。

此外，Prometheus還提供了一套完整的PromQL查詢語言，通過其提供的HTTP查詢接口，使用者可以很方便地將指標數(shù)據(jù)與Grafana(可視化監(jiān)控指標展示工具)結(jié)合起來，從而靈活地定制屬于系統(tǒng)自身的關(guān)鍵指標監(jiān)控Dashboard(看板)。

2. Prometheus Operator安裝部署

前面我們簡單介紹了Prometheus監(jiān)控系統(tǒng)的基本原理，接下來的內(nèi)容將以實操的方式演示如何使用Prometheus構(gòu)建一套針對Kubernetes集群的微服務(wù)監(jiān)控體系。

在實際的應(yīng)用場景中，針對不同的監(jiān)控對象Prometheus的部署方式也會有所不同。例如要監(jiān)控的對象是底層的物理機，或者以物理機方式部署的數(shù)據(jù)庫等中間件系統(tǒng)，那么這種情況下一般也會將Prometheus監(jiān)控系統(tǒng)的部署環(huán)境放置在物理機下。

而如果針對的是Kubernetes集群的監(jiān)控，那么現(xiàn)在主流的方式是采用Promethues-Operator將Promethues部署到Kubernetes集群之中，這樣能以更原生的方式實施對Kubernetes集群及容器的監(jiān)控。這里所說的Promethues-Operator  是指專門針對Kubernetes的Promethues封裝包，它可以簡化Promethues的部署和配置。

接下來我們具體演示如何通過Promethues-Operator在Kubernetes中快速安裝部署Promethues(Kubernetes實驗環(huán)境可參考本專欄相關(guān)內(nèi)容)，具體步驟如下：

1)、安裝Helm

在本次安裝過程中，將使用到Kubernetes的包管理工具Helm。Helm是Kubernetes的一種包管理工具，與Java中的Maven、NodeJs中的Npm以及Ubuntu的apt和CentOS的yum類似。主要用來簡化Kubernetes對應(yīng)用的部署和管理。

首先從Github下載相應(yīng)的Helm安裝包，具體命令參考如下：

#找到Github中Helm相關(guān)的發(fā)布包，參考鏈接如下 https://github.com/helm/helm/releases  #確定好相關(guān)版本后，將具體安裝版本下載至某個安裝了kubectl的節(jié)點  wget https://get.helm.sh/helm-v3.4.0-rc.1-linux-amd64.tar.gz

解壓，并將下載的可執(zhí)行Helm文件拷貝到文件夾/usr/local/bin下，命令如下：

tar -zxvf helm-v3.4.0-rc.1-linux-amd64.tar.gz  #將下載的可執(zhí)行helm文件拷貝到文件夾/usr/local/bin下 mv linux-amd64/helm /usr/local/bin/

之后執(zhí)行helm version，如果能看到Helm版本信息，就說明Helm客戶端安裝成功了，具體如下:

$helm version version.BuildInfo{Version:"v3.4.0-rc.1",  GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004",  GitTreeState:"clean", GoVersion:"go1.14.10"}

安裝完Helm客戶端后，由于一些公共Kubernetes包是在遠程倉庫中管理的，所以還需要添加helm  charts(Helm中的Kubernetes安裝包又叫charts)官方倉庫，命令如下：

$helm repo add stable https://charts.helm.sh/stable

查看本地helm倉庫是否添加成功，命令如下：

$helm repo list NAME      URL                           stable    https://charts.helm.sh/stable

此時，查看Helm倉庫就能看到各種組件的charts列表了，命令效果如下：

$helm search repo stable  NAME                              CHART VERSION   APP VERSION     DESCRIPTION                                        stable/acs-engine-autoscaler      2.1.3           2.1.1           Scales worker nodes within agent pools             stable/aerospike  ...

如上所示，此時通過“helm search”命令就可以查看到各種stable版本的Kubernetes安裝包了!

2)、Helm搜索Prometheus-Operator安裝包

在具體安裝Prometheus-Operator之前，我們先用“helm”命令搜索Prometheus相關(guān)的charts包，命令如下：

$ helm search repo prometheus

具體搜索結(jié)果如下圖所示：

如上圖所示，我們可以看到Helm倉庫中可以搜索到版本為0.38.1的“stable/prometheus-operator”的安裝包。接下來就可以通過helm具體安裝了!

3)Helm安裝Prometheus-Operator監(jiān)控系統(tǒng)

接下來啊，通過Helm具體安裝prometheus-operator監(jiān)控系統(tǒng)，命令如下：

#創(chuàng)建k8s名稱空間 kubectl create ns monitoring  #通過helm安裝promethues-operator監(jiān)控系統(tǒng) helm install promethues-operator stable/prometheus-operator -n monitoring

執(zhí)行安裝命令后，輸出結(jié)果如下：

WARNING: This chart is deprecated manifest_sorter.go:192: info: skipping unknown hook: "crd-install" manifest_sorter.go:192: info: skipping unknown hook: "crd-install" manifest_sorter.go:192: info: skipping unknown hook: "crd-install" manifest_sorter.go:192: info: skipping unknown hook: "crd-install" manifest_sorter.go:192: info: skipping unknown hook: "crd-install" manifest_sorter.go:192: info: skipping unknown hook: "crd-install" NAME: promethues-operator LAST DEPLOYED: Mon Oct 26 10:15:45 2020 NAMESPACE: monitoring STATUS: deployed REVISION: 1 NOTES: ******************* *** DEPRECATED **** ******************* * stable/prometheus-operator chart is deprecated. * Further development has moved to https://github.com/prometheus-community/helm-charts * The chart has been renamed kube-prometheus-stack to more clearly reflect * that it installs the `kube-prometheus` project stack, within which Prometheus * Operator is only one component.  The Prometheus Operator has been installed. Check its status by running:   kubectl --namespace monitoring get pods -l "release=promethues-operator"  Visit https://github.com/coreos/prometheus-operator for instructions on how to create & configure Alertmanager and Prometheus instances using the Operator.

執(zhí)行完安裝命令后，查看具體的Kubernetes Pods信息，命令如下：

$ kubectl get po -n monitoring  NAME                                                     READY   STATUS    RESTARTS   AGE alertmanager-promethues-operator-promet-alertmanager-0   2/2     Running   0          5m42s prometheus-promethues-operator-promet-prometheus-0       3/3     Running   1          5m31s promethues-operator-grafana-5df74d9cb4-5d475             2/2     Running   0          6m53s promethues-operator-kube-state-metrics-89d8c459f-449k4   1/1     Running   0          6m53s promethues-operator-promet-operator-79f8b5f7ff-pfpbl     2/2     Running   0          6m53s promethues-operator-prometheus-node-exporter-6ll4z       1/1     Running   0          6m53s promethues-operator-prometheus-node-exporter-bvdb4       1/1     Running   0          6m53s

如上所示，可以看到Prometheus監(jiān)控系統(tǒng)相關(guān)的組件都以Pod的方式運行在了Kubernetes集群中。

Prometheus監(jiān)控效果演示

通過前面的實際操作，我們通過Helm的方式已經(jīng)將Prometheus  Operator安裝包部署在了Kubernetes集群之中。而此時的Prometheus實際上就已經(jīng)開始發(fā)揮作用，并采集了各類Kubernetes的運行指標信息?？梢酝ㄟ^Promethues內(nèi)置的監(jiān)控界面對此進行查看，具體步驟如下：

查看Kubernetes中查看內(nèi)置監(jiān)控界面所在的Pod節(jié)點，命令如下：

kubectl -n monitoring get svc

使用nodeport方式將promethues-operator內(nèi)置界面服務(wù)暴露在集群外，并指定使用30444端口，命令如下：

kubectl  patch svc promethues-operator-promet-prometheus -n monitoring -p '{"spec":{"type":"NodePort","ports":[{"port":9090,"targetPort":9090,"nodePort":30444}]}}' service/promethues-operator-promet-prometheus patched

此時在瀏覽器中輸入Pod節(jié)點所在的宿主機IP+端口地址，URL示例如下：

http://10.211.55.11:30444/graph

此時就可以看到Promethues內(nèi)置的監(jiān)控可視化界面了，效果如下圖所示：

而如果此時以PromeQL的方式查看一個具體指標，以“http_requests_total”為例，展示效果如圖所示：

由此說明，此時Promethues監(jiān)控系統(tǒng)已經(jīng)開始運行，并采集了相關(guān)Metrics指標數(shù)據(jù)！

Grafana可視化監(jiān)控系統(tǒng)

Grafana是一個強大的跨平臺的開源度量分析和可視化工具，可以將采集的指標數(shù)據(jù)進行定制化的圖形界面展示,經(jīng)常被用作為時間序列數(shù)據(jù)和應(yīng)用程序分析的可視化。Grafana支持多種數(shù)據(jù)源，如InfluxDB、OpenTSDB、ElasticSearch以及Prometheus。

前面我們在Kubernetes中安裝部署Prometheus-Operator時，實際上Grafana就已經(jīng)被集成并運行了，可以通過Kubernetes的相關(guān)命令查詢Grafana的實際運行Pod，并將其Web端口對外進行暴露，具體如下：

#查看服務(wù)節(jié)點信息kubectl -n monitoring get  svc#使用nodeport方式將promethues-operator-grafana暴露在集群外，指定使用30441端口kubectl patch svc  promethues-operator-grafana -n monitoring -p  '{"spec":{"type":"NodePort","ports":[{"port":80,"targetPort":3000,"nodePort":30441}]}}'

需要注意由于Grafana的應(yīng)用運行的默認端口為80，為避免實驗環(huán)境沖突，這里映射時將目標容器端口指定為3000，并最終將節(jié)點端口映射為30441。完成后，瀏覽器輸入URL：

#IP地址為映射命令執(zhí)行時所在的節(jié)點http://10.211.55.11:30441

如果映射正常，此時會返回Grafana可視化圖形界面的登錄界面，如圖所示：

這里缺省登錄賬號密碼為：admin/prom-operator。輸入后可進入Grafana主界面如下圖所示：

可以看到部署完成的Grafana已經(jīng)默認內(nèi)置了許多針對Kubernetes平臺的企業(yè)級監(jiān)控Dashboard，例如針對Kubernetes集群組件的“Kubernetes/API  server”、“Kubernetes/Kubelet”，以及針對Kubernetees計算資源的“Kubernetes/Compute  Resources/Pod”、“Kubernetes/Compute Resources/Workload”等等。

這里我們找一個針對Kubernetes物理節(jié)點的“Nodes”監(jiān)控Dashboard，點擊打開后看到的監(jiān)控效果如下圖所示：

 

上圖所示的Dashboard中展示了Kubernetes集群所在的各物理節(jié)點CPU、負載、內(nèi)存、磁盤I/O、磁盤空間、網(wǎng)絡(luò)傳輸?shù)扔布Y源的使用情況。從這些豐富的視圖可以看出Grafana強大的監(jiān)控指標可視化能力!

看完上述內(nèi)容，你們對基于Kubernetes的微服務(wù)監(jiān)控體系是怎么樣的有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。