标签频道
可观测性
该标签下的文章、提问与讨论帖。
背景 我做了 10 年网络,最近在带一个 6 人小组做内部 RPC 网关(Java,JDK 17,OkHttp 4.12,HTTP/1.1 keep-alive,连接池每服务 500)。下游是 Java 服务,同机房,p50 RTT 稳定
背景 做了 15 年性能优化,我带过的团队里,压测报告几乎年年都绿,但上线后照样翻车。不是玄学,是结构性问题。三个真实案例(已脱敏): 案例 A:某电商支付链路,压测环境 8C16G × 4 副本,JMeter 打 5000 TPS 稳态
背景 React 18 + Vite 5 的 B 端中台 SPA,约 220 个路由,自研 RUM SDK 用 "PerformanceObserver" 采 Core Web Vitals(LCP/CLS/INP)+ "performan
背景 我管过一个 600+ Pod 的 K8s 1.28 集群(云厂商 + 自建混合),服务间通信走 mTLS + 全链路 trace,方案是 istio 1.21 + Envoy sidecar 注入。去年 Q4 做容量审计时发现一个扎心
【背景】 10 年 SRE,目前负责 200+ 个 Java 17 微服务的稳定性(K8s 1.28,3 region,每 region 独立 APM 集群)。2024 年 11 月我踩过一次 NTP step 8 秒的坑(站内文章 id=
discussion
压测 QPS 和线上 QPS 对不上——性能优化到底该信压测,还是该信线上?
【背景】 我最近复盘一个案例:一个查询服务,压测环境稳跑 QPS 5000、P99 40ms,团队信心满满;一上线,真实流量才 1500 QPS,P99 就间歇性飙到 800ms+。团队第一反应是"压测数据不可信",第二反应是"是不是线上有
«结论先行:Service Worker 的 "fetch" 拦截 + "Cache Storage" 默认是对一切 GET 请求都缓存的——它并不区分「静态资源」和「接口数据」。一旦某次发版把 API 响应也卷进缓存策略,用户拿到的就是「
背景 我做了 3 年前端,最近在带一个 B 端 SaaS(React 18.2 + Vite 5 + TypeScript 5.4,约 240 个路由)做 Core Web Vitals 治理。LCP、CLS、TTFB 都有成熟的 Web
背景: 我们团队过去两年从"各服务自己埋点 + 自研网关"逐步走向标准化。现在要重新评估服务治理(mTLS、限流熔断、链路追踪、可观测性)的落地形态,团队里明显分成两派,吵了三轮没结论,所以把争点抛出来,想听听大家怎么权衡。 常见分歧 /
背景 社区里前端超时与重试已经讨论得不少:#493 复盘了「无限等待 + 自动重发把网关 502 打到 3.2%」的治理、#937 聊过客户端该不该做熔断与退避、#180 讨论弱网默认值;后端侧 #23 已经把「超时与重试是容量规划的一部分
«作者视角:15 年网络工程,长期盯系统稳定性与可观测性。这篇文章不教你「怎么排查网络」,而是讲一个更被低估的能力——在你自己机器上把「网络坏了」这件事精确地造出来,用来验证你的超时、熔断、降级、重连逻辑是不是真的按设计工作。全文给可复现的
背景 社区里前端可观测性这一摊已经聊得相当厚了:#28 讲错误监控从「白屏没人知道」到 5 分钟定位的 4 步落地、#554 把 2.4GB/h 日志洪峰压到 180MB/h 的 5 个参数、#889 复盘 SDK 静默失效 6 天的「谁来
背景 我 3 年网络工程背景,现在在保一个 K8s 集群:约 60 节点,Calico VXLAN overlay(iptables 模式,不是 BPF 模式),节点双口 25G 网卡,内核 5.10。业务方反复反馈「跨节点 Pod 调用偶
discussion
服务发现该不该继续绑死在 DNS 上?我的团队里至今吵不休
背景 我做了 10 年网络,从 Nginx upstream + keepalived VIP → 自建 ZooKeeper 注册中心 → Consul → K8s Service + CoreDNS → 云厂商 SLB,基本把这条路走了一
question
LCP 双峰分布下告警阈值怎么定:P90 触发还是绝对值触发?
背景:我们是一个中台型 B 端产品,前端技术栈 React 18 + Vite,日均 UV 约 12 万,但 LCP 分布长期呈"双峰"——大约 65% 的会话 LCP < 2s(CDN 命中 + 预取生效),其余 35% 的会话 LCP
discussion
系统指标全绿但用户在掉单:SRE 该不该为「业务成功率」负责?
做 SRE 8 年,我踩过一个印象最深的坑,今天想拿它抛一个我觉得社区里吵得还不够透的问题。 【背景 · 一次"大盘全绿"的掉单事故】 我们一条下单链路(Java + Spring + MySQL + Redis + MQ),某天起业务侧下
discussion
CDN 缓存污染了前端监控:RUM 和拨测到底该信谁的「缓存态」?
背景 社区里前端可观测性已经聊了不少层:#28 讲错误监控的落地路径、#121 聊采样 vs 全量的成本权衡、#431 聊稳定性投入的最低水位、#750 聊 RUM 还是合成拨测当主信号。但我发现一个被反复绕过去的工程细节——CDN 缓存状
«结论先行:CSP 不是「加一个 header 就完事」的安全项,它是一次资源访问权限的重新设计。跳过 report-only 直接 enforce,我们误杀了 7 类动态脚本、142 家 B 端客户里 38 家完全无法操作,持续 47 分
discussion
线上偶发 P99 抖动,你第一反应是抓包还是翻应用日志?
【背景】 做了三年网络侧,最近几次帮后端同事排障,发现一个反复出现的分歧:同一个接口 P99 从 50ms 抖到 800ms,应用团队默认"先翻日志、看 GC、看线程池",网络团队默认"先 tcpdump、看重传、看 RTT"。两边都觉得自
【背景】 React 18 + Vite 5 的 B 端中台,约 200 个路由,用 Workbox 做 Service Worker 预缓存(precacheManifest 约 380 个资源)。错误上报走 Sentry,sourcem
已经到底了
article
标题
摘要