求助：AWS Systems Manager Session Manager几小时后无法登录EC2实例

SSM Agent 相关排查 #

• 检查SSM Agent运行状态：查看系统日志或CloudWatch日志，确认amazon-ssm-agent进程是否在2-3小时后崩溃/停止。可通过命令systemctl status amazon-ssm-agent（systemd系统）或service amazon-ssm-agent status验证，同时查看日志文件/var/log/amazon/ssm/amazon-ssm-agent.log中的报错信息。
• 验证IAM角色权限：确认实例关联的IAM角色包含AmazonSSMManagedInstanceCore权限，且未被意外修改。同时检查安全组/NACL是否允许实例出站访问SSM服务端点（ssm.<区域>.amazonaws.com），避免网络规则后期被调整。

实例资源占用排查 #

• 监控资源指标：查看CloudWatch的CPUUtilization、MemoryUtilization、DiskSpaceUtilization指标，确认是否存在资源耗尽情况。也可在实例正常时设置定时任务记录资源使用：echo "0 * * * * root top -b -n1 >> /var/log/resource_usage.log" >> /etc/crontab，后续分析日志定位资源占用高峰。
• 检查磁盘空间：执行df -h查看根目录、/var目录及WordPress相关目录（如/var/log/httpd、wp-content/cache）的占用情况，磁盘满会导致SSM Agent无法写入日志或正常运行。

自动扩缩容与负载均衡排查 #

• 查看ASG事件历史：确认ASG是否将实例标记为不健康并触发终止/替换操作，检查实例生命周期内的状态变更记录。
• 验证ELB健康检查：确认ELB的健康检查规则是否正常，是否因WordPress服务异常导致实例被标记为不健康，进而影响网络连通性。
• 检查生命周期钩子：若ASG配置了生命周期钩子，确认钩子执行的脚本未停止SSM Agent或修改相关权限。

系统层面排查 #

• 检查OOM Killer记录：查看/var/log/messages或dmesg输出，确认是否因内存不足导致SSM Agent进程被系统终止。
• 验证防火墙与SELinux：检查iptables/firewalld规则是否被修改，阻止SSM Agent通信；查看/var/log/audit/audit.log，确认SELinux未拒绝SSM Agent的操作。
• 排查自动更新影响：检查系统是否有yum自动更新任务，确认更新过程未重启SSM Agent或导致服务崩溃。

WordPress 应用排查 #

• 排查插件/主题资源泄漏：禁用所有WordPress插件，观察实例是否仍出现无法登录的情况，逐步定位存在内存/CPU泄漏的插件或主题。
• 检查数据库连接问题：查看WordPress调试日志（需开启WP_DEBUG），确认是否存在数据库连接异常导致进程挂起，占用实例资源。

内容的提问来源于stack exchange，提问作者Mahbub Rahman