04 Prometheus + Grafana 监控告警体系搭建全记录

04 Prometheus Grafana 监控告警体系搭建全记录摘要在 K3s 集群上用 DaemonSet 部署 Node Exporter cAdvisor 采集 4 台服务器指标Prometheus 负责存储与告警规则Grafana 自动配置数据源并导入自建看板实现 CPU/内存/磁盘三条告警规则与真实告警触发验证。一、背景与目标集群搭好了、应用上线了但运维心里没底CPU 什么时候被打满磁盘还剩多少容器是否异常——没有监控的集群等于裸奔。本文目标搭建 Prometheus采集与告警引擎 Grafana可视化看板 Node Exporter主机指标 cAdvisor容器指标四件套覆盖全部 4 台机器并让告警真的响过一次。二、环境说明组件版本/说明端口Prometheusv2.53.0K8s Deployment PVC 10Gi9090 → NodePort 30900Grafana11.2.0K8s Deployment PVC 2Gi3000 → NodePort 30300Node Exporterv1.8.1DaemonSet每节点 1 个9100cAdvisorv0.49.1DaemonSet每节点 1 个8080监控目标集群 3 节点 监控节点 0004docker 方式-告警规则CPU 85% / 内存 85% / 磁盘 85%持续 5m-三、架构设计采集层Node Exporter0001:9100PrometheusDeploymentPVC静态采集 8 个 targetNode Exporter0002:9100Node Exporter0003:9100Node Exporter0004:9100 dockercAdvisor 0001:8080cAdvisor 0002:8080cAdvisor 0003:8080cAdvisor 0004:8080 dockerGrafanaNodePort 30300告警规则CPU/内存/磁盘浏览器设计要点Node Exporter / cAdvisor 用 DaemonSet自动在每个节点跑一个副本天然覆盖集群全部节点。hostNetwork 模式Exporter 直接绑宿主端口Prometheus 用节点 IP 静态配置即可简单可靠。node4 不在集群内用 docker run 方式补装两个 Exporter同样纳入采集实现4 台全监控。cAdvisor 对接 containerdK3s 内置 containerd 的 socket 在/run/k3s/containerd/containerd.sockcAdvisor 挂载后加--containerd参数。四、实操步骤4.1 Prometheus 配置ConfigMap 挂载global:scrape_interval:15sevaluation_interval:15srule_files:-/etc/prometheus/rules/*.ymlscrape_configs:-job_name:node-exporterstatic_configs:-targets:-192.168.0.16:9100# 3 集群节点-192.168.0.77:9100-192.168.0.33:9100-192.168.0.12:9100# node4 docker 方式-job_name:cadvisorstatic_configs:-targets:[同 4 台:8080]4.2 告警规则3 条groups:-name:loomy-node-alertsrules:-alert:NodeHighCPUexpr:100-(avg by (instance) (rate(node_cpu_seconds_total{modeidle}[2m])) * 100)85for:5mlabels:{severity:warning}annotations:summary:节点 CPU 使用率过高 ({{ $labels.instance }})-alert:NodeHighMemoryexpr:(1-(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 10085for:5m-alert:NodeHighDiskexpr:(1-(node_filesystem_avail_bytes{mountpoint/}/ node_filesystem_size_bytes{mountpoint/})) * 10085for:5m术语解释PromQL 里的rate(...[2m])表示取最近 2 分钟的速率for: 5m表示持续 5 分钟才告警避免抖动误报。4.3 cAdvisor DaemonSet对接 K3s containerdcontainers:-name:cadvisorimage:gcr.m.daocloud.io/cadvisor/cadvisor:v0.49.1args:---housekeeping_interval10s---containerd/run/k3s/containerd/containerd.sock---containerd-runtime-endpoint/run/k3s/containerd/containerd.socksecurityContext:{privileged:true}# 需要特权访问 cgroup/sysfsvolumeMounts:-{name:var-run,mountPath:/var/run}-{name:sys,mountPath:/sys,readOnly:true}-{name:containerd,mountPath:/var/lib/containerd,readOnly:true}4.4 Grafana 自动配置Provisioning不用手工点界面把数据源和看板以文件方式塞给 Grafanaprovisioning即预置配置机制Pod 启动即完成接入# datasources.yamlapiVersion:1datasources:-name:Prometheusuid:prometheustype:prometheusurl:http://prometheus.monitoring:9090isDefault:true# dashboards.yaml - 指向 /var/lib/grafana/dashboards# 自建看板 JSON(uidloomy-node): CPU/内存/磁盘/网络/容器 CPU 5 张曲线 4 张统计卡同时开启 Grafana 匿名访问auth.anonymous.enabled true方便演示与截图。4.5 部署kubectl apply-fmonitoring-stack.yaml# namespace/DS/CM/PVC/Deploy/SVC 一次到位# node4 补装(docker 方式)dockerrun-d--namenode-exporter--nethost--pidhost-v/:/host:ro,rslave prom/node-exporter:v1.8.1--path.rootfs/hostdockerrun-d--namecadvisor--nethost--privileged\-v/:/rootfs:ro-v/var/run:/var/run:ro-v/sys:/sys:ro\-v/var/lib/docker/:/var/lib/docker:ro-v/dev/disk/:/dev/disk:ro\gcr.m.daocloud.io/cadvisor/cadvisor:v0.49.1--housekeeping_interval10s五、效果验证5.1 Prometheus Targets采集目标健康TARGET node-exporter 192.168.0.16:9100 up TARGET node-exporter 192.168.0.77:9100 up TARGET node-exporter 192.168.0.33:9100 up TARGET node-exporter 192.168.0.12:9100 up TARGET cadvisor 192.168.0.16:8080 up TARGET cadvisor 192.168.0.77:8080 up TARGET cadvisor 192.168.0.33:8080 up TARGET cadvisor 192.168.0.12:8080 up5.2 测试告警触发临时把 CPU 阈值降到 1%# 修改 ConfigMap 规则 - 重启 Prometheus - 等待评估 ALERT NodeHighCPU firing instance192.168.0.16:9100 # 触发成功, 然后恢复正式阈值(85%), 确认 3 条规则重新加载 RULE NodeHighCPU stateinactive RULE NodeHighMemory stateinactive RULE NodeHighDisk stateinactive5.3 GrafanaGrafana 健康检查GET /api/health→ HTTP 200数据源 Prometheus 自动接入uidprometheus自建看板Loomy 节点监控看板已导入展示 CPU/内存/磁盘/网络实时曲线截图见 docs/images/六、踩坑与解决方案坑 1cAdvisor 的 gcr.io 镜像在国内拉不到现象Pod 状态ImagePullBackOff事件报gcr.io/cadvisor/cadvisor:v0.49.1: not found用阿里云 gcrio 镜像源也 404。原因gcr.io 需要翻墙阿里云registry.aliyuncs.com/gcrio仓库并未同步 cadvisor 镜像。解决实测 DaoCloud 的 gcr 代理gcr.m.daocloud.io可拉取改镜像名为gcr.m.daocloud.io/cadvisor/cadvisor:v0.49.1直接使用HEAD 403 不代表不可用要以实际 pull 为准。坑 25Mbit 带宽下镜像拉取极慢现象node-exporter 拉镜像 7 分 25 秒grafana 8 分 27 秒Prometheus 一度 ContainerCreating 近 8 分钟。原因所有镜像走 5Mbit 公网几百 MB 的镜像需要好几分钟。解决① 尽早配置 containerd/docker 镜像加速docker.m.daocloud.io 等② 大镜像提前后台拉取不阻塞部署主流程③ 验证脚本放宽等待超时轮询而非固定 sleep。坑 3频繁 SSH 密码登录触发云侧临时封禁现象自动化脚本高频连接每次命令一条 SSH channel一段时间后全部 ECS 的 22 端口不可达持续约 30 分钟。原因云厂商安全策略把频繁密码登录识别为暴力破解风险临时封禁来源 IP。解决① 尽快切换到SSH Key 免密密钥登录不触发密码爆破检测② 长任务用单连接复用一个 SSHClient 跑多条命令减少建连次数③ 脚本加断线自动重连与等待机制。坑 4f-string 与 awk 花括号冲突现象f... | awk {print $1, $3}直接SyntaxError。解决f-string 内字面量花括号要写成{{ }}转义或改用普通字符串拼接。七、总结与延伸四件套分工清晰Exporter 采集 → Prometheus 存储告警 → Grafana 展示各司其职。Probing 优先于猜测镜像能不能拉、端口通不通一条命令实测胜过文档猜测HEAD 403 的教训。自动化脚本要能自愈加自动重连、幂等、轮询等待才能扛住真实环境的抖动。延伸方向接入 Alertmanager 实现钉钉/邮件通知采集 K8s 自身指标kube-state-metrics加 Loki 收集容器日志把告警接到 AI 运维 Agent 做自动处置AIOps。配套源码https://gitcode.com/cpyaxjq/k8s-ai-ops deploy/yaml/monitoring/、scripts/deploy_monitoring.py、scripts/verify_monitoring.py