摘要：客戶端庫，為需要監(jiān)控的服務生成相應的并暴露給。根據(jù)配置文件，對接收到的警報進行處理，發(fā)出告警。再創(chuàng)建一個來告訴需要監(jiān)控帶有為的背后的一組的。

什么是Prometheus

關于Prometheus

Prometheus 是一套開源的系統(tǒng)監(jiān)控報警框架。它的設計靈感源于 Google 的 borgmon 監(jiān)控系統(tǒng)，由SoundCloud 在 2012 年創(chuàng)建，后作為社區(qū)開源項目進行開發(fā)，并于 2015 年正式發(fā)布。2016 年，Prometheus 正式加入 Cloud Native Computing Foundation(CNCF)，成為受歡迎度僅次于 Kubernetes 的項目，目前已廣泛應用于Kubernetes集群監(jiān)控系統(tǒng)中，大有成為Kubernetes集群監(jiān)控標準方案的趨勢。

Prometheus的優(yōu)勢

• 強大的多維度數(shù)據(jù)模型：

  • 時間序列數(shù)據(jù)通過 metric 名和鍵值對來區(qū)分。
  • 所有的 metrics 都可以設置任意的多維標簽。
  • 數(shù)據(jù)模型更隨意，不需要刻意設置為以點分隔的字符串。
  • 可以對數(shù)據(jù)模型進行聚合，切割和切片操作。
  • 支持雙精度浮點類型，標簽可以設為全 unicode。
• 靈活而強大的查詢語句（PromQL）：在同一個查詢語句，可以對多個 metrics 進行乘法、加法、連接、取分數(shù)位等操作。
• 易于管理： Prometheus server 是一個多帶帶的二進制文件，可直接在本地工作，不依賴于分布式存儲。
• 高效：平均每個采樣點僅占 3.5 bytes，且一個 Prometheus server 可以處理數(shù)百萬的 metrics。
• 動態(tài)獲?。?/strong>可以通過服務發(fā)現(xiàn)或者靜態(tài)配置去獲取監(jiān)控的 targets。
• 使用 pull 模式采集時間序列數(shù)據(jù)，可以避免有問題的服務器推送壞的 metrics。
• 支持 push gateway 的方式把時間序列數(shù)據(jù)推送至 Prometheus server 端。
• 多種可視化圖形界面。

Prometheus架構及組件

圖片源于Prometheus官方文檔

上圖為Prometheus的架構圖，包含了Prometheus的核心模塊及生態(tài)圈中的組件，簡要介紹如下：

• Prometheus Server: 用于收集和存儲時間序列數(shù)據(jù)。
• Client Library: 客戶端庫，為需要監(jiān)控的服務生成相應的 metrics 并暴露給 Prometheus server。當 Prometheus server 來 pull 時，直接返回實時狀態(tài)的 metrics。
• Push Gateway: 主要用于短期的 jobs。由于這類 jobs 存在時間較短，可能在 Prometheus 來 pull 之前就消失了。為此 jobs 可以直接向 Prometheus server 端推送它們的 metrics。這種方式主要用于服務層面的 metrics，對于機器層面的 metrices，建議使用 node exporter。
• Exporters: 用于暴露已有的第三方服務的 metrics 給 Prometheus。
• Alertmanager: 從 Prometheus server 端接收到 alerts 后，會去除重復數(shù)據(jù)，分組，并路由到對應的接受方式，發(fā)出報警。

工作原理

如上圖可見，Prometheus 的主要模塊包括：Prometheus server exporters Pushgateway PromQL Alertmanager 以及圖形界面，其大概的工作流程是：

1. Prometheus server 定期從配置好的 jobs 或者 exporters 中拉 metrics，或者接收來自 Pushgateway 發(fā)過來的 metrics，或者從其他的 Prometheus server 中拉 metrics。
2. Prometheus server 在本地存儲收集到的 metrics，并運行已定義好的 alert.rules，記錄新的時間序列或者向 Alertmanager 推送警報。
3. Alertmanager 根據(jù)配置文件，對接收到的警報進行處理，發(fā)出告警。
4. 在圖形界面中，可視化采集數(shù)據(jù)。

