上一篇【第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日志收集方案全对比