基于Kubernetes的微服務監控體系是怎么樣的

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

監控系統是運維體系乃至整個軟件產品生命周期中最重要的一環，完善的監控可以幫助我們事前及時發現故障，事后快速追查定位問題。而在以微服務為代表的云原生架構體系中，系統分為多個層次，服務之間調用鏈路復雜，系統中需要監控的目標非常多，如果沒有一個完善的監控系統就難以保證整體服務的持續穩定。

監控對象及分層

在實際場景中監控系統按照監控的對象及系統層次結構，從底向上可以依次劃分為基礎層、中間層、應用層、業務層等多個層面的監控。具體可如圖所示：

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

• 資源利用：是對像I/O利用率、CPU利用率、內存使用率、磁盤使用率、網絡負載等這樣的硬件資源進行監控。避免因應用程序本身或其它特殊情況引起的硬件資源耗盡而出現的服務故障。

• 網絡通信：是對服務器之間的網絡狀態進行監控。網絡通信是互聯網的重要基石，如果主機之間的網絡出現如延遲過大、丟包率高這樣的網絡問題，將會嚴重影響業務。

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

中間層監控主要是指對諸如Nginx、Redis、MySQL、RocketMQ、Kafka等應用服務所依賴的中間件軟件的監控，它們的穩定也是保證應用程序持續可用的關鍵。一般來說特定的中間件軟件都會根據自身特點構建針對性的監控體系。

應用層監控這里就是指對業務性服務程序的監控，一般來說我們對應用程序監控的關注點主要體現在以下幾個方面：

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

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

• 資源消耗。應用程序部署后會消耗一定的資源，例如應用程序對內存、CPU的消耗情況;

• 服務的健康狀態。例如當前服務是否存活，運行是否穩定等;

調用鏈路。在微服務架構中，由于調用鏈路變長，還需要重點監控服務之間的調用關系和調用情況，避免局部上下游服務之間的鏈路故障引發系統全局性雪崩;

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

業務指標也是體現系統穩定性的核心要素。任何系統，如果出現了問題，最先受到影響的肯定是業務指標。對于核心業務指標的設定因具體的業務和場景而異，所以對于業務層的監控需要構建具備業務特點的業務監控系統。

常見的監控指標類型

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

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

1. 計數器(Counter)

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

2. 測量儀(Gauge)

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

3. 直方圖(Histogram)

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

4. 摘要(Summary)

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

Kubernetes微服務監控體系

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

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

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

而回到以Kubernetes為載體的微服務監控體系，雖然曾經Kubernetes項目的監控體系非常復雜，社區中也有很多方案。但是這套體系發展到今天，已經完全演變成了以Prometheus項目為核心的一套統一方案。在本節的內容中我們就將演示如何圍繞Prometheus來構建針對Kubernetes的微服務監控系統。

1. Prometheus簡介

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

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

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

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

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

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

2. Prometheus Operator安裝部署

前面我們簡單介紹了Prometheus監控系統的基本原理，接下來的內容將以實操的方式演示如何使用Prometheus構建一套針對Kubernetes集群的微服務監控體系。

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

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

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

1)、安裝Helm

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

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

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

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

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

之后執行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相關的charts包，命令如下：

$ helm search repo prometheus

具體搜索結果如下圖所示：

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

3)Helm安裝Prometheus-Operator監控系統

接下來啊，通過Helm具體安裝prometheus-operator監控系統，命令如下：

#創建k8s名稱空間 kubectl create ns monitoring  #通過helm安裝promethues-operator監控系統 helm install promethues-operator stable/prometheus-operator -n monitoring

執行安裝命令后，輸出結果如下：

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.

執行完安裝命令后，查看具體的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監控系統相關的組件都以Pod的方式運行在了Kubernetes集群中。

Prometheus監控效果演示

通過前面的實際操作，我們通過Helm的方式已經將Prometheus  Operator安裝包部署在了Kubernetes集群之中。而此時的Prometheus實際上就已經開始發揮作用，并采集了各類Kubernetes的運行指標信息。可以通過Promethues內置的監控界面對此進行查看，具體步驟如下：

查看Kubernetes中查看內置監控界面所在的Pod節點，命令如下：

kubectl -n monitoring get svc

使用nodeport方式將promethues-operator內置界面服務暴露在集群外，并指定使用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節點所在的宿主機IP+端口地址，URL示例如下：

http://10.211.55.11:30444/graph

此時就可以看到Promethues內置的監控可視化界面了，效果如下圖所示：

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

由此說明，此時Promethues監控系統已經開始運行，并采集了相關Metrics指標數據！

Grafana可視化監控系統

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

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

#查看服務節點信息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的應用運行的默認端口為80，為避免實驗環境沖突，這里映射時將目標容器端口指定為3000，并最終將節點端口映射為30441。完成后，瀏覽器輸入URL：

#IP地址為映射命令執行時所在的節點http://10.211.55.11:30441

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

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

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

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

 

上圖所示的Dashboard中展示了Kubernetes集群所在的各物理節點CPU、負載、內存、磁盤I/O、磁盤空間、網絡傳輸等硬件資源的使用情況。從這些豐富的視圖可以看出Grafana強大的監控指標可視化能力!

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