Prometheus 工作的核心，是使用 Pull （抓?。┑姆绞饺ニ鸭槐O(jiān)控對象的 Metrics 數(shù)據(jù)（監(jiān)控指標數(shù)據(jù)），然后，再把這些數(shù)據(jù)保存在一個 TSDB （時間序列數(shù)據(jù)庫，比如 OpenTSDB、InfluxDB 等）當中，以便后續(xù)可以按照時間進行檢索。

適用場景

Prometheus非常適合記錄純時間序列的數(shù)據(jù)。它既適用于面向服務器等硬件指標的監(jiān)控，也適用于高動態(tài)的面向服務架構的監(jiān)控。對于現(xiàn)在流行的微服務，Prometheus的多維度數(shù)據(jù)收集和數(shù)據(jù)篩選查詢語言也是非常的強大。Prometheus是為服務的可靠性而設計的，當服務出現(xiàn)故障時，它可以使你快速定位和診斷問題。它的搭建過程對硬件和服務沒有很強的依賴關系。

Prometheus重視可靠性，即使在故障情況下，您也可以隨時查看有關系統(tǒng)的可用統(tǒng)計信息。如果您需要100％的準確度，例如按請求計費，Prometheus不是一個好的選擇，因為收集的數(shù)據(jù)可能不夠詳細和完整。

總之，在需要高可用性的業(yè)務場景，Prometheus是一個非常好的選擇，但對于高精度、高準確率的業(yè)務場景，Prometheus并非最佳選擇。

核心概念

為了在 Prometheus 的配置和使用中可以更加順暢，我們對 Prometheus 中的數(shù)據(jù)模型、metric 類型以及 instance 和 job 等概念做個簡要介紹。

數(shù)據(jù)模型

Prometheus 中存儲的數(shù)據(jù)為時間序列，是由 metric 的名字和一系列的標簽（鍵值對）唯一標識的，不同的標簽則代表不同的時間序列。

• metric 名字：該名字應該具有語義，一般用于表示 metric 的功能，例如：http_requests_total 表示 http 請求的總數(shù)。其中，metric 名字由 ASCII 字符，數(shù)字，下劃線，以及冒號組成，且必須滿足正則表達式 a-zA-Z_:*。
• 標簽：使同一個時間序列有了不同維度的識別。例如 http_requests_total{method="Get"} 表示所有 http 請求中的 Get 請求。當 method="post" 時，則為新的一個 metric。標簽中的鍵由 ASCII 字符，數(shù)字，以及下劃線組成，且必須滿足正則表達式 a-zA-Z_:*。
• 樣本：實際的時間序列，每個序列包括一個 float64 的值和一個毫秒級的時間戳。
• 格式： 如http_requests_total{method="POST"endpoint="/api/tracks"}。

metric 類型

Prometheus 客戶端庫主要提供四種主要的 metric 類型，分別如下：

1. Counter

一種累加的 metric，典型的應用如：請求的個數(shù)，結束的任務數(shù)， 出現(xiàn)的錯誤數(shù)等等。
例如，查詢 http_requests_total{method="get" job="kubernetes-nodes" handler="prometheus"} 返回 8，10 秒后，再次查詢，則返回 14。

1. Gauge

一種常規(guī)的 metric，典型的應用如：溫度，運行的 goroutines 的個數(shù)。例如：go_goroutines{instance="10.9.81.55" job="kubernetes-nodes"} 返回值 147，10 秒后返回 124。

1. Histogram

可以理解為柱狀圖，典型的應用如：請求持續(xù)時間，響應大小?？梢詫τ^察結果采樣，分組及統(tǒng)計。
例如，查詢 http_request_duration_microseconds_sum{job="kubernetes-nodes" handler="prometheus"} 時，返回結果如下：

1. Summary

類似于 Histogram 典型的應用如：請求持續(xù)時間，響應大小。提供觀測值的 count 和 sum 功能。提供百分位的功能，即可以按百分比劃分跟蹤結果。

instance&job

instance: 一個多帶帶 scrape 的目標， 一般對應于一個進程。

jobs: 一組同類型的 instances

例如，一個 api-server 的 job 可以包含4個 instances：

