小白也能輕鬆上手的Prometheus教程

時間 2020-05-01

標籤輕鬆上手 prometheus 教程简体版

原文原文鏈接

這篇文章將承接此前關於使用Prometheus配置自定義告警規則的文章。在本文中，咱們將demo安裝Prometheus的過程以及配置Alertmanager，使其可以在觸發告警時能發送郵件，但咱們將以更簡單的方式進行這一切——經過Rancher安裝。nginx

咱們將在這篇文章中看到沒有使用依賴項的狀況下如何完成這一操做。在本文中，咱們不須要：git

專門配置運行指向Kubernetes集羣的kubectlgithub
有關kubectl的知識，由於咱們可使用Rancher UI正則表達式
Helm binary的安裝/配置api

前期準備

一個谷歌雲平臺帳號（免費的便可），其餘雲也是同樣的併發
Rancher v2.4.2（文章發佈時的最新版本）app
運行在GKE（版本爲1.15.11-gke.3）上的Kubernetes集羣（EKS或者AKS也能夠）負載均衡

啓動一個Rancher實例

首先，啓動一個Rancher實例。你能夠根據Rancher的指引啓動：運維

https://www.rancher.cn/quick-start/ide

使用Rancher部署一個GKE集羣

使用Rancher來設置並配置一個Kubernetes集羣。你能夠訪問下方連接獲取文檔：

https://rancher2.docs.rancher.cn/docs/cluster-provisioning/_index

部署Prometheus

咱們將利用Rancher的應用商店來安裝Prometheus。Rancher的應用商店主要集合了許多Helm Chart，以便於用戶可以重複部署應用程序。

咱們的集羣起來而且開始運行以後，讓咱們在「Apps」的標籤下選擇爲其建立的默認項目，而後單擊「Launch」按鈕。

如今咱們來搜索咱們感興趣的chart。咱們能夠設置不少字段——可是對於本次demo來講咱們將保留默認值。你能夠在Detailed Description部分找到關於這些值的有用信息。無需擔憂出現問題，儘管去查看它們的用途。在頁面底部，點擊【Launch】。Prometheus Server以及Alertmanager將會被安裝以及配置。

當安裝完成時，頁面以下所示：

接下來，咱們須要建立Services以訪問Prometheus Server以及Alertmanager。點開資源下方的工做負載標籤，在負載均衡部分，咱們能夠看到目前尚未配置。點擊導入YAML，選擇prometheus namespace，一次性複製兩個YAML並點擊導入。稍後你將瞭解咱們如何知道使用那些特定的端口和組件tag。

apiVersion: v1
kind: Service
metadata:
  name: prometheus-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 9090
      protocol: TCP
  selector:
    component: server

apiVersion: v1
kind: Service
metadata:
  name: alertmanager-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 9093
      protocol: TCP
  selector:
    component: alertmanager

完成以後，service將顯示Active。

在右側垂直省略號的下拉菜單裏你能找到IP並點擊View/Edit YAML。在yaml文件的底部，你將會看到相似的部分：

status:
  loadBalancer:
    ingress:
      - ip: 34.76.22.14

訪問IP將爲咱們展現Prometheus Server和Alertmanager的GUI。你會發現這時沒有什麼內容能夠查看的，由於還沒有定義規則以及配置告警。

添加規則

規則可讓咱們觸發告警。這些規則都是基於Prometheus的表達式語言。不管什麼時候，只要符合條件，告警就會被觸發併發送給Alertmanager。

如今來看看咱們如何添加規則。

在資源->工做負載標籤下，咱們能夠看到Deployment在運行chart時建立了什麼。咱們來詳細看看prometheus-server和prometheus-alertmanager。

咱們從第一個開始並理解其配置，咱們如何編輯它並瞭解服務在哪一個端口上運行。點擊垂直省略號菜單按鈕並點擊View/Edit YAML。

首先，咱們看到的是兩個與Deplolyment關聯的容器：prometheus-server-configmap-reload和prometheus-server。容器prometheus-server的專屬部分有一些相關信息：

正如咱們所瞭解的，Prometheus經過prometheus.yml進行配置。該文件（以及其餘在serverFiles中列出的文件）將掛載到server pod。爲了添加/編輯規則，咱們須要修改這個文件。實際上，這就是一個Config Map，能夠在Resources Config的標籤頁下找到。點擊垂直的省略菜單按鈕並Edit。在規則部分，讓咱們添加新的規則並點擊保存。

groups:
  - name: memory demo alert
    rules:
      - alert: High Pod Memory
        expr: container_memory_usage_bytes{pod_name=~"nginx-.*", image!="", container!="POD"} > 5000000
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: High Memory Usage

  - name: cpu demo alert
    rules:
      - alert: High Pod CPU
        expr: rate (container_cpu_usage_seconds_total{pod_name=~"nginx-.*", image!="", container!="POD"}[5m]) > 0.04
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: High CPU Usage

規則將會由Prometheus Server自動加載，而後咱們在Prometheus Server GUI中能看到它們：

這是關於以上兩條規則的解釋：

container_memory_usage_bytes：當前內存使用狀況（以字節爲單位），包括全部內存，不管任什麼時候候訪問。
container_cpu_usage_seconds_total：累積的CPU時間（以秒爲單位）

全部的指標都可以在如下頁面中找到：

https://github.com/google/cadvisor/blob/master/metrics/prometheus.go

在Prometheus中全部正則表達式都使用RE2 syntax。使用正則表達式，咱們只能爲名稱與特定模式匹配的Pod選擇時間序列。在咱們的示例中，咱們須要尋找以nginx-開頭的pod，而且排除「POD」，由於這是容器的父cgroup，並且會顯示pod內全部容器的統計信息。

對於container_cpu_usage_seconds_total來講，咱們使用所謂的子查詢（Subquery）。它會每5分鐘返回咱們的指標。

若是你想了解更多關於查詢以及例子，能夠在官方的Prometheus文檔中查看。

配置告警

只要出現問題，告警就能當即提醒咱們，使得咱們可以馬上知道系統中發生了錯誤。而Prometheus經過Alertmanager組件來提供告警。

與Prometheus Server的操做步驟相同：在資源->工做負載標籤頁下，點擊prometheus-alertmanager右側菜單欄按鈕，選擇View/Edit YAML，檢查其配置：

Alertmanager經過alertmanager.yml進行配置。該文件（及其餘列在alertmanagerFiles內的文件）將掛載到alertmanager pod上。接下來咱們須要修改與alertmanager相關聯的configMap以便於設置告警。在Config標籤頁下，點擊prometheus-alertmanager行的菜單欄，而後選擇Edit。使用如下代碼代替基本配置：

global:
  resolve_timeout: 5m
route:
  group_by: [Alertname]
  # Send all notifications to me.
  receiver: demo-alert
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  routes:
    - match:
        alertname: DemoAlertName
      receiver: "demo-alert"

receivers:
  - name: demo-alert
    email_configs:
      - to: your_email@gmail.com
        from: from_email@gmail.com
        # Your smtp server address
        smarthost: smtp.gmail.com:587
        auth_username: from_email@gmail.com
        auth_identity: from_email@gmail.com
        auth_password: 16letter_generated token # you can use gmail account password, but better create a dedicated token for this
        headers:
          From: from_email@gmail.com
          Subject: "Demo ALERT"

新配置將會由Alertmanager從新加載，而且咱們能在Status標籤頁下看到GUI。

測試End-to-End方案

讓咱們部署一些組件來進行監控。對於練習來講部署一個簡單的nginx deployment就足夠了。使用Rancher GUI，在資源->工做負載標籤頁下點擊導入YAML，粘貼如下代碼（本次使用默認的命名空間）並點擊導入：

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
            - containerPort: 80

在Prometheus UI中，咱們爲使用此前爲告警配置的兩個表達式中的1個來查看一些指標：

rate (container_cpu_usage_seconds_total{pod_name=~"nginx-.*", image!="", container!="POD"}[5m])

讓咱們在其中一個Pod中添加一些負載以查看值的變化。當值大於0.04時，咱們應該得到告警。爲此，咱們須要選擇其中一個nginx Deployment Pod並點擊Execute Shell。在其中咱們將執行一個命令：

告警有3個階段：

Inactive-條件不知足
Pending-知足條件
Firing-告警被觸發

咱們已經看到告警處於inactive狀態，因此繼續在CPU上增長負載讓咱們能觀察到剩餘兩種狀態：

只要告警觸發，將會顯示在Alertmanager中：

將Alertmanager配置爲在咱們收到告警時發送電子郵件。若是咱們查看收件箱，則會看到相似的內容：

總結

咱們都知道監控在整個運維過程當中多麼重要，可是若是沒有告警，監控是不完整的。告警能夠在問題發生時，而後咱們馬上知道系統中出現了問題。Prometheus囊括了這兩種功能：監控解決方案以及其Alertmanager組件的告警功能。本文中咱們看到了使用Rancher部署Prometheus如此容易而且將Prometheus Server與Alertmanager集成。咱們還使用Rancher配置了告警規則並推送了Alertmanager的配置，因此它能在問題發生時提醒咱們。最後，咱們瞭解瞭如何根據Alertmanager的定義/集成收到一封包含觸發告警詳細信息的電子郵件（也能夠經過Slack或PagerDuty發送）。