引言

為什么前面用的好好的 Kube-prometheus-stack 好好的，不用了，要使用 Prometheus-Operator 呢？

首先，先介紹下我們的基本環境，我現在使用的集群是我們公司的 Test 環境的集群，托管在阿里云里面的 ACK Serverless 集群，對于業界開箱即用的一些監控生態工具，是很難做到全方面監控的。所以，我這邊想要去做一套針對 ACK Serverless 集群的監控方案，但是這個肯定需要一些時間來好好研究的。

其次，我們前面講解到了我們的自動化報告生成，生成的報告，里面的數據不是我們想要的。我是用 Kube-Prometheus-stack 的 Chart 包部署的，有的數據不全，因為這個包當時是我們團隊的另外一個人負責的，而且目前這個監控方案后面還會涉及到生產環境。所以，我這邊打算把之前部署的刪除了，準備使用 Prometheus-Operator，重新設計一套監控方案，重新深入貫穿下 Prometheus 的生態。

為什么呢？我們來先詳細認識下 ACK Serverless 集群

ACK Serverless

? ACK Serverless 集群 是一種 "無服務器" 的 Kubernetes 集群，即用戶無需管理底層的節點資源（如 EC2 或 ECS 實例），系統會根據用戶的實際負載動態調度容器到后端資源。

? 用戶只需專注于工作負載的部署和業務邏輯，而不需要手動管理集群中的節點。

架構核心：

? 它基于 阿里云 Elastic Container Instance (ECI)，用以提供容器運行的計算資源。

? 每個 Pod 都會被調度到 ECI 中運行，而不是固定的節點。

主要特點

無需節點管理

? ACK Serverless 集群不需要管理 Kubernetes 節點（如虛擬機或物理機）。

? 用戶不需要擔心節點的擴容、縮容、健康檢查等復雜運維工作。

按需擴展

? Pod 在工作負載增加時動態啟動，直接使用 阿里云 ECI 作為后端資源。

? 當負載減少時，Pod 會被回收，避免資源浪費。

秒級彈性

? Pod 啟動基于 ECI，啟動速度極快（通常幾秒鐘）。

? 非常適合運行短期或突發性的工作負載。

原生 Kubernetes 支持

? 兼容 Kubernetes 生態系統和原生 API。

? 支持 Helm、Kubectl 等 Kubernetes 工具。

高性價比

? 資源按實際使用計費，不使用時不產生費用。

? 無需為空閑節點支付費用。

資源隔離

? 每個 Pod 是獨立運行的，與其他用戶隔離。

? 支持阿里云 VPC 網絡，安全可靠。

核心組件與工作原理

核心組件

ACK Serverless Control Plane：

? 負責管理 Kubernetes API 和調度邏輯。

? 無需用戶手動操作，阿里云托管。

Elastic Container Instance (ECI)：

? 提供 Pod 的計算和存儲資源。

? 動態為每個 Pod 分配資源，按需計費。

Serverless Pod：

? 工作負載直接以 Pod 的形式運行在 ECI 上。

? 支持容器鏡像、存儲卷掛載、網絡配置等功能。

工作原理

1. 用戶創建 Serverless Pod 或通過 Deployment 等資源部署工作負載。

2. ACK Serverless 的調度器會將 Pod 動態分配到 ECI 資源中運行。

3. 如果沒有足夠的資源，系統會自動擴展 ECI 實例。

4. 任務完成后，Pod 會被釋放，資源將被回收。

我們這里還需要學習下 ECI (Elastic Container Instance)

Elastic Container Instance (ECI)

ECI 是阿里云提供的一種按需運行容器的服務，無需管理底層計算資源。ECI 直接運行容器任務，不依賴虛擬機或物理機，用戶只需要關注容器鏡像、運行配置以及資源需求。

簡單來說，ECI 是一種 Serverless 容器運行平臺，它提供了類似虛擬機的運行環境，但用戶不需要關心服務器的管理和運維。

ECI 的核心特點

無服務器

? 無需配置或管理底層的節點（ECS 實例）。

