Skip to content

Мониторинг

Введение

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

Bash
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