Prometheus

背景与问题界定 某互联网团队在微服务化后的第一年陷入了"监控碎片化"困境：Metrics 用 Prometheus 单机版自建，每台节点单独部署 node_exporter；Logging 使用 ELK 技术栈，但 Elasticsearch 集群索引膨胀到 15TB，平均查询延迟超过 20 秒；链路追踪使用 Jaeger，但与 Metrics 和 Logging 之间完全割裂，排查一个问题需要同时打开三个不同的 Dashboard。最让人崩溃的是某次线上故障——大量 503 错误由某个服务导致，但运维花了 40 分钟在三个界面之间反复来回跳转才定位到根因：一个被错误配置的 Redis 连接池引发 GC 暂停，最终触发了超时雪崩。可观测性的三个支柱不能各自为战，必须在一个统一平面上实现 Signals 关联。 目标拆解与工程约束 统一 Signal 关联：任一服务实例的 Metrics、Logs 和 Traces 必须能够通过统一的 Labels（namespace、pod、container、trace_id）关联在一起，支持从 Metrics 异常直接跳转到对应时间窗口的 Log 和 Trace 详情。 低成本日志存储：每天 200GB+ 的日志增长必须被控制，采用 LOKI 的"只索引 Metadata 而不全文索引"设计模式，结合日志压缩归档策略，将单日存储成本相比 ELK 降低 60% 以上。 大规模 Metrics 聚合：集群规模超过 500 个 Target，Prometheus 单实例无法承载后需要平滑扩展为 Thanos 或 Cortex 的全局视图架构，支持长达 12 个月的指标历史数据查询。 高可用与自愈：监控系统本身不能成为单点故障——Prometheus 需要 RWO（每个可用区独立实例）架构，Grafana 必须多副本部署并共享告警状态，Loki 的 Distributor 和 Querier 组件必须无状态化。 方案设计 架构选型确定"Prometheus + Thanos + Grafana + Loki + Tempo"作为统一可观测性技术栈。Metrics 路径：每个集群部署一个 Prometheus 实例（配置为 --shard 分片），通过 Thanos Sidecar 将数据上传到对象存储（兼容 S3），Thanos Query 提供全局 PromQL 查询入口： ...

背景 很多团队的监控体系，起点都差不多： 接了 Prometheus 做了几个 Grafana 大盘 报警规则也写了一堆 结果线上一出问题，还是有两个老问题： 真故障没及时报 不重要的抖动疯狂报 本质原因通常不是“监控没接”，而是指标设计和告警语义不对。 尤其在 Go 微服务里，写 metrics 很容易，写出真正有业务意义的 metrics 并不容易。 先区分：监控数据不等于告警指标 你当然可以采很多数据，但不是所有数据都适合直接拿来告警。 比如这些指标： goroutine 数量 GC 次数 进程 RSS 请求总量 它们都很有价值，但更适合作为排障上下文，而不是一上来就触发 Pager。 真正适合做核心告警的，通常是离用户体验更近的信号。 这就是 SLI / SLO 的意义。 什么是 SLI / SLO 简单说： SLI：你用什么指标衡量服务质量 SLO：这个质量要达到什么目标 以一个 HTTP API 为例，最常见的两个 SLI 是： 可用性 成功请求比例是不是足够高。 延迟 请求耗时是不是在可接受范围内。 例如： 30 天内成功率不低于 99.9% 95% 的请求延迟低于 200ms 这两个目标就比“CPU 超过 80% 告警”更接近真实业务体验。 Go 服务里的基础指标 假设你已经有一个标准 HTTP 中间件，可以记录请求总量和耗时。 ...