我正在运行一个 Ubuntu Linux 服务器，上面有 Apache、wsgi、django 和 mysql。最近发生了一些事情，wsgi 进程冻结了。重新启动 apache 解决了这个问题。与许多实时系统一样，最好让系统恢复运行，而不是四处摸索。然而，我们在诊断问题时遇到了麻烦，因为一切看起来都很好，我们现在不知道问题的全部状态。
是否有任何工具/命令（在 linux/debian/ubuntu 上（或任何其他 *nix 风格，我可以编译任何命令）），在调用时会将有关系统当前状态的一些详细信息写入文件？如果/当这种情况再次发生时，我们可以运行此命令，然后着手解决一些问题（重新启动 apache/服务器等），然后我们可以尝试诊断问题。
希望记录的事情清单：
- CPU 状态（及各种类型）
- 流程清单及各种详细信息
- 文件系统使用情况的详细信息
- 所有打开文件的列表（以及哪个进程拥有这些文件，等等）
- 所有开放互联网连接的列表
- （如果可能）我们的 mod_wsgi 进程正在执行的详细信息
- MySQL 状态：当前正在运行的查询等。
- （或许）在 apache/mysql/mod_wsgi 上运行 strace 几秒钟，以收集他们正在做的事情的一些数据，并将其保存到文件中。
- 我还忘记了什么吗？
理论上，这是一组简单的命令，如果没有其他人这样做，那么我们就编写自己的脚本，但如果我们能使用合适的工具就更好了。
答案1
mod_wsgi 4.0 正在努力更好地从所有 WSGI 请求线程因某些原因而阻塞的问题中恢复过来，而这最终是导致此问题的原因。这如何导致 Apache 整体阻塞以及为什么您可能无法从 Apache 中注销任何内容，这一点已基本得到理解。
作为已实施的新恢复机制的一部分，mod_wsgi 将在重新启动被阻止的守护进程之前尝试记录每个 WSGI 请求线程的最小堆栈跟踪，以便您可以看到代码被阻止的位置。
我们还正在进行线程利用率的跟踪和报告工作，以便您可以知道请求线程何时因某种原因开始在代码中阻塞。这些数据将能够报告给 New Relic 等工具，以便您可以将其绘制成图表，然后结合 New Relic Python 代理捕获的有关您的应用程序的所有其他 Web 请求信息进行分析。
New Relic 现在还具有服务器监控功能，因此它还可以跟踪有关整个系统的合理数量的信息，包括磁盘活动、网络活动、CPU、进程等。因此，总的来说，New Relic 是监控系统的一个可能选择。
总的来说，随着时间的推移，我们正在做大量的工作试图使 mod_wsgi 更易于监控，并且能够在应用程序由于某种原因开始挂起时更好地自动恢复。
您可以考虑加入 mod_wsgi 邮件列表并留意有关此问题的帖子，或者在邮件列表中询问有关此问题的任何具体问题。