由Elastic Beanstalk启动的EC2实例Web.stdout日志随机停止排查咨询

1. 检查journald自身运行状态与日志 #

• 重启journald后，立即查看其自身的运行日志，定位停止输出前后的异常：

  journalctl -u systemd-journald --since "10 minutes ago"
  

  重点关注磁盘空间不足、内存耗尽、权限报错、进程崩溃相关的日志条目。
• 检查journald核心配置文件/etc/systemd/journald.conf，验证关键参数是否合理：
  • SystemMaxUse/SystemKeepFree：确认是否触发磁盘配额限制，导致journald停止接收日志
  • MaxFileSize/MaxRetentionSec：检查日志文件大小或留存时间限制是否引发轮转异常
  • Storage：若配置为volatile，需确认内存是否耗尽；若为persistent，检查/var/log/journal目录的权限与剩余空间

2. 排查系统资源限制 #

• 检查/var/log/journal所在磁盘的剩余空间：

  df -h /var/log/journal
  

• 排查内存使用情况，确认journald是否被OOM Killer终止：

  free -h
  dmesg | grep -i oom
  

• 检查进程文件句柄限制，确认journald是否耗尽句柄：

  ulimit -n
  lsof -p $(pidof systemd-journald) | wc -l
  

3. 验证Elastic Beanstalk相关配置 #

• 检查.ebextensions目录下的自定义配置，确认是否存在覆盖journald默认设置、日志轮转规则的脚本，避免配置冲突。
• 检查EB的日志收集机制，确认awslogs或其他日志代理进程是否运行正常，是否存在卡住导致日志流转中断的情况：

  systemctl status awslogs
  

• 确认应用启动时的用户权限：EB启动应用的用户需具备向journald写入日志的权限，避免因权限不足导致日志无法输出。

4. 排查应用自身输出问题 #

• 检查应用的日志输出缓冲机制：部分语言（如Python、Java）默认启用输出缓冲，若未手动刷新，可能出现“日志停止”的假象。可尝试在应用中强制刷新stdout/stderr（如Python中print(..., flush=True)）。
• 检查应用进程的文件描述符，确认stdout/stderr是否被意外关闭：

  lsof -p <你的应用进程ID> | grep -E "(stdout|stderr)"
  

5. 其他验证手段 #

• 运行持续输出测试，判断问题范围：在终端执行以下命令，观察测试日志是否也会停止输出。若停止，说明是journald本身的问题；若正常，则问题出在应用到journald的链路：

  while true; do echo "test log $(date)"; sleep 1; done
  

• 检查SELinux/AppArmor权限：查看审计日志，确认是否有安全模块阻止journald接收日志：

  ausearch -m avc -ts recent
  

• 查看systemd版本：若使用较旧版本，可能存在已知bug，可考虑升级到稳定版：

  systemd-journald --version
  

内容的提问来源于stack exchange，提问作者Jonny Shanahan