какие типы уведомлений представлены в системе мониторинга
Какие типы уведомлений представлены в системе мониторинга
Онлайн-уведомления — это один из способов оповещения пользователя об активности объекта.
Получать онлайн-уведомления могут только те пользователи, которые на момент их срабатывания авторизованы в системе. Онлайн-уведомления не хранятся в системе после завершения сессии.
Для получения онлайн-уведомлений об объекте пользователю необходимо право доступа Просмотр элемента и его основных свойств на объект, а также права доступа на просмотр элементов в зависимости от типа уведомления. Например, для получения онлайн-уведомлений о водителях необходимо право доступа Просмотр водителей.
По умолчанию онлайн-уведомления показываются во всплывающем окне, но опцию Автоматическое отображение событий можно отключить в настройках пользователя. Чтобы перейти к ручному режиму работы, отключите эту опцию. В таком случае, при необходимости, окно онлайн-уведомлений можно открыть вручную с помощью иконки 
в нижней панели. При наличии непрочитанных уведомлений, около этой иконки показывается их количество. Количество новых онлайн-уведомлений также показывается на вкладке браузера.
Настройки уведомлений
Получение онлайн-уведомлений может сопровождаться звуковым сигналом. Для этого включите опцию Воспроизведение звука при событиях в настройках пользователя. Если вместо стандартного звукового сигнала необходимо использовать другой, в свойствах уведомления надо указать URL-адрес, с которого его следует загрузить. Для разных уведомлений можно выбрать разные звуковые сигналы.
Для того чтобы визуально выделить уведомления разных типов, в настройках действий для них можно выбрать разные цвета фона.
Онлайн-уведомления можно также просматривать в мини-окнах. Для этого в свойствах уведомления необходимо включить опцию Мигание мини-окна.
Действия с уведомлениями
Для пользователей верхнего уровня и пользователей с правами дилера во всплывающем окне онлайн-уведомлений доступен фильтр Типы уведомлений.
Новые уведомления показываются в верхней части списка. Заголовок берется из названия уведомления и выделяется синим цветом. Чтобы раскрыть или скрыть полный текст уведомления, используйте кнопку-переключатель + / − или щелкните в любом месте между + / − и названием уведомления.
После щелчка по названию или тексту уведомления карта центрируется на том месте, где произошло событие. После щелчка по названию объекта карта центрируется на его последнем положении. При этом объект добавляется в рабочий список вкладки Мониторинг и на карту.
Чтобы удалить уведомление, нажмите на кнопку 
напротив его имени. Можно также удалить прочитанные или все уведомления, нажав на Удалить все или Удалить прочитанные внизу окна уведомлений.
Окно уведомлений можно перемещать по экрану. Также можно менять размеры окна, потянув за его край в нужную сторону. Позиция и размер сохраняются до следующего открытия окна уведомлений.
Регистрация произвольного события
Для регистрации произвольного события нажмите на Произвольное событие в окне онлайн-уведомлений. Событие регистрируется на основании полученных данных об активности объекта. При такой регистрации в качестве комментария используется текст уведомления. Зарегистрированное событие и комментарий к нему можно увидеть в отчете События.
Браузерные push-уведомления
Системой предусмотрена возможность настроить браузерные push-уведомления. Их преимущество заключается в том, что уведомление можно увидеть, находясь на любой вкладке вашего браузера, или когда браузер свернут. После получения первого онлайн-уведомления открывается диалоговое окно, в котором предлагается настроить получение браузерных push-уведомлений.
Типы уведомлений
Существуют различные условия срабатывания уведомления.
Скорость
В этом случае следует установить наименьшую и наибольшую разрешенные скорости, указанные на шкале двумя маркерами. Для установки маркера в нужное положение можно либо двигать его мышью, либо вводить значение с клавиатуры. Диапазон, в котором уведомление срабатывает, выделен для наглядности красным цветом.
Дополнительно может быть включен контроль значения датчика — тогда уведомление сработает только в случае соблюдения обоих условий.
Геозона
При выборе этого типа уведомлений в следующем окне необходимо указать тип контроля: срабатывать внутри геозоны или за ее пределами. Также необходимо указать геозоны или группы геозон (показываются в квадратных скобках), на которые данное уведомление будет распространяться. Для удобства поиска можно воспользоваться динамическим фильтром над списком. Геозоны должны быть созданы заранее, причем они должны принадлежать тому же ресурсу, что и само уведомление.
Выберите логический оператор — значение, на основании которого будет срабатывать уведомление.
Для объекта в геозоне:
Для объекта вне геозоны:
Дополнительно можно задать скоростные условия или значение датчика — тогда уведомление сработает только в случае соблюдения всех указанных условий.
Тревога (SOS)
Этот тип уведомления не требует настройки специфических параметров. Однако используемое Вами оборудование должно поддерживать соответствующий функционал или в свойствах объекта должен быть настроен соответствующий датчик.
Цифровой вход
Укажите номер цифрового входа, а также тип срабатывания: срабатывать в случае активации либо в случае деактивации.
Параметр в сообщении
Данный тип уведомления помогает отслеживать параметры в сообщениях. Контролируемый параметр должен быть реальным, то есть присылаемым оборудованием. Виртуальные параметры, такие как speed, alt, sats и т.п., этим типом уведомления контролироваться не могут.
Предусмотрено 4 типа контроля параметра в сообщении: диапазон значений, текстовая маска, присутствие параметра, отсутствие параметра.
Значение датчика
Если контролируется скачок значений, то необходимо ввести дельту. Уведомление сработает в случае превышения указанной дельты. Следует отметить, что с указанной дельтой сравнивается модуль дельты значений.
Потеря связи
Уведомление может срабатывать как при потере связи, так и при ее восстановлении. Выберите нужную опцию в секции «Уведомление». Возможен выбор обеих опций сразу.
Далее выберите тип контроля:
Установите время потери данных/координат (в минутах), по истечении которого сработает уведомление.
С помощью опции «Геозоны» можно контролировать потерю связи относительно определенных геозон или групп геозон. Выберите тип контроля: срабатывать внутри геозоны или за ее пределами. Также необходимо указать геозоны или группы геозон (показываются в квадратных скобках), на которые данное уведомление будет распространяться. Геозоны должны быть созданы заранее, причем они должны принадлежать тому же ресурсу, что и само уведомление.
Простой
Дополнительно может быть включен контроль значения датчика, тогда уведомление сработает только в случае соблюдения обоих условий: превышения времени простоя и наличия при этом недопустимого значения датчика. Такое сочетание удобно использовать, например, чтобы контролировать не простой как таковой, а простой с включенным двигателем или навесным оборудованием.
С помощью опции «Геозоны» можно контролировать простой относительно определенных геозон или групп геозон. Выберите тип контроля: срабатывать внутри геозоны или за ее пределами. Также необходимо указать геозоны или группы геозон (показываются в квадратных скобках), на которые данное уведомление будет распространяться. Геозоны должны быть созданы заранее, причем они должны принадлежать тому же ресурсу, что и само уведомление.
Можно получить уведомление о приходе какого-либо SMS-сообщения. Чтобы конкретизировать, какое именно SMS-сообщение будет срабатывать, введите дополнительно маску текста SMS-сообщения. Это может пригодиться, например, если оборудование шлет SMS определенного содержания в случае обнаружения неполадок.
Взаиморасположение объектов
Данное уведомление позволяет контролировать приближение объектов друг к другу и их удаление друг от друга. Следует выбрать тип проверки: приближение либо удаление и логический оператор (значение, на основании которого будет срабатывать уведомление). Если выбран «ИЛИ», уведомление активируется при приближении или удалении от любого из выбранных объектов. Если же указан логический оператор «И», уведомление срабатывает, когда объект одновременно приближается или удаляется ото всех отмеченных объектов. Укажите радиус в метрах — дистанцию между объектами, при уменьшении или увеличении которой сработает уведомление. Далее нужно выбрать объекты, чье положение будет оцениваться по отношению к объектам, выбранным для самогó уведомления. Для удобства поиска можно воспользоваться динамическим фильтром над списком.
Адрес
Это уведомление подобно контролю геозоны. Оно позволяет контролировать вход/выход, нахождение в или вне определенного места. Введите параметры адреса (например, город, улицу и дом) и из выпадающего списка выберите наиболее подходящий вариант. Также укажите радиус точки. Дополнительно могут быть применены фильтры по датчику и скорости.
Превышение количества сообщений
При помощи данного типа уведомления можно контролировать поток сообщений от объекта. Это могут быть либо обычные сообщения с данными (сообщения с координатами, показаниями датчиков и т.п.), либо SMS-сообщения. Укажите лимит сообщений и интервал сброса счетчика. Например, если настроить уведомление, как показано в примере ниже, уведомление сработает, если объект пришлет 3 или более SMS-сообщений в течение 1 часa.
Заправка
Уведомление данного типа позволяет контролировать заправки топлива. При создании уведомления вы можете задать маски датчиков, которые должны использоваться для определения заправки и ее объема. Также с помощью опции «В геозоне/Вне геозоны» можно контролировать заправки относительно определенных геозон. Геозоны должны быть созданы заранее и принадлежать тому же ресурсу, что и уведомление.
Уведомление срабатывает в момент достижения минимального объема заправки, указанного на вкладке «Расход топлива» свойств объекта, а также повторно после того, как система получает достаточное количество данных для определения полного объема заправки (получен весь объем данных, сообщения из черного ящика, импортированные сообщения и т.п.). Для того чтобы уведомление приходило только один раз (по достижении минимального объема заправки), необходимо активировать опцию «Игнорировать пересчитанные данные».
Уведомление данного типа позволяет контролировать сливы топлива. При создании уведомления вы можете задать маски датчиков, которые должны использоваться для определения слива и его объема. Также с помощью опции «В геозоне/Вне геозоны» можно контролировать сливы относительно определенных геозон. Геозоны должны быть созданы заранее и принадлежать тому же ресурсу, что и уведомление.
Уведомление срабатывает в момент достижения минимального объема слива, указанного на вкладке «Расход топлива» свойств объекта, а также повторно после того, как система получает достаточное количество данных для определения полного объема слива (получен весь объем данных, сообщения из черного ящика, импортированные сообщения и т.п.). Для того чтобы уведомление приходило только один раз (по достижении минимального объема слива), необходимо активировать опцию «Игнорировать пересчитанные данные».
Прохождение маршрута
Для контроля маршрута укажите, какие именно изменения при прохождении рейса по этому маршруту должны контролироваться: начало, завершение, прерывание рейса, вход/выход/пропуск контрольной точки, опережение графика или отставание и др. Дополнительно можно задать маску имени маршрута, расписания и/или рейса.
Водитель
Выберите, хотите ли Вы контролировать назначение либо снятие водителя. Чтобы контролировать и то, и другое, придется создать два уведомления. Чтобы уточнить конкретного водителя, введите его код (или часть кода) в поле «Маска кода водителя». Если оставить в этом поле просто звездочку (*), будут контролироваться все водители без исключения.
Прицеп
Выберите, хотите ли Вы контролировать назначение либо снятие прицепа. Настраивается аналогично предыдущему типу уведомления.
Активность пассажира
Для получения уведомлений о посадке или высадке пассажира выставьте соответствующие флаги. Укажите код необходимого пассажира в соответствующем поле. Если оставить в этом поле только звездочку (*), будут контролироваться все пассажиры без исключения.
Тревога по пассажирам
Здесь необходимо указать время, по истечении которого Вам будет отправлено тревожное сообщение, если любой из пассажиров выбранного ресурса не вышел из транспортного средства. Указанное время отсчитывается с момента прикрепления пассажира к объекту.
Техобслуживание
Особенности срабатывания уведомления:
Примечание.
В зависимости от настроек ресурса, в настройках различных типов уведомлений будут использоваться такие единицы как километры, метры, километры в час (если ресурс использует метрическую систему) или мили, футы, мили в час (если ресурс использует американскую или имперскую систему измерения).
Какие типы уведомлений представлены в системе мониторинга
Здесь можно настроить получение онлайн-уведомлений для вкладки Мониторинг таким образом, чтобы они приходили только из определенных ресурсов, а не из всех, на которые есть доступ. Для каждого ресурса можно также указать типы уведомлений, которые необходимо получать.
Вкладка Уведомления доступна только пользователям верхнего уровня и пользователям с правами дилера.
На вкладке представлено два списка. В левом выбираются ресурсы, в правом — типы уведомлений.
Напротив имени ресурса показывается количество выбранных для него типов уведомлений, а во всплывающей подсказке к числовому индикатору — их список.
Для того чтобы настраивать фильтрацию уведомлений для ресурса, пользователю необходимо на него право доступа Просмотр уведомлений.
По умолчанию выбраны все ресурсы и все типы уведомлений для них. Для того чтобы изменить перечень типов уведомлений, которые должны приходить из какого-либо ресурса, выберите его в списке слева. Для быстрого поиска нужного ресурса воспользуйтесь динамическим фильтром. Отметьте в списке типов уведомлений те, которые необходимо получать.
Можно настроить фильтрацию уведомлений для нескольких ресурсов одновременно. Для этого следует выбрать ресурсы с зажатой клавишей Ctrl и отметить типы уведомлений в списке справа. Черный чекбокс около названия типа уведомления означает, что для него отличаются настройки у выбранных ресурсов (то есть для одних ресурсов этот тип отмечен, а для других — нет).
Для пользователей верхнего уровня и пользователей с правами дилера во всплывающем окне онлайн-уведомлений доступен фильтр по типу уведомлений.
Внедрение мониторинга и системы оповещений
Система мониторинга помогает отслеживать поведение инфраструктуры и приложений и определить приемлемые диапазоны производительности и надежности. Понимая, какие компоненты отслеживать и на каких метриках сосредоточиться в том или ином сценарии, вы можете приступить к планированию стратегии мониторинга, которая охватывает все критические аспекты сервисов. В статье Сбор метрик инфраструктуры и приложений вы изучили популярную структуру для определения важных метрик, а также узнали, какие данные собирать на разных этапах и уровнях.
В этой статье вы узнаете, из каких компонентов состоит система мониторинга и как использовать их для реализации своей стратегии. Определив основные обязанности эффективной и надежной системы мониторинга, вы сможете понять, как элементы этой системы выполняют эти функциональные требования. Также мы поговорим о том, как лучше всего перенести политики мониторинга в дашборды и политики предупреждений, которые предоставят вашей команде необходимую информацию о важных событиях в системе.
Важные качества системы мониторинга и отправки оповещений
В одном из заключительных разделов статьи Основы мониторинга и сбора метрик мы обсудили некоторые из наиболее важных качеств эффективной системы мониторинга. Чтобы лучше понимать работу основных компонентов этих систем, полезно проанализировать характеристики, которые ранее мы определили как полезные или необходимые:
Компоненты системы мониторинга
Системы мониторинга состоят из нескольких различных компонентов и интерфейсов, которые работают вместе, чтобы собирать и визуализировать метрики, сообщать о работоспособности развертывания и т.п. Ниже мы рассмотрим основные компоненты этой системы.
Распределенные агенты мониторинга и экспортеры данных
Основная часть системы мониторинга может быть развернута на выделенном сервере, но данные об инфраструктуре должны собираться из разных источников. Для этого на каждой отдельной машине по всей сети устанавливается агент мониторинга – небольшое приложение, предназначенное для сбора и пересылки данных в централизованную точку хранения. Эти агенты собирают статистику и показатели использования ресурсов тех хостов, на которых они установлены, и отправляют их на центральное программное обеспечение мониторинга.
Агенты работают как демоны на каждом хосте в системе. Они могут поддерживать базовую конфигурацию для надежной аутентификации с удаленной конечной точкой данных, определять частоту данных или политику выборки и устанавливать уникальные идентификаторы хостов. Чтобы уменьшить влияние на другие сервисы, агент должен использовать минимальное количество ресурсов и иметь возможность работать практически без управления. В идеале, установить агент на новой ноде и начать отправлять метрики в центральную систему мониторинга должно быть очень просто.
Агенты мониторинга обычно собирают общие метрики уровня хоста, но также бывают агенты для мониторинга программного обеспечения (например, веб-серверов или серверов баз данных). Однако данные большинства специализированных типов программного обеспечения необходимо собирать и экспортировать либо путем изменения самого программного обеспечения, либо путем создания собственного агента (через создание сервиса, который анализирует конечные точки состояния программы или записи логов). Многие популярные средства мониторинга имеют библиотеки, позволяющие упростить добавление пользовательских инструментов. Как и в случае с агентами, необходимо свести к минимуму воздействие пользовательских сервисов на систему – они не должны влиять на здоровье или производительность приложений.
До сих пор мы говорили об архитектуре продвижения, в которой агенты загружают собранные данные в центральное место хранения. Но бывают также системы с архитектурой извлечения. В таких системах мониторинга отдельные хосты отвечают за сбор, агрегирование и обслуживание метрик в заданном формате в доступной конечной точке. Сервер мониторинга проверяет конечную точку метрики на каждом хосте и собирает данные. Программное обеспечение, которое собирает и представляет данные через конечную точку, имеет много общих требований с агентами, но проще в конфигурации, поскольку ему не нужно знать, как общаться с другими машинами.
Вхождение метрик
Одной из самых загруженных частей системы мониторинга является компонент вхождения метрики. Поскольку данные генерируются постоянно, процесс сбора данных должен быть достаточно ошибкоустойчивым для обработки большого объема задач и координации с уровнем хранения для правильной записи входящих данных.
В системах продвижения конечной точкой входа метрик является централизованное место в сети, туда отправляет свои собранные данные каждый агент мониторинга или агрегатор статистики. Конечная точка должна иметь возможность одновременно аутентифицировать и принимать данные с большого количества хостов. Конечные точки вхождения метрик часто распределяют нагрузку, что обеспечивает ошибкоустойчивость и обработку больших объемов трафика.
В системах с архитектурой извлечения соответствующий компонент представлен механизмом опроса, который охватывает и анализирует конечные точки метрик на отдельных хостах. Он имеет примерно такие же требования, но некоторые функции представлены наоборот. Например, если отдельные ноды реализуют аутентификацию, процесс сбора метрик должен иметь возможность предоставить правильные учетные данные для входа в систему и доступа к защищенной конечной точке.
Уровень управления данными
Уровень управления данными отвечает за организацию и запись входящих данных из компонента входа и за ответ на запросы от административных уровней. Данные метрик обычно записываются в формате временного ряда, который представляет изменения во времени. Базы данных временных рядов – это базы данных, которые специализируются на хранении и организации данных такого типа, они часто используются в системах мониторинга.
Основной задачей уровня управления данными является сохранение входящих данных по мере их получения или сбора с хостов. Как минимум, уровень хранения должен сохранять полученные метрики, их значения, время создания значения и данные о хосте, к которому относится это значение.
Чтобы хранить данные в течение более продолжительного периода времени, уровень хранения должен обеспечивать экспорт данных, когда набор превысит локальные ограничения обработки, памяти или хранения. Соответственно, уровень хранения также должен иметь возможность импортировать данные, чтобы использовать историю данных системы, когда это необходимо.
Уровень управления данными также должен обеспечивать организованный доступ к сохраненной информации. Для систем, использующих базы данных временных рядов, эта функциональность обеспечивается встроенными языками запросов или API. Они могут использоваться для интерактивного опроса и исследования данных, но основными потребителями этой информации, вероятно, будут дашборды для визуализации данных и система оповещения.
Уровень визуализации
На уровне управления данными основаны интерфейсы, которые помогают пользователю понять собираемые данные. Поскольку метрики выражаются данными временных рядов, такие данные лучше всего визуализировать в виде графика со временем по оси х. Это позволяет легко понять, как значения меняются во времени. Метрики можно визуализировать в разных временных масштабах, чтобы проследить тенденции в течение длительных периодов времени, а также выявить последние изменения, которые могут повлиять на работу системы в настоящее время.
Уровни визуализации и управления данными позволяют накладывать данные с разных нод или из разных частей стека приложений и получать их целостное представление. Данные временных рядов обеспечивают согласованный масштаб, который помогает обнаружить события или изменения, которые происходят одновременно. Интерактивное наложение данных позволяет операторам визуализировать метрики наиболее удобным образом.
Наиболее часто используемые графики и данные часто организуются в дашборды. Дашборды обеспечивают непрерывное представление текущих метрик и могут использоваться для устранения неполадок или глубокого изучения определенных областей вашей системы. Например, дашборд с подробной разбивкой мощности физических хранилищ может пригодиться при планировании ресурсов, но никак не поможет в ежедневном администрировании системы. Общие и специализированные дашборды мониторинга помогут эффективнее использовать данные.
Система оповещений и настройка порогов
Графики и дашборды помогают разобраться с данными системы, но они полезны только тогда, когда администратор системы просматривает страницу. Одной из важнейших функций системы мониторинга является освобождение членов команды от постоянного активного наблюдения за системой. Чтобы минимизировать вмешательство человека в работу, система должна быть в состоянии привлечь внимание оператора в момент, когда это действительно необходимо. Для этого системы мониторинга используют определяемые пользователем пороговые значения и системы оповещения.
Целью системы оповещений является своевременное уведомление операторов о важных событиях или критических изменениях в данных. Поскольку для этого требуется, чтобы система понимала, что считается значительным событием в конкретной системе, вы должны определить свои критерии оповещения. Определения оповещений включают методы уведомлений и пороговые значения, на основе которых система непрерывно оценивает входящие данные. Пороги обычно определяют максимальное или минимальное среднее значение для той или иной метрики за определенный период времени, а метод уведомления описывает, как отправить предупреждение.
Одним из самых сложных аспектов системы оповещений является поиск баланса, который позволит вам вовремя реагировать на проблемы и при этом не перегружать операторов уведомлениями. Для этого вам нужно понять, какие метрики являются лучшими показателями реальных проблем, какие проблемы требуют немедленного внимания, какие методы уведомления лучше всего подходят для разных сценариев. Для этого язык определения порога должен быть достаточно мощным, чтобы адекватно описать ваши критерии. Аналогично, система уведомлений должна предлагать разные методы связи для проблем разного приоритета.
Мониторинг «черного ящика» и «белого ящика»
Теперь вы знаете, как работают и за что отвечают различные части системы мониторинга. Давайте поговорим о способах определения пороговых значений и оптимизации настройки предупреждений.
Мониторинг «черного ящика» и «белого ящика» – это разные модели мониторинга. Они не являются взаимоисключающими, поэтому системы часто комбинируют их, чтобы использовать преимущества каждой из моделей.
Мониторинг «черного ящика» – это определение оповещений или графиков, основанное только на внешне видимых факторах. Эта модель мониторинга берет внешнюю перспективу за основу, что позволяет сосредоточиться на публичном поведении вашего приложения или сервиса. Не зная ничего о состоянии базовых компонентов, мониторинг «черного ящика» предоставляет данные о функциональности системы с точки зрения пользователя. Это позволяет определить проблемы, которые активно влияют на пользовательский опыт клиентов, потому о таких проблемах важно оповещать операторов.
Альтернативная модель – мониторинг «белого ящика» – также невероятно полезна. Мониторинг «белого ящика» собирает внутреннюю информацию о вашей инфраструктуре. Поскольку количество внутренних процессов значительно превышает внешние процессы, часто в системе мониторинга данные «белого ящика» количественно доминируют над данными «черного ящика». Эта модель работает с более полной информацией о ваших системах, потому мониторинг «белого ящика» позволяет строить прогнозы. Например, отслеживая изменения в использовании ресурсов, он может уведомить вас, когда вам может понадобиться масштабирование определенных сервисов.
«Черный» и «белый ящик» – это просто способы классифицировать различные типы перспектив в системе. Имея доступ к данным «белого ящика», вы можете изучать внутренние проблемы, оценивать основные причины их возникновения. С другой стороны, мониторинг «черного ящика» помогает быстро выявить серьезные проблемы в работе приложения, сразу продемонстрировав влияние этой проблемы на пользователя.
Приоритет и типы уведомлений
Отправка предупреждений и уведомлений является одной из наиболее важных частей системы мониторинга. Без уведомлений о важных изменениях команда не будет знать о событиях, влияющих на работу системы. Операторам придется постоянно следить за дашбордами, чтобы оставаться в курсе событий. С другой стороны, избыточное количество уведомлений о неважных событиях с высоким процентом ложных срабатываний может принести больше вреда, чем пользы.
В этом разделе мы поговорим о разных уровнях уведомлений и о том, как наилучшим образом использовать их для максимальной эффективности мониторинга. Также мы обсудим некоторые критерии приоритета событий.
Пейджер
Начнем с предупреждений с наивысшим приоритетом. Пейджеры представляют уведомления, которые пытаются в срочном порядке обратить внимание на критическую проблему с системой. Эта категория предупреждений должна использоваться для серьезных ситуаций, требующих немедленного вмешательства. Системе оповещения требуется надежный способ связаться с людьми, несущими ответственность за решение этой проблемы.
Уведомления пейджеров нужно хранить для решения критических проблем с вашей системой. Это самые важные предупреждения, которые посылает ваша система, их нельзя игнорировать. Чтобы обеспечить реакцию оператора на проблему, системы оповещения часто включают возможность уведомлять другого человека или группу, если первая страница не подтверждается в течение определенного периода времени.
Поскольку пейджеры по своей природе невероятно разрушительны, их следует использовать экономно: только тогда, когда становится ясно, что существует оперативно неприемлемая проблема. Часто они привязываются к методам «черного ящика».
Вторичные уведомления
Следующий уровень приоритетности – это вторичные уведомления, к которым относятся электронные письма и билеты. Они призваны постоянно напоминать о том, что операторы должны исследовать развивающуюся ситуацию. В отличие от оповещений пейджеров, уведомления не сообщают о необходимости немедленных действий, поэтому они обычно обрабатываются персоналом по мере поступления, а не пытаются добиться срочного ответа от оператора. Если в вашей команде нет постоянно работающих администраторов, уведомления должны отправляться в ситуациях, которые могут подождать до следующего рабочего дня.
Билеты и электронные письма, созданные системой мониторинга, позволяют операторам понять, на какой задаче они должны сосредоточиться в ближайшее время. Поскольку уведомления не должны использоваться для извещения о критических проблемах, которые влияют на производительность в настоящее время, они часто привязываются к индикаторам «белого ящика»: это позволяет прогнозировать или идентифицировать возникающие проблемы, которые необходимо будет решить в ближайшее время.
В других случаях оповещения могут отслеживать те же действия, что и пейджеры, но им устанавливаются более низкие, менее критические пороговые значения. Например, вы можете настроить отправку уведомления, когда в течение определенного периода времени немного вырастает задержка приложения, а пейджер будет сообщать, когда задержка увеличивается сильно.
В целом уведомления наиболее подходят в ситуациях, которые требуют вмешательства, но не представляют непосредственной угрозы стабильности работы системы. Они должны привлечь внимание к проблеме, чтобы команда могла исследовать и смягчать ошибки, прежде чем они станут критичными.
Информация логов
Иногда вам может понадобиться информация о конкретном поведении, но при этом не нужно призывать операторов к немедленным действиям. Технически это не предупреждения: в подобных ситуациях может быть полезно установить пороговые значения, которые будут просто записывать информацию в логи или файлы, после чего данные будут использоваться в дашбордах системы мониторинга. Это позволяет предоставить оператору скомпилированную информацию, которая пригодится в исследовании проблемы и может сократить количество запросов для сбора сведений о проблеме.
Эта стратегия имеет смысл только для сценариев, которые имеют очень низкий приоритет и не требуют срочного ответа. Такие данные полезны потому, что позволяют сопоставить связанные факторы и обобщить информацию по времени. Позже эти данные можно использовать в качестве дополнительных источников. Вероятно, у вас не будет много триггеров такого типа, но они могут пригодиться в тех случаях, когда вы вынуждены просматривать одни и те же данные каждый раз, когда возникает проблема. Альтернативным вариантом является сохранение запросов и настойка дашбордов.
В каких случаях не нужно отправлять оповещения?
Важно четко понимать, какие предупреждения должна получать ваша команда. Каждое предупреждение должно сообщать о проблемах, требующих ручного вмешательства оператора или принятия того или иного решения. Потому при настройке системы оповещений нужно обратить внимание на все проблемы, решение которых можно автоматизировать.
Автоматическое восстановление возможно в случаях, когда:
Некоторые ответы проще автоматизировать, чем другие, но, как правило, автоматизировать можно любой сценарий, который соответствует указанным выше критериям. Метрика по-прежнему может быть привязана к пороговым значениям, но вместо отправки сообщения человеку триггер может запустить сценарий восстановления для решения проблемы. Ведение логов может предоставить ценную информацию о состоянии системы и эффективности пороговых значений и автоматических сченариев.
Важно помнить, что в автоматизированных процессах тоже могут возникнуть проблемы. В таком случае хорошо бы настроить дополнительные предупреждения для сценариев, чтобы оператор был уведомлен о сбое автоматизированного восстановления.
Оптимизация пороговых значений и отправки уведомлений
Теперь, когда мы рассмотрели различные доступные средства оповещения, мы можем поговорить об оптимизации системы предупреждений.
Уведомления, сгенерированные событиями с реальным воздействием пользователя
Как упоминалось ранее, предупреждения, основанные на сценариях с реальным воздействием пользователей, являются наилучшими. Они позволяют анализировать сценарии сбоев или ухудшение производительности на уровнях, с которыми взаимодействуют пользователи.
Это требует хорошего понимания избыточности инфраструктуры, взаимоотношения различных компонентов и целей организации в отношении доступности и производительности. Ваша цель – выявить симптоматические метрики, которые могут достоверно указать на текущие или потенциальные проблемы, влияющие на пользователя.
Пороговые значения разного приоритета
После того, как вы определили симптоматические метрики, нужно выявить соответствующие значения, которые можно использовать в качестве пороговых. Чтобы обнаружить правильные пороговые значения для некоторых метрик, вам придется провести несколько тестов.
Если у вас есть история, проверьте значения в ней, чтобы определить, какие сценарии вы восстанавливали ранее. Для каждой метрики полезно определить аварийный порог, который вызовет оповещение пейджера, и одно или несколько пороговых значений с более низким приоритетом. Определив пороги, убедитесь, что они эффективны в данной среде.
Установка контекста
Минимизировав время, затрачиваемое на извещение операторов о проблеме, вы поможете им быстрее справиться с ситуацией. С этой целью полезно попытаться предоставить контекст в предупреждении, чтобы операторы могли быстро понять проблему и начать устранять ее.
Оповещения должны четко указывать на затронутые компоненты и системы, пороговые значения метрики и время возникновения ошибки. Предупреждение также должно содержать ссылки для получения дополнительной информации. Это могут быть ссылки на конкретные дашборды, связанные с запущенной метрикой, ссылки на систему билетов на страницу оповещений системы мониторинга, где оператор найдет более подробный контекст.
На этом этапе цель состоит в том, чтобы предоставить операторам достаточную информацию для быстрого реагирования и помочь им сосредоточиться на проблеме. Не нужно предоставлять абсолютно всю информацию о событии (это даже не рекомендуется), достаточно базовых сведений с подсказками, где искать дополнительную информацию.
Отправка уведомлений правильным сотрудникам
Оповещения бесполезны, если они не вызывают ответной реакции. Часто реакция зависит от уровня знаний, опыта и прав доступа оператора, который получил оповещение. В большой организации сложно выбрать ответственного человека или группу: если разные аспекты инфраструктуры распределены между сотрудниками, то одних специалистов уведомление будет касаться напрямую, а другие не будут иметь компетенции решать возникшую проблему. Потому нужно четко понимать, кто должен заниматься устранением проблем того или иного характера.
Лучше всего, если ваша система оповещения включает механизм планирования смен, но если нет, вы можете разработать процедуру для ротации оповещений вручную на основе вашего расписания.
План передачи уведомления на более высокие уровни – это второй инструмент, позволяющий убедиться, что уведомление попадет к правильным людям. Если у вас есть персонал, обслуживающий систему 24 часа в сутки, лучше всего отправлять предупреждения системы мониторинга непосредственно сотрудникам смены. Операторы могут сами выполнить смягчение, а если им понадобится помощь, они смогут передать уведомление более опытным сотрудникам. Наличие плана передачи уведомления на более высокие уровни может минимизировать время решения проблемы.
Заключение
Теперь вы знаете, как работают системы мониторинга и оповещения в реальных сценариях. Вы знаете также, из каких компонентов состоит система мониторинга, за что отвечает каждый компонент и какие бывают модели мониторинга. Кроме того, вы можете оптимизировать систему оповещений с учетом приоритета и типа уведомлений.