如何排查EC2上Docker Compose栈周期性崩溃且无法SSH连接的问题
你的问题核心是宿主机看似运行但完全无法连接,这种情况大概率是系统内核层面的问题(比如OOM Killer触发后导致系统僵死、内核panic),或者网络栈完全挂掉,以下是具体排查步骤:
强制收集EC2系统级日志
打开AWS CloudWatch日志代理,配置收集宿主机的/var/log/messages、/var/log/syslog、/var/log/kern.log,同时开启EC2的实例控制台输出(AWS控制台EC2实例详情里可设置),这能帮你拿到SSH无法连接时的系统启动/运行日志,尤其是内核报错、OOM Killer的记录。替换SSH为AWS Session Manager
不用依赖SSH端口,直接通过AWS Systems Manager的Session Manager连接实例,只要实例能联网到AWS服务,哪怕SSH进程挂了也能进入系统排查,避免崩溃时完全无法访问。定时记录系统资源状态
在EC2上添加cron任务,每5分钟记录一次系统资源情况,保存到持久化日志文件:*/5 * * * * echo "=== $(date) ===" >> /var/log/resource-monitor.log && free -m >> /var/log/resource-monitor.log && top -bn1 | head -20 >> /var/log/resource-monitor.log && iostat >> /var/log/resource-monitor.logt2.small只有2G内存,多个容器运行时很容易触发OOM,日志里能看到崩溃前的内存占用、CPU负载情况。
配置内核panic日志
修改/etc/sysctl.conf添加以下参数,让内核panic时保存日志到磁盘:kernel.panic = 5 kernel.panic_on_oops = 1 kernel.core_pattern = /var/crash/core-%e-%p-%t执行
sysctl -p生效,这样如果内核panic,能留下核心文件供分析。检查EC2状态检查结果
查看AWS控制台里的实例状态检查(系统状态检查+实例状态检查),如果周期性出现失败,可能是EC2硬件层面的问题,考虑更换实例。验证Docker守护进程的可靠性
给Docker守护进程添加systemd重启策略,确保如果Docker本身崩溃能自动重启:sudo systemctl enable docker sudo systemctl edit docker.service在编辑器里添加:
[Service] Restart=always RestartSec=5然后重启systemd:
sudo systemctl daemon-reload && sudo systemctl restart docker
你提供的Docker Compose配置:
version: '3' services: nginx: image: ..../nginx-docker:2.3.0 restart: always container_name: nginx links: - ghost ports: - "80:80" - "443:443" volumes: - ./logs/nginx:/var/log/nginx/ depends_on: - ghost networks: - app-network ghost: image: .../ghost-s3-adapter:5.33.6 restart: always container_name: ghost volumes: - ${MOUNT_POINT} - ./logs/ghost:/logs/ networks: - app-network environment: url: ${URL} pim: image: .../product-api:4.9.29 restart: always container_name: pim ports: - "9090:9090" volumes: - ./logs/spring:/logs - ./uploads:/data/uploads networks: - app-network networks: app-network: driver: bridge
内容的提问来源于stack exchange,提问作者Torsten

