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