我正在运行一个Ubuntu Linux服务器，Apache，wsgi，django和mysql就可以了。 最近发生了一些事情，并且wsgi进程结束了。 重新启动Apache解决了这个问题。 与许多现场系统一样，最好让系统恢复正常运行，而不是四处闲逛。 然而，我们在诊断问题方面遇到了困难，因为一切都很好，而且我们现在还不知道问题的全貌。
有没有任何工具/命令（在Linux / Debian / Ubuntu的（或任何其他* nix的味道，我很好，编译任何命令）），当被调用时，将写入文件的一些细节状态的系统就是现在？ 如果/当这种情况再次发生时，我们可以运行这个命令，然后开始扑灭一些火灾（重新启动apache /服务器等），然后我们可以尝试诊断问题。
它会logging的东西的愿望清单：
从理论上说，这是一组简单的命令，如果没有其他人这样做，那么我们只会编写我们自己的脚本，但是如果我们可以使用适当的工具，会更好。
工作正在mod_wsgi 4.0中完成，以便更好地从所有WSGI请求线程阻塞某个事件的问题中恢复，这最终将成为这个问题的原因。 那么这是如何导致Apache作为一个整体阻塞，以及为什么你可能不会从Apache有关它的任何日志logging是主要理解。
作为已实现的新恢复机制的一部分，mod_wsgi将在重新启动阻塞的守护进程之前尝试logging每个WSGI请求线程的最小堆栈跟踪，以便您可以看到代码被阻塞的位置。
还有跟踪和报告线程利用率的工作，所以你可以知道什么时候请求线程出于某种原因开始阻塞你的代码。 这些数据将能够被报告到诸如New Relic之类的工具中，以便您可以绘制它，然后结合New Relic Python代理捕获的关于Web请求的所有其他信息来分析它。
New Relic现在也有服务器监控，所以它也可以跟踪整个系统，磁盘活动，networking活动，cpu，进程等等的合理数量信息。因此，作为一个整体，New Relic是监控你的系统。
总体而言，随着时间的推移，为了使mod_wsgi更容易监控，并且在你的应用程序由于某种原因挂起时能够更好地自动恢复，正在做很多工作。
你可能会考虑进入mod_wsgi邮件列表并留意这个post，或者询问你在邮件列表上的具体问题。
总的来说，我希望我的监控系统能够适应可能导致或引发崩溃的条件。 拥有某种基于历史的监控解决scheme将有助于识别趋势。 Orca ， Cacti ， Munin …如果它是一个独立的系统，它们都能很好地工作。
在Red Hat / CentOS / Fedora方面，我们有sosreport工具，收集详细的硬件和处理信息。
既然你在Ubuntu上，那还不是很完美。 我认为你可以使用Apport的一些位（如果你可以绑定到你的应用程序），但其他一切可能是实用程序的组合：dmesg，dpkg，lshw，udevadm，dmidecode …