凌晨两点的告警:Old 区 12 分钟涨满 2 月 18 号凌晨 2 点 07 分,值班电话响了。监控看板上,我们的智能问答服务实例 qa-svc-7d9f 的老年代曲线是一条近乎垂直的直线:从 1.2 GB 到 5.8 GB 用了 12 分钟,然后 Full GC,STW 4.7 秒,接着又是一条
27 万个虚拟线程,把 4 核 8G 的容器拖死了 12 月 6 号凌晨,告警电话把我叫醒。AI 批处理服务的响应时间从正常的 300 毫秒涨到 30 秒以上,CPU 100%,但业务吞吐几乎归零。 # 监控截图里的数据 jvm_threads_live
周五下午 16:42,37 万行订单没了 11 月 15 号周五,下午四点四十二,我正准备收拾东西下班,监控群里炸了。 [16:42:07] 告警:order_center 慢查询数 5 分钟内 0 → 143 [16:42:31] 告警:order_center QPS 从 3800 跌到 41
毫无征兆的线程池打满 新上线的网关用 JDK 21 虚拟线程处理请求。压测到 8000 并发时,吞吐量突然从 1.2 万 req/s 跌到谷底,响应从 30ms 飙到 8 秒,CPU 却只有 40%——典型的"线程都在等,CPU 没事干"。jstack 一看,200 个平台线程(carrier)全卡
告警:0 点 15 分,堆积 1200 万 8 月 31 号晚上大促,我们值守到凌晨。0 点 15 分,告警响了: [P1] RocketMQ consumer lag: group=order-sync-consumer, topic=ORDER_SYNC_TOPIC diff=1,20
十月十六号:一个线程池配置引发的连锁故障 那天下午三点,监控系统开始报"下单接口超时率 35%"。我打开看的时候,发现不只是下单——商品详情、购物车、用户信息,几乎所有接口都在超时。网关的活跃连接数从平时的 200 涨到了 7800。 整个服务集群像是被什么东西卡住了。 现象:线程全在 WAITIN