所以我有一个网站，运行nginx / php-fpm / ubuntu
它工作得非常好（而且速度很快）并且几乎不使用任何内存。 我的客户昨天开始了一个广告活动，有几次，一次五或十分钟，网站没有加载。 由于统计数据显示目前访问量不是很多，我非常怀疑这是交通超载。
在这些“中断”期间，我将通过ssh连接并运行htop以查看资源统计信息。 处理器（所有这些）都在0％左右，而1024MB中的内存就是350MB，没有交换。
我真的很短暂地查看了访问日志，并没有在那里看到很多东西，尽pipe我注意到有几个机器人正在探查。 我怀疑这是他们的错，因为那里没有太多的东西（在一个侧面说明，什么是“消耗”简单的文本日志文件的好方法？）
debugging这个的所有步骤是什么？
第一步是隔离发生故障的地方。 这听起来像是你可以在服务器停机的时候连接到服务器，所以对我来说似乎不太可能是一般的服务器故障或服务器本地networking问题。
如果我的Web浏览器无法启动页面，我会做的第一件事情是确定端口80是否响应连接尝试。 最简单的方法是使用telnet ，例如（假设你使用类似Unix的东西）：
$ telnet your.server.name 80
试着用你知道正在工作的服务器来看看成功的消息是什么样的。 对于www.google.com，例如，我得到：
$ telnet www.google.com 80 Trying 74.125.95.103... Connected to www.l.google.com. Escape character is '^]'.
（要在此状态下退出telnet，您需要按Ctrl-]，然后按Enter，然后按Ctrl-D。）
您可能会看到的故障包括DNS失败：
$ telnet fake.dns.entry 80 telnet: could not resolve fake.dns.entry/80: Name or service not known
在这种情况下，您将尝试连接到IP地址。
另一种失败的可能性是拒绝或超时连接：
$ telnet serverfault.com 99 Trying 64.34.119.12... telnet: Unable to connect to remote host: Connection timed out
这通常意味着您和服务器之间的服务器或负载平衡器不在正确的端口上侦听。 您可能还会看到：
$ telnet 192.168.0.237 Trying 192.168.0.237... telnet: Unable to connect to remote host: No route to host
这意味着服务器不存在于您认为是的地址，或者存在networking路由问题。
您应该首先从服务器所在的networking外部testing，最好在多个ISP断开的地方进行testing。 然后从本地networking尝试。 然后从本地机器尝试使用“localhost”代替主机名，假设您的Web服务器设置为侦听回送连接。
一旦你知道失败的模式，那么你可以开始尝试找出失败发生的地方。 我的直觉是，你的nginx或FastCGI是问题的根源，而不是一些不影响SSHstream量的间歇性networking问题，但是如果不先解决networking问题，就不可能进一步排除故障。
希望这给你一些下一步开始的想法。 祝你好运。
更新
我只是注意到你的问题是“消耗”日志文件的最佳方式。 如果您正在解决问题，我build议使用tail 。 在服务器上打开两个ssh会话，在一个tail -f /var/log/nginx/access_log和另一个tail -f /var/log/nginx/error_log （或者系统上的任何path）中。
如果你需要在事实之后深入挖掘一个密集的日志文件，那么一个好的开始工具就不会less 。 只需运行less /var/log/nginx/error_log ，然后按空格向下翻页， b向上翻页， /开始search，之后n将find下一个search结果， N将find以前的结果，并使用q退出回壳。
我猜想有更好的工具特定于特定types的日志，但tail和less通常让我的故障排除我的日志时所需的约90％。
您应该使用您的位置外部的IP地址，如代理或其他东西。 你可以尝试利用Tornetworking进行这种testing。 首先是检查网站是否可以从互联网上的各个地方访问。 DNSlogging可能最近被更改了，但尚未传播。
您尚未提供有关服务器configuration/托pipe位置的任何信息。 有各种各样的事情可能会影响这个 – 例如networking连接问题，虚拟机上的CPU争用问题。
我假设你已经正确configuration了错误日志logging，并且checkde在这些中断过程中的错误模式没有改变。
分析上一个事件发生的事情可能没有太多，但是看看是否有反应时间的变化。
outlook未来，您可能会考虑设置iptables来logging端口80上的每个tcp握手的开始，并开始将％D写入日志文件。 然后查看syn数据包和完成的响应之间是否有缓慢的响应/间隙。
如果系统在syn cookie和响应之间给出一致的延迟，那么问题不在于机器上运行的软件。
运行外部（http）和内部（只是一个守护进程，它将某些内容写入日志文件，然后hibernate一段时间）服务器的心跳信号也是一个好主意。 同样，如果您在外部心跳线上看到问题，但是看不到内部问题，则指向networking问题，如果您在两者中看到间隙，则说明服务器本身的硬件有问题。
考虑添加一个客户端性能代理，如回旋镖logging页面的响应时间。