Мониторинг начинается с метрик. Часть 2: серверное ПО

Мониторинг виртуальных машин 

Если на сервере запущены виртуальные машины, рекомендуем сконфигурировать следующие алерты:

• на изменение количества виртуальных машин на хост-машине;

• на количество виртуальных машин в статусе != running.

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

• CPU Load Average превышает количество доступных процессоров и не равно 0 в течение 5 минут.

• CPU Idle < 10% за последние 10 минут.

• объем свободного места на диске < 10%.

• free inodes <10%.

• нагрузка на диск (iostat) > 95% в течение 1 часа.

• ntpd ±500 секунд в течение 5 минут.

• заполнение SWAP > 90%.

• используемая оперативная память > 85% от доступного объема.

Мониторинг контейнеров

Минимальное покрытие мониторингом для сервера, который используется для запуска контейнеризированных приложений без дополнительных средств оркестрации вроде Kubernetes и Docker Swarm, на наш взгляд состоит из следующих алертов:

• Docker / docker_alive — алерт на приостановку работы сервиса docker.

• Docker / KVM / LXC amount_changed — алерт на изменение количества запущенных контейнеров. При этом всегда необходимо уточнить, была ли приостановка плановой (в случае уменьшения), или же необходимо поставить на мониторинг новый контейнер (в случае увеличения).

• Docker / KVM / LXC — алерт на то, что контейнер с конкретным названием или маской остановлен. Аналогично предыдущему пункту, остановка может быть как плановой, так и произойти в случае аварии.

О мониторинге и алертах для инструментов оркестрации (Kubernetes, Docker Swarm и подобных) поговорим в одной из следующих статей.

Мониторинг веб-серверов 

Веб-сервер — один из главных компонентов любого веб-проекта, он первым «встречает» пользовательский трафик. Здесь мы рассматриваем nginx и Apache как самые популярные и часто встречающиеся в нашей работе. В нашей практике набор метрик и алертов для покрытия мониторингом веб-сервера выглядит так:

• Nginx status (RPS). Алерт при нулевом RPS в течение 10 минут (в 99% случаев свидетельствует о том, что веб-сервер не работает) и алерт на значительное, в разы, превышение стандартной нагрузки. Что является нормальной, а что аномальной нагрузкой, как раз и позволяет определить статистика по этой метрике.

• Apache sent no data. В нашей системе мониторинга такой алерт срабатывает, когда агент мониторинга не может получить от Apache данные по количеству свободных воркеров в течение трёх минут, и сигнализирует также о том, что веб-сервер не работает.

• Apache IdleWorkers. Триггером для активации алерта является отсутствие свободных воркеров в течение трёх минут. Без свободных воркеров возникает очередь входящих ожидающих обработки запросов к веб-серверу, что может привести к «отваливанию» пользователей.

• Apache/Nginx 5xx_errors. Порог срабатывания алерта на количество «пятисотых» ошибок определяется индивидуально и зависит от нормальной активности на сервере. Если «пятисотых» слишком много, это может свидетельствовать об ошибках как в коде приложения, так и в инфраструктуре проекта.

• Apache/Nginx 4xx_errors. Порог на количество «четырёхсотых» также определяется индивидуально в зависимости от средней активности на сервере. Срабатывание алерта может свидетельствовать как об ошибках в коде приложения или инфраструктуре (например, об ошибках в системе синхронизации контента на CDN-серверах), так и о DDoS-атаках или попытках взлома, например, личного кабинета пользователя, путем подбора пароля;

• Apache/Nginx -rate. Процентное соотношение количества ошибок определенного кода к общему потоку запросов к веб-серверу. Очень полезный алерт, с помощью которого можно определить, например, что ошибок всего лишь 0,5% от общего количества и ситуация далека от критичной. А вот если их 50%, то что-то явно идёт не так.

Мониторинг application-серверов

Application-сервер — компонент, который непосредственно отвечает за работу проекта, реализует выполнение кода, обрабатывает пользовательские запросы и запросы к базе данных и т д. Поэтому, конечно, является одним из самых важных объектов мониторинга. В статье мы также рассмотрим наиболее часто встречающиеся в нашей работе application-серверы — PHP-FPM и Apache. Но в общем и целом описанные подходы можно использовать в мониторинге любых application-серверов.

Для PHP-FPM «из коробки» мы выставляем следующие алерты:

• RPS = 0 в течение трёх минут — сигнализирует о том, что пользовательские запросы не попадают в пул обработки.

• timeout 3 min — данные с application-сервера не приходят в течение трёх минут, значит, вероятнее всего, данный компонент недоступен.

Также на практике мы не выставляем алерты, но собираем следующие метрики (чтобы как раз в случае необходимости настройки алертов у нас была статистика обычного поведения системы):

• MAX CHILDREN REACHED — сколько раз с момента запуска PHP-FPM количество дочерних процессов достигало лимита. Мониторим увеличение значения параметра: резкий рост означает, что лимит слишком низкий и не позволяет обработать все входящие запросы, и, скорее всего, приведёт к «пятисотым». 

• ACTIVE PROCESSES — количество активных процессов.

• IDLE PROCESSES — количество простаивающих процессов.

• TOTAL PROCESSES — общее количество простаивающих и активных процессов, которое должно быть равно сумме двух предыдущих метрик.

• LQUEUE (listen queue length) — определяет максимальное количество подключений, которые будут поставлены в очередь.

Для Apache рекомендуем устанавливать следующие алерты:

• Idle Workers = 0 в течение трёх минут — сигнализирует о том, что у application-сервера нет свободных потоков для обработки запросов.

• timeout 3 min — аналогично мониторингу PHP-FPM сигнализирует о недоступности сервера.

Аналогично тому, как мы организовываем мониторинг PHP-FMP, для Apache собираем такие метрики:

• TOTAL ACCESS — общее количество воркеров (потоков, процессов) application-сервера.

• BUSY WORKERS — количество «занятых» воркеров.

• KEEPALIVE (READ) — количество воркеров в состоянии keepalive.

• READING REQUEST — количество воркеров в состоянии read.

• SENDING REPLY — количество воркеров в состоянии send.

• LOGGING — количество воркеров в состоянии logging.

• CLOSING CONNECTION — количество воркеров в состоянии closing.

• GRACEFULLY FINISHING — количество воркеров в состоянии finishing.

• DNS LOOKUP — количество воркеров в состоянии dnslookup.

• IDLE CLEANUP OF WORKER — количество воркеров в состоянии cleanup.

Мониторинг Supervisor’а и кастомных сервисов

Помимо web- и application-серверов на серверах любого веб-проекта могут встречаться и другие виды приложений, требующие постоянной и бесперебойной работы. Например: обработчики очередей (рассылка сообщений, асинхронная обработка запросов), Node.js-приложения, сценарии оболочки и т д. 

Рассмотрим мониторинг данного уровня на примере популярного инструмента для управления приложениями и сервисами Supervisor. Для него на наш взгляд основными являются следующие алерты:

• supervisor is_alive — алерт на «живость» самого менеджера процессов Supervisor.

• amout_changed — алерт, срабатывающий при изменении количества запущенных supervisor’ом процессов. По аналогии с мониторингом контейнеризированных приложений алерт может сработать при плановой остановке или быть маркером аварии аварию.

• supervisor — алерт, срабатывающий при остановке конкретного процесса.

Если же вы используете для управления кастомными сервисами и приложениями какой-либо другой менеджер (например systemctl), рекомендуем в любом случае установить два алерта:

• is_alive — алерт на остановку или рестарт конкретного сервиса (опять же, если алерт сработал, нужно выяснить, была ли остановка плановой, либо это результат ошибки в работе данного компонента или компонента, с которым он взаимодействует).

• errors_count — алерт, срабатывающий при возникновении ошибок в работе сервиса, обрабатываемых самим сервисом без его перезагрузки/остановки (порог определяется индивидуально).

Мониторинг доступности URL’ов, доменов и SSL-сертификатов

Кроме мониторинга проекта «изнутри», сбора метрик и настройки алертов на работу серверов, железа, ПО, на наш взгляд, любой проект ВСЕГДА необходимо мониторить и «снаружи» — чтобы знать, как работу нашего проекта видят конечные пользователи.

Это может быть проверка доступности конкретных endpoint’ов сайта, проверка на наличие необходимого контента на определенной странице сайта, географически распределенный мониторинг доступности проекта из разных регионов и так далее. 

Вот список алертов, которые позволят сконфигурировать базовый мониторинг внешнего состояния проекта:

• HTTP CODE — срабатывает, когда http-код ответа отличается от «нормального» (2хх, 3хх) в течение двух минут. Показывает, что какая-либо страница (например, конкретная новость в новостной ленте, статья в блоге или карточка товара) недоступна для пользователей из-за ошибки в работе приложения, инфраструктуры или ошибок на уровне интернет-провайдера.

• PAGE SIZE — оповещает, что размер ответа при запросе к конкретному URL изменился. Данная ситуация может произойти, например, при ошибках в работе шаблонизатора, ошибках при взаимодействии с базой данных, случайно удаленным блоком на странице в процессе разработки и так далее. Обычно устанавливаем пороги срабатывания в ±20% от «эталонного» значения.

• RESPONSE TIME — срабатывает, когда время ответа на запрос больше «нормального» в течение трех минут. Помогает заметить проблемы с взаимодействием с БД (например, нет индекса по полю, по которому ведется выборка при генерации страницы), сетевые проблемы, проблемы, возникшие в результате выкладки новой неоптимизированной версии кода и т.д.

• sent no data — если система мониторинга не получает данные метрик, это тоже повод для алерта. Может свидетельствовать как об аварии, так и об ошибках в работе самой системы мониторинга.

• SSL-cert expire date, domain expire date — напоминает, когда до истечения срока действия SSL-сертификата или регистрации домена остается менее 7 дней. 

Выводы

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

В этой статье получилось привести меньше конкретных рекомендаций по пороговым значениям, чем в прошлой. В случае приложений, в отличие от системных параметров, они гораздо больше зависят от специфики проекта и используемого ПО. Здесь не меньшее значение приобретает наблюдение за штатным поведением системы и логирование ключевых метрик — именно их мы и постарались перечислить, чтобы в случае нештатной ситуации можно было определить, что она нештатная и предпринять соответствующие действия. Без этого не добиться аптайма в четыре девятки.

Ну, а в следующей статье расскажем о наших принципах мониторинга баз данных (MySQL, PostgreSQL, MongoDB и других).