可观测性

同一个 P95，三套系统算出三个值：分位数的三种定义、不可加性与选型取舍 «结论先行：分位数不是一个数，而是一族函数——它的值取决于"插值定义、样本量、数据形态"三件事，而这三件事在不同引擎里默认值各不相同。更隐蔽的是，分位数不可加、不可跨

背景 先打个比方：错误信息就像餐厅后厨的"出菜提示"。顾客问"这菜怎么还没上"，你要么回"我们 3 号灶的天然气阀门第 7 根管子漏了，请等 8 分钟"——太透，等于把后厨图纸递给了竞争对手；要么回"稍等"——太模糊，顾客根本不知道是排队还

«结论先行：很多「网络变慢」根本不是丢包、不是带宽不够、更不是链路断了，而是发送侧把接收侧的缓冲灌满了——队列越积越长，RTT 从 5ms 涨到 480ms，丢包率却是 0。这类故障在 "ping"、"iperf" 的带宽测试里全都「正常」

背景 上个月我们团队一个 B 端 SaaS 前端发版出了点事：灰度 10% 放量后第 4 分钟，一个路由守卫的竞态 bug 导致部分用户进不去"订单中心"页面。但当时没有任何人盯着灰度大盘——QA 回归在发版前已经跑完了，开发同学发完就切到

一、现象与背景：全量上报撑爆了上报链路 先摆数字。我们一个 B 端中台（React 18.2 + Vite 5，日均 PV 约 230 万、峰值 41 QPS 的活跃会话约 1.2 万个），监控 SDK 最初的设计是所有事件 100% 全量

背景 社区里 #211 在聊「可观测性该做多深」、#90 在聊「网络观测边界」，角度都偏「该建什么」。但我在一线干了 3 年网络工程，发现真正卡住团队的往往不是「建不建」，而是**「间歇性故障到底要不要查到底」**——这是两笔完全不一样的账

【背景】React 18 + Vite 5 的 B 端中台，自研上报链路（错误 + 性能 + 用户行为三类事件），前端用 IndexedDB 做本地队列，navigator.sendBeacon / fetch 上行，服务端落 ClickH

【背景】 我负责一个数据中心出口：两台核心（Cisco N9K，IOS-XR）做 eBGP 双活，下行 4 条 100G 上联走 ECMP（等价多路径，哈希键默认含五元组 + VLAN）。业务是对象存储网关，流量特征很"肥"：少数几条大对象

一、现象与背景：一个「下降 12%」的假胜利 去年我们给公司核心交易链路做了一轮 GC 调优 + 连接池扩容，上线后周报写的是漂亮数字：87 个接口的平均耗时从 287ms 降到 252ms，下降 12%，被当成季度技术亮点汇报。 直到两个

结论先行 2024 年 Q3 我们一个 B 端数据平台的网关 502 比例从基线 0.4% 飙到 3.2%，值班同学以为是网关挂了。排查后发现根因在前端：请求层没有超时上限、失败后无条件自动重发，在弱网场景下形成了「请求堆积 → 网关过载

先抛一个我 2021 年踩过的真实案例，再讲我的困惑，想听听大家的判断。 【背景案例】 某电商的"下单成功页"需要聚合 4 个下游：库存扣减、营销券核销、积分写入、物流预占。同步串行 P50 ≈ 210ms，P99 飙到 480ms（物流预

背景 我做了 8 年数据工程，长期泡在高并发链路的性能调优里。这几年我发现一个奇怪的现象：社区里关于"怎么把 P99 打下来"的文章汗牛充栋（连接池、超时重试、Kafka 幂等、慢查询都写透了），但很少有人正面回答一个更前置的问题——我们到

【背景】 React 18.2 + Vite 5 的 B 端中台，约 120 个路由，大量使用 "useEffect" 做副作用（API 请求、WebSocket 订阅、定时器）。今年启用了 Concurrent Mode（"startTr

【背景】 我在 K8s（1.28 / Calico CNI）里跑一批 Java gRPC 微服务，客户端 → HAProxy（stream 模式，L4 TCP 透传）→ 后端 Pod。后端 Pod 单实例并发连接 500~1500，连接是长

背景 社区里前端可观测性、稳定性责任边界的话题已经不少：#61 聊过前端该不该背 P99 和 on-call，#121 讨论过上报采样还是全量，#28 讲过错误监控从白屏到 5 分钟定位的 4 步落地。把这些串起来看，我发现大家其实都默认了

【背景】 我在 Linux（Ubuntu 22.04 / kernel 5.15）上跑一批 Java gRPC 微服务，单 Pod 并发连接 2000+，业务方偶尔报"接口偶发变慢"，但应用侧 trace 里 handler 耗时看着正常。

«结论先行：WebSocket 客户端的「心跳间隔 × 判定断开次数 × 重连退避 × jitter × 服务端限流」这 5 组参数，任何一个配错都会在网关重启 / 机房抖动 / 运营商 NAT 超时的瞬间把雪崩放大 10 倍以上。这篇文章

现象与背景 我们一个 B 端数据中台，核心页面是「实时监控看板」，默认每 3 秒轮询一次 "/api/metrics/summary"，同时用户可以在顶部筛选栏切换时间范围（近 1 小时 / 近 24 小时 / 近 7 天）。 问题出在哪？

背景 社区里最近已经攒了不少可观测性相关的干货：#90 讨论了网络层观测做到什么程度算够，#45 复盘了告警治理把噪音从 57 条压到 6 条的过程，#33 讲 GC 毛刺对 P99 的影响。这些文章共同指向一个问题——观测能力是稳定性体系

【背景】 React 18 + Vite 5 的 B 端中台，主线程之外拆了 3 个 Worker：一个跑 Markdown 解析（约 200k 行代码）、一个跑图表渲染（OffscreenCanvas）、一个跑本地搜索索引。今年把 Sen