Claire's Blog

下載Metricbeat的docker版本​ 官網介紹: https://www.elastic.co/beats/metricbeat 其中給普羅米修斯使用的模組為: https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-prometheus.html 官方映像檔: https://hub.docker.com/r/elastic/metricbeat 下載映像檔 docker pull docker.elastic.co/beats/metricbeat:8.5.3 新建一個Metricbeat的Pod​ 設定metrucbeat的deployment apiVersion: apps/v1 kind: Deployment metadata: name: metricbeat namespace: default spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: workload.user.cattle.io/workloadselector: apps.deployment-srs3-metricbeat template: spec: affinity: {} containers: – image:…

Prometheus Rule功能介紹 Prometheus Rule 是用於在 Prometheus 中定義規則的 YAML 配置文件。它可以根據指定的表達式或條件對 metrics 進行匹配和計算，並在達到一定條件時生成警報或創建新的 metrics。 Prometheus Rule 的主要功能如下： Metrics 計算：通過表達式對符合條件的 metrics 進行匹配和計算，生成新的 metrics。 警報：當符合指定條件的 metrics 達到一定閾值時，生成警報。 規則繫結：可以為指定的 metrics 繫結指定的規則，進行自動化的警報觸發。 標註註釋：在生成警報時可以加上自定義的標註和註釋，方便後續的統計和分析。 通常在配合 Grafana 等圖形化界面使用時，Prometheus Rule 可以讓用戶方便的自定義需要監控的 metrics，並在 Grafana 上實現對這些 metrics 的實時監控和報警，以實現系統的實時監控和異常處理。 設定Prometheus Rule 這是一個…

架構圖所在位置 Prometheus Web UI 如何在Rancher裡面查看Web UI​ 將Web UI轉到自己的電腦查看​ kubectl -n cattle-monitoring-system port-forward prometheus-rancher-monitoring-prometheus-0 9090:9090 Web UI是普羅米修斯內建附帶的狀態查看頁面，可以從這邊來看現在普羅米修斯所使用的config或者endpoint的設定 Grafana Grafana完整的支持PromQL，並且提供自動補完功能，非常方便 安裝 sudo apt-get install -y apt-transport-https sudo apt-get install -y software-properties-common wget sudo wget -q -O /usr/share/keyrings/grafana.key https://apt.grafana.com/gpg.key 添加此存儲庫以獲得穩定版本： echo “deb [signed-by=/usr/share/keyrings/grafana.key]…

當我們在看使用Prometheus-operator產生出來的yaml檔案時，會發現裡面用了許多的source_labels標籤，這個是讓operator可以進一步處理資料標籤的方式(如增/刪要送出的資料、端點) relabel_config ​ Endpoint 的值是由 __scheme__ + __address__ + __metrics_path__ 所組成​ 添加新標籤​ 更新現有標籤​ 重寫現有標籤​ 更新指標名稱​ 刪除不需要的標籤​ 刪除不需要的指標​ 在特定條件下刪除指標​ 修改標籤名稱​ 從多個現有標籤構建標籤 更多教學 請見: [Prometheus] Service Discovery & Relabel https://godleon.github.io/blog/Prometheus/Prometheus-Relabel/

先決條件 需要一個具有管理員權限的 Kubernetes 集群。 安裝prometheus-operator 安裝prometheus-operator的自定義資源定義 (CRD) 以及運營商本身所需的 RBAC 資源。 運行以下命令以安裝 CRD 並將 Operator 部署到default命名空間中： 可以使用以下命令檢查是否完成： 佈署範例 這邊是使用OpenShift的yaml去設定相關佈署資訊，更多請見: https://docs.openshift.com/container-platform/4.11/rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.html 部署一個簡單的Pod，其中包含 3 個image，用於偵聽端口並公開指標8080 apiVersion: apps/v1 kind: Deployment metadata: name: example-app spec: replicas: 3 selector: matchLabels: app: example-app template: metadata: labels: app:…

Prometheus Operator​介紹 官方網站: https://prometheus-operator.dev/ Prometheus Operator 提供Kubernetes原生部署和管理Prometheus及相關監控組件。該項目的目的是為 Kubernetes 集群簡化和自動化基於 Prometheus 的監控堆棧的配置。 Prometheus算子包括但不限於以下特性： Kubernetes 自定義資源：使用 Kubernetes 自定義資源部署和管理 Prometheus、Alertmanager 及相關組件。 簡化的部署配置：配置 Prometheus 的基礎知識，例如版本、持久性、保留策略和本地 Kubernetes 資源的副本。 Prometheus Target Configuration：根據熟悉的Kubernetes標籤查詢，自動生成監控目標配置；無需學習普羅米修斯特定的配置語言。 Prometheus Operator優點​ 下面是一個最原始的普羅米修斯的設定範例，若是這樣設定，每一個監控目標都需要手動設定，當Pod自動增加/減少時，會需要有人幫忙更改監控對象，所以Prometheus Operator就出現了。 主要功能是去做Services Discovery，例如我們可以用Deployment去管理Pod的產生，用Service去管理Pod之間的互連，而Operator可以透過Service Monitor去發現需要監控的Service，並且可以隨著Pod的增減動態改變。​ Prometheus Operator裡面有一個叫做prometheus-config-reloader的，可以透過ServiceMonitor產生新的prometheus.yml Prometheus Operator能做什麼​ 要了解Prometheus Operator能做什麼，其實就是要了解Prometheus Operator為我們提供了哪些自定義的Kubernetes資源，列出了Prometheus…

資料提供端​在架構圖的哪邊呢 資料提供端的資料長怎樣呢 Counter: 代表一個單調遞增的計數器​ Gauge: 表示可以任意上下的單個數值​ Histogram:直方圖對觀察結果進行採樣（通常是請求持續時間或響應大小等），並將它們計入可配置的存儲桶中。它還提供所有觀察值的總和。​ Summary: 與histogram類似，摘要對觀察結果進行採樣（通常是請求持續時間和響應大小等）。雖然它還提供了觀察總數和所有觀察值的總和，但它計算了滑動時間窗口上的可配置分位數。 查看現有的資料提供端提供了那些資訊 打開Prometheus面板的Targets ​ 選擇要查看的目標的endpoint連結，除了node-exporter外，都會需要在k8s的內網去讀取資料，以json-exporter來說，可在namespace內部使用下面指令查看:​ 但是同時我們也會發現有許多的網址是無法連上的，因為部分的exporter若是有需要使用密鑰​ ​ 取得pod-exporter所提供的資料​ ​rancher-monitoring-kubelet可以取得在所有node裡面的Pods的運行狀態，但是在k8s取得Pods的狀態需要認證，因此需要在yaml裡面設定所需要的Secrets，指令如下: 更多資訊請見:Accessing the Kubernetes API from a Pod 了解資料提供端的樣子的重要性​ 可了解要怎麼在Grafana搜尋目標資料，並了解有哪些資料是可以取得的 上面的資料可用以下的PromQL來撈出，sum代表所有串流的數字加總，並以pod label做資料加總分組的依據。 因此了解有哪些資料，才能夠使用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…