我们的网络服务器容量达到 100% 的那一天

为什么 json_encode 要添加反斜杠？

起源

几个月前的一天，QA 工程师在 Slack 上给我发短信说他无法登录 Web 应用程序。我自然而然地尝试用他的凭证登录，成功了。我以为他忘记了密码，就把密码发给了他，他说现在可以登录了。我当时没多想。

两小时后，快要下线的时候，我收到一位客户的邮件，说他们无法登录。我以为他们忘了密码，就没再理会，打算明天一早就联系他们。后来，我团队的一位移动开发人员也说了同样的话。

于是我开始调查。我去了那个网站，试图登录，但登录不上。按回车键后，页面会重新加载，而且没有任何错误提示。

当一位同事提到可能是数据库连接问题时，我迅速开始调试。我们最近从使用单个数据库实例迁移到数据库集群，并假设这可能是导致问题的原因，或者某个实例承担了过多的负载。由于这次变更是规模最大且最新的一次，我们最终将关注点集中在了它上面。然而，数据库控制台看起来一切正常，没有显示任何特定实例的额外负载。

这个问题只在生产环境中出现过，所以可以肯定它与任何代码更改无关。这时，我们开始收到越来越多的客户投诉，于是我决定做一件危险的事：在生产环境中进行调试。

我使用 Cyber​​duck 连接到服务器，导航到登录视图文件，并记录了类似 的内容logging in。令我惊讶的是，当我点击“保存”时，文件并没有保存。Cyber​​duck 显示了一条模糊的错误信息，我当时记不清了，也不明白是什么原因。

又调试了几个小时后，我们发现服务器的磁盘使用率已经达到了 100%。那天，我学到了两个有用的 Unix 命令：du和df。手册页如下：

du实用程序显示每个文件参数以及以每个目录参数为根的文件层次结构中每个目录的文件系统块使用情况。

df实用程序显示有关指定文件系统或文件所属文件系统的可用磁盘空间量的统计信息。

这意味着一件事：我们必须升级磁盘大小。幸好我的同事找到了一个办法，不用停机就能完成升级。

危机解除。人们可以登录了。

结束...不是

信不信由你，但由于当时工作量巨大，我们并没有采取进一步措施来监控服务器磁盘空间，也没有深入调查导致这种情况的原因。因此，不出所料，两个月后，服务器容量再次达到了 100% ！

我们准备得更充分，很快就发现了问题所在，并升级了磁盘容量。这次，我花了一些时间去深入研究这个问题的原因，因为过去两个月我们上传的文件并不多，所以磁盘空间占用大约 90GB 是合理的。

再次，我利用du和df命令来查明占用磁盘空间的目录：

$ du -sh /var
...
170.3G    /mail
...

想象一下，邮件目录占用了 170 GB，几乎占了整个服务器磁盘空间的 80%！进一步挖掘发现，罪魁祸首是 crontab。我们运行了几个 cron 作业，crontab 会向 root 用户发送电子邮件，这些邮件存储在 中/var/mail。这些内容在 crontab 文件中清晰地列出，如下所示，但某个 cron 作业的输出却返回了大量垃圾信息，不知何故，这些垃圾信息很快就占满了整个目录。

$ crontab -l
...
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
...

现在怎么办？

行动计划是首先停止进一步的电子邮件，然后删除现有的电子邮件以释放服务器。

$ crontab -e
MAILTO="" # to disable cron emails

$ sudo rm /var/mail/ubuntu

我们更加明智地决定，应该设置一个监控服务来捕捉这个问题，以防它再次发生。我们选择的服务是Monit，而且它出奇地容易上手。它创建了一个仪表板，让我们可以轻松地可视化所有需要的数据，从磁盘空间到 CPU 使用率再到内存，并且会在自定义事件发生时发送电子邮件警报。这篇很棒的文章对如何在 Ubuntu 服务器上设置 Monit 非常有帮助。

剩下的就都过去了。我们再也没有遇到磁盘空间问题。到目前为止。

感谢阅读！下次再见👋

封面照片由Taylor Vick在 Unsplash 上拍摄