Ответ на вопрос “что сделать, чтобы сайт не упал” – один: пользоваться мониторингом. Если вы технический специалист и отвечаете за техническую сторону проекта – то пользоваться самому, если вы менеджер или предприниматель – настроить отправку уведомлений в вашу техслужбу (сисадмину).
Как мы выяснили в прошлом посте, банально мониторить “открываемость” главной страницы – скучно. И бесполезно для бизнеса. Если главная страница перестала открываться – это уже всё, финиш, всё так глубоко упало что вы можете даже не попасть на сервер в шелл. И придётся перезагружать его физически (кнопкой reset в датацентре, хорошо если у вас такая возможность есть).
Поэтому более правильно использовать так называемые системы прогнозирования проблем, которые на основе непрерывного мониторинга внутренних показателей могут дать вам сигнал задолго до возникновения реального ущерба.
Что можно и нужно мониторить?
Общая нагрузка (load average). Это простейший показатель “нагруженности” сервера, который показывает сколько процессов хотели, но не смогли запуститься за последнюю минуту, 5 минут и 15 минут. Если процесс не смог запуститься – значит возникает и растёт очередь, аналогичная дорожной пробке.
Растёт потребление оперативной памяти, потребление swap, резко снижается быстродействие дисковой подсистемы, программы и сайты на сервере начинают работать ощутимо медленнее, вплоть до полного отказа.
Количество запущенных процессов. Логично предположить, что чем больше процессов, тем больше очередь – что тесно связано с предыдущим показателем. Часто бывает, что сайт при резком росте нагрузки (“хабра-эффект” или ddos) не может обслужить всех пользователей, и количество процессов apache скачкообразно возрастает.
Либо, другой пример, из-за “криво” написанного кода CMS её внутренние процессы (кроны) запускаются и “зависают”, в результате чего через сутки (или через пару часов) на сервере скапливаются большое количество висящих и ничего не делающих процессов. Это однозначно свидетельствует о сбое, но подумайте как вы смогли бы заметить это без мониторинга? Разве ваш разработчик сайта никогда не делал ошибок?
Факт наличия обязательных процессов. Этот пример столь же банален, сколь часто о нём не думают. На сервере упала база данных – обычно это видно сразу, прямо на главной странице можно увидеть что-то вроде “database connect fail”. А если упал почтовый сервер? Сегодня с утра пришло в три раза меньше заявок от клиентов – это естественный спад или почтовый сервер просто не работает?
Свободная оперативная память и swap. Системы Linux, в отличие от Windows, используют почти всю оперативную память прежде чем занимать swap. Поэтому с ростом нагрузки на ваш сайт (например, в ходе рекламной кампании) объём свободной памяти будет уменьшаться почти до нуля, и при этом будет расти объём swap. А это значит, что система вместо обслуживания клиентов будет заниматься тем, чтобы перетасовывать память и перетаскивать неиспользуемые данные в swap, а используемые – обратно в “оперативку”.
Значение занятого swap, большее нуля, уже является признаком лавинообразного нарастания нагрузки на сервере. Не ждите, как правило дальше лучше не станет.
Свободное место на диске. Как показывает практика, нет таких дисков которые невозможно “забить”. Автору известны примеры, когда из-за невнимательности программиста лог-файлы ошибок возрастали до 600 гигабайт за считанные часы. А систему ротации (обрезки) логов обычно настраивают на запуск только раз в сутки или в неделю.
К тому же, если вы предоставляете вашим сотрудникам или клиентам возможность что-то загружать на сервер, то свободное место для этого тоже рано или поздно кончится.
Изменение системных файлов. Типичный пример – /etc/passwd, это файл в котором Linux хранит информацию о пользователях и паролях. Если вы давно не меняли пароли, а мониторинг вам сообщает что этот файл изменился – разве это не сигнал о возможной хакерской атаке?
Контроль полной “прогрузки” страницы. Неочевидный, но в то же время простейший фокус: достаточно мониторить, что в контенте целевых страниц присутствует “</html>”. В 99% случаев его отсутствие означает, что страница не догрузилась до конца.
“Старость” файлов-флагов. Часто требуется, чтобы процессы, запускаемые по крону (допустим каждую минуту), запускались только в единственном экземпляре и не работали параллельно. Обычно для этого запускаемый процесс в начале создаёт специальный файлик (флаг), а в конце работы – удаляет. Следующий процесс смотрит наличие файлика, и если он есть – не запускается. Подумайте, что произойдёт если первый процесс “упадёт” в середине?
Правильно. Файлик останется лежать, и следующие процессы не запустятся. Сколько часов вы готовы ждать с неработающим функционалом? Ни минуты. Поэтому следует настроить мониторинг так, чтобы он мог уведомлять вас о слишком “старых” файлах-флагах.
Автоматические действия. Бывает так, что вы далеко от цивилизации, телефон едва “ловит” мобильный интернет, и выйти в сеть посмотреть “что там с сервером” совершенно невозможно. В конце концов, это может быть просто глубокая ночь. Правильный мониторинг не будет сидеть и ждать, пока вы (или ваш сисадмин) проснётесь и прореагируете. Он выполнит заданные автоматические действия, например перезапустит службы или перезагрузит сервер в целом.
Резюме: мониторинг сервера не состоит в том, чтобы круглосуточно сидеть и наблюдать графики активности, как в плохих фильмах. Стабильность работы базируется на правильно настроенных показателях, на гибкой системе оповещения, и на автоматических действиях. Профессиональная система мониторинга trackFort обеспечивает и все эти возможности, и многие другие.