线上服务挂了2小时没日志可查！K8s日志采集的坑，我一个不落全踩了

凌晨1点47分，钉钉告警群炸了。订单服务5xx飙到30%，用户下单全部超时。我爬起来打开Kibana准备查日志——空的。切到Grafana看Fluent Bit指标——采集量断崖式归零。

日志没了，线上故障等于在黑暗里排雷。

最后这个故障花了2小时才定位根因，整个过程中日志系统的崩溃让排查效率暴降80%。事后复盘，我发现日志链路上埋了至少4个定时炸弹，而这些问题90%的K8s集群都存在，只是还没爆而已。

事故现场

时间：周三凌晨1:47
告警：order-service 5xx rate > 20%，持续5分钟
用户体感：下单接口超时，页面转圈后报错
业务影响：核心交易链路中断，预估损失约12万/小时

打开Kibana查order-service最近10分钟ERROR日志，索引里最后一条停在1:32——距离告警过去15分钟，之后一片空白。

kubectl logs直接看Pod：

$ kubectl logs order-service-7b8f9c6d4-xk2mn-nproduction--tail=100

能看到实时日志。应用还在打日志，问题出在采集链路。

排查踩坑——4步全错

第一步：Fluent Bit挂了？

$ kubectl get pods-nlogging-lapp=fluent-bit NAME READY STATUS RESTARTS AGE fluent-bit-4xk2n1/1 Running03d fluent-bit-7nm9p1/1 Running03d fluent-bit-bx5st1/1 Running03d

全部Running，没重启。

第二步：ES写不进去了？

$curl-selasticsearch.logging.svc:9200/_cluster/health|jq.{"status":"green","number_of_nodes":3,"active_shards":847}

集群健康，green状态。

第三步：网络抖动？

$ kubectlexec-itfluent-bit-4xk2n-nlogging --curl-selasticsearch.logging.svc:9200

通的，返回正常。

到这里已经懵了——Agent在跑、ES正常、网络通畅，日志就是不进来。

第四步：看Fluent Bit自身日志

$ kubectl logs fluent-bit-4xk2n-nlogging--tail=50

关键报错出现了：

[2025/07/10 01:33:15] [warn] [input:tail:tail.0] pausing tail, mem_buf_limit reached [2025/07/10 01:33:15] [warn] [input:tail:tail.0] pausing tail, mem_buf_limit reached

内存缓冲区满了，停止读取日志文件。

但缓冲区为什么会满？正常情况下日志从读取到写入ES只需几十毫秒，不可能积压。继续往上翻：

[2025/07/10 01:30:42] [error] [output:es:es.0] HTTP status=429, Retry in 15 seconds [2025/07/10 01:30:57] [error] [output:es:es.0] HTTP status=429, Retry in 30 seconds [2025/07/10 01:31:27] [error] [output:es:es.0] HTTP status=429, Retry in 60 seconds

ES返回429（Too Many Requests），bulk写入被限流了。

根因——4个炸弹同时引爆

整个崩溃链路：

应用日志量突增 → ES bulk队列打满返回429 → Fluent Bit重试堆积 → 内存缓冲区撑满 → 停止采集 → 日志断流

日志量为什么突增？回头看监控，1:30有个CronJob触发数据同步任务，每秒打印上万行DEBUG日志，日志量瞬间打到平时50倍。

4个问题叠加：

任何一个单独存在都不会炸，四个叠在一起就是连环爆。

修复方案——配置直接拿走

修复1：缓冲区扩容 + 文件缓冲兜底

内存缓冲从5MB调到50MB，开启filesystem buffer，满了先落盘不丢弃：

