核心是分层设计与系统性优化：按业务拆分采集、用远端存储替代本地tsdb、预计算告警指标、分层聚合告警规则，避免单点瓶颈和oom。
用 Prometheus 监控大规模分布式系统，核心不是“堆资源”，而是分层设计、合理拆分、避免单点瓶颈。单实例 Prometheus 在百万级时间序列下极易 OOM 或查询延迟飙升，必须从架构、采集、存储、告警四个层面系统性优化。
按服务或职责维度拆分采集层
不建议用一个 Prometheus 实例抓取全部服务。应依据业务边界、SLA 要求或资源特征划分采集单元：
- 将核心交易链路（如支付、订单）单独部署专用 Prometheus，保障低延迟采集与高优先级告警
- 基础设施类指标（node-exporter、kube-state-metrics）可归为一组，采集频率可设为 30s–60s，降低压力
- 批处理或离线任务指标通过 Pushgateway 上报，避免拉取不可达问题
- Kubernetes 中利用
kubernetes_sd_configs配合relabel_configs过滤标签，只保留必要维度（如namespace、pod、service），减少 label 组合爆炸
用远端存储替代本地 TSDB
默认的本地磁盘存储受限于单机容量与 I/O，15 天保留期和压缩率再高也难支撑长期、全量指标留存。生产环境应切换为远端写入：
- 选择支持 PromQL 兼容查询的远端存储，如 VictoriaMetrics、Thanos Receiver 或 Cortex
- Prometheus 配置
remote_write将数据实时推送，同时保留本地 short-term cache（用于最近 2–4 小时的高频查询） - 关闭本地 WAL 的持久化冗余（如设置
--storage.tsdb.wal-compression并定期清理），降低内存占用 - 远端存储按租户/集群/环境做 bucket 隔离，便于权限控制与成本分摊
告警规则分层与聚合计算前置
在海量指标下，直接在查询时计算错误率或 P99 延迟会拖慢 Alertmanager，也易触发误告。应把计算逻辑下沉：
- 在采集侧或 Prometheus 内使用
record rules预计算关键指标，例如：
rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) → 存为job:api_error_rate:avg5m - 告警规则只基于预计算指标判断阈值，响应更快、更稳定
- 跨集群告警（如“全局订单成功率
- Alertmanager 配置
group_by: [alertname, job, cluster]，防止同类告警刷屏
可视化与诊断聚焦黄金信号
Grafana 不是指标堆砌场，而是问题定位入口。仪表盘应围绕 Google 四个黄金信号构建：
- 延迟：展示 P50/P90/P99 延迟热力图，按 service + endpoint + status 拆解
- 流量：QPS 曲线叠加同比/环比，识别容量拐点
- 错误：错误率+错误类型分布（如 4xx vs 5xx），联动 trace ID 下钻
- 饱和度：CPU、内存、连接池使用率，结合历史基线标出异常水位
- 每个大盘顶部固定“健康状态卡片”，用 PromQL 计算 SLI（如
sum(rate(http_request_duration_seconds_count{job="api"}[1h])) by (job)），一目了然
