Django Elastic Beanstalk自动扩缩容时健康检查返回404问题排查

首先咱们拆解下这个问题：手动部署完全正常，但自动扩缩容出来的新实例，一开始健康检查一直返回404，过20分钟又能正常访问。这大概率和新实例的初始化流程、健康检查时机，或者你的wsgi.conf配置有关，我整理了几个最可能的原因和修复方案：

1. Django路由里没配置/health/端点 #

ELB的健康检查默认请求/health/，如果你的Django项目压根没定义这个路由，自然会返回404。至于20分钟后恢复，可能是Elastic Beanstalk的健康检查重试机制最终“放过”了实例，或者后续某个初始化脚本补了相关配置？

修复步骤：

• 在任意一个app的views.py里添加健康检查视图：

  from django.http import HttpResponse
  
  def health_check(request):
      return HttpResponse("OK", status=200)
  

• 在项目根目录的urls.py里注册路由：

  from django.urls import path
  from your_app_name.views import health_check  # 替换成你的app名称
  
  urlpatterns = [
      # 其他已有的路由...
      path('health/', health_check, name='health_check'),
  ]
  

2. wsgi.conf配置导致应用启动过早或依赖未就绪 #

如果你的wsgi.conf里的应用启动逻辑，没有等待实例初始化的关键步骤完成（比如静态文件收集、数据库迁移），就会出现实例刚启动时，应用还没准备好响应请求的情况，20分钟后这些步骤完成，应用才正常服务。

常见的wsgi配置问题及修复：

• 未等待静态文件收集完成：Elastic Beanstalk部署时会运行collectstatic，但如果WSGI进程提前启动，此时静态文件还没生成，可能导致应用加载失败。你可以通过ebextensions配置，强制让collectstatic完成后再启动WSGI进程。
• 未依赖数据库迁移完成：如果你的应用启动需要数据库表存在，但迁移脚本还没跑完，也会导致服务异常。同样可以用ebextensions控制命令执行顺序。

举个ebextensions配置示例（创建.ebextensions/01_deploy.config文件）：

container_commands:
  01_run_migrations:
    command: "source /var/app/venv/staging-LQM1lest/bin/activate && python manage.py migrate --noinput"
    leader_only: true  # 只在领头实例上执行迁移，避免多实例重复操作
  02_collect_static_files:
    command: "source /var/app/venv/staging-LQM1lest/bin/activate && python manage.py collectstatic --noinput"

3. Elastic Beanstalk健康检查时机太激进 #

默认情况下，Elastic Beanstalk在实例启动后立刻开始健康检查，但此时你的Django应用可能还在加载依赖、建立数据库连接，完全没准备好响应请求，所以返回404。等20分钟后应用初始化完成，自然就正常了。

修复方法：

• 调整健康检查参数：在Elastic Beanstalk控制台的「配置」→「负载均衡器」→「健康检查」里，延长「响应超时」时间，增加「健康检查间隔」和「不健康阈值」，给应用足够的初始化时间。
• 更换健康检查路径：如果不想新增/health/路由，可以改成你项目中已有的、不需要依赖复杂资源的端点（比如根路径/），前提是这个端点能快速返回200状态码。

4. 实例资源瓶颈导致启动缓慢 #

新实例启动时，CPU、内存资源可能被初始化脚本占满，导致应用加载速度极慢，20分钟后资源释放才正常服务。这种情况你可以去CloudWatch查看实例的监控指标（CPU使用率、内存使用率）确认。

修复方法：

• 升级EC2实例类型，选择配置更高的机型；
• 优化Django应用启动速度，比如减少不必要的模块导入、清理冗余依赖。

如果能把你的wsgi.conf具体内容贴出来，我可以帮你更精准地定位问题！

内容的提问来源于stack exchange，提问作者Patrick Tutu