Лак, переставший работать периодически ни по какой очевидной причине
В течение последних нескольких лет мы выполняли Лак как кэш и подсистему балансировки нагрузки перед несколькими апачскими серверами, служащими нескольким тысячам веб-сайтов.
Мы также используем monit, чтобы гарантировать, что, если лак когда-нибудь умирает, он перезапущен. Раздел лака в 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 соответственно и это обычно непримечательно пользователям.
Однако за последние несколько недель мы видим шквалы этих отказов, обычно в течение нескольких часов, и пользователи замечают сбои соединения. Сегодня было особенно плохо.
Нет никаких подсказок в системном журнале (это - debian поле btw), как предложено разделом "Varnish crashing" в: https://www.varnish-cache.org/docs/3.0/tutorial/troubleshooting.html и все, что мы видим там, являются monit сбой, это, проверяют порт 80 затем остановок и запуск лака.
Дополнительно мы не видим скачка в пропускной способности или количестве хитов к веб-серверам бэкенда, которые предположили бы, что это перестало работать под выше, чем нормальная нагрузка.
Мы выполняли Лак 3.0.3, который я обновил до 3.0.7, но проблема продолжилась. Никакие другие изменения не были внесены в это поле, которые совпадают с запуском задач, и конфигурация лака не была изменена в довольно долгое время.
Кто-либо имел какой-либо подобный опыт с лаком или имеет какие-либо предложения при поиске и устранении неисправностей этого далее? Это могло быть своего рода нападение?
Любая справка или совет значительно ценятся!
Ваш подход здесь кажется немного тяжеловесным, так как есть много причин, по которым запрос может провалиться, не все из которых являются проблемами с лаком (например, проблемы с соединением, сбои на задней панели и т.д.) Перезапуск лака приведет к отключению во время его повторного запуска, поэтому его следует использовать только в качестве крайней меры.
Перед перезапуском я бы порекомендовал запустить paintadm debug.health на лаковом блоке, чтобы посмотреть, в каком состоянии находится ваша бэкэнд. В зависимости от результата, вы можете решить, где искать дальше:
- Если бэкэнд считается нездоровым, то проблема лежит между лаком и бэкэндом (или в самом бэкэнде). Проверьте подключение к сети, а также мониторинг бэкэнда.
- Если бэкэнд считается здоровым, то проблема заключается в том, что между монитором и бэкэндом находится лак. Проверьте подключение к лаковому серверу, а также отладьте сам мониторинг.
- Если лакировочный процесс не может установить соединение, то проблема заключается в самом лакировании. Проверьте, какие лаковые процессы запущены и ищите сообщения об ошибках в логах.