结合 K8s 集群搭建 SRE 智能运维 Agent 的实操项目，我从定位、核心架构、项目落地、踩坑感悟四个层面讲下我对 Prometheus 的理解。
一、核心定位
Prometheus 是一套开源、面向云原生场景的时序监控告警系统，采用 Pull 拉取架构采集指标，配套独立的告警组件 Alertmanager，搭配 Grafana 做可视化，是当前 K8s 生态标准监控方案。 和传统监控最大区别：专门适配容器动态扩缩、多标签多维指标，天生适配 K8s 动态调度的场景，也是我自研 SRE 故障自愈 Agent 的数据来源底座。
二、四大核心核心能力
多维标签时序数据模型所有监控指标都由「指标名 + 多组键值标签」组成，比如
kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff",namespace="default",pod="crash-app"}。 标签可以区分命名空间、Pod 名称、故障类型，筛选、聚合数据非常灵活。我项目里 Pod 崩溃告警，就是靠reason="CrashLoopBackOff"这个标签精准过滤故障 Pod。Pull 拉取式采集架构Prometheus 服务端主动访问各个服务暴露的
/metrics接口拉取指标，而非客户端主动推送。 优势：被监控业务不需要感知监控服务地址，K8s 里通过 ServiceMonitor 自动发现新增 Pod、Deployment，服务扩缩容后监控自动生效，不用改配置，适配容器动态特性。 我项目中 kube-prometheus-stack 会自动创建 ServiceMonitor，自动采集节点、容器、kubelet、API Server 全套指标，无需手动配置采集目标。PromQL 专用查询语言，核心灵魂PromQL 支持聚合、过滤、区间计算、速率统计等复杂运算，能精准算出业务、容器资源状态。 在我的项目里有两处关键使用： 一是配置告警规则，通过 PromQL 表达式识别持续崩溃的 Pod； 二是 SRE Agent 主动调用 Prometheus 告警 API，底层也是通过 PromQL 筛选出 FIRING 状态的故障告警，作为 AI 智能体的感知输入。 比如可以快速计算 Pod 近 5 分钟 CPU 使用率、接口错误率、容器异常等待状态。
分层告警体系（Prometheus 规则 + Alertmanager 分发）我先在 Prometheus 中基于 PromQL 编写告警规则，当表达式持续满足阈值就生成告警； 告警不会直接推送，而是转发给 Alertmanager，由它统一做去重、分组、静默、路由分发。 整个项目最关键的
PodCrashLooping故障告警，就是基于这套机制产出，供给 SRE Agent 抓取、交给 Ollama 大模型判断是否重启 Pod，是整个 AIOps 自愈链路的数据源。
三、项目落地实操经验
我没有手动拆分部署 Prometheus、Grafana、Alertmanager，而是直接使用官方整合的kube-prometheus-stackHelm Chart 一键安装整套监控栈：
- Chart 内置全套 K8s 采集规则、ServiceMonitor，自动识别集群内所有节点、Pod、控制器；
- 开箱自带大量监控面板模板，Grafana 直接导入就能查看节点资源、容器 CPU / 内存、Pod 生命周期状态；
- 部署时通过 Helm values 开启 NodePort，外部虚拟机可直接访问 Prometheus UI 和 Grafana 可视化页面；
- 自定义创建
PrometheusRule资源，新增 Pod 持续崩溃告警规则，规则持久化存 Git，交给 Argo CD 统一管理，符合 GitOps 规范。
四、实操踩坑与个人感悟
时序监控强依赖时间同步 NTP部署完成后 Grafana 所有图表显示 No Data，指标完全不展示。排查很久才找到根源：虚拟机系统时间和宿主机物理机时间不同步。 Prometheus 是时序数据库，所有指标携带时间戳，时间偏移过大时数据无法匹配图表窗口，直接无数据。 这件事让我明白：所有时序监控系统，集群所有节点必须统一同步 NTP 时间，是基础前置条件。
GitOps 规范约束：监控配置全部代码化自定义告警规则、Grafana 面板、采集配置全部以 YAML 形式存 Git 仓库，由 Argo CD 自动同步更新。禁止登录 Prometheus 页面手动修改规则，保证监控环境可复现、变更可追溯。
Prometheus 是 AIOps 智能运维的数据底座常规监控只做到 “人看告警、手动处理故障”，而我的项目拓展了 Prometheus 能力：让自研 SRE Agent 主动拉取告警数据，送入大模型分析决策，自动删除异常 Pod 完成自愈。 这也让我理解 Prometheus 不只是单纯的可视化监控工具，还可以作为时序数据平台，对接自动化、AI 运维平台，拓展 AIOps 能力。
五、总结
Prometheus 凭借轻量化、云原生适配、灵活的 PromQL 和完整告警链路，成为 K8s 环境监控事实标准。在我的项目中，它既是集群资源可视化监控工具，也是整套 SRE 智能自愈平台的数据源头，打通了「故障采集 - LLM 决策 - 自动恢复」完整链路。同时部署、配置全程遵循 GitOps，所有监控规则代码化，运维规范、可落地到企业生产环境。
