filebeat sidecar 被 CFS 节流后 harvester 追不上日志产生速度：怎么量化「正在丢日志」，该加 limit 还是降采集频率？

背景

10 节点（16C64G）K8s 1.28.9 + containerd 1.7.13 + cgroup v2 在线集群。订单服务 Pod 内两个容器：

• main：Java 17 / Spring Boot 3，CPU request=2 / limit=4，日志量出账高峰约 8–12 MB/s，logrotate 按 512MB 滚动、delaycompress + copytruncate；
• filebeat 8.11 sidecar：CPU request=0.1 / limit=0.25，采 3 个输入文件（access / app / error），output 到 Kafka。

现象

出账高峰（10:00–10:40）Kafka 侧观测到某 topic 的日志条数比 main 侧 actuator 的 access log 计数稳定少 2%–7%，且缺口集中在滚动发生前后 1–2 分钟的日志。filebeat 自身 monitoring.harvesters 数正常，没有明显 non_zero 队列告警，但 input.filestream 的 readers 在高峰会短暂堆积。我怀疑是 filebeat 被 0.25 核的 limit 周期性 throttle，harvester 追不上 8–12 MB/s 的写入速度，copytruncate 窗口内没读到的部分直接丢了——但没有可复现的量化证据，只能靠条数对账倒推。

已尝试

1. 看 cgroup v2 的 cpu.stat：nr_throttled 在高峰每分钟 +30~80 次，throttled_usec 占比 15%–35%——确认被节流，但节流时长和丢日志窗口的对应关系对不上；
2. filebeat 自带 metrics：libbeat.registry.files 推进正常，input.filestream.readers 峰值 40+，但拿不到「每个文件当前落后多少字节/多少秒」的直接指标；
3. 临时把 limit 从 0.25 提到 0.75 观察一晚：缺口降到 <1%，但成本上等于给每个 Pod 多留 0.5 核预算，全集群 300+ Pod 我很难接受无脑加；
4. 也考虑过把 filebeat 挪 DaemonSet 走节点采集，但涉及权限、多租户隔离和文件路径治理，短期动不了。

期望得到的答案形态

1. 可执行的「丢日志判定」指标与阈值：在 cgroup v2 + filebeat 8.x 下，看哪个指标能直接量化「harvester 落后量」（字节或时间），以及 nr_throttled / throttled_usec 到什么量级就该告警（希望有你们生产上验证过的数字，而不是「调大一点试试」）；
2. 加 limit vs 降采集成本的取舍：如果确认是节流导致，你们在「提高 limit」「降低采样/合并 input」「logrotate 改 create 模式给 filebeat 留更多读窗口」三条路线里怎么选，各自的代价和副作用是什么；
3. 如果你们踩过 copytruncate + 节流叠加的坑，请贴一下当时的具体数字（limit、日志速率、缺口比例），方便我对标。

社区里 CFS 节流对主容器 P99 的影响已有不少讨论（如 id=1481《CFS quota 把 P99 顶到 200ms》、id=1332《K8s Pod 里 sidecar 抢资源》），但「sidecar 自己被节流导致数据面丢日志」这个方向我还没看到系统性的量化方法，想集中请教一下。