Как известно, нельзя управлять тем, что не измеряешь. В контексте IT-проектов это означает необходимость мониторинга всех частей проекта: от утилизации CPU до бизнес-показателей вроде количества заказов в интернет магазине или показов баннеров на сайте.

Чтобы сервис работал стабильно и техническая поддержка могла в режиме 24/7 быть эффективной, нужно собирать метрики, визуализировать их динамику (в дашбордах и графиках), анализировать результаты и работать с инцидентами — желательно до того, как они стали инцидентами. Однако мониторинг мониторингу рознь. Он выполняет свою функцию, если система:

1) отслеживает метрики, которые нужны для принятия решений, и не мониторит лишнее;
2) уведомляет, когда ещё можно что-то сделать без последствий для работоспособности сервиса, но не спамить ложной тревогой.

Звучит просто и логично, но на практике найти баланс не всегда легко.

Эта статья будет первой в серии заметок о том, как мы организуем мониторинг у наших 400+ клиентов. Расскажем, какие метрики снимаем, каких методологий придерживаемся и какие алерты видим каждый день.

Методологии сбора метрик

Существует три основных подхода к сбору метрик: USE (Tom Wilkie), RED (Brendan Gregg), LTES (Google SRE). Они отличаются по целям мониторинга и, естественно, включают разный набор метрик (но «E» везде отвечает за ошибки). Давайте разберем каждый из них отдельно.

В методологии USE для каждого ресурса (CPU, дисковая подсистема, память и т.д.) рекомендуется снимать следующие метрики:

• Utilization — время или процент использования ресурса, занятого «полезной работой»;
• Saturation — насыщенность, то есть количество отложенной или поставленной в очередь «работы»;
• Errors — количество ошибок в работе компонента.

RED предлагает мониторить:

• Rate — количество запросов в единицу времени (например, rps на микросервис или сервер);
• Errors — количество ошибок;
• Duration (оно же latency) — время обработки одного запроса.

В LTES по аналогии с двумя предыдущими методологиями отслеживают:

• Latency — время на обработку одного запроса (с разделением на успешные и ошибочные запросы);
• Traffic — количество запросов к компоненту (для веб-сервера это могут http-запросы, для базы данных — транзакции и т.п.);
• Errors — количество ошибок;
• Saturation — здесь это количественная метрика, отражающая, насколько компонент использует свои ресурсы и сколько у него «работы в очереди».

Нельзя сказать, что какая-то из этих методологий «правильная». Каждый отдельный компонент системы нужно мониторить, основываясь на здравом смысле. Для веб- или application-сервера лучше подходят RED и LTES, для шины данных или обработчиков очередей задач — USE.

Концепции алертинга

Построение алертинга — системы автоматического оповещения о том, что метрика достигла порогового значения, — основывается на концепциях SLI, SLA и SLO.

SLI (Service level indicators) — набор ключевых метрик, по которым можно определить жизненный статус сервиса, его производительность, «удовлетворенность» конечных пользователей работой сервиса. Например, в SLI может входить количество 500-х ошибок или количество активных пользователей.

SLA (Service level agreement) — так называемое «соглашение об уровне доступности сервиса», которое определяется как ВНЕШНЕЕ обязательство перед конечным пользователем или клиентом. Например, SLA нашей круглосуточной техподдержки обычно составляет 15 минут — за это время мы обязуемся отреагировать на запрос или инцидент клиента, и это не зависит от внутренних обстоятельств.

SLO (Service level objectives) — набор целевых, «желаемых» значений SLI, выход за пределы которых может привести к нарушению SLA конкретного сервиса или компонента. Максимально допустимое отклонение от «идеальных» показателей в данной концепции называется Error Budget (право на ошибку). Как пример, это может быть: максимальное количество 500-х ошибок за 5 минут, максимальное время недоступности веб-страницы, максимально допустимая нагрузка на процессор и т д.

Казалось бы, SLO и есть тот порог, на который надо установить алерты. Но SLO — это «желаемое» состояние, и не всё, что от него отличается, обязательно является нештатной ситуацией. Если настроить алерты на отклонение от SLO, то, с одной стороны, возрастает вероятность появления так называемого «алертного шума» — большого количества оповещений при вполне адекватной работе системы, с другой — есть риск получить алерт только в момент нарушения SLA.

Простыми словами: алерт должен срабатывать не тогда, когда «всё уже очень плохо», и не от каждой «помехи», а тогда, когда возникла проблема, но ещё можно что-то исправить.

По нашему опыту, чтобы достичь этого баланса, внутренние алерты лучше всего устанавливать на значения, находящееся между SLO и Error Budget — когда поведение системы еще можно назвать штатным, но если ничего не предпринять, есть риск выйти за пределы SLA.

Метрики и пороговые значения

Так как это первая статья в цикле, здесь мы решили привести список алертов на базовые системные метрики. Если ваша система мониторинга в зачаточном состоянии, то смело начните с этого списка — ниже объясним, в чём смысл и важность каждого пункта. Если вы уже в теме, то просто пройдитесь по списку как по чек-листу — вдруг что-то упускаете.

CPU. Для мониторинга использования процессорного времени на сервере мы обычно выставляем два базовых алерта:

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

На их основе можно идентифицировать критически высокую нагрузку на сервере (при этом фиксируем не разовые скачки, которые в большинстве случаев являются нормой, а постоянно высокий уровень в течение какого-то времени — в нашем случае это 10 минут), а также недоступность сервера.

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

• заполнение SWAP > 90% (актуально для версий ядра Linux младше третей);
• активная запись в SWAP (swapin > 1 Мбайт/с) в течение 2-5 минут (актуально для новых версий ядра Linux)
• используемая оперативная память > 85%.

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

Дисковая подсистема. Основные алерты по метрикам в дисковой подсистеме, которые мы настраиваем практически всем клиентам, это:

• нагрузка на диск (iostat) > 95% в течение 1 часа;
• free inodes (по каждому разделу) <10%;
• свободное место на диске (по каждому разделу) <10% + дополнительный алерт < 5%.

Слишком высокая нагрузка на дисковую подсистему чревата полной деградацией всей системы. Например, если снизится скорость чтения/записи данных на диск, то это может повлиять на скорость формирования кеша и работы с БД. А если кончится место или свободные inodes, то запись на диск полностью остановится, что приведёт к блокировке работы всего сервиса или потере чувствительных данных. А в некоторых случаях к «битым» базам данных, которые админы будут долго и мучительно пытаться восстановить.

Однако, конфигурируя алерты на процент свободного места, стоит учесть, какое ПО на сервере. Например, если этот сервер делает бэкапы, т.е. бывает периодическое резкое увеличение объема данных, или на нём работает ElasticSearch, то лучше иметь свободными 15% от большого диска. Если же ничего подобного там нет или объем дисковой подсистемы измеряется десятками терабайт, то скорее всего алерт на 10% — избыточная перестраховка, и порог срабатывания можно смело снизить до 3−5%.

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

Дополнительный мониторинг дисков:

• результат SMART-теста диска отличается от passed — если тест не пройден (статус failed), диск может быть неисправен, и есть риск потерять данные;
• количество поврежденных (переназначенных) секторов HDD > 1;
• процент износа SSD — < 10% от полезного срока службы. Как правило производитель определяет порог, после которого диск переходит в read-only режим;
• процент использования NVMe > 90%;
• объем резервной области NVMe < 15%;
• ошибки целостности данных NVMe > 1.

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

• алерт на «вылет» диска из рейда;
• алерт, срабатывающий в начале проверки/синхронизации после восстановления диска в массиве (помогает понять, что резкие скачки в нагрузке на CPU или память временные и не являются проблемой);
• количество битых дисков > 1.

Если контроллер имеется, то дополнительно имеет смысл поставить алерты на различные ошибки, здоровье, кеш, состояние батареи и т.д.

Синхронизация времени на сервере с эталонным. Рассинхронизация времени иногда приводит к сложнодиагностируемым ошибкам как в серверном ПО, так и в клиентских приложениях. Поэтому мы мониторим ее, запрашивая статус используемых на сервере утилит синхронизации времени, например, ntpd, chronyd или systemd-timesyncd, и используем алерты следующего вида:

• > 500 миллисекунд в течение 5 минут;
• < 500 миллисекунд в течение 5 минут.

Большая рассинхронизация иногда приводит к интересным последствиям. Например, нам встречались ошибки в репликации данных между двумя базами (как в схеме мастер-слейв так и мастер-мастер) или получение логов «из будущего». Также отставание времени на сервере может неприятно повлиять на работу интернет-магазинов: например крон-задание, которое должно запускаться ровно в полночь, из-за рассинхрона времени запустится раньше или позже обычного и нарушит формирование отчетов — как внутренних, так и внешних, скажем, для налоговой.

Сетевые интерфейсы. Мониторить объем входящего и исходящего трафика может быть необходимо из-за специфики тарификации трафика или когда заведомо известно о проблемах с сетевым каналом. Кроме того, если сервер используется для раздачи контента, резкие скачки нагрузки на канал могут сигнализировать о какой-либо аномалии, например, DDoS-атаке. В нашей практике алерты на сетевые интерфейсы чаще всего устанавливаются по просьбе клиентов и отслеживают следующее:

• входящая нагрузка >75% или >90% от лимита;
• исходящая нагрузка >75% или >90% от лимита;
• алерт на резкий (и нехарактерный при этом) скачок входящего или исходящего трафика.

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

Нет большого смысла мониторить те метрики, с которыми непонятно что делать или которые дороже собирать и обрабатывать, чем могут быть потенциальные издержки от отсутствия мониторинга на них. А алерты не должны возникать каждые две секунды и сливаться в белый шум— тут, мы надеемся, помогут пороговые значения, приведенные в статье. В них вложено 13 лет опыта и практика настройки мониторинга тысяч и тысяч серверов наших клиентов.

В следующих статьях поговорим о мониторинге системного ПО, application-уровня, системах виртуализации и контейнеризации.