问题背景

开发团队报告一个服务的日志采集出现异常。经检查发现，某个大小为 300MB 的日志归档文件本应包含约 300 万条日志，实际却仅采集了数千条即中止，采集过程未能完整执行。

初步判断，这类问题通常由两类常见原因导致：

  • Sincedb 记录异常(已排除，因文件为新归档文件)
  • Logstash 内部队列堵塞或内存溢出(OOM)

下面是异常的日志采集：

【实操】生产环境Logstash崩了—— 问题排查_日志采集

下面是正常的日志采集：

【实操】生产环境Logstash崩了—— 问题排查_docker_02

排查过程

1.检查容器磁盘占用

我猜测logstash容器内会有蛛丝马迹

但是我对logstash 官方容器内部构造不了解，官方文档也没有相应介绍。

 没问题，按照我写的文章【Docker磁盘空间爆满的隐形杀手：容器可写层的深度排查指南 】来操作。

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Size}}" |grep logstash
  • 1.

【实操】生产环境Logstash崩了—— 问题排查_java_03

这里面有1.4G的文件，正常来说logstash内不会有这么大的文件

2. 定位容器存储目录

 docker inspect logstash | grep "MergedDir" 查看可写层的目录：

【实操】生产环境Logstash崩了—— 问题排查_java_04

3. 深入探查可写层文件
cd /var/lib/docker/overlay2/ea4dd1b88d64a6e4a512c72d29ac43fafb4c2896c76f7b7e5569a783135220c5/merged
  • 1.

运行 du -sh * |sort -h

【实操】生产环境Logstash崩了—— 问题排查_java_05

层层查找 ，发现 /var/lib/docker/overlay2/ea4dd1b88d64a6e4a512c72d29ac43fafb4c2896c76f7b7e5569a783135220c5/merged/usr/share/logstash下有个异常文件：java_pid1.hprof

【实操】生产环境Logstash崩了—— 问题排查_日志采集_06

真是意外之喜，发现了JAVA的内存Dump， 该文件是 JVM 在发生OOMs时生成的内存堆转储, 意味着 Logstash 进程因内存不足而崩溃，从而导致日志采集任务被中断。此类问题通常源于：

  • 内存资源配置不足(logstash内存分配过低)
  • 管道配置不合理(批量处理大小过大、worker数量过大)
  • input日志突增，推送ES速度太慢，导致内存quene占满

后续我还会对java_pid1.hprof 文件进行根因分析

原创不易，求个关注👍