三分鐘快速解析Kubernetes微服務監控體系

時間 2020-12-03

標籤 node linux git github 數據庫後端瀏覽器服務器網絡數據結構欄目 Linux 简体版

原文原文鏈接

監控系統是運維體系乃至整個軟件產品生命週期中最重要的一環，完善的監控能夠幫助咱們事前及時發現故障，過後快速追查定位問題。而在以微服務爲表明的雲原生架構體系中，系統分爲多個層次，服務之間調用鏈路複雜，系統中須要監控的目標很是多，若是沒有一個完善的監控系統就難以保證總體服務的持續穩定。node

監控對象及分層

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

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

資源利用：是對像I/O利用率、CPU利用率、內存使用率、磁盤使用率、網絡負載等這樣的硬件資源進行監控。避免因應用程序自己或其它特殊狀況引發的硬件資源耗盡而出現的服務故障。
網絡通訊：是對服務器之間的網絡狀態進行監控。網絡通訊是互聯網的重要基石，若是主機之間的網絡出現如延遲過大、丟包率高這樣的網絡問題，將會嚴重影響業務。

須要說明的是，在基於Kubernetes容器化技術的新型雲原生基礎設施中，基礎層的監控不只要對宿主機自己進行監控，也要對Kubernetes集羣狀態及其容器資源使用狀況進行監控。這在後面咱們構建基於Kubernetes的基礎層監控體系時將會具體介紹。github

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

應用層監控這裏就是指對業務性服務程序的監控，通常來講咱們對應用程序監控的關注點主要體如今如下幾個方面：後端

HTTP接口請求訪問。包括接口響應時間、吞吐量等；
JVM監控指標。對於Java服務，還會重點關注GC時間、線程數、FGC/YGC耗時等JVM性能相關的指標；
資源消耗。應用程序部署後會消耗必定的資源，例如應用程序對內存、CPU的消耗狀況；
服務的健康狀態。例如當前服務是否存活，運行是否穩定等；
調用鏈路。在微服務架構中，因爲調用鏈路變長，還須要重點監控服務之間的調用關係和調用狀況，避免局部上下游服務之間的鏈路故障引起系統全局性雪崩；

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

業務指標也是體現系統穩定性的核心要素。任何系統，若是出現了問題，最早受到影響的確定是業務指標。對於核心業務指標的設定因具體的業務和場景而異，因此對於業務層的監控須要構建具有業務特色的業務監控系統。服務器

常見的監控指標類型

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

從總體上看，常見的Metrics指標類型主要有四類：數據結構

計數器（Counter）
測量儀（Gauge）
直方圖（Histogram）
摘要（Summary）

一、計數器（Counter）

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

二、測量儀（Gauge）

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

三、直方圖（Histogram）

直方圖是一種將多個數值聚合在一塊兒的數據結構，能夠表示數據的分佈狀況。好比以常見的響應耗時舉例，能夠把響應耗時數據分爲多個桶（Bucket）,每一個桶表明一個耗時區間，例如0～100毫秒、100～500毫秒，以此類推。經過這樣的形式，能夠直觀地看到一個時間段內的請求耗時分佈，這將有助於咱們理解耗時狀況分佈。

四、摘要（Summary）

摘要與直方圖相似，表示的也是一段時間內的數據結果，可是摘要反應的數據內容不太同樣。摘要通常用於標識分位值，分位值其實就是咱們常說的TP90、TP99等。例若有100個耗時數值，將全部的數值從低到高排列，取第90%的位置，這個位置的值就是TP90的值，若是這個桶對應的值假設是80ms，那麼就表明小於等於90%位置的請求都≤80ms。

Kubernetes微服務監控體系

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

從監控對象及系統分層的角度看，監控系統須要監控的範圍是很是普遍的，但從微服務監控的角度來講，若是你的微服務部署徹底是基於Kubernetes雲原生環境的，那麼咱們須要關注的監控對象主要就是Kubernetes集羣自己以及運行其中的微服務應用容器。例如對容器資源使用狀況，如CPU使用率、內存使用率、網絡、I/O等指標的監控。

固然，這並非說像基礎層的物理機、虛擬機設備或者中間層軟件的監控咱們不須要關注，只是這部分工做通常會有專門的人員去維護。而若是使用的是雲服務，那麼雲服務廠商大都已經爲咱們提供了監控支持。此外，對於基礎物理層及大部分中間軟件的監控並非本文所要表達的重點，因此也就再也不作過多的實踐，你們對此有個全局的認識便可。

而回到以Kubernetes爲載體的微服務監控體系，雖然曾經Kubernetes項目的監控體系很是複雜，社區中也有不少方案。可是這套體系發展到今天，已經徹底演變成了以Prometheus項目爲核心的一套統一方案。在本節的內容中咱們就將演示如何圍繞Prometheus來構建針對Kubernetes的微服務監控系統。

一、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（看板）。

二、Prometheus Operator安裝部署

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

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

而若是針對的是Kubernetes集羣的監控，那麼如今主流的方式是採用Promethues-Operator將Promethues部署到Kubernetes集羣之中，這樣能以更原生的方式實施對Kubernetes集羣及容器的監控。這裏所說的Promethues-Operator 是指專門針對Kubernetes的Promethues封裝包，它能夠簡化Promethues的部署和配置。

接下來咱們具體演示如何經過Promethues-Operator在Kubernetes中快速安裝部署Promethues，具體步驟以下：

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微服務監控體系的構建步驟，但願可以對你們學習Kubernetes有所幫助。目前以Kubernetes爲表明的容器化技術已經成爲現代軟件應用發佈的標準方式，做爲一名普通研發人員，對Kubernetes的學習將有助於咱們更深刻的理解總體軟件系統的構建原理，也是咱們進階提高必不可少的知識儲備！