在过去的几年中，我们一直在为数千个网站提供服务的多个 Apache 服务器前运行 Varnish 作为缓存和负载均衡器。
我们还使用 monit 来确保如果 varnish 死机，它会重新启动。monitrc 中的 varnish 部分如下所示：
# Check varnish on port 80
check process varnish with pidfile /var/run/varnishd.pid
start program = "/etc/init.d/varnish start"
stop program = "/etc/init.d/varnish stop"
if failed host 127.0.0.1 port 80 protocol http
and request "/monit-check-url"
then restart
至少 3 年来，它一直运行良好。我们偶尔会遇到 80 端口检查失败的情况，但 monit 会相应地重新启动 varnish，因此用户通常不会注意到。
然而，在过去几周里，我们经常看到此类故障，通常持续几个小时，用户会注意到连接失败。今天的情况尤其糟糕。
系统日志中没有找到任何线索（顺便说一下，它是一个 Debian 机器），正如“Varnish 崩溃”部分所暗示的那样：https://www.varnish-cache.org/docs/3.0/tutorial/troubleshooting.html我们在其中看到的是 monit 未能检查端口 80，然后停止并启动 varnish。
此外，我们没有看到后端网络服务器的带宽或点击次数出现任何峰值，这表明它在高于正常负载的情况下出现故障。
我们之前运行的是 Varnish 3.0.3，我将其升级到了 3.0.7，但问题仍然存在。此机器没有进行与问题开始相关的其他任何更改，而且 Varnish 配置很长时间没有更改了。
有没有人有过类似的使用 varnish 的经历，或者对进一步排除故障有什么建议？这可能是某种攻击吗？
非常感谢任何帮助或建议！
答案1
您在这里的方法似乎有点过于严厉，因为请求失败的原因有很多，并非所有原因都是 varnish 问题（例如连接问题、后端故障等）重新启动 varnish 会在重新启动时导致中断，因此只能作为最后的手段。
在重新启动任何程序之前，我建议先运行varnishadm debug.health一下 varnish 盒，看看 varnish 认为你的后端处于什么状态。根据结果，你可以决定进一步查看哪里：
- 如果后端被认为不健康，那么问题就在于 varnish 和后端之间（或后端本身）。检查后端的网络，以及后端上的任何监控。
- 如果后端被认为是健康的，那么问题就出在 monit 和 varnish 之间。检查 varnish 服务器的网络，并调试监控本身。
- 如果 varnishadm 进程无法建立连接，则问题出在 varnish 本身。检查正在运行的 varnish 进程，并在日志中查找来自 varnish 的任何错误消息。