? 容器實例直接運行在阿里云托管的基礎設施上。

按需啟動

? 容器實例在用戶請求時按需啟動，支持秒級啟動。

? 無需提前分配資源，避免閑置成本。

彈性擴展

? 容器實例會根據負載動態擴展（水平擴展或縮容）。

? 適合突發性和高彈性負載需求。

支持原生容器生態

? 完全兼容 OCI（Open Container Initiative）容器鏡像。

? 可以通過 Docker CLI 或 Kubernetes API 部署和管理容器。

與阿里云服務的深度集成

? 支持 VPC（專有網絡）、NAS（網絡存儲）、OSS（對象存儲）等阿里云服務。

? 可以結合云監控、日志服務進行容器狀態和性能監控。

ECI 和 ACK Serverless 的關系

ACK Serverless 是基于 ECI 構建的

? ACK Serverless 集群 使用 ECI 作為其底層計算資源。Serverless Pod 會被調度到 ECI 上運行，而不需要管理任何節點。

? 區別在于：

a.ECI 是單獨運行的容器實例，更類似于“裸容器”。

b.ACK Serverless 提供了 Kubernetes 的調度和管理能力，用戶可以通過 Kubernetes 的 Deployment、Service 等資源來管理工作負載。

使用方式的不同

? 直接使用 ECI：

a.適用于需要直接運行容器任務的場景，如事件驅動的任務、短期批量任務。

b.可以通過 ECI 的 API、CLI 或阿里云控制臺啟動容器。

? 通過 ACK Serverless 使用 ECI：

? 適合需要完整 Kubernetes 管理能力的場景。

? 用戶可以部署復雜的 Kubernetes 工作負載（如 Deployment、StatefulSet）。

? ACK Serverless 集群自動將工作負載映射到 ECI 上運行。

彈性與擴展對比

ECI 和傳統 ECS 的對比

我們再了解下真正要操作的對象：

Virtual Kubelet

圖片

Virtual Kubelet 是一個開源項目，允許 Kubernetes 將其節點擴展到其他服務（如服務器無關的容器實例、邊緣設備等）。 由于這些節點并非實際的物理或虛擬機，傳統的監控方法（如通過 Node Exporter 或直接訪問 Kubelet 的 /metrics 接口）可能不適用。

它并不是一個真正的物理節點或虛擬機，而是一個代理，通常用于將 Kubernetes 節點擴展到其他服務 （如阿里云 ECI、Azure ACI、AWS Fargate）。

虛擬節點并沒有底層的操作系統環境，也無法暴露 /proc 或 /sys 文件系統。

介紹

Prometheus 是一種開源的監控和警報工具，用于收集和記錄應用程序和系統的度量數據。它特別適用于在 Kubernetes 集群中監控容器化應用程序。Kubernetes 集群中通常與 Prometheus 一起使用的組件是 Prometheus Operator 和 Grafana。

以下是在 Kubernetes 中使用 Prometheus 的主要步驟：

? 安裝 Prometheus Operator： Prometheus Operator 是一種 Kubernetes 控制器，用于簡化 Prometheus 的部署和管理。您可以通過在 Kubernetes 中部署 Prometheus Operator 來自動設置和管理 Prometheus 實例。

? 配置 Prometheus 實例： Prometheus Operator 將通過 Kubernetes 的自定義資源定義（CRD）創建和管理 Prometheus 實例。您可以使用 PrometheusRule CRD 定義監控規則，并使用 ServiceMonitor CRD 定義需要監控的目標（例如 Kubernetes 服務）。

? 配置和導入 Dashboard： Grafana 通常與 Prometheus 一起使用，用于可視化監控指標。您可以在 Grafana 中導入 Prometheus 的預定義儀表板或自定義儀表板來查看和分析度量數據。

? 監控應用程序和系統： Prometheus 通過 HTTP 端點從目標應用程序和系統中拉取度量數據。您可以在應用程序中暴露 Prometheus 格式的度量數據，并在 ServiceMonitor 中定義用于監控的目標。