• job: api-server

  • instance 1: 1.2.3.4:5670
  • instance 2: 1.2.3.4:5671
  • instance 3: 1.2.3.4:5672
  • instance 4: 1.2.3.4:5673

當 scrape 目標時，Prometheus 會自動給這個 scrape 的時間序列附加一些標簽以便更好的分別，例如：instance，job。

部署Prometheus

前言

對于一套Kubernetes集群而言，需要監(jiān)控的對象大致可以分為以下幾類：

• Kubernetes系統(tǒng)組件：Kubernetes內(nèi)置的系統(tǒng)組件一般有apiserver、controller-manager、etcd、kubelet等，為了保證集群正常運行，我們需要實時知曉其當前的運行狀態(tài)。
• 底層基礎設施： Node節(jié)點(虛擬機或物理機)的資源狀態(tài)、內(nèi)核事件等。
• Kubernetes對象： 主要是Kubernetes中的工作負載對象，如Deployment、DaemonSet、Pod等。
• 應用指標： 應用內(nèi)部需要關心的數(shù)據(jù)指標，如httpRequest。

部署Prometheus

在Kubernetes中部署Prometheus，除了手工方式外，CoreOS開源了Prometheus-Operator以及kube-Prometheus項目，使得在K8S中安裝部署Prometheus變得異常簡單。下面我們介紹下如何在UK8S中部署Kube-Prometheus。

1、關于Prometheus-Operator

Prometheus-operator的本職就是一組用戶自定義的CRD資源以及Controller的實現(xiàn)，Prometheus Operator這個controller有BRAC權限下去負責監(jiān)聽這些自定義資源的變化，并且根據(jù)這些資源的定義自動化的完成如Prometheus Server自身以及配置的自動化管理工作。

在K8S中，監(jiān)控metrics基本最小單位都是一個Service背后的一組pod，對應Prometheus中的target，所以prometheus-operator抽象了對應的CRD類型" ServiceMonitor "，這個ServiceMonitor通過 sepc.selector.labes來查找對應的Service及其背后的Pod或endpoints，通過sepc.endpoint來指明Metrics的url路徑。
以下面的CoreDNS舉例，需要pull的Target對象Namespace為kube-system，kube-app是他們的labels，port為metrics。

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    k8s-app: coredns
  name: coredns
  namespace: monitoring
spec:
  endpoints:
  - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    interval: 15s
    port: metrics
  jobLabel: k8s-app
  namespaceSelector:
    matchNames:
    - kube-system
  selector:
    matchLabels:
      k8s-app: kube-dns

2、準備工作

ssh到任意一臺Master節(jié)點，克隆kube-prometheus項目。該項目源自CoreOS開源的kube-prometheus，與原始項目相比，主要作為以下優(yōu)化：

• 將Prometheus和AlbertManager的數(shù)據(jù)存儲介質(zhì)由emptyDir改為UDisk，提升穩(wěn)定性，避免數(shù)據(jù)丟失；
• 將鏡像源統(tǒng)一修改為UHub，避免鏡像拉取失敗的情況出現(xiàn)；
• 新增UK8S專屬文件目錄，用于配置監(jiān)控controller-manager、schduler、etcd；
• 將執(zhí)行文件按目錄劃分，便于修改及閱讀。

yum install git -y
git clone --depth=1 -b kube-prometheus https://github.com/ucloud/uk8s-demo.git

3、修改UK8S專屬文件配置參數(shù)

在manifests目錄下有UK8S目錄，這批配置文件主要用于為UK8S中的controller-manager、schduler、etcd手動創(chuàng)建endpoints和svc，便于Prometheus Server通過ServiceMonitor來采集這三個組件的監(jiān)控數(shù)據(jù)。

cd /uk8s-demo/manifests/uk8s
# 修改以下兩個文件，將其中的IP替換為你自己UK8S Master節(jié)點的內(nèi)網(wǎng)IP
vi controllerManagerAndScheduler_ep.yaml
vi etcd_ep.yaml

4、 備注

