503 使用 apache/wsgi 在日志中没有任何痕迹

Posted 2023-03-10

【中文标题】503 使用 apache/wsgi 在日志中没有任何痕迹

【英文标题】：503 with no trace in the logs using apache/wsgi

【发布时间】：2019-05-19 20:54:30

【问题描述】：

我的 Flask 应用定期返回 503 错误。我说不出原因。可能与负载有关。它不是系统的，因此不是文件权限问题。这更像是 10 个后续请求的 5 次。在浏览器中使用 F5 可以轻松重现。

我想调试它，但在日志中找不到任何内容。

我检查了 apache 主日志文件（访问/错误）和 VirtualHost 访问/错误日志文件。我已经尝试将LogLevel 设置为调试，但无济于事。

当应用程序返回一个503（例如，将abort(503) 与 Flask 一起使用）时，错误会记录在虚拟主机访问日志中（这不是 apache 错误，所以它会记录在访问日志中）。它也记录在我的应用程序日志中，因为我的框架记录了所有 http 错误。

我过去一直遇到负载问题，没有可用的线程。这导致 apache 本身返回 503 错误，我很确定这些错误已记录在访问或错误日志中（很可能是错误）。

客户端怎么可能得到一个 503 并且日志中没有它的踪迹？

虚拟主机配置摘录：

    ErrorLog $APACHE_LOG_DIR/my-app-error.log
    CustomLog $APACHE_LOG_DIR/my-app-access.log combined

    WSGIDaemonProcess my-app threads=5
    WSGIScriptAlias /api /srv/my-app/application.wsgi process-group=my-app application-group=%GLOBAL
    WSGIPassAuthorization On

    <Location /api>
        WSGIProcessGroup my-app
    </Location>

    <Directory /srv/my-app/>
        Options FollowSymLinks
        AllowOverride All
    </Directory>

Debian Stretch、apache 2.4.25、mod_wsgi 4.5.11。

编辑 1：所有 WSGi 应用程序都受到影响

我们注意到同一 apache 实例上另一个虚拟主机中的另一个 wsgi 应用程序出现 503 错误。此应用程序处于轻负载（接近于零），因此它不应该是 503。但是，在加载默认 VHost 页面（“Apache2 Debian 默认页面”“它有效！”页面）时，我没有得到 503 .就像所有 WSGI 应用程序都存在某种 mod_wsgi 限制一样，但不是全局 apache 限制，因为只有 WSGI 应用程序受到影响。

编辑 2：重启 apache

systemctl reload apache2 不会改变任何东西。但是，systemctl restart apache2 暂时解决了它。直到下一次。

重启前

● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-12-04 11:13:23 CET; 2 weeks 0 days ago
  Process: 10023 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS)
  Process: 536 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
 Main PID: 977 (apache2)
    Tasks: 133 (limit: 4915)
   Memory: 1.7G
      CPU: 6d 6h 3min 51.105s
   CGroup: /system.slice/apache2.service
           ├─  977 /usr/sbin/apache2 -k start
           ├─10066 /usr/sbin/apache2 -k start
           ├─10067 /usr/sbin/apache2 -k start
           ├─10068 /usr/sbin/apache2 -k start
           ├─10069 /usr/sbin/apache2 -k start
           ├─16834 /usr/sbin/apache2 -k start
           └─16836 /usr/sbin/apache2 -k start

重启后

● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-12-19 12:32:02 CET; 3s ago
  Process: 11840 ExecStop=/usr/sbin/apachectl stop (code=exited, status=0/SUCCESS)
  Process: 11735 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS)
  Process: 11850 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
 Main PID: 11854 (apache2)
    Tasks: 79 (limit: 4915)
   Memory: 125.3M
      CPU: 4.080s
   CGroup: /system.slice/apache2.service
           ├─11854 /usr/sbin/apache2 -k start
           ├─11855 /usr/sbin/apache2 -k start
           ├─11856 /usr/sbin/apache2 -k start
           ├─11857 /usr/sbin/apache2 -k start
           └─11858 /usr/sbin/apache2 -k start

我在这里看到的差异是进程数（不知道如何得出结论）和内存使用量。好吧，应用程序似乎对内存有点贪婪，但我认为服务器可以处理。

【问题讨论】：

我在带有 libapache2-mod-wsgi 4.5.17 的 Ubuntu 18.04.2 中遇到了同样的问题。

【参考方案1】：

以防万一：我们遇到了类似的问题，烧瓶 wsgi 应用程序间歇性地返回 503（例如，每 5-10 个请求）。

手动测试显示相应的请求没有显示在 apache 访问日志中（而成功的请求没有）。

正如workaround 的回答所暗示的那样，apache 配置确实还包含其他应用程序的代理配置，我们将keepalive=On 关键字用于我们的ProxyPass 指令之一（不适用于flask 应用程序，但对于以相同前缀提供的另一个应用程序）。摘录：

    <Location /curated-cofs>
        WSGIProcessGroup curated-cofs   # this is the flask app
    </Location>

    <Location /curated-cofs/optimade>
        ProxyPass http://localhost:3759 keepalive=On timeout=1200
        ProxyPassReverse http://localhost:3759
    </Location>

我们实际上没有充分的理由在这里使用keepalive 关键字（没有内部防火墙）。

从 ProxyPass 指令中删除关键字似乎已经解决了烧瓶应用程序的 503 问题作为副作用。

【讨论】：

这个问题太老了，我不能再复制它了，但这可能会对未来的读者有所帮助。

【参考方案2】：

首先，您查看访问日志了吗？因为如果没有错误日志，这意味着服务器被访问过，所以访问日志中肯定有一些东西。 如果有，请检查 Flask 是否确实在服务。

其次，您是否在代理请求？如果这样做，请确保您的代理配置正常。

当然，请确保您的 mod_wsgi 配置为 correct

【讨论】：

> "我检查了 apache 主日志文件（访问/错误）和 VirtualHost 访问/错误日志文件。我尝试将 LogLevel 设置为调试，但无济于事。"