TeamLead
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Метрики

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

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

Он выполняет свою функцию, если система:

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

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

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

USE

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

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

RED

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

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

LTES

В 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.

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