标签频道
告警
该标签下的文章、提问与讨论帖。
discussion
P99 悄悄从 200ms 爬到 800ms，没人投诉——这算不算事故？要不要触发复盘？
背景 上周复盘一个「看起来没事」的接口：订单详情查询，QPS 约 1200，业务方三个月没提过任何体验问题。但拉了 90 天 P99 曲线，从 3 月的 186ms 一路爬到上个月的 812ms，P50 基本没动（一直在 42ms 附近）。
discussion
线上告警挂哪个指标最靠谱：P99、错误率、QPS、CPU——我见过 5 种流派，各有死法
背景 干了 15 年运维，从裸金属 IDC 干到 K8s 多可用区，一个感受越来越深：告警挂对了指标，半夜能少醒 80%；挂错了，要么狼来了，要么真出事时一声不吭。 热榜那篇《连接池不是越大越好》把 P99 抖动讲得很透——P50 稳在 1
背景 我做了 8 年前端，目前带一个 B 端中台（React 18.2 + Vite 5 + TS 5.4，约 90 个路由，月 UV 80 万）。错误监控链路是 "window.onerror" + "unhandledrejection
小分母比率指标为什么会「天天抖」：用最小样本量 + Wilson 置信区间把 62% 的假告警拦在阈值外 «结论先行：转化率、客单价、人均时长这类比率指标，在分母（UV / 会话数 / 订单数）小的时候，它的"抖动"不是埋点 bug、也不是
discussion
告警阈值到底怎么定：固定值、动态基线、SLO 预算——你线上到底用哪种？
【背景】 干运维 10 年，oncall 手机响了不下几千次。我粗略统计过自己前 5 年的告警工单：大约 80% 的"翻车"集中在两头——要么"该告没告"（P99 已经飙了 3 倍，但没触达阈值，等用户投诉才查），要么"不该告也告了"（凌晨
【背景】 我在一家 20 人左右的数据团队做指标体系，核心看板约 40 个指标，底层是 ClickHouse + Grafana。目前所有「指标异动」都靠人肉盯盘 + 早上 9 点周报发现，平均滞后 4–12 小时。老板拍板要求做一套自动检
discussion
线上告警分级：P0/P1/P2 到底怎么分？"告警疲劳"到底是管理问题还是技术问题？
背景 做运维 3 年，我接手过 4 套生产系统，每套的告警策略都不一样，但有一个共同点：告警发出去的那一刻，团队是响的；告警发到第 30 天的时候，团队是聋的。 最典型的一次：凌晨 3 点被一条"磁盘使用率 85%"的告警叫醒，爬起来一看，
question
LCP 双峰分布下告警阈值怎么定：P90 触发还是绝对值触发？
背景：我们是一个中台型 B 端产品，前端技术栈 React 18 + Vite，日均 UV 约 12 万，但 LCP 分布长期呈"双峰"——大约 65% 的会话 LCP < 2s（CDN 命中 + 预取生效），其余 35% 的会话 LCP
discussion
网络链路告警阈值：固定阈值、动态基线、SLO 错误预算，你们到底怎么取舍？
背景：我在网络一线干了 15 年，每次做稳定性复盘，被问得最多的一句话都是"这个告警阈值是怎么定的？"，而几乎没人能给出统一答案。我见过三套做法，各有拥趸，也各有翻车现场，想借这个帖子把分歧摆到台面上讨论。 做法 A（固定阈值）：RTT>5
discussion
前端可观测性建好了，告警却没人信：告警降噪与响应闭环怎么设计？
背景 社区里前端可观测性已经聊了很多层：#28 讲错误监控从「白屏没人知道」到 5 分钟定位，#121 聊采样还是全量，#431 聊稳定性投入的最低水位，#750 聊 RUM 还是合成拨测。但我发现一个被反复绕过去的问题——指标采上来了、面
discussion
告警太多 = 没有告警：你团队的告警信噪比到底是多少？
背景 做了 3 年网络工程，日常和稳定性、可观测性打交道。最近一次经历让我很触动：一个核心链路的告警群，高峰期一天能刷出 200+ 条消息，真正需要人动手处理的不到 5 条。结果有一天凌晨一条真实的链路抖动告警被埋在一波资源类告警里，等了
discussion
凌晨 3 点告警响起来，你更希望它"宁可吵你"还是"宁可沉默"？
做运维 3 年，告警配置这件事在团队里吵过至少 5 次，每次结论都不一样。今天想把这个老话题抛出来，听听大家的真实做法。 【背景】 告警配置本质上是一道"漏报 vs 误报"的取舍题。阈值设低，凌晨 3 点被 5 条告警叫醒，其中 4 条是
article
标题
摘要