上面提到要修改controllerManagerAndScheduler_ep.yaml和etcd_ep.yaml這兩個文件，這里解釋下原因。
由于UK8S的ETCD、Scheduler、Controller-Manager都是通過二進制部署的，為了能通過配置"ServiceMonitor"實現(xiàn)Metrics的抓取，我們必須要為其在K8S中創(chuàng)建一個SVC對象，但由于這三個組件都不是Pod，因此我們需要手動為其創(chuàng)建Endpoints。

apiVersion: v1
kind: Endpoints
metadata:
  labels:
    k8s-app: etcd
  name: etcd
  namespace: kube-system
subsets:
- addresses:
  - ip: 10.7.35.44 # 替換成master節(jié)點的內(nèi)網(wǎng)IP
    nodeName: etc-master2
  ports:
  - name: port
    port: 2379
    protocol: TCP
- addresses:
  - ip: 10.7.163.60 # 同上
    nodeName: etc-master1
  ports:
  - name: port
    port: 2379
    protocol: TCP
- addresses:
  - ip: 10.7.142.140 #同上
    nodeName: etc-master3
  ports:
  - name: port
    port: 2379
    protocol: TCP

5、部署Prometheus Operator

先創(chuàng)建一個名為monitor的NameSpace，Monitor創(chuàng)建成功后，直接部署Operator，Prometheus Operateor以Deployment的方式啟動，并會創(chuàng)建前面提到的幾個CRD對象。

# 創(chuàng)建Namespace
kubectl apply -f  00namespace-namespace.yaml
# 創(chuàng)建Secret，給到Prometheus Server抓取ETCD數(shù)據(jù)時使用
kubectl -n monitoring create secret generic etcd-certs --from-file=/etc/kubernetes/ssl/ca.pem --from-file=/etc/kubernetes/ssl/etcd.pem --from-file=/etc/kubernetes/ssl/etcd-key.pem
# 創(chuàng)建Operator
kubectl apply -f operator/
# 查看operator啟動狀態(tài)
kubectl get po -n monitoring
# 查看CRD
kubectl get crd -n monitoring

6、部署整套CRD

比較關鍵的有Prometheus Server、Grafana、 AlertManager、ServiceMonitor、Node-Exporter等，這些鏡像已全部修改為UHub官方鏡像，因此拉取速度相對比較快。

kubectl apply -f adapter/ 
kubectl apply -f alertmanager/ 
kubectl apply -f node-exporter/ 
kubectl apply -f kube-state-metrics/ 
kubectl apply -f grafana/ 
kubectl apply -f prometheus/ 
kubectl apply -f serviceMonitor/
kubectl apply -f uk8s/

我們可以通過以下命令來查看應用拉取狀態(tài)。

kubectl -n monitoring get po

由于默認所有的SVC 類型均為ClusterIP，我們將其改為LoadBalancer，方便演示。

 kubectl edit svc/prometheus-k8s -n monitoring
# 修改為type: LoadBalancer
[root@10-9-52-233 manifests]# kubectl get svc -n monitoring
# 獲取到Prometheus Server的EXTERNAL-IP及端口

可以看到，所有K8S組件的監(jiān)控指標均已獲取到。

7、監(jiān)控應用指標

我們先來部署一組Pod及SVC，該鏡像里的主進程會在8080端口上輸出metrics信息。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-app
        image: uhub.service.ucloud.cn/uk8s_public/instrumented_app:latest
        ports:
        - name: web
          containerPort: 8080
---
kind: Service
apiVersion: v1
metadata:
  name: example-app
  labels:
    app: example-app
spec:
  selector:
    app: example-app
  ports:
  - name: web
    port: 8080

再創(chuàng)建一個ServiceMonitor來告訴prometheus server需要監(jiān)控帶有l(wèi)abel為app: example-app的svc背后的一組pod的metrics。

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
  labels:
    team: frontend
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - port: web

打開瀏覽器訪問Prometheus Server，進入target發(fā)現(xiàn)已經(jīng)監(jiān)聽起來了，對應的config里也有配置生成和導入。

8、說明

該文檔只適用于kubernetes 1.14以上的版本，如果你的kubernetes版本為1.14以下，可以使用release-0.1.

實時文檔歡迎訪問https://docs.ucloud.cn/uk8s/monitor/prometheus/README