上一篇【第74篇】Operator模式——讓K8s學會“自動駕駛“把DBA的活也干了下一篇【第76篇】EFK/PLG——K8s日志收集方案全對比摘要前面的文章我們讓集群能跑、能調度、能自愈。但有個扎心的問題它現在到底健康嗎Pod悄悄OOM了、節點CPU跑滿了、某個接口P99漲到5秒——如果沒有監控你全都不知道直到用戶投訴。Prometheus是K8s監控的事實標準。它用Pull模式定時抓各個組件的/metrics端點自帶時序數據庫TSDB配Grafana出炫酷大盤、AlertManager發告警。這篇文章講清Prometheus架構、核心概念以及一套生產推薦的監控組件全家桶。一、為什么是Prometheus1.1 Pull模式【Prometheus 的工作方式——主動去要】 傳統監控(如Zabbix)是Push: 被監控對象主動發數據給中心 → 中心被動收 Prometheus是Pull: Prometheus 定時(如15s)主動HTTP GET 各個目標的 /metrics 端點 → 抓取指標存入TSDB 為什么Pull更適合K8s? ? Pod頻繁創建銷毀Pull自動發現新目標(Service Discovery) ? 目標掛了 → 抓取失敗 → 自然知道(不用它主動報) ? 防火墻友好(只出不容)要點Prometheus的Pull模式特別契合K8s的動態性——它內置Service Discovery能從API Server自動發現現在有哪些Pod/Service要監控Pod沒了抓取自然失敗。配合TSDB時序數據庫為指標優化高效存海量時間序列數據。二、Prometheus架構2.1 組件全景【Prometheus 生態組件】 ┌──────────────────────────────────────────────┐ │ Prometheus Server │ │ ? Retrival: 抓取/發現目標 │ │ ? TSDB: 存時序數據(本地磁盤) │ │ ? HTTP Server: 提供查詢(PromQL) │ └──────────────────┬───────────────────────────┘ │ 抓指標 ┌────────────┼────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │Exporter │ │App本身 │ │Node │ │(redis等)│ │/metrics │ │Exporter │ └─────────┘ └─────────┘ └─────────┘ ┌──────────────────────────────────────────────┐ │ AlertManager │ │ ? 接收Prometheus的告警 │ │ ? 去重/分組/靜默 │ │ ? 發到 郵件/Slack/釘釘/Webhook │ └──────────────────────────────────────────────┘ ▲ 告警規則觸發 │ ┌──────────────────────────────────────────────┐ │ Grafana │ │ ? 連Prometheus查數據 │ │ ? 炫酷可視化大盤 │ └──────────────────────────────────────────────┘2.2 核心概念【Prometheus 三個核心概念】 metric (指標): 一個被測量的量 如: cpu_usage, http_requests_total, pod_restarts 帶label區分維度: http_requests_total{methodGET,path/api} job (任務): 一組同類的抓取目標 如: jobkubernetes-pods instance (實例): 一個具體的抓取目標(一個Pod/一個Node) 如: instance10.244.1.5:8080三、K8s監控全家桶3.1 要監控什么【K8s 監控的四個層次 對應Exporter】 1. 主機層(節點): Node Exporter → CPU/內存/磁盤/網絡/load 2. K8s組件層: 組件自帶metrics → API Server / kubelet / etcd / scheduler → 通過kube-apiserver的/metrics抓取 3. K8s資源層: Kube-State-Metrics (KSM) → Deployment副本數、Pod狀態、PVC狀態 → 不是運行時指標而是對象狀態(第060/062篇的資源) 4. 應用層: 應用自己暴露/metrics → 用client_golang/client_java埋點 → 或需要Metrics Server(Pod CPU/內存, 給HPA用, 第025篇) 一句話: 節點用Node Exporter資源狀態用KSM 組件用自帶metrics應用自己埋點組件監控內容給誰用Node Exporter節點資源運維大盤Kube-State-MetricsK8s對象狀態告警/大盤Metrics ServerPod CPU/內存HPAcAdvisor容器指標內置kubelet應用/metrics業務指標開發大盤四、Prometheus Operator4.1 用Operator管監控手動部署Prometheus要寫一堆Deployment/ConfigMap/Service還很脆。Prometheus OperatorCoreOS出品現CNCF用CRD把這些封裝了# 一條規則定義抓取目標(ServiceMonitor是CRD)apiVersion:monitoring.coreos.com/v1kind:ServiceMonitormetadata:name:my-app-monitorspec:selector:matchLabels:app:my-app# 匹配帶這個label的Serviceendpoints:-port:web# 抓這個端口的/metricsinterval:15s---# 一條規則定義告警apiVersion:monitoring.coreos.com/v1kind:PrometheusRulemetadata:name:pod-alertsspec:groups:-name:pod.rulesrules:-alert:PodCrashLoopingexpr:rate(kube_pod_container_status_restarts_total[5m])0for:2mlabels:severity:warningannotations:summary:Pod {{ $labels.pod }} 在重啟# 用Helm一鍵裝整套(kube-prometheus-stack)helm repoaddprometheus-community https://prometheus-community.github.io/helm-charts helminstallkps prometheus-community/kube-prometheus-stack-nmonitoring# 包含: Prometheus AlertManager Grafana NodeExporter KSM# 開箱即用還帶一堆預置Dashboard!要點Prometheus Operator把監控基礎設施也變成了K8s原生資源——ServiceMonitor聲明抓誰、PrometheusRule聲明告警啥。配合kube-prometheus-stack這個Helm chart一條命令裝好全套監控棧還帶預置Grafana大盤省去大量手工配置。這就是OperatorHelm配合的典范第073/074篇。五、PromQL速覽# 查Pod CPU使用率rate(container_cpu_usage_seconds_total[5m])# 查HTTP請求QPSsum(rate(http_requests_total[5m]))by(path)# 查節點內存使用率1-(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)# 查重啟次數多的Podkube_pod_container_status_restarts_total5# 這些查詢可以直接在Grafana畫成圖或做成告警規則六、告警示例# 節點CPU高告警-alert:NodeCPUHighexpr:(1-avg(rate(node_cpu_seconds_total{modeidle}[5m])))0.85for:5mannotations:summary:節點 {{ $labels.instance }} CPU超85%持續5分鐘# AlertManager會發給: 釘釘/Slack/郵件/Webhook本篇小結Prometheus是K8s監控事實標準Pull模式主動抓/metrics、自帶TSDB、Service Discovery自動適配動態Pod。架構上Prometheus Server抓數據AlertManager發告警Grafana做可視化。K8s監控分四層節點用Node Exporter、K8s對象狀態用Kube-State-Metrics、組件用自帶metrics、應用自己埋點Pod級CPU/內存靠Metrics Server供HPA。Prometheus Operator把監控也K8s原生化ServiceMonitor/PrometheusRule配合kube-prometheus-stack Helm chart開箱即用。下篇講日志——和監控并稱可觀測性雙璧的EFK/PLG。上一篇【第74篇】Operator模式——讓K8s學會“自動駕駛“把DBA的活也干了下一篇【第76篇】EFK/PLG——K8s日志收集方案全對比 【Kubernetes從入門到精通】第75篇：Prometheus+Grafana——K8s監控體系搭建完全指南，讓集群“看得見“
上一篇【第74篇】Operator模式——讓K8s學會“自動駕駛“把DBA的活也干了下一篇【第76篇】EFK/PLG——K8s日志收集方案全對比摘要前面的文章我們讓集群能跑、能調度、能自愈。但有個扎心的問題它現在到底健康嗎Pod悄悄OOM了、節點CPU跑滿了、某個接口P99漲到5秒——如果沒有監控你全都不知道直到用戶投訴。Prometheus是K8s監控的事實標準。它用Pull模式定時抓各個組件的/metrics端點自帶時序數據庫TSDB配Grafana出炫酷大盤、AlertManager發告警。這篇文章講清Prometheus架構、核心概念以及一套生產推薦的監控組件全家桶。一、為什么是Prometheus1.1 Pull模式【Prometheus 的工作方式——主動去要】 傳統監控(如Zabbix)是Push: 被監控對象主動發數據給中心 → 中心被動收 Prometheus是Pull: Prometheus 定時(如15s)主動HTTP GET 各個目標的 /metrics 端點 → 抓取指標存入TSDB 為什么Pull更適合K8s? ? Pod頻繁創建銷毀Pull自動發現新目標(Service Discovery) ? 目標掛了 → 抓取失敗 → 自然知道(不用它主動報) ? 防火墻友好(只出不容)要點Prometheus的Pull模式特別契合K8s的動態性——它內置Service Discovery能從API Server自動發現現在有哪些Pod/Service要監控Pod沒了抓取自然失敗。配合TSDB時序數據庫為指標優化高效存海量時間序列數據。二、Prometheus架構2.1 組件全景【Prometheus 生態組件】 ┌──────────────────────────────────────────────┐ │ Prometheus Server │ │ ? Retrival: 抓取/發現目標 │ │ ? TSDB: 存時序數據(本地磁盤) │ │ ? HTTP Server: 提供查詢(PromQL) │ └──────────────────┬───────────────────────────┘ │ 抓指標 ┌────────────┼────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │Exporter │ │App本身 │ │Node │ │(redis等)│ │/metrics │ │Exporter │ └─────────┘ └─────────┘ └─────────┘ ┌──────────────────────────────────────────────┐ │ AlertManager │ │ ? 接收Prometheus的告警 │ │ ? 去重/分組/靜默 │ │ ? 發到 郵件/Slack/釘釘/Webhook │ └──────────────────────────────────────────────┘ ▲ 告警規則觸發 │ ┌──────────────────────────────────────────────┐ │ Grafana │ │ ? 連Prometheus查數據 │ │ ? 炫酷可視化大盤 │ └──────────────────────────────────────────────┘2.2 核心概念【Prometheus 三個核心概念】 metric (指標): 一個被測量的量 如: cpu_usage, http_requests_total, pod_restarts 帶label區分維度: http_requests_total{methodGET,path/api} job (任務): 一組同類的抓取目標 如: jobkubernetes-pods instance (實例): 一個具體的抓取目標(一個Pod/一個Node) 如: instance10.244.1.5:8080三、K8s監控全家桶3.1 要監控什么【K8s 監控的四個層次 對應Exporter】 1. 主機層(節點): Node Exporter → CPU/內存/磁盤/網絡/load 2. K8s組件層: 組件自帶metrics → API Server / kubelet / etcd / scheduler → 通過kube-apiserver的/metrics抓取 3. K8s資源層: Kube-State-Metrics (KSM) → Deployment副本數、Pod狀態、PVC狀態 → 不是運行時指標而是對象狀態(第060/062篇的資源) 4. 應用層: 應用自己暴露/metrics → 用client_golang/client_java埋點 → 或需要Metrics Server(Pod CPU/內存, 給HPA用, 第025篇) 一句話: 節點用Node Exporter資源狀態用KSM 組件用自帶metrics應用自己埋點組件監控內容給誰用Node Exporter節點資源運維大盤Kube-State-MetricsK8s對象狀態告警/大盤Metrics ServerPod CPU/內存HPAcAdvisor容器指標內置kubelet應用/metrics業務指標開發大盤四、Prometheus Operator4.1 用Operator管監控手動部署Prometheus要寫一堆Deployment/ConfigMap/Service還很脆。Prometheus OperatorCoreOS出品現CNCF用CRD把這些封裝了# 一條規則定義抓取目標(ServiceMonitor是CRD)apiVersion:monitoring.coreos.com/v1kind:ServiceMonitormetadata:name:my-app-monitorspec:selector:matchLabels:app:my-app# 匹配帶這個label的Serviceendpoints:-port:web# 抓這個端口的/metricsinterval:15s---# 一條規則定義告警apiVersion:monitoring.coreos.com/v1kind:PrometheusRulemetadata:name:pod-alertsspec:groups:-name:pod.rulesrules:-alert:PodCrashLoopingexpr:rate(kube_pod_container_status_restarts_total[5m])0for:2mlabels:severity:warningannotations:summary:Pod {{ $labels.pod }} 在重啟# 用Helm一鍵裝整套(kube-prometheus-stack)helm repoaddprometheus-community https://prometheus-community.github.io/helm-charts helminstallkps prometheus-community/kube-prometheus-stack-nmonitoring# 包含: Prometheus AlertManager Grafana NodeExporter KSM# 開箱即用還帶一堆預置Dashboard!要點Prometheus Operator把監控基礎設施也變成了K8s原生資源——ServiceMonitor聲明抓誰、PrometheusRule聲明告警啥。配合kube-prometheus-stack這個Helm chart一條命令裝好全套監控棧還帶預置Grafana大盤省去大量手工配置。這就是OperatorHelm配合的典范第073/074篇。五、PromQL速覽# 查Pod CPU使用率rate(container_cpu_usage_seconds_total[5m])# 查HTTP請求QPSsum(rate(http_requests_total[5m]))by(path)# 查節點內存使用率1-(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)# 查重啟次數多的Podkube_pod_container_status_restarts_total5# 這些查詢可以直接在Grafana畫成圖或做成告警規則六、告警示例# 節點CPU高告警-alert:NodeCPUHighexpr:(1-avg(rate(node_cpu_seconds_total{modeidle}[5m])))0.85for:5mannotations:summary:節點 {{ $labels.instance }} CPU超85%持續5分鐘# AlertManager會發給: 釘釘/Slack/郵件/Webhook本篇小結Prometheus是K8s監控事實標準Pull模式主動抓/metrics、自帶TSDB、Service Discovery自動適配動態Pod。架構上Prometheus Server抓數據AlertManager發告警Grafana做可視化。K8s監控分四層節點用Node Exporter、K8s對象狀態用Kube-State-Metrics、組件用自帶metrics、應用自己埋點Pod級CPU/內存靠Metrics Server供HPA。Prometheus Operator把監控也K8s原生化ServiceMonitor/PrometheusRule配合kube-prometheus-stack Helm chart開箱即用。下篇講日志——和監控并稱可觀測性雙璧的EFK/PLG。上一篇【第74篇】Operator模式——讓K8s學會“自動駕駛“把DBA的活也干了下一篇【第76篇】EFK/PLG——K8s日志收集方案全對比