Prometheus 做大之后的问题
Prometheus 是云原生指标监控的重要基础设施。对于单个集群或少量服务，Prometheus + Grafana + Alertmanager 的组合清晰、灵活、生态成熟。
但当企业进入多集群、多云、多团队阶段后，问题通常不在 Prometheus 本身，而在平台化治理：
- 多套 Prometheus 分散在不同集群和团队，规则、标签和保留周期不统一。
- Grafana 仪表盘重复建设，权限、模板和数据源维护成本持续上升。
- Alertmanager 负责基础告警路由，但值班排班、升级、认领、IM 协同和 MTTR 分析仍要额外系统支撑。
- 日志、链路、事件、RUM、云监控和数据库指标往往在其他平台里，故障定位需要跨系统切换。
- 平台团队需要统一交付最佳实践，而不是让每个业务团队各自拼装一套监控栈。
Flashcat 的定位
Flashcat 不要求团队放弃 Prometheus 生态，而是把它纳入统一可观测平台。
| 现有能力 | Flashcat 的补充方向 |
|---|---|
| Prometheus 指标采集和查询 | 统一接入、组织和呈现多套指标数据，降低多集群治理成本。 |
| Grafana 仪表盘 | 支持复用 Grafana 仪表盘模板，并在统一平台中沉淀场景化视图。 |
| Alertmanager 告警 | 可结合 Flashduty 扩展为降噪、分派、排班、升级、触达和协同闭环。 |
| Exporter 生态 | 可配合 Categraf 做 all-in-one 采集，减少多 Agent 维护成本。 |
| PromQL 与标签体系 | 继续复用 Prometheus 生态，同时推动团队统一标签和业务组规范。 |
推荐落地路径
- 盘点 Prometheus 实例、Remote Write/Read、长期存储、Grafana 数据源和 Alertmanager 路由。
- 先统一关键业务的指标查询入口和仪表盘模板，不急于改动底层采集链路。
- 建立服务、集群、环境、团队等基础标签规范，减少后续规则和看板重复维护。
- 把高价值告警接入 Flashduty，补齐值班、升级、认领和处理效率分析。
- 逐步把日志、链路、事件、RUM 和云监控数据接入 Flashcat，建立跨数据类型的故障定位视图。
适合什么团队
- 已经大量使用 Prometheus 和 Grafana，但缺少统一平台入口。
- 多个 Kubernetes 集群各自维护监控规则和仪表盘。
- 希望继续保留 Prometheus 生态，而不是推倒重来。
- 告警治理已经超过 Alertmanager 基础能力，需要 On-call 闭环。
- 希望用统一可观测平台承接 AI 根因分析和 Agentic Observability 场景。
