标签频道
告警
该标签下的文章、提问与讨论帖。
«结论先行：环比告警 / 3σ 基线 / 同环比这三类方案，本质上都是「变点检测（change-point detection）」，它们对「跳变」很灵、对「匀速漂移（gradual drift）」几乎失明。 去年我们一条推荐链路的 CTR
【背景】 做指标体系第 5 年，我发现一个绕不开的矛盾：我们采的指标越来越多（一个核心服务 Prometheus 里 4000+ series，光 cardinality 就让我头疼），但真正在值班时「被看到、且能立刻采取行动」的告警，其实
【背景】 我做了 5 年算法，近两年主做指标体系搭建。负责一条 B 端 SaaS 的核心业务看板：约 30 个原子指标（活跃、留存、下单转化、支付成功率、客单价、接口 P99、错误率等），底层 Kafka → Flink 实时聚合 → Cl
【背景】 我做了 15 年技术文档，其中 8 年在帮团队搭指标体系与告警规则。最近接手一条核心交易链路（QPS ~5k，P99 基线 45ms，5xx 错误率基线 0.1%，HikariCP 池 50），想把三项指标合成一个 0–100 的
【背景】 做了 5 年运维，带过两个团队的值班，最直观的感受是：告警数量和业务故障数之间，从来没有正相关过。 去年接手一个新团队的时候，Prometheus + Alertmanager 里挂着 480 条告警规则。一个月下来，值班同学收到
【背景】 做了 5 年算法工程，前 3 年大部分时间其实在搭指标体系：从最初「有什么埋什么、看板铺满 200 个指标」，到后来被迫做减法。现在负责一个日活 300 万级的推荐服务，核心指标从最初 140+ 砍到了 12 个，告警只配了 5
背景 我维护一个高并发查询服务（Spring Boot 3.2，JDK 17，K8s 6 副本，入口稳态 800 QPS、凌晨低峰只有几十 QPS）。同一张表查询，P50 ≈ 80ms，P99 ≈ 420ms，P999 偶发尖峰到 2s+（
背景 8 年网络工程，现保一个跨机房调用链（HTTP/1.1 长连接池，单侧峰值约 800 conn/s、存量长连接 2 万，内核 5.10，节点 40 台）。过去 12 个月复盘过 4 次「P99 抖动」事故：应用侧 P99 从稳态 ~8
背景 3 年网络工程，负责一批 K8s iptables 模式集群（12 个节点，内核 5.10，nf_conntrack_max 维持默认 262144，没改过）。业务以 HTTP/1.0 短连接 + 一个上游重试风暴入口为主，单节点稳态
背景 我 3 年网络工程背景，现在保一个 K8s 集群（约 60 节点、Calico VXLAN iptables 模式、内核 5.10），业务侧核心是「HTTP API + MySQL 长连接池 + 少量 WebSocket」。我踩过的坑
背景 做了 8 年算法，近两年主做指标体系与异动归因。一条 B 端 SaaS 业务线，核心看板 40+ 指标（订单量、支付成功率、API 成功率、DAU、人均会话等），底层 Kafka → Flink 实时聚合 → ClickHouse，7
【背景】 做了 8 年技术文档与指标体系搭建，过去三年里帮三个团队从零搭过可观测性告警体系，也帮两个团队做过"告警治理"（把 400+ 条规则砍到 80 条）。在这个过程中，被问得最多、也最容易吵起来的一个问题就是： 阈值到底用绝对值，还是
【背景】 我 10 年 SRE，值班排班表上最真实的一行数据：我们一套核心链路，Prometheus 告警规则 480 条，一周告警 1200+ 条，其中「真需要人看」的不到 100 条。也就是说值班同学每天要翻过 100 多条狼，才能抓到
【背景】 我做了 15 年算法，近两年主做 B 端 SaaS 的指标体系，核心看板 40+ 指标，底层 Kafka → Flink 实时聚合 → ClickHouse，值班 7×24。比率型指标（支付成功率、下单转化率、API 成功率）占了
背景 Kafka 3.5（KRaft，3 broker），topic "order-settle" 24 分区，消费组 8 实例（每实例 3 分区），"max.poll.interval.ms=300000"（5min），"session.
背景 我做了三年多指标体系搭建，最大的感受是：选对指标只完成了一半，另一半是阈值怎么定才有"提前量"又不"狼来了"。 社区里最近几个热帖（HikariCP pending 线程预警、eBPF 建连失败观测、告警规则回放验证）都在问"阈值怎么
背景 上周复盘一个「看起来没事」的接口：订单详情查询，QPS 约 1200，业务方三个月没提过任何体验问题。但拉了 90 天 P99 曲线，从 3 月的 186ms 一路爬到上个月的 812ms，P50 基本没动（一直在 42ms 附近）。
背景 干了 15 年运维，从裸金属 IDC 干到 K8s 多可用区，一个感受越来越深：告警挂对了指标，半夜能少醒 80%；挂错了，要么狼来了，要么真出事时一声不吭。 热榜那篇《连接池不是越大越好》把 P99 抖动讲得很透——P50 稳在 1
背景 我做了 8 年前端，目前带一个 B 端中台（React 18.2 + Vite 5 + TS 5.4，约 90 个路由，月 UV 80 万）。错误监控链路是 "window.onerror" + "unhandledrejection
文
标题
摘要