0. 导读

到上一篇 HPA 自动扩缩容，我们已经完成了 K8s 部署、发布、网络、配置、存储、弹性伸缩 全套核心能力。服务已经可以做到零停机发布、自动扩容、数据持久化、资源均衡。

但此时你的集群仍然存在致命盲区：

• Agent 服务 CPU、内存异常飙升，完全无感知

• LLM 推理超时、RAG 检索报错上涨，只能用户反馈后才发现

• 集群节点资源爆满、Pod 频繁重启、OOM 崩溃，后台毫无提示

• HPA 伸缩异常、副本数异常波动无法实时观测

• 线上故障只能瞎排查，没有数据、没有趋势、没有依据

没有监控的生产环境 = 裸奔上线。

本篇我们落地云原生监控告警最后一块闭环：Prometheus + Grafana 全套生产监控体系。专门针对Java微服务 + Python Agent/RAG/LLM服务 做适配，手把手搭建可视化大盘、指标采集、告警规则、异常预警，彻底实现故障前置、问题可视、运维可控。

---

1. 云原生监控核心架构（必须吃透）

传统服务器监控是「单点采集、日志零散」，K8s 动态容器环境必须依赖时序指标监控体系。

1.1 三大核心组件分工

• Prometheus（时序数据库+采集器）：核心枢纽，负责定时抓取集群、节点、Pod、服务的各项指标，持久化时序数据

• Grafana（可视化大盘）：读取 Prometheus 数据，绘制曲线图、仪表盘、拓扑图，实现资源趋势、性能变化可视化

• AlertManager（告警中心）：匹配告警规则，异常时推送钉钉/企业微信/邮件，实现故障实时预警

1.2 完整监控数据流

集群/服务暴露Metrics指标 → Prometheus定时抓取 → 时序存储 → Grafana可视化展示 → AlertManager异常告警

这套架构是目前 K8s 官方标准监控方案，零商业成本、原生适配、性能极强，可直接支撑企业级 AI 云原生集群。

---

2. 各类服务指标暴露方案（双栈适配）

想要被监控，服务必须暴露 /metrics 指标接口，针对我们的 Java + Python 双栈体系，全网统一标准适配。

2.1 Java SpringBoot 服务（天然支持）

SpringBoot 自带 Actuator 监控端点，只需引入依赖，默认暴露丰富指标：

• JVM 堆内存、非堆内存、GC 次数、GC 耗时

• 接口 QPS、响应耗时、成功率、异常率

• 线程数、连接池、CPU 使用率

完全适配集群监控、性能分析、故障定位，是 Java 云原生服务的标配。

2.2 Python Agent / FastAPI 服务（AI核心）

Python LangChain、LangGraph、RAG 服务需要手动接入 prometheus-client，暴露自定义指标：

• LLM 调用次数、成功次数、失败次数、超时率

• RAG 检索耗时、向量查询 QPS

• Agent 工具调用次数、排队任务数

• Python 进程内存、CPU、线程状态

AI 服务业务指标远比重启、资源指标更重要，可以精准定位：是模型问题、检索问题、代码问题还是集群资源问题。

2.3 K8s 集群原生指标

通过 kube-state-metrics 自动采集集群全量指标：

• 节点 CPU、内存、磁盘、负载

• Pod 状态、重启次数、OOM 次数、就绪状态

• Deployment 副本数、扩缩容事件

• HPA 伸缩记录、资源使用率趋势

---

3. Prometheus 核心原理与采集方式

3.1 核心特性

• 主动拉取（Pull）模式：Prometheus 定时主动抓取各服务指标，无需服务推送

• 时序存储：按时间戳存储指标数据，完美适配趋势分析、故障回溯

• 多维标签：支持按节点、命名空间、Pod、服务名多维度筛选监控数据

3.2 生产常用采集规则

• Node 节点采集：监控整机资源水位，防止节点资源打满雪崩

• Pod 容器采集：监控单个服务资源波动，定位异常 Pod

• Service 业务采集：监控 Java、Agent 业务接口指标

• HPA 指标采集：监控弹性伸缩是否正常生效

---

