所以我用 nginx/php-fpm/ubuntu 建立并运行了一个网站
它运行良好（而且速度很快），几乎不占用任何内存。我的客户昨天启动了一个广告活动，有几次网站一次五到十分钟都无法加载。我非常怀疑这是流量过载，因为统计数据显示到目前为止访客并不多。
在这些“中断”期间，我会通过 ssh 连接并运行 htop 来查看资源统计信息。处理器（所有处理器）的利用率约为 0%，内存约为 1024mb 中的 350mb，并且没有交换。
我简单查看了一下访问日志，并没有发现太多内容，不过我确实注意到有几个机器人在四处搜索。我怀疑这不是他们的错，因为那里没有太多内容（顺便问一下，什么是“使用”简单文本日志文件的好方法？）
调试这个的所有步骤是什么？
答案1
第一步是找出故障发生的位置。听起来您在停机期间能够连接到服务器，所以在我看来不太可能是一般服务器故障或服务器本地网络问题。
如果我的 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
这意味着服务器并不存在于您认为的地址，或者中间存在网络路由问题。
您应该首先从服务器所在的网络外部进行测试，最好是在多个 ISP 断开连接的地方。然后从本地网络尝试。然后从本地计算机尝试，使用“localhost”代替主机名，假设您的 Web 服务器设置为监听环回连接。
一旦了解了故障模式，就可以开始尝试找出故障发生的位置。我的直觉是，您的 nginx 或 FastCGI 是问题的根源，而不是某些不影响 SSH 流量的间歇性网络问题，但如果不先解决网络问题，就无法进一步排除故障。
希望这能给你一些下次开始的想法。祝你好运。
更新
我刚刚注意到你关于“使用”日志文件的最佳方式的附带问题。如果你正在解决问题，我建议使用tail。在服务器上打开两个 ssh 会话，在一个tail -f /var/log/nginx/access_log和另一个中tail -f /var/log/nginx/error_log（或系统上的路径）。
如果你需要在事后挖掘密集的日志文件，那么一个好的入门工具就是less。只需运行less /var/log/nginx/error_log，然后按空格键向下翻页，b向上翻页，/启动搜索，之后n将找到下一个搜索结果，并将N找到上一个结果，然后使用q退出并返回到 shell。
我猜想存在针对特定类型日志的更好的工具，但是tail通常less在解决日志问题时这些工具能够满足我的 90% 的需求。
答案2
您应该使用您所在位置之外的 IP 地址，例如代理或其他东西。您可以尝试利用 Tor 网络进行此类测试。首先要检查该网站是否可以从互联网的各个地方访问。可能是 DNS 记录最近已更改，但尚未传播。
答案3
您没有提供任何有关服务器配置方式/托管位置的信息。有各种各样的因素可能会影响这一点 - 例如网络连接问题、虚拟机上的 CPU 争用问题。
我假设您已经正确配置了错误日志，并且已经检查在这些中断期间错误模式没有发生变化。
您可能无法做太多事情来分析之前发生的事件 - 但请查看响应时间是否存在变化。
接下来，您可以考虑设置 iptables 来记录端口 80 上每次 tcp 握手的开始，并开始将 %D 写入日志文件。然后查看 syn 数据包和完成的响应之间是否存在缓慢的响应/间隙。
如果系统在 syn cookie 和响应之间给出一致的延迟，则问题不在于机器上运行的软件。
针对服务器运行外部 (http) 和内部 (只是一个将内容写入日志文件然后休眠较短时间间隔的守护进程) 心跳可能也是个好主意。同样，如果您看到外部心跳出现问题，但内部心跳未出现问题，则表明存在网络问题，如果您看到两者之间存在差距，则服务器本身的硬件存在问题。
考虑添加客户端性能代理（例如 boomerang）来记录页面响应时间。