Перейти к содержимому

Мониторинг сервера - что смотреть до того, как сайт упадёт

Смотрим состояние сервера регулярно, чтобы узнавать о проблемах раньше, чем о них сообщат посетители.

Решение

Проверяем место на разделах:

Окно терминала
df -h / /home /var # сайт, база и журналы часто на разных
du -sh /home/bitrix/www/upload/ /home/bitrix/www/bitrix/backup/ 2>/dev/null
du -sh /var/log/ /var/lib/mysql/
df -i /home # свободные записи файлов, а не байты
# смотреть стоит все три раздела: они кончаются по-разному

Кончившееся место роняет сайт быстрее любой ошибки в коде: перестают писаться кэш, сессии и журналы, а база отказывается принимать записи. Три обычных пожирателя места - загрузки сайта, резервные копии и системные журналы.

Смотрим память и нагрузку:

Окно терминала
free -m
uptime # средняя нагрузка за 1, 5 и 15 минут
nproc # с чем эту нагрузку сравнивать
dmesg | grep -i 'killed process' | tail -5

Средняя нагрузка выше числа ядер процессора означает очередь задач. Записи об убитых процессах - прямое доказательство нехватки памяти, и они появляются раньше, чем посетители начинают жаловаться.

Смотрим состояние базы:

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SELECT table_schema, ROUND(SUM(data_length + index_length)/1024/1024) AS mb
FROM information_schema.tables GROUP BY table_schema;
-- размер базы стоит знать до того, как он упрётся в место на диске

База растёт незаметно и упирается либо в место на диске, либо в число одновременных соединений. Обе величины стоит знать заранее, а не выяснять их в момент отказа сайта.

Проверяем сайт средствами платформы:

Окно терминала
# проверка системы: соответствие требованиям и права на файлы
php -f /home/bitrix/www/bitrix/modules/main/tools/check_system.php 2>/dev/null | tail -20

Проверка системы из админки показывает несоответствия требованиям и проблемы с правами на файлы. Её проходят после каждого обновления окружения и продукта, а вовсе не только при первой установке сайта.

Пороги тревоги задают заранее, а не в момент отказа сервера. Место меньше пятнадцати процентов свободного, средняя нагрузка выше числа ядер, растущее число медленных запросов - все три показателя дают запас в дни, а не в минуты.

Регулярность здесь важнее полноты набора показателей. Пять команд раз в неделю дают больше, чем сложная система мониторинга, в которую никто не смотрит, и на одиночном сервере такого набора обычно достаточно.

Журналы без настроенной ротации сами со временем становятся причиной отказа. Растущий журнал ошибок съедает раздел за неделю на посещаемом сайте, и настраивают его ротацию до того, как это случится в первый раз.

Типичные проблемы

Сайт упал без изменений в коде.

На одном из разделов кончилось свободное место. Первым делом смотрят разделы с файлами сайта, базой данных и системными журналами.

Процессы падают под нагрузкой.

Серверу не хватает памяти, и система убивает процессы. Видно это именно в журнале ядра системы, а не в журналах самого сайта.

База отказывает в соединении.

Сайт упёрся в предел числа одновременных соединений с базой. Число процессов PHP согласуют именно с этим пределом.

Место кончилось из-за журналов.

У системных журналов не настроена ротация файлов. Они растут постоянно и сами себя не чистят.

После обновления окружения появились странные сбои.

После обновления не пройдена проверка системы. Она называет несоответствия требованиям прямо, а не через побочные симптомы.

Частые вопросы

Нужна ли отдельная система мониторинга?

На одном сервере хватает регулярной проверки этих команд и оповещений хостинга. Отдельная система окупается на нескольких серверах и на круглосуточных магазинах.

Как часто смотреть показатели?

Раз в неделю в спокойное время и обязательно после каждого обновления. Ежедневный просмотр нужен только на растущем проекте.

Что чистить в первую очередь при нехватке места?

Старые резервные копии, журналы и кэш. Загрузки сайта не трогают: там лежат картинки товаров и файлы заказов.

Как понять, что пора на сервер помощнее?

По устойчивой очереди к процессам PHP при уже включённом кэше и по нехватке памяти под нагрузкой. До этого дешевле настроить кэш и запросы.

Смежное

Первоисточник