Prometheus

背景 把 user_id 加进指标 label，看起来方便筛选，实际上可能为每个用户制造一组新的时间序列。成本会乘上其他标签组合。 核心判断 标签值使用路由模板、状态分类和有限业务枚举。 用户、订单与 trace ID 留在日志或追踪系统，必要时使用 exemplar 关联。 给每个指标定义标签组合上限，并监控活跃序列增长。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 sum by (route, status) (rate(http_requests_total[5m])) # 单独执行，统计该指标的活跃序列数 count(http_requests_total) 边界与误区 /users/123 不是稳定 route 标签，应归一成 /users/:id。两个 PromQL 示例分别执行，分号不是查询之间的通用连接符。 验证方式 估算 route×status×method×instance 的组合数，压测随机用户输入，确认时间序列数量不随用户总数持续增长。 小结 指标标签只表达有限集合，用户、订单和 trace id 应放在日志或 trace 中。

背景与问题界定 某互联网团队在微服务化后的第一年陷入了"监控碎片化"困境：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 中间件，可以记录请求总量和耗时。 ...