4. Grafana 生产大盘搭建（双栈专属）

Prometheus 只负责存数据，Grafana 负责可视化展示，生产环境核心看三大面板。

4.1 集群节点总览大盘

用于观测集群整体健康度：

• 节点在线状态、CPU/内存使用率趋势

• 磁盘使用率、磁盘 IO 负载

• 集群总 Pod 数、异常 Pod 数、重启次数

作用：快速判断是全局集群问题还是单个服务问题。

4.2 Java 微服务监控大盘

聚焦业务稳定性：

• JVM 堆内存趋势、GC 频率、GC 耗时

• 接口 QPS、P95/P99 响应耗时、错误率

• 线程活跃数、阻塞线程数

• Pod 资源使用率、重启记录

4.3 Python Agent/RAG 专属监控大盘（AI项目重点）

AI 服务不可只看资源，必须看业务语义指标：

• LLM 调用成功率、失败率、超时率

• RAG 检索平均耗时、TopK 查询波动

• Agent 工具调用排队数量、堆积趋势

• Python 进程内存波动、内存泄漏趋势

• HPA 扩容前后 QPS 变化对比

通过这套大盘，可以精准定位：用户对话卡顿是 模型慢、检索慢、代码慢、还是资源瓶颈。

---

5. 生产级告警规则配置（核心保命能力）

可视化只是看数据，告警才是保障生产稳定的核心。我整理了一套可直接上线的告警规则，适配所有双栈云原生项目。

5.1 集群资源告警

• 节点 CPU 使用率持续 5 分钟 > 80%：节点负载过高预警

• 节点内存使用率持续 5 分钟 > 85%：防止内存溢出集群雪崩

• 磁盘使用率 > 85%：防止磁盘打满集群瘫痪

5.2 Pod 服务异常告警

• Pod 重启次数 > 3 次/10分钟：疑似 OOM、代码报错、探针异常

• Pod 状态异常、就绪探针失败：服务不可用告警

• HPA 持续扩容但负载不降：存在服务性能瓶颈

5.3 AI Agent 业务告警（专属）

• LLM 调用失败率 > 5%：模型密钥、接口、限流异常

• LLM 平均响应耗时暴涨：模型负载过高、网络拥堵

• RAG 检索超时率飙升：向量库压力过大、索引异常

• Agent 任务堆积持续上涨：服务处理能力不足，需要扩容

5.4 告警推送方式

生产首选 钉钉/企业微信机器人，实时推送告警信息、故障时间、故障级别、对应Pod和服务名，无需登录后台即可快速处理事故。

---

6. 监控体系落地后的运维质变

搭建整套监控体系后，你的 AI 云原生项目彻底脱离“野生部署”，具备企业级运维能力：

• 故障前置：用户没感知，运维已收到告警并处理

• 问题精准定位：区分是集群、节点、容器、代码、模型、中间件问题

• 容量预判：根据资源趋势提前扩容，杜绝峰值突发崩溃

• 迭代有据可依：每次 Agent 优化、Prompt 迭代、代码升级均可对比性能指标

• 配合HPA实现极致稳定：监控看趋势、HPA 做实时伸缩，双层保障

---

7. 生产高频踩坑总结

• 指标采集为空：服务未暴露 /metrics 接口、容器端口未开放、采集规则路径错误

• 监控数据断断续续：Prometheus 资源过低、抓取间隔过长、网络波动

• 告警轰炸、误报过多：未配置持续时间判断，瞬时波动触发无效告警

• AI服务看不出问题：只监控资源，未自定义 LLM/RAG 业务指标

• Grafana图表无数据：标签不匹配、命名空间筛选错误、指标名称变更

---

8. 总结

• Prometheus+Grafana 是 K8s 云原生标准监控方案，是生产环境上线的必备条件

• Java 服务依赖原生监控指标，Python Agent 必须自定义 AI 业务指标，才能精准观测服务状态

• 节点、Pod、业务、HPA 四层监控体系，彻底消除集群运维盲区

• 配合实时告警能力，实现故障提前发现、快速定位、快速恢复

• 完成本篇落地后，你的双栈云原生项目正式具备企业级生产稳定性