? 警報配置： Prometheus 還支持配置警報規則，以便在達到特定閾值或條件時觸發警報。警報規則可以定義為 PrometheusRule CRD。

常見的幾款監控工具

以下這些工具可以用于在 Kubernetes 集群中實現監控和指標收集，以便于監視集群中的各種資源和應用的性能。

? Heapster： Heapster 是一個 Kubernetes 集群的資源監控工具，用于收集和匯總資源使用情況數據，如 CPU、內存、網絡等。

? Metrics Server： Metrics Server 是 Kubernetes 官方提供的一個輕量級指標收集器，用于提供節點和 Pod 等資源的實時性能指標，可以用于水平自動擴展等。

? Prometheus Operator： Prometheus Operator 是一個 Kubernetes 控制器，用于管理和部署 Prometheus 和相關的監控組件。它可以自動創建和管理 Prometheus 實例、ServiceMonitor 和其他配置。

? kube-prometheus 或 kube-prometheus-stack： 這是一個基于 Prometheus 的 Kubernetes 集群監控解決方案。它包含了一系列組件，用于部署和管理 Prometheus、Alertmanager、Grafana 等，以實現對 Kubernetes 集群和應用的全面監控。

heapster-》metrics-server-》prometheus-operator -》kube-prometheus-》kube-prometheus-stack

相關地址：

prometheus-operator GitHub 地址[1]

kube-prometheus GitHub 地址[2]

kube-prometheus-stack GitHub 地址[3]

這些工具的組合可以幫助您搭建一個完整的監控系統，用于監視 Kubernetes 集群中的資源利用率、應用的性能、服務的可用性等指標。請注意，隨著時間的推移，Kubernetes 社區的工具和技術也可能會有變化和演進，因此在使用這些工具時，建議查閱相關文檔以獲得最新信息和最佳實踐。

1）kube-prometheus 和 kube-prometheus-stack 區別

? "kube-prometheus" 和 "kube-prometheus-stack" 本質上是同一個項目，只是在不同的時間和版本中使用了不同的名稱。"kube-prometheus-stack" 是 "kube-prometheus" 項目的更新版本，它提供了更多的功能、改進和修復。

? 最初，項目被稱為 "kube-prometheus"，但隨著時間的推移，項目團隊對項目進行了大量的改進和擴展，并將其重命名為 "kube-prometheus-stack"，以更好地反映其提供的綜合性監控解決方案。

? "kube-prometheus-stack"（或簡稱 "kube-prometheus"）是一個在 Kubernetes 集群中部署和管理 Prometheus 監控系統以及相關組件的綜合解決方案。它集成了 Prometheus、Grafana、Alertmanager 等一系列組件，還包括預配置的監控規則和儀表盤，以及一鍵部署功能。用戶可以通過部署 "kube-prometheus-stack" 來快速啟動一個全面的 Kubernetes 集群監控系統，無需逐個配置各個組件。

? 總結起來，"kube-prometheus-stack" 是 "kube-prometheus" 項目的更新版本，提供更多的功能和改進，是一個便捷的綜合性監控解決方案，適合在 Kubernetes 環境中快速部署和使用。

2）Prometheus Operator 和 Kube-orometheus 或 Kube-prometheus-stack 對比

"Prometheus Operator" 和 "kube-prometheus"（或 "kube-prometheus-stack"）都是用于在 Kubernetes 集群中部署和管理 Prometheus 監控系統的工具。它們有一些相似之處，但也存在一些區別。以下是它們的主要特點和區別的對比：

Prometheus Operator：

? 核心功能： Prometheus Operator 是一個 Kubernetes 控制器，專門用于管理 Prometheus 和相關組件的配置和部署。它自動創建和管理 Prometheus 實例、ServiceMonitor、Alertmanager、PrometheusRule 等 Kubernetes 資源。

? 聲明式配置： Prometheus Operator 通過自定義資源定義（Custom Resource Definitions，CRDs）來實現聲明式配置。您可以創建 Prometheus、ServiceMonitor 等資源對象來定義監控配置，Operator 會根據這些定義自動創建和維護相關的資源。

