[[354899]]

本文轉載自微信公眾號「無敵碼農」，作者無敵碼農 。轉載本文請聯(lián)系無敵碼農公眾號。

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

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

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

 

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

• 資源利用：是對像I/O利用率、CPU利用率、內存使用率、磁盤使用率、網(wǎng)絡負載等這樣的硬件資源進行監(jiān)控。避免因應用程序本身或其它特殊情況引起的硬件資源耗盡而出現(xiàn)的服務故障。
• 網(wǎng)絡通信：是對服務器之間的網(wǎng)絡狀態(tài)進行監(jiān)控。網(wǎng)絡通信是互聯(lián)網(wǎng)的重要基石，如果主機之間的網(wǎng)絡出現(xiàn)如延遲過大、丟包率高這樣的網(wǎng)絡問題，將會嚴重影響業(yè)務。

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

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

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

• HTTP接口請求訪問。包括接口響應時間、吞吐量等;
• JVM監(jiān)控指標。對于Java服務，還會重點關注GC時間、線程數(shù)、FGC/YGC耗時等JVM性能相關的指標;
• 資源消耗。應用程序部署后會消耗一定的資源，例如應用程序對內存、CPU的消耗情況;
• 服務的健康狀態(tài)。例如當前服務是否存活，運行是否穩(wěn)定等;

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

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

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

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

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

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

2. 測量儀(Gauge)

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

3. 直方圖(Histogram)

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

4. 摘要(Summary)

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

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

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

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

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

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

1. Prometheus簡介

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

簡單理解Metrics的表現(xià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)結構，如下圖所示：

 

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

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

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

2. Prometheus Operator安裝部署

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

在實際的應用場景中，針對不同的監(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)境可參考本專欄相關內容)，具體步驟如下：

1)、安裝Helm

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

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

#找到Github中Helm相關的發(fā)布包，參考鏈接如下 
https://github.com/helm/helm/releases 
 
#確定好相關版本后，將具體安裝版本下載至某個安裝了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相關的charts包，命令如下：

$ helm search repo prometheus

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

 

如上圖所示，我們可以看到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í)行安裝命令后，輸出結果如下：

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)相關的組件都以Pod的方式運行在了Kubernetes集群中。

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

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

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

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節(jié)點所在的宿主機IP+端口地址，URL示例如下：

http://10.211.55.11:30444/graph 

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

 

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

 

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

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

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

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

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

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

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

 

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

 

可以看到部署完成的Grafana已經默認內置了許多針對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、負載、內存、磁盤I/O、磁盤空間、網(wǎng)絡傳輸?shù)扔布Y源的使用情況。從這些豐富的視圖可以看出Grafana強大的監(jiān)控指標可視化能力!

后記 

本文給大家從理論到實踐簡單介紹了Kubernetes微服務監(jiān)控體系的構建步驟，希望能夠對大家學習Kubernetes有所幫助。目前以Kubernetes為代表的容器化技術已經成為現(xiàn)代軟件應用發(fā)布的標準方式，作為一名普通研發(fā)人員，對Kubernetes的學習將有助于我們更深入的理解整體軟件系統(tǒng)的構建原理，也是我們進階提升必不可少的知識儲備!

原文鏈接：https://mp.weixin.qq.com/s/WbkoqOnCQv0cywPysfKzng