[SERVICE] Flush 1 Log_Level info HTTP_Server On HTTP_Listen 0.0.0.0 HTTP_Port 2020 storage.path /var/fluent-bit/storage/ storage.sync normal storage.checksum off storage.max_chunks_up 128 [INPUT] Name tail Path /var/log/containers/*.log Parser cri Tag kube.* Mem_Buf_Limit 50MB storage.type filesystem Skip_Long_Lines On Refresh_Interval 5 Rotate_Wait 30 DB /var/fluent-bit/tail-db/pos.db

核心：storage.type filesystem配合storage.path，缓冲区满了日志写本地磁盘暂存，下游恢复后再发。这是防丢日志的关键配置。

修复2：ES扩大写入队列

# elasticsearch.ymlthread_pool:write:queue_size:1000# 默认200size:8# 写入线程数，按CPU核数调indices:memory:index_buffer_size:20%# 默认10%

Fluent Bit output端加重试控制：

[OUTPUT] Name es Match kube.* Host elasticsearch.logging.svc.cluster.local Port 9200 Logstash_Format On Logstash_Prefix k8s-logs Replace_Dots On Suppress_Type_Name On Buffer_Size 512KB Retry_Limit 5 workers 2

workers 2多线程并发写入提高吞吐，Retry_Limit 5避免无限重试耗尽资源。

修复3：高日志量Pod采集隔离 + 限流

[FILTER] Name grep Match kube.* Exclude $kubernetes['labels']['logging-exclude'] true [FILTER] Name throttle Match kube.batch.* Rate 1000 Window 5 Interval 1s Print_Status true

CronJob Pod模板加标签：

metadata:labels:logging-exclude:"true"

修复4：Kyverno强制生产环境日志级别

apiVersion:kyverno.io/v1kind:ClusterPolicymetadata:name:require-log-levelspec:validationFailureAction:Enforcerules:-name:check-log-levelmatch:resources:kinds:-Podnamespaces:-productionvalidate:message:"生产环境Pod必须设置LOG_LEVEL且不能为DEBUG"pattern:spec:containers:-env:-name:LOG_LEVELvalue:"!DEBUG"

架构改造——加Kafka缓冲层

改造前：

容器stdout → Fluent Bit → Elasticsearch（直连）

改造后：

容器stdout → Fluent Bit → Kafka（缓冲） → Logstash → Elasticsearch ↘ S3（审计日志冷存储）

Kafka扛着，ES挂了日志也不丢。Fluent Bit的Kafka output配置：

[OUTPUT] Name kafka Match kube.* Brokers kafka-0.kafka.svc:9092,kafka-1.kafka.svc:9092,kafka-2.kafka.svc:9092 Topics k8s-logs Timestamp_Key @timestamp rdkafka.log.connection.close false rdkafka.request.required.acks 1 rdkafka.message.max.bytes 1048576

日志系统自身的监控——不能裸奔

# Prometheus告警规则groups:-name:logging-pipelinerules:-alert:FluentBitInputPausedexpr:fluentbit_input_paused == 1for:2mlabels:severity:criticalannotations:summary:"Fluent Bit采集暂停！日志可能丢失"-alert:FluentBitOutputRetryHighexpr:rate(fluentbit_output_retries_total[5m])>10for:3mlabels:severity:warningannotations:summary:"Fluent Bit写入重试频繁，下游可能阻塞"-alert:KafkaConsumerLagexpr:kafka_consumer_group_lag{group="logstash-consumer"}>100000for:5mlabels:severity:warningannotations:summary:"日志消费积压超10万条"

Fluent Bit开启metrics端点：

[SERVICE] HTTP_Server On HTTP_Listen 0.0.0.0 HTTP_Port 2020

Prometheus通过:2020/api/v1/metrics/prometheus拉取。

三条血泪教训

1. 日志系统必须有自己的监控和告警。日志链路断了你根本不知道，等排查线上故障才发现没日志——已经晚了。

2. 永远不要让一个Pod的日志暴增拖垮整个节点的采集。做好隔离和限流，CronJob/Job这类批处理任务是重灾区。

3. 内存缓冲区 ≠ 不丢日志。Mem_Buf_Limit到了就停采，必须配合文件缓冲或Kafka才能真正保障。

如果你的K8s集群日志方案还是Fluent Bit直连ES、没有缓冲层、没有采集限流、没有日志系统自身的监控——趁没爆之前赶紧改，别等凌晨2点被教做人。

觉得有用就转发一下，让更多人少踩这个坑 🙏