? 自動發現： Prometheus Operator 支持自動發現 Kubernetes 中的 Service、Pod、Namespace 等資源，無需手動配置每個監控目標。

? 生態系統整合： Prometheus Operator 集成了 Grafana 和 Alertmanager，并可以輕松與其他監控工具集成。

? 靈活性： Prometheus Operator 允許根據不同的需求和配置選擇性地部署多個 Prometheus 實例，每個實例可以針對特定的監控任務進行配置。

Kube-prometheus 或 Kube-prometheus-stack：

? 綜合解決方案： kube-prometheus（或 kube-prometheus-stack）是一個完整的監控解決方案，集成了 Prometheus、Grafana、Alertmanager 等一系列組件，以及一些預配置的監控規則和儀表盤。

? 快速啟動： kube-prometheus 提供了一鍵式的部署方式，適合快速啟動一個完整的監控系統，無需逐個配置各個組件。

? 預配置規則和儀表盤： kube-prometheus 提供了一些默認的監控規則和 Grafana 儀表盤，可以快速啟用監控功能。

? 集成和擴展： 由于 kube-prometheus 集成了多個組件，您可以使用這個解決方案來快速部署一個全面的監控系統，并且可以根據需要進行定制和擴展。

綜合來看，Prometheus Operator 專注于 Prometheus 和相關資源的管理和自動化配置，而 kube-prometheus 或 kube-prometheus-stack 則是一個更加綜合的解決方案，適合快速啟動一個完整的監控系統，尤其對于剛開始使用 Prometheus 的用戶來說，可以減少配置的復雜性。您可以根據實際需求和情況選擇合適的工具。

Prometheus Operator 的工作原理

Operator 是由 CoreOS 公司開發的，用來擴展 Kubernetes API，特定的應用程序控制器，它用來創建、配置和管理復雜的有狀態應用，如數據庫、緩存和監控系統。Operator 基于 Kubernetes 的資源和控制器概念之上構建，但同時又包含了應用程序特定的一些專業知識，比如創建一個數據庫的Operator，則必須對創建的數據庫的各種運維方式非常了解，創建 Operator 的關鍵是 CRD（自定義資源） 的設計。

CRD 是對 Kubernetes API 的擴展，Kubernetes 中的每個資源都是一個 API 對象的集合，例如我們在YAML文件里定義的那些 spec 都是對 Kubernetes 中的資源對象的定義，所有的自定義資源可以跟 Kubernetes 中內建的資源一樣使用 kubectl 操作。

Operator 是將運維人員對軟件操作的知識給代碼化，同時利用 Kubernetes 強大的抽象來管理大規模的軟件應用。目前 CoreOS 官方提供了幾種 Operator 的實現，其中就包括我們今天的主角：Prometheus Operator，Operator 的核心實現就是基于 Kubernetes 的以下兩個概念：

? 資源： 對象的狀態定義

? 控制器： 觀測、分析和行動，以調節資源的分布

從概念上來講 Operator 就是針對管理特定應用程序的，在 Kubernetes 基本的 Resource 和 Controller 的概念上，以擴展 Kubernetes API 的形式。幫助用戶創建，配置和管理復雜的有狀態應用程序。從而實現特定應用程序的常見操作以及運維自動化。

在 Kubernetes 中我們使用 Deployment、DamenSet，StatefulSet 來管理應用 Workload，使用 Service，Ingress 來管理應用的訪問方式，使用 ConfigMap 和 Secret 來管理應用配置。我們在集群中對這些資源的創建，更新，刪除的動作都會被轉換為事件 (Event)，Kubernetes 的 Controller Manager 負責監聽這些事件并觸發相應的任務來滿足用戶的期望。這種方式我們成為聲明式，用戶只需要關心應用程序的最終狀態，其它的都通過 Kubernetes 來幫助我們完成，通過這種方式可以大大簡化應用的配置管理復雜度。

而除了這些原生的 Resource 資源以外，Kubernetes 還允許用戶添加自己的自定義資源 (Custom Resource)。并且通過實現自定義 Controller 來實現對 Kubernetes 的擴展。 當然我們如果有對應的需求也完全可以自己去實現一個 Operator，接下來我們就來給大家詳細介紹下 Prometheus-Operator 的使用方法。

下面三個yaml文件 很好的表述了，Prometheus 如何關聯選擇 Servicemonitor，Servicemonitor 如何關聯選擇目標 Service。

圖片

為了能讓 Prometheus 監控 k8s 內的應用，Prometheus-Operator 通過配置 Servicemonitor 匹配到由 Service 對象自動填充的 Endpoints，并配置 Prometheus 監控這些 Endpoints 后端的 Pods，ServiceMonitor.Spec 的 Endpoints 部分就是用于配置 Endpoints 的哪些端口將被 Scrape 指標。

Servicemonitor 對象很巧妙，它解耦了“監控的需求”和“需求的實現方”。 Servicemonitor 只需要用到 Label-selector 這種簡單又通用的方式聲明一個 “監控需求”，也就是哪些 Endpoints 需要搜集，怎么收集就行了。讓用戶只關心需求，這是一個非常好的關注點分離。當然 Servicemonitor 最后還是會被 Operator轉化為原始的復 雜的 Scrape config,但這個復雜度已經完全被 Operator 屏蔽了。

Prometheus告警對接流程

下圖很好的展現了Prometheus在配置報警時需要操作哪些資源，及各資源起到的作用

圖片

? 首先通過配置 Servicemonitor/Podmonitor 來獲取應用的監控指標；

? Prometheus.spec.alerting 字段會匹配 Alertmanager 中的配置，匹配到 Alertmanager 實例

? 然后通過 Prometheusrule 對監控到的指標配置報警規則；

? 最后配置告警接收器，配置 Alertmanager config 來配置如何處理告警，包括如何接收、路由、抑制和發送警報等；

Prometheus Operator 架構

圖片

上圖是 Prometheus-Operator 官方提供的架構圖，其中 Operator 是最核心的部分，作為一個控制器，他會去創建 Prometheus、ServiceMonitor、AlertManager 以及 PrometheusRule 4個CRD 資源對象，然后會一直監控并維持這4個資源對象的狀態。

其中創建的 Prometheus 這種資源對象就是作為 Prometheus Server 存在，而 ServiceMonitor 就是 Exporter 的各種抽象，Exporter 前面我們已經學習了，是用來提供專門提供 Metrics 數據接口的工具，Prometheus 就是通過 ServiceMonitor 提供的 Metrics 數據接口去 Pull 數據的，當然 AlertManager 這種資源對象就是對應的 AlertManager 的抽象，而 PrometheusRule 是用來被 Prometheus 實例使用的報警規則文件。

這樣我們要在集群中監控什么數據，就變成了直接去操作 Kubernetes 集群的資源對象了，是不是方便很多了。上圖中的 Service 和 ServiceMonitor 都是 Kubernetes 的資源，一個 ServiceMonitor 可以通過 LabelSelector 的方式去匹配一類 Service，Prometheus 也可以通過 LabelSelector 去匹配多個 ServiceMonitor。

在最新版本的 Operator 中提供了一下幾個 CRD 資源對象：

? Prometheus

? Alertmanager

? ServiceMonitor

? PodMonitor

? Probe

? ThanosRuler

? PrometheusRule

? AlertmanagerConfig

? PrometheusAgent

? ScrapeConfig

Prometheus

該 CRD 聲明定義了 Prometheus 期望在 Kubernetes 集群中運行的配置，提供了配置選項來配置副本、持久化、報警實例等。

對于每個 Prometheus CRD 資源，Operator 都會以 StatefulSet 形式在相同的命名空間下部署對應配置的資源，Prometheus Pod 的配置是通過一個包含 Prometheus 配置的名為 Prometheus-name 的 Secret 對象聲明掛載的。

該 CRD 根據標簽選擇來指定部署的 Prometheus 實例應該覆蓋哪些 ServiceMonitors，然后 Operator 會根據包含的 ServiceMonitors 生成配置，并在包含配置的 Secret 中進行更新。

如果未提供對 ServiceMonitor 的選擇，則 Operator 會將 Secret 的管理留給用戶，這樣就可以提供自定義配置，同時還能享受 Operator 管理 Operator 的設置能力。

Alertmanager

該 CRD 定義了在 Kubernetes 集群中運行的 Alertmanager 的配置，同樣提供了多種配置，包括持久化存儲。

對于每個 Alertmanager 資源，Operator 都會在相同的命名空間中部署一個對應配置的 StatefulSet，Alertmanager Pods 被配置為包含一個名為 Alertmanager-name 的 Secret，該 Secret 以 alertmanager.yaml 為 key 的方式保存使用的配置文件。

當有兩個或更多配置的副本時，Operator 會在高可用模式下運行 Alertmanager 實例。

ThanosRuler

該 CRD 定義了一個 Thanos Ruler 組件的配置，以方便在 Kubernetes 集群中運行。通過 Thanos Ruler，可以跨多個 Prometheus 實例處理記錄和警報規則。

一個 ThanosRuler 實例至少需要一個 queryEndpoint，它指向 Thanos Queriers 或 Prometheus 實例的位置。queryEndpoints 用于配置 Thanos 運行時的 --query 參數，更多信息也可以在 Thanos 文檔中找到。

ServiceMonitor

該 CRD 定義了如何監控一組動態的服務，使用標簽選擇來定義哪些 Service 被選擇進行監控。這可以讓團隊制定一個如何暴露監控指標的規范，然后按照這些規范自動發現新的服務，而無需重新配置。

為了讓 Prometheus 監控 Kubernetes 內的任何應用，需要存在一個 Endpoints 對象，Endpoints 對象本質上是 IP 地址的列表，通常 Endpoints 對象是由 Service 對象來自動填充的，Service 對象通過標簽選擇器匹配 Pod，并將其添加到 Endpoints 對象中。一個 Service 可以暴露一個或多個端口，這些端口由多個 Endpoints 列表支持，這些端點一般情況下都是指向一個 Pod。

Prometheus Operator 引入的這個 ServiceMonitor 對象就會發現這些 Endpoints 對象，并配置 Prometheus 監控這些 Pod。ServiceMonitorSpec 的 endpoints 部分就是用于配置這些 Endpoints 的哪些端口將被 scrape 指標的。

注意：endpoints（小寫）是 ServiceMonitor CRD 中的字段，而 Endpoints（大寫）是 Kubernetes 的一種對象。

ServiceMonitors 以及被發現的目標都可以來自任何命名空間，這對于允許跨命名空間監控的場景非常重要。使用 PrometheusSpec 的 ServiceMonitorNamespaceSelector，可以限制各自的 Prometheus 服務器選擇的 ServiceMonitors 的命名空間。使用 ServiceMonitorSpec 的 namespaceSelector，可以限制 Endpoints 對象被允許從哪些命名空間中發現，要在所有命名空間中發現目標，namespaceSelector 必須為空：

spec:
  namespaceSelector:
    any: true
PodMonitor

該 CRD 用于定義如何監控一組動態 pods，使用標簽選擇來定義哪些 pods 被選擇進行監控。同樣團隊中可以制定一些規范來暴露監控的指標。

Pod 是一個或多個容器的集合，可以在一些端口上暴露 Prometheus 指標。

由 Prometheus Operator 引入的 PodMonitor 對象會發現這些 Pod，并為 Prometheus 服務器生成相關配置，以便監控它們。

PodMonitorSpec 中的 PodMetricsEndpoints 部分，用于配置 Pod 的哪些端口將被 scrape 指標，以及使用哪些參數。

PodMonitors 和發現的目標可以來自任何命名空間，這同樣對于允許跨命名空間的監控用例是很重要的。使用 PodMonitorSpec 的 namespaceSelector，可以限制 Pod 被允許發現的命名空間，要在所有命名空間中發現目標，namespaceSelector 必須為空：

spec:
  namespaceSelector:
    any: true

PodMonitor 和 ServieMonitor 最大的區別就是不需要有對應的 Service。

Probe

該 CRD 用于定義如何監控一組 Ingress 和靜態目標。除了 target 之外，Probe 對象還需要一個 prober，它是監控的目標并為 Prometheus 提供指標的服務。例如可以通過使用 blackbox-exporter 來提供這個服務。

PrometheusRule

用于配置 Prometheus 的 Rule 規則文件，包括 recording rules 和 alerting，可以自動被 Prometheus 加載。

AlertmanagerConfig

在以前的版本中要配置 Alertmanager 都是通過 Configmap 來完成的，在 v0.43 版本后新增該 CRD，可以將 Alertmanager 的配置分割成不同的子對象進行配置，允許將報警路由到自定義 Receiver 上，并配置抑制規則。

AlertmanagerConfig 可以在命名空間級別上定義，為 Alertmanager 提供一個聚合的配置。這里提供了一個如何使用它的例子。不過需要注意這個 CRD 還不穩定。

這樣我們要在集群中監控什么數據，就變成了直接去操作 Kubernetes 集群的資源對象了，是這樣比之前手動的方式就方便很多了。

PrometheusSgents

是一種新的 CRD，主要用于定義 Prometheus Agent 實例。

Prometheus Agent 是一種輕量化的 Prometheus 模式，適用于 遠程寫入 的場景。

它的主要作用是采集監控數據并將其轉發到遠程存儲（例如 Thanos 或 Cortex），而不需要存儲數據或提供查詢功能。

適用場景

• ? 僅需要采集監控數據并將其轉發到遠程存儲，不需要存儲和查詢功能。
• ? 適合邊緣監控或分布式監控場景，例如 IoT、邊緣計算。
• ? 資源受限的環境中更適合使用 Prometheus Agent。

ScrapeConfig

用于動態配置 Prometheus Scrape Configuration（Prometheus 的抓取配置）。

它允許用戶通過聲明式方式為 Prometheus 添加或修改抓取配置 (scrape_configs)，而無需直接編輯 Prometheus 的全局配置文件（prometheus.yaml）。

主要目的是提供更靈活的抓取配置選項，尤其是用于復雜場景中自定義抓取目標或特殊的認證需求。

在默認情況下，Prometheus Operator 是通過 ServiceMonitor 或 PodMonitor 來定義抓取目標的。

然而，這種方式有一定限制，無法滿足一些復雜場景，比如：

• ? 自定義抓取目標（不通過 Kubernetes 服務發現）。
• ? 針對特定的認證方式配置（如 BasicAuth、BearerToken、OAuth）。
• ? 自定義 metrics_path 或抓取規則。

為了解決這些問題，Prometheus Operator 引入了 ScrapeConfig CRD。

主要功能

自定義抓取目標

• ? 可以定義任意非 Kubernetes 的抓取目標，例如外部的 HTTP 服務、API 網關等。

靈活的認證方式

• ? 支持 BasicAuth、TLS 認證、Bearer Token、OAuth 等多種認證方式。

特定的抓取設置

• ? 自定義 metrics_path、scheme（HTTP/HTTPS）、interval（抓取間隔）等參數。

與 ServiceMonitor 和 PodMonitor 的區別

• ? ServiceMonitor 和 PodMonitor 更適合 Kubernetes 內部資源的監控。
• ? ScrapeConfig 用于外部資源或高度定制化的抓取需求。

簡言之，Prometheus Operator 能夠幫助用戶自動化的創建以及管理 Prometheus Server 以及其相應的配置。

結語

這邊我們算是把整個 Prometheus 必要的概念和原理熟悉后，我們接下來就該實操了，下面的也是一個大工程，需要一些時間去把這個貫穿和實現。

引用鏈接

[1] prometheus-operator GitHub 地址: https://github.com/prometheus-operator/prometheus-operator[2] kube-prometheus GitHub 地址: https://github.com/prometheus-operator/kube-prometheus[3] kube-prometheus-stack GitHub 地址: https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack