在過去的幾年裡，我們一直在為數千個網站提供服務的多個 apache 伺服器前面運行 Varnish 作為快取和負載平衡器。
我們也使用 monit 來確保如果 varnish 死機，它會重新啟動。 Monitrc 中的清漆部分如下所示：
# 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，並且使用者通常不會注意到。
然而，在過去的幾周里，我們看到了一系列的故障，通常持續幾個小時，並且用戶注意到連接故障。今天的情況特別糟糕。
正如“Varnish crashing”部分所建議的那樣，系統日誌中沒有任何線索（順便說一句，這是一個 debian box）：https://www.varnish-cache.org/docs/3.0/tutorial/troubleshooting.html我們在那裡看到的是 monit 檢查連接埠 80 失敗，然後停止並啟動 varnish。
此外，我們沒有看到後端網路伺服器的頻寬或點擊次數出現任何峰值，這表明它在高於正常負載的情況下發生了故障。
我們運行的是 Varnish 3.0.3，我將其升級到 3.0.7，但問題仍然存在。沒有對該框進行任何與問題開始一致的其他更改，並且清漆配置在相當長的時間內沒有更改。
有沒有人有過類似的清漆經驗，或對進一步解決此問題有任何建議？會不會是某種攻擊？
非常感謝任何幫助或建議！
答案1
您在這裡的方法似乎有點嚴厲，因為請求失敗的原因有很多，並非所有原因都是清漆問題（例如連接問題、後端故障等）重新啟動清漆會在再次啟動時導致中斷，所以只能作為最後的手段使用。
在重新啟動任何操作之前，我建議varnishadm debug.health在 varnish 框上運行以查看 varnish 認為您的後端處於什麼狀態。
- 如果後端被認為不健康，那麼問題就出在 varnish 和後端之間（或後端本身）。檢查後端的網路以及後端的任何監控。
- 如果後端被認為是健康的，那麼問題就出在 monit 和 varnish 之間。檢查清漆伺服器的網絡，並調試監控本身。
- 如果 varnishadm 程序無法建立連接，則問題出在 varnish 本身。檢查哪些 varnish 程序正在運行，並在日誌中查找 varnish 的任何錯誤訊息。