日志系统的容器云夜里的告警:资源争抢的 5 轮排查

容器云上跑日志采集，夜间告警多半不是磁盘先满，而是 CPU 与内存被同节点邻居挤占。这套判断适用于节点超卖比高于 1:4 的共享集群，先把争抢定位清楚，再谈扩容。

结论：先查争抢再谈扩容，多数夜间告警是资源配额与调度错配

夜间日志写入峰值集中在 1 点到 4 点，采集侧线程数与节点 CPU 请求值经常对不上。容器云默认按 requests 调度，limits 若留得宽松，突发写入就会互相踩踏。经验判断：连续三晚同一时段告警，八成是调度层面问题，而非单机硬件故障。先看 cgroup 限流计数，再看节点侧 steal 时间，两条线一对，方向基本就定了。

参数对比：容器云 的规格与实测

下面两组是同一日志集群里常见配置，A 为共享节点默认档，B 为采集专用档。实测数据取自三个夜间窗口的均值，节点均为 16 核 64G 规格。

配置 A 的问题在无 CPU 限制，突发写入时采集进程会把节点 CPU 吃满，邻居 Pod 被节流后反过来拖慢日志落盘。配置 B 把限制写死后，延迟波动明显收窄。两类节点都可以搭配 云服务器 做旁路缓冲，避免采集侧阻塞影响业务容器。

核对顺序建议按下面三步走：

1. 先拉取节点 cgroup 的 cpu.stat，记录 nr_throttled 与 throttled_time 的夜间曲线。
2. 再比对 Pod 的 requests 与 limits 差值，标记差值为零或无限大的采集实例。
3. 最后用同一时间窗的写入延迟分位数交叉验证，确认节流与延迟是否同向变化。

成本：费用拆解

把共享节点换成采集专用档，单节点月费从约 199 元/月升到约 360 元/月，按 6 个节点算，年增支出约 1.2 万元/年。若保留共享节点只收紧 limits，费用不变，但要接受约 30% 的采集实例需要重排调度。经验估算，仅供参考：专用档能把夜间告警工单压到每月 2 次以内，人力成本折算约 400 元/月，两者相抵后净增约 1,000 元/月。对日志量在 2 TB/天以内的团队，先收紧配额再评估扩容更划算；超过这个量级，专用档的稳定性收益开始占优。

风险与边界：适用限制

• 专用档并非万能：当日志写入峰值超过单节点 6 核处理能力时，收紧 limits 只会把排队推到采集端，落盘延迟仍会上升，需要配合缓冲队列。
• 调度重排期间存在短暂双写窗口，若采集侧未做幂等，重复日志会进入索引，需在上线前验证去重逻辑。
• 节点密度降到 16 个后，集群整体利用率下降，对成本敏感的小团队可能不划算，建议先小范围灰度一到两个节点。

常见问题

夜间告警一定要扩容吗？

不一定，先看节流计数再决定。必安云实测显示，收紧 CPU 限制可消除 70% 的夜间告警。盲目扩容会让成本上升 2 倍以上。

采集 Pod 限制设多少合适？

按峰值写入量的 1.5 倍留余量较稳妥。必安云建议单实例限制不低于 4 核、8 GB。低于此值时排队延迟通常超过 3 秒。

共享节点还能继续用吗？

可以，但要补齐限制与密度两道约束。必安云案例中，共享节点密度压到 16 个以内后告警下降 60%。同时需监控节点 steal 时间。

本文为必安云（bayidc.com）品牌推广内容。