Мониторим: Статистика vs реагирование

Расскажу о двух видах мониторинга, неважно чего –ИТ инфраструктуры, людей, объектов и т.д. – оперативном и статистическом.

Цели, способы сбора, задачи, пользователи - разные.

Вид первый - оперативный мониторинг:

Оперативный мониторинг нужен для реактивной реакции - то есть по факту того, что проблема случилась.

Пользователи такого мониторинга – диспетчера, дежурные смены, персонал, который смотрит за тем, чтобы 24/7 работа продолжалась.

Вот так обычно выглядит результат работы оперативного мониторинга:

Как правило, такие люди могут сами начать решение проблемы или передают и контролируют эскалацию. Технически оперативный мониторинг должен как можно более точнее отражать текущее состояние инфраструктуры и быстро уведомлять о смене статуса ее готовности.

Быстрое обновление состояния - это главная задача оперативного мониторинга. В больших сложных инфраструктурах оперативный мониторинг нужен, чтобы судить об успешности восстановления и часто от его скорости зависят действия по восстановлению. Проверить сеть из 5000 устройств руками нельзя – поэтому после исправления ситуации инженеры ждут результатов мониторинга. И если результаты видны не сразу, скорость работ может сильно замедлится. Типичный пример – «мы все сделали, руками 3 проверки сделали, просто мониторинг тормозит».

Второй вид мониторинга – аналитический или статистический.

Он выглядит несколько по-другому, обычно так:

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

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

И немного общих слов

Вроде бы банально, но важно отличать и понимать разницу между этими двумя сущностями.

Потому что задачи, технические характеристики, пользователи и ожидаемые результаты у этих двух систем разные. И попытки смешивать, как правило, свидетельствуют о той или иной «ошибке» - архитектурной, управленческой, технической и недешево обходятся.

Приведу примеры – попытка хранить 100% исторических данных часто ведет к экспоненциальному удорожанию железа, в то время как сохранение 95% достаточно для долговременной аналитики.

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

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

Особенности, направленные на 100% точность результатов статистики сильно замедляют производительность – например, возможность чтения из хранилища истории данных для работы триггеров создает много операций чтения и тормозит заливку данных.

В Glaber я пытаюсь разделить оперативный и аналитический мониторинг, это позволяет сильно ускорять работу, время запуска, производительность, но может приводить к несколько иной логике работы или результатам чем ожидаются от Zabbix.

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

Так делается, чтобы а) не перегружать «дорогую» SQL базу состоянием всех элементов мониторинга и б) отображать действительно валидную информация.

В Zabbix же при старте последняя информация считывается их БД и отображается то, что было загружено из базы, хоть потенциально информация может быть и сильно устаревшей. И у операторов оперативного мониторинга возникает дополнительная задача – проверка времени информации для понимания адекватности данных.

Вы скажете «рестарт сервера – задача разовая, стартовали и работает, на работу не влияет». А вот и нет. Отдельно об этом напишу.