Как я делал мониторинг

Часть лирическая. Комментированием «отладочных» строчек исходников обычно и заканчивается основная работа над проектом. На этот раз проект был жутко размазан во времени на два месяца и пересекался с другими. Но наконец он завершен, можно вздохнуть спокойно… и начать получать профит.
Мониторинг — признак зрелости, завершённости структуры. Созданием мониторинга своего айтишного «хозяйства» закрываю некую «главу».

Часть нетехническая.
Итак, мониторинг. В общем жить можно и без него. Просто узнавать о больших сбоях по возмущенным крикам/просьбам/мольбам по телефону или почте. А о маленьких и не догадываться. В итоге — убытки, нервы и репутация, в конце концов. Отсутствие мониторинга это типичная ситуация по той простой причине что обычно руки до этого не доходят. Хотя нет, вру. Просто всем пофиг. Админам, разработчикам, пользователям.

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

Часть техническая.
Какие интересные вопросы решены при разработке:

1. Кто мониторит сам мониторинг?
Как система должна реагировать на собственные сбои? Ведь мониторинг зависит от провайдера дата-центра, каналов связи, железа сервера, программных сбоев, сбоев/откатов баз данных.
Решение вопроса самомониторинга без излишнего усложнения самого проекта было самой интересной частью работы.

Я решил не создавать алгоритм подробного анализа и карту сбоев. Это всё интересно для человека, но не для алгоритма индикаторов. Выделяется лишь период «недоверия» (non trust) системы к себе и делается склейка повторных «мульти»-сбоев. На стороне конкретных «индикаторов» периоды доверия/недоверия учитывается в основном алгоритме.

2. Шкала уровня проблемы.
Каждая обнаруженная проблема имеет свой приоритет и важность. Так, например, сбой канала связи в пару минут, в нерабочее время — лишь повод для записи в журнал событий с пометкой «уведомление». Но сбой «основного сервера» в пик нагрузки это повод отправить смс на телефон администратора, а при неустранении за определенное время — оповестить по почте его начальника.
За основу была взята nix-овая система из 9 уровней nothing..emergency. Подробности в отдельном посте Приоритет событий (уровень важности сообщений) в мониторинге и логах

3. Ненавязчивые уведомления
Решение в дискретизации статуса и уровня проблемы по значения индикатора. В зависимости от уровня проблемы и модуля используется необходимый email и, если требуется, номер телефона для sms. Никаких повторных уведомлений без существенного изменения статуса проблемы.
У типового индикатора, с ростом значения, а значит и со временем, ростёт уровень. Например — сбой длительностью 5 минут имеет уровень — notify, 20 минут — warning, 60 — error, час — уже critical, 2 часа — alert.
Кроме того, в уведомлениях и алгоритме следует учитывать и рабочее (актуальное) время для каждого индикатора. Решается простым массивом и функцией на 5 строк.

Для уведомлений в моей конфигурации назначены 3 почтовых ящика и 2 телефона для смс.
Первый, личный, телефон отвечает только за сбои уровня «alert» (самый высокий для системы). Второй, рабочий телефон, получает смс о меньших, но тоже важных сбоях «critical». Рабочий телефон в нерабочее время стоит на вибре и не отвлекает. Однако если проблема доростает до уровня «alert» — зазвенит личный.
Аналогично и с почтой. На основной email приходят уведомления о сбоях alert и critical, второй — дублирует + события error. На третий, «мусорный» ящик, приходят все события, включая уведомления с более низкими статусами «warning» и «notify».
Такая система позволяет получать информацию ненавязчиво и реагировать по мере возможности.

4. Безопасный способ обмена данными в системе
Авторизация с учётом атаки «man in the middle» и шифрование данных: классическое, взбивка и шум. Но здесь я скорее хотел размяться вместо того чтобы использовать массу готовых решений.

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

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

Подробности, возможно, будут в отдельных постах.

Похожие записи:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *