在 Kubernetes 中使用 Elastic Agent 控制日志体积，核心是在采集端做过滤，而不是把所有容器日志都塞进 Elasticsearch。
先说结论：通过 Elastic Agent 策略配置过滤规则，排除无关命名空间或日志模式，并结合索引生命周期管理控制存储。
- 适合：生产环境日志噪音大、存储成本高的场景
- 先准备：确认 Elastic Agent 版本及 Kubernetes 集成策略权限
- 验收：观察 Elasticsearch 索引增长速率及 Agent 资源占用
命令速用版
如果你使用 Kubernetes Integration，可以在策略中添加 processors 来丢弃特定日志。以下是一个配置片段示例，展示如何在 YAML 策略中排除特定命名空间：
inputs:- id: kubernetes-logstype: kubernetesprocessors:- drop_event:when:equals:kubernetes.namespace.name: "kube-system"如果是通过 Fleet 界面管理，需在 Policy 编辑页面的 Kubernetes 集成设置中找到日志过滤选项，添加排除规则。
为什么会这样
Kubernetes 集群中每个 Pod 的标准输出和标准错误流默认都可能被收集。如果不加限制，系统组件（如 kube-system 命名空间）的频繁心跳日志、调试日志会占据大量存储空间。Elastic Agent 作为采集端，如果在发送前不进行过滤，所有数据都会写入 Elasticsearch，导致索引体积迅速膨胀。公开资料中没有看到可靠的量化数据说明具体能减少多少体积，因为这完全取决于业务日志的噪音比例，但原理上减少无用日志采集是直接有效的手段。
分步处理
1. 识别高体积来源
先不要急着改配置，使用 Elasticsearch 的索引统计功能查看哪个索引增长最快。通常 Kubernetes 日志索引会包含命名空间信息，确认是否是特定业务或系统命名空间占用过高。
2. 配置采集过滤
在 Elastic Agent 的 Policy 中，针对 Kubernetes 日志输入源添加处理器。除了排除命名空间，还可以基于日志内容过滤，例如丢弃包含特定关键词（如 "health check"）的日志行。注意不要过度过滤，以免丢失故障排查线索。
3. 设置资源限制
在部署 Elastic Agent 的 DaemonSet 或 StatefulSet 中，设置合理的 requests 和 limits。防止因日志突发流量导致 Agent 自身 OOM（内存溢出）崩溃，进而造成日志积压。
4. 配置索引生命周期管理（ILM）
即使采集端做了过滤，仍需配置 ILM 策略。设置热温冷架构，定期删除过期索引。这是防止存储无限增长的最后一道防线。
怎么验证是否生效
1. 检查 Agent 状态
使用命令 kubectl get pods -n elastic-system 确认 Agent Pod 处于 Running 状态，且重启次数没有异常增加。
2. 观察索引增长
在 Kibana 的 Stack Management 中查看索引大小变化趋势。如果过滤生效，新增索引的增长速率应明显放缓。
3. 抽样日志
在 Kibana Discover 页面查询被过滤的命名空间或关键词，确认是否还能检索到相关日志。如果查不到，说明过滤已生效。
常见坑
1. 误删关键日志
配置过滤规则时，避免使用过于宽泛的正则或关键词。建议先在测试环境验证，或先配置为 "标记" 而非 "丢弃"，观察一段时间后再正式丢弃。
2. Agent 资源不足
日志过滤本身需要消耗 CPU 和内存。如果规则过于复杂，可能导致 Agent 处理延迟。需监控 Agent 自身的资源使用率。
3. 忽略系统日志
完全排除 kube-system 命名空间可能导致无法排查集群层面问题。建议仅排除已知的高频噪音组件，保留核心组件日志。
参考来源
- Elastic 官方文档 - Elastic Agent 策略配置
- Elastic 官方文档 - Kubernetes 集成日志收集
原文链接：https://www.zjcp.cc/ask/10438.html