分类频道
可观测性
该分类下的文章、提问与讨论帖。
一、现象或背景：监控数据分散导致的 3 天故障定位 2024 年 11 月 12 日 02:47，我们监控到某核心微服务的 P99 响应时间从 80ms 激增至 1200ms。运维团队花了 72 小时才定位到： 1. 监控数据分散：业务指标
背景 做了 5 年指标体系，我发现一个反直觉的事实：同一个服务，团队 A 和团队 B 算出来的「错误率」可能差一个数量级，而差异不在于监控系统，在于「什么算一次失败」的定义根本没对齐。 举一个真实场景：一个商品搜索接口，日请求量 2000
【背景】 做了 5 年前端，最近半年被绩效指标绑死在「核心页面端到端 P99 ≤ 300ms」上。但每次复盘对不上号：后端 APM（SkyWalking + 自研埋点）显示核心查询接口 P99 是 85ms，前端 RUM（自研 SDK 基于
【背景】 做了 8 年指标体系，最怕的不是"设计新指标"，而是"改老指标的口径"。上个月我们团队改了一个核心指标——"日活跃接口调用量"从"所有请求数"改为"去重独立接口调用数"（排除客户端重试和心跳探活）。改之前我以为影响面可控，结果：3
【背景】 我在一家中台团队负责核心链路的指标体系搭建（3 年，Java + Go 混合栈，MySQL + Redis + Kafka，K8s 部署）。去年 Q3 一次典型的 P99 抖动（订单查询接口 P99 从 12ms 飙到 85ms，
«结论先行：给指标加一个"每请求唯一"的标签（traceId / requestId / 订单号），等于把 Prometheus 从"时序数据库"改成了"事件日志存储"。TSDB 的内存按 time series 条数线性膨胀，1 个 8C
【背景】 我平时负责指标体系搭建，上周排查一次 P99 告警，发现一个很尴尬的口径问题：监控大盘上这个接口过去 1 小时的 P99 是 210ms，但我拿原始埋点日志重算，同样的时间窗 P99 是 480ms。 差异的根源是我们链路的存储设
背景 我做了 10 年 SRE，最近给一条核心交易链路（P99 SLO 300ms、30 天窗口，对外承诺 99.95%）上了 Google SRE Book 那套「多窗口多 burn rate」告警： - 快窗口：1h / 2h，burn
背景 干了 10 年网络，最常被拉进「P99 突然从 20ms 飙到 300ms」的排查群，然后第一句话永远是：「网络你们看下有没有问题。」 问题是——「网络有没有问题」这件事，在微服务架构里根本没有一个干净的度量。 TCP 没断、ping
背景 做指标体系这几年，我发现一个很反直觉的现象：大家花大量精力在"采集什么指标"和"看板怎么画"上，但对最基础也最容易被低估的一步——阈值到底怎么定——讨论得远远不够。 我见过三种典型翻车： 1. 某支付网关 P99 延迟告警写死 200
背景 热榜上几篇 P99 抖动、超时重试、连接池的帖子我都读完了，大家排查路径都很扎实。但我复盘自己这 15 年做指标体系时发现一个反复出现的现象：团队越把 P99 当唯一北极星，线上反而越「看起来在变好、体验在变差」。典型症状是 P99
背景 12 节点集群（16C64G，Kubernetes 1.28.9，containerd 1.7.13，内核 5.15），日志链路是：业务容器 stdout 走 containerd 的 json-file 驱动（"--log-opt
文
标题
摘要