Category: Prometheus

資料提供端​在架構圖的哪邊呢

資料提供端的資料長怎樣呢

• Counter: 代表一個單調遞增的計數器​
• Gauge: 表示可以任意上下的單個數值​
• Histogram:直方圖對觀察結果進行採樣（通常是請求持續時間或響應大小等），並將它們計入可配置的存儲桶中。它還提供所有觀察值的總和。​
• Summary: 與histogram類似，摘要對觀察結果進行採樣（通常是請求持續時間和響應大小等）。雖然它還提供了觀察總數和所有觀察值的總和，但它計算了滑動時間窗口上的可配置分位數。

查看現有的資料提供端提供了那些資訊

• 打開Prometheus面板的Targets
  
  
  ​
• 選擇要查看的目標的endpoint連結，除了node-exporter外，都會需要在k8s的內網去讀取資料，以json-exporter來說，可在namespace內部使用下面指令查看:​

  curl “http://127.0.0.1:7979/probe?module=default&target=http://127.0.0.1:1985/api/v1/streams/”​

• 但是同時我們也會發現有許多的網址是無法連上的，因為部分的exporter若是有需要使用密鑰​

​

取得pod-exporter所提供的資料​

​rancher-monitoring-kubelet可以取得在所有node裡面的Pods的運行狀態，但是在k8s取得Pods的狀態需要認證，因此需要在yaml裡面設定所需要的Secrets，指令如下:

# 取得該namespace的所有密鑰​
kubectl get secret -n cattle-monitoring-system​
# 取得密鑰的內容​
kubectl -n cattle-monitoring-system get secret rancher-monitoring-prometheus-token-hvlqt -o jsonpath={.data.token} | base64 –d​
​
# 將pod-exporter的網址後面加上-H並帶入密鑰
curl https://172.17.2.22:10250/metrics/cadvisor-k -H “Authorization: Bearer ${TOKEN}”

更多資訊請見:Accessing the Kubernetes API from a Pod

了解資料提供端的樣子的重要性​

可了解要怎麼在Grafana搜尋目標資料，並了解有哪些資料是可以取得的

上面的資料可用以下的PromQL來撈出，sum代表所有串流的數字加總，並以pod label做資料加總分組的依據。
(sum(stream_clients_clients{namespace=~”namespace_name”, pod=~”pod_name.+”, name=~”.+”}) by (pod))
因此了解有哪些資料，才能夠使用PromQL撈出所需資料

如何產生這些資料​

官方提供許多各種語言可使用的函式庫​
https://prometheus.io/docs/instrumenting/clientlibs/​

以下為幾個我嘗試過的exporter:​

• Node.js的swagger-stats​: https://github.com/slanatech/swagger-stats​
• 將JSON轉為exporter格式: json-exporter​
• 使用Pushgateway​: https://github.com/prometheus/pushgateway​

不論使用上面哪個方法，最終都需要有一個類似這個頁面的產出，一個靜態的純文字頁面，上面有著我們要觀察的值​

​

​

Prometheus 簡介

我們在 SoundCloud 的官方博客中可以找到一篇關於他們爲什麼需要新開發一個監控系統的文章 Prometheus: Monitoring at SoundCloud，在這篇文章中，他們介紹到，他們需要的監控系統必須滿足下面四個特性：

簡單來說，就是下面四個特性：

• 多維度數據模型
• 方便的部署和維護
• 靈活的數據採集
• 強大的查詢語言

實際上，多維度數據模型和強大的查詢語言這兩個特性，正是時序數據庫所要求的，所以 Prometheus 不僅僅是一個監控系統，同時也是一個時序數據庫。那爲什麼 Prometheus 不直接使用現有的時序數據庫作爲後端存儲呢？這是因爲 SoundCloud 不僅希望他們的監控系統有着時序數據庫的特點，而且還需要部署和維護非常方便。

此外，Prometheus 數據採集方式也非常靈活。要採集目標的監控數據，首先需要在目標處安裝數據採集組件，這被稱之爲 Exporter，它會在目標處收集監控數據，並暴露出一個 HTTP 接口供 Prometheus 查詢，Prometheus 通過 Pull 的方式來採集數據，這和傳統的 Push 模式不同。

不過 Prometheus 也提供了一種方式來支持 Push 模式，你可以將你的數據推送到 Push Gateway，Prometheus 通過 Pull 的方式從 Push Gateway 獲取數據。目前的 Exporter 已經可以採集絕大多數的第三方數據，比如 Docker、HAProxy、StatsD、JMX 等等，官網有一份 Exporter 的列表。

Prometheus 的整體架構圖

從上圖可以看出，Prometheus 生態系統包含了幾個關鍵的組件：Prometheus server、Pushgateway、Alertmanager、Web UI 等，但是大多數組件都不是必需的，其中最核心的組件當然是 Prometheus server，它負責收集和存儲指標數據，支持表達式查詢，和告警的生成。

使用套件

1. Prometheus
2. Prometheus Operator
3. K8S
4. Rancher

步驟一、設定自訂義指標

1. 設定Exporter，這邊有許多官方提供的函式庫
https://prometheus.io/docs/instrumenting/clientlibs/
2. 設定該export的service名為my-export

apiVersion: v1
kind: Service
metadata:
  labels:
    app: my-export
  name: my-export
  namespace: default
spec:
  clusterIP: None
  clusterIPs:
  - None
  ports:
  - name: my-export
    port: 7979
    protocol: TCP
    targetPort: 7979
  selector:
    prometheus-customized-metrix: my-export
  type: ClusterIP

設定Service Monitors

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: my-export
  name: my-export
  namespace: default
spec:
  endpoints:
  - interval: 30s
    params:
      module:
      - default
      target:
      - http://127.0.0.1:1985/api/v1/streams/
    path: /probe
    port: my-export
  jobLabel: jobLabel
  namespaceSelector:
    matchNames:
    - default
  selector:
    matchLabels:
      app: my-export

步驟二、設定自訂義規則

增加Prometheus Rules

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    app: rancher-monitoring
    app.kubernetes.io/instance: rancher-monitoring
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/part-of: rancher-monitoring
    app.kubernetes.io/version: 16.6.1_up16.6.0
    chart: rancher-monitoring-16.6.1_up16.6.0
    heritage: Helm
    release: rancher-monitoring
  name: my-data
  namespace: default
spec:
  groups:
  - name: my-data
    rules:
    - expr: sum(mydata{container="my-container", name=~".+",namespace=~"default"})
        by (pod)
      labels:
        namespace: default
        service: eventqueue
      record: mydata

設定HPA

在HorizontalPodAutoscaler增加一個設定如下

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-hpa
  namespace: default
spec:
  behavior:
    scaleDown:
      policies:
      - periodSeconds: 60
        type: Pods
        value: 1
      selectPolicy: Max
      stabilizationWindowSeconds: 300
    scaleUp:
      policies:
      - periodSeconds: 60
        type: Pods
        value: 1
      selectPolicy: Max
      stabilizationWindowSeconds: 300
  maxReplicas: 2
  metrics:
  - object:
      describedObject:
        apiVersion: v1
        kind: Service
        name: eventqueue
      metric:
        name: mydata
      target:
        type: Value
        value: 1k
    type: Object
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-container

參考資料

1. https://docs.openshift.com/container-platform/4.9/nodes/pods/nodes-pods-autoscaling.html
2. https://www.padok.fr/en/blog/scaling-prometheus-rabbitmq