标签频道
监控告警
该标签下的文章、提问与讨论帖。
一、背景与问题：Rebalance风暴的代价 在电商大促场景中，某平台order-event topic因消费者组Rebalance风暴导致每秒数千消息丢失。当消费者组规模从8实例扩到16实例时，Rebalance频率从每10分钟1次激增至
背景 我们有一个Kafka消费者组，消费的是"order-event" topic（24分区，8实例），近期流量高峰期间频繁出现Rebalance风暴，导致消息积压丢失。已尝试调大session.timeout.ms至15s、增加fetch
一、现象：凌晨 3 点的告警，比想象中严重 2025-07-12 03:17，监控群弹出第一条告警：Redis 主节点 "used_memory" 达到 58.7GB，逼近 "maxmemory 64GB" 上限。20 分钟后，业务侧开始报
一、背景与问题 Kafka消费者组Rebalance风暴已成为分布式系统稳定性的重要挑战。我们团队在2023年Q4经历的生产事故中，因突发流量激增导致消费者组频繁Rebalance，最终引发服务雪崩。事故后分析发现，32%的线上业务仍停留在
【背景】 我们团队去年因Kafka消费者组频繁Rebalance导致业务抖动，最终定位是消费速率突变+分区缩扩容触发的连锁反应。现在线上仍有32%的业务使用Kafka作为核心数据总线，但Rebalance风暴的防御体系仍停留在『调大sess
背景 我们线上有一个对账服务，依赖 Kafka 消费位点（offset）进行数据同步。最近发现一个潜在风险：消费组停机超过 "offsets.retention.hours"（默认 7 天）后重启，会因为 "auto.offset.rese
现象：MySQL 8.0，K8s 部署 4 副本，单副本 4C8G，入口稳态 800 QPS、峰值 1500。每次连接池打满都是「用户先投诉、我们再复盘」，事后看 GC、慢日志、max 配置，结论往往是「配置没问题，是下游抖动」。 已尝试：
背景 8 年运维，管着十几个 Kafka 3.5（KRaft，3 broker）消费组。社区那篇《停机 8 天静默跳过 465 万条》（id=1530）我反复看了几遍，结论我认："__consumer_offsets" 是带 TTL 的缓存
【背景】 做了 8 年指标体系，最怕的不是"设计新指标"，而是"改老指标的口径"。上个月我们团队改了一个核心指标——"日活跃接口调用量"从"所有请求数"改为"去重独立接口调用数"（排除客户端重试和心跳探活）。改之前我以为影响面可控，结果：3
【背景】 做了 10 年数据分析与指标体系搭建，一个反复被问的问题：告警阈值到底怎么定？ 最常见的两种做法： 做法 A：绝对值 - P99 > 200ms 报警 - 错误率 > 1% 报警 - 队列长度 > 1000 报警 优点：简单、可解
【背景】 我负责一套 MySQL 8.0.36 / InnoDB 订单+账务系统，单主单从，主库 buffer pool 64G，核心表 1.2 亿行，"innodb_purge_threads=4"，隔离级别 REPEATABLE REA
【背景】 做了 10 年算法工程，最近半年主要在帮业务搭指标体系与告警链路。踩到一个反复出现的坑：阈值定得太死，要么半夜狼来了，要么白天出事没人喊。 举两个真实场景（已脱敏）： - 场景 A：某支付网关 P99 绝对阈值 500ms，但业务
【背景】 我做了 3 年技术文档，近两年重心在数据分析与指标体系搭建。最近半年在 3 个不同团队做"事故复盘 → 改进项 → 监控告警"的落地收尾。反复出现同一个模式：复盘会上 6–8 个工程师各自喊"应该盯 X 指标"，最后落地时只留 1
【背景】 我做了 3 年 SRE，手上管着 40 来个服务的告警。去年 Q4 我们团队把「每周 3am 被叫醒次数」立成了硬指标：从平均 6 次压到 0，庆功会上老板说这就是「稳定性的胜利」。 但今年 Q1 复盘一起 P2 事故时我发现一个
【背景】 做了 15 年数据分析与指标体系，我发现一个很少被摆到台面上、却天天在坑人的问题：同一个接口、同一段时间，「P99」在不同系统里能对出两三个不同的数字——Grafana 一个、APM 平台一个、日志离线聚合又一个。复盘事故、写 S
一、现象：凌晨 3 点的告警，比想象中严重 2025-07-12 03:17，监控群弹出第一条告警：Redis 主节点 "used_memory" 达到 58.7GB，逼近 "maxmemory 64GB" 上限。20 分钟后，业务侧开始报
【背景】 3 年前端，现在负责一个中型 B 端产品：日均 80w PV，12 个核心页面，React + Webpack，自研监控 SDK 上报到自建的日志平台。 去年花了一个季度把可观测性「补齐」： - Sentry：JS 异常 + 接口
【背景】 做了 15 年技术文档，后来一头扎进指标体系搭建，踩得最多的坑不是算法，而是「口径」。举个真实到不能再真实的场景：同一套订单服务，同一个 P99，三个团队算出三个数—— - 网关侧按请求维度算，窗口 5 分钟，P99 = 86ms
【背景】 我负责一个订单查询服务：Spring Boot 3.2 + JDK 17 + HikariCP 5.1 + MySQL 8.0，K8s 部署 4 副本，单副本 4C8G，入口稳态 800 QPS、峰值 1500。每次连接池打满都是
«结论先行：systemd 的 "Restart="、"StartLimitBurst"、"WatchdogSec" 是三条互相独立、互相不兜底的防线。绝大多数团队只配了第一条（"Restart=on-failure"），于是「进程死了能拉
已经到底了
文
标题
摘要