标签频道
告警阈值
该标签下的文章、提问与讨论帖。
一、现象与背景：吞吐满格，但 P99 抖到 480ms 在数据中心内网链路中，我们曾遇到一个经典 bufferbloat 案例： - 环境：双口 25G 上联，白天高峰时段链路利用率爬到 85%~92%； - 症状：业务 P99 从早上的
现象或背景：连接池告警误报率高达 70%，浪费大量排查时间 在一次高并发的业务场景中，我们团队遇到了一个典型的连接池告警误报问题： - 问题规模：日均告警 120 条，其中 85% 是误报。 - 影响：值班同学需要花费大量时间排查，误报率严
背景 5 年网络工程，现负责一批跨机房 HTTP/1.1 + gRPC over HTTP/2 调用链，单侧稳态存量长连接 2 万上下，新建连接速率峰值 ~800 conn/s，内核 5.15。日常告警体系是 Prometheus + no
背景 5 年网络工程，现负责一批跨机房 HTTP/1.1 + gRPC over HTTP/2 调用链，单侧稳态存量长连接 2 万上下，新建连接速率峰值 ~800 conn/s，内核 5.15。日常告警体系是 Prometheus + no
背景 8 年网络工程，长期盯稳定性与可观测性。这次问的不是「怎么治」——社区 #584《带宽 100% 跑满、丢包却是 0：用 fq_codel 把排队延迟从 480ms 压回 25ms 的一次实战》已经把「灌满接收侧缓冲→队列越积越长→R
【背景】 15 年网络工程，从裸机到 K8s 都趟过。过去三年我维护一套跨机房（RTT 2~8ms）的 gRPC + HTTP/1.1 调用链，单侧新建连接速率峰值 ~800 conn/s，存量长连接 2 万上下。 每次 P99 抖动复盘，
背景 我负责一条 B 端 SaaS 的指标看板链路：埋点/订单流 → Kafka → Flink 聚合 → ClickHouse 小时级 T+0 任务（Airflow 调度，共 37 个核心指标、约 120 个上游 ETL 节点）。业务方对
背景 我负责一个 B 端 SaaS 前端（React 18 + Vite 5，约 20 个页面），DAU 约 3.5 万，RUM 采样率 10%，核心页日均约 3~5 万会话。去年把 CLS 从 Lighthouse 0.35 治到 0.0
背景 我做了 10 年 SRE，最近给一条核心交易链路（P99 SLO 300ms、30 天窗口，对外承诺 99.95%）上了 Google SRE Book 那套「多窗口多 burn rate」告警： - 快窗口：1h / 2h，burn
背景 8 年前端，负责一个 B 端 SaaS（约 200 个路由、日活 3w+）的性能可观测。现状是双通道： - 合成拨测：固定机型/网络/地区，每天 4 轮，数据干净稳定，LCP P99 ≈ 1.8s； - RUM：全量会话采样 10%，
【背景】 我在给一条 B 端数据平台的指标体系定 SLO 告警。核心链路里有一组「低频但关键」的接口：报表导出、批量对账、权限校验，流量特征是高峰约 500 req/min，凌晨谷底约 20~40 req/min，而监控采集与告警窗口统一是
【背景】 我做了 8 年算法，近两年重心在指标体系与异动归因。手上是一条 B 端 SaaS 业务线，核心指标约 40 个（订单量、DAU、人均会话、付费率、ARPU 等），按天出看板。归因侧我已经用 LMDI 把复合指标的分子/分母贡献拆开
数据质量监控（DQC）规则怎么分层落地：从「天天误报」到「该响的响」 «站在指标体系落地视角，对比「全量规则一刀切」与「规则分层 + 阈值分级」两种 DQC 方案的取舍，给一套可复现的规则分层、阈值定法与误报治理路径。» 一、现象与背景：规
【背景】 我做了 10 年算法，近两年主要精力在指标体系与数据监控。负责一条 B 端 SaaS 的核心大盘，日均核心指标约 20 个（DAU、任务成功率、API P99 延迟、付费转化率等），需要 7×24 自动告警，值班同学只看告警群、不
文
标题
摘要