Создание PULSE - удобный для разработчиков инструмент для мониторинга серверов (часть 5)

Создание PULSE - удобный для разработчиков инструмент для мониторинга серверов (часть 5)

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

ВНИМАНИЕ: Pulse запущен и доступен для использования. Вы можете создать учетную запись, посетив https://pulse.alphametric.co

Создание умного уведомителя

Если вы посмотрите, как работает Pulse, он потенциально может отправлять тысячи уведомлений каждый час. В зависимости от данных, которые он получает, он может рассылать пользователям огромное количество идентичных уведомлений, становясь по сути платной услугой для рассылки спама!

Очевидно, это далеко не идеально. Вместо этого мы должны отсортировать эти уведомления:

1. Мы должны использовать минимальные интервалы времени между отправкой одного и того же уведомления, например. предупреждать кого-нибудь раз в час о высокой загрузке ЦП.
2. Мы должны установить дневной лимит для каждого монитора. Пользователю не нужно знать одно и то же более X раз в день.
3. Мы должны сгруппировать данные монитора для сервера, где это возможно, чтобы еще больше уменьшить количество отправляемых уведомлений.

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

// Retrieve the monitors which have "bad" statistics
monitors = getMonitorsWithProblems()
// Filter monitors which are not permitted to receive a notification monitors -> filter() -> hasEnoughTimePassed() 
monitors -> filter() -> withinLimit()
// Create a new notice that a notification will be sent
monitors -> each() -> storeNotice()
// Group the monitors to reduce the number of notifications
monitors -> groupBy(channel, route)
// Send the notifications for the monitors
monitors -> each() -> notify()

Теперь давайте разберемся, как это будет работать на самом деле. У нас есть метод, который извлекает мониторы с данными, которые нарушают указанный пользователем порог (и поэтому требует отправки уведомления). Потом…

Фильтрация неподходящих мониторов

Нам нужно отфильтровать мониторы, о которых мы уже недавно отправляли уведомление. Это довольно просто реализовать. Просто добавьте столбец interval в таблицу монитора и присвойте ему номер (в минутах). Затем добавьте столбец notified_at метки времени в таблицу и обновите его при необходимости:

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

Для этого нам нужна notices таблица, которая связана с таблицей мониторов и содержит записи, не имеющие ничего, кроме меток времени. Нам также нужно добавить еще один столбец в таблицу мониторов, который, как и interval, представляет собой число, указывающее maximum количество уведомлений, которые могут быть отправлены в день.

Затем все, что нам нужно сделать, это проверить, не меньше ли количество записей уведомлений для данного монитора дневного максимума:

Если монитор удовлетворяет критериям для обоих этих фильтров, мы можем двигаться дальше.

Сохранение уведомления для монитора

Как вы, наверное, догадались, второй фильтр, оставленный как есть, всегда будет возвращать значение true, чего мы не хотим. Если мы передадим условие, нам нужно будет увеличить количество уведомлений для монитора, а также обновить notified_at временную метку монитора:

Группировка уведомлений вместе

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

Нет смысла отправлять отдельное электронное письмо для каждого товара. Вместо этого мы должны отправить одно электронное письмо, содержащее сводку всех трех. К счастью для нас, Laravel позволяет группировать коллекцию, как нам нужно.

Сначала сгруппируем по каналу уведомления (электронная почта, Slack и т. Д.), А затем сгруппируем эти вложенные элементы по маршруту уведомления (например, по адресу электронной почты):

Наконец отправьте уведомления

Теперь, когда мы выполнили все критерии фильтрации и организовали статистические данные в группы, мы, наконец, можем отправлять уведомления! Вот пример уведомления по электронной почте с красиво представленными данными:

Подведение итогов изменений

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

Если предположить, что у нас есть неверные данные для ЦП сервера, диска хранения и сети в трафике, и что плохие данные непрерывно поступали в течение 24 часов, тогда Pulse отправил бы 3 отдельных сообщения электронной почты каждые 2 минуты в течение этого периода.

Это колоссальные 2160 писем!

Помимо финансовых затрат, я уверен, что наш почтовый провайдер отключил бы нашу учетную запись, полагая, что мы рассылаем СПАМ.

Теперь давайте рассмотрим тот же сценарий, но с новым интеллектуальным уведомителем Pulse, обеспечивающим принятие решений. Предполагая, что монитор interval составляет 60 (то есть, один раз в час), а дневной maximum лимит равен 5, тогда Pulse будет отправлять 1 электронное письмо каждые 60 минут максимум до 5 раз.

Это сокращение на 2155 писем!

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

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

Более реалистичный сценарий - это назначение мониторов с более высоким приоритетом, например. ЦП на такой канал, как Slack, чтобы получить более быстрый ответ, в то время как использование диска, вероятно, менее критично в этот конкретный момент, и поэтому его можно отправить по электронной почте.

В конечном итоге Pulse позволяет делать то, что вы хотите. Назначьте разные каналы для каждого монитора или используйте один для падения. Все зависит от вас.

Заключение

Ну вот и все на этой неделе. Далее мы рассмотрим еще одну функцию, которую Pulse будет поддерживать… тихие серверы. Наш уведомитель работает, когда получает данные, но что, если он их не получает? В этой ситуации нам нужно сообщить пользователям, что мы не получаем статистику и что, возможно, их сервер не работает.

Все это будет в статье на следующей неделе. А пока не забудьте подписаться на меня здесь, на Medium, а также в Twitter, чтобы получать более частые обновления.

ВНИМАНИЕ: Pulse запущен и доступен для использования. Вы можете создать учетную запись, посетив https://pulse.alphametric.co

Спасибо, удачного кодирования!