Мониторинг

Введение

User space ПО не имеет прямого доступа к инфе о current состоянии системы и процессов, поэтому в linux есть “каталог” /proc, где и хранится вся инфа в виде файлов (linux же) о состоянии железа, процессов и т.д. Но это не настоящий каталог - он нигде не хранится (ни на SSD/HDD, ни на RAM) (и файлы там имеют нулевой размер), он просто генерируется на лету, когда запрашиваешь данные (по команде ls, например). Получается, ПО типа ps, htop, uname, uptime и т.п. берут инфу из этого каталога.

cat /proc/version
# и
uname -a
# покажут примерно одно и то же

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

  • Инфраструктурный слой Данные о работе ПО и оборудования (железо) опорной инфраструктуры

  • Прикладной слой Данные о работе ПО, реализующих бизнес-логику сервера

  • Бизнес-слой Данные об активности пользователя или конечной точки подключения


Хороший мониторинг

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

Система должна соответствовать двум принципам:

  1. Отслеживать метрики, помогающие принимать решения и НЕ мониторить лишнее.
  2. Уведомлять, когда еще что-то можно сделать без последствий для работоспособности сервиса и НЕ спамить ложной тревогой.

Source: https://www.itsumma.ru/blog/alerts

Три популярных подхода к сбору метрики:

  • LTES / 4 golden signals (Google SRE)

    • Latency Время на обработку одного запроса (с разделением на успешные/ошибочные)
    • Traffic Кол-во запросов к компоненту (для веб-сервера это могут http-запросы, для БД - транзакции и т.п.)
    • Errors Кол-во ошибок
    • Saturation Количественная метрика, отражающая, насколько компонент использует свои ресурсы и сколько у него «работы в очереди»
  • RED (Brendan Gregg)

    • Rate Кол-во запросов в единицу времени (RPS, например)
    • Errors Кол-во ошибок
    • Duration (Latency) Время обработки одного запроса
  • USE (Tom Wilkie)

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

Для веб- или application-сервера лучше подходят RED и LTES, для шины данных или обработчиков очередей задач - USE.

Source: https://www.itsumma.ru/blog/alerts


Prometheus Алертинг Мониторинг, который я разворачивал в рамках практической работы: Module 22 Мониторинг HTTP status codes

monitoring