Если каждое событие ведёт себя как одно и то же оповещение, критический сигнал теряется в шуме.
В продуктивной среде не все события одинаково важны. Backend на обслуживании, все backend down, переход cluster IP на другой узел, истечение сертификата в течение 30 дней или превышение порога request rate требуют разных операционных реакций. Если все они превращаются в единообразное email-оповещение, команда быстро испытывает усталость от оповещений.
В классических подходах уведомления обычно ограничены email и syslog. А операционные команды хотят получать разные события по разным каналам: критический failover — по SMS, рутинное предупреждение — в UI, событие безопасности — по SNMP или Syslog, сводку для руководителя — по email. Без разделения каналов либо все получают всё, либо критические события упускаются.
Управление тихими часами тоже важно. Будить всю команду в 03:00 из-за предупреждения низкой важности излишне; но настоящий сбой или смена cluster IP всё равно должны быть видимы. Тихие часы должны означать не полное исчезновение события, а его обработку по нужному каналу в нужное время.
Отчёт об одинаковым текстом о событиях вроде pool down, backend down, cluster IP swap и закрытия зоны затрудняет анализ первопричины. Оператор сначала пытается разобраться, что означает оповещение, и лишь затем принимает меры. Эта задержка особенно на высоконагруженных платформах напрямую отражается на качестве сервиса.
Система уведомлений TR7 разделяет события с помощью жизненного цикла оповещений, 30+ готовых ключей состояния, мультиканальности, многоязычности, тихих часов и управления порогами per-pool; доставляет их нужному человеку, по нужному каналу, с нужным контекстом.
Наш подход
TR7 управляет уведомлениями не как разовыми сообщениями, а как объектами оповещений с жизненным циклом и действиями по каналам.
Машина состояний оповещений отслеживает жизненный цикл события
Активные оповещения хранятся по alarmKey, обновляются через updateAlarm и закрываются через endAlarm. Так одно и то же событие не порождается снова и снова как новое оповещение; отслеживаются начало, обновление и закрытие события.
Синхронизация cluster делает оповещение видимым на всех узлах
Состояние оповещений и уведомлений может передаваться другим узлам внутри cluster. Так операционная команда видит не только события узла, к которому подключена, но и критическое состояние по всему кластеру.
Оценка состояния pool разделяет работоспособность сервиса на шесть классов
Состояние pool классифицируется значениями UNKNOWN, OK, WARN, DISABLED, ERR и EVALUATING. Эта модель не сводит состояния обслуживания, предупреждения, ошибки и оценки к одному плоскому тексту оповещения.
Машина состояний cluster IP детально отслеживает поведение failover
Состояния cluster IP оцениваются разными сигналами, такими как доступность интерфейса, конфликт IP, переход IP и поведение двух узлов. События failover доставляются операционной команде с более чётким контекстом.
Возможности
Система уведомлений предоставляет жизненный цикл оповещений, пороги pool, мультиканальность, многоязычность, тихие часы, предупреждение о сертификате и архивируемую историю событий.
Жизненный цикл оповещений управляет началом, обновлением и закрытием одного и того же события
Поток updateAlarm, endAlarm и getAlarms отслеживает активные оповещения с их жизненным циклом. При повторном поступлении того же alarmKey событие обновляется; не дублируется как полностью новое оповещение. Поведением события можно более контролируемо управлять с помощью таких полей, как staticPayload, ifAbsent и dontNotify. Эта структура снижает шум оповещений и делает историю событий более осмысленной.
Оповещения приходят в тот канал, куда инженер действительно смотрит
Почта и SNMP — это места, куда оповещения уходят, чтобы их проигнорировали. Кроме них TR7 доставляет в WhatsApp и BiP как в полноценные каналы, рядом с SMS, syslog и исходящими webhook в Jira, Slack, Teams или ServiceNow. Канал выбирается для каждого пула и каждой критичности, поэтому превышение порога в 03:40 приходит туда, где кто-то смотрит, а не в ящик, который откроют только утром.
Конфигурация notify per-pool обеспечивает выбор порога и канала на уровне сервиса
Для каждого pool можно задать пороги serviceStatus, poolStatus, bandwidth, request rate, current session и new connection. В рамках той же структуры можно выбрать предпочтения каналов email, SMS, WhatsApp, BiP, SNMP и UI. Так критический сервис можно отслеживать с более агрессивной политикой оповещений, а сервис низкой важности — с более тихой политикой. Поведение уведомлений не применяется единообразно ко всей платформе.
Множество каналов уведомлений предлагает подходящее действие для разных операционных команд
TR7 предлагает модель уведомлений с поддержкой нескольких каналов: email, SMS, WhatsApp, BiP, SNMP, Syslog и UI. Критические инфраструктурные события могут доставляться в системы управления сетью по SMS или SNMP, сводки для руководителей — по email, рутинные состояния — через UI. Одно и то же событие может отправляться по разным каналам с разным приоритетом. Эта гибкость снижает зависимость от внешнего менеджера оповещений.
Многоязычный движок шаблонов генерирует уведомление на языке пользователя
NotificationTranslator с помощью логики перевода на основе словаря может генерировать тексты уведомлений на разных языках. Локальная операционная команда может получать уведомления на своём языке, международная команда — на английском. Возможна доставка одного и того же события разным пользователям на разных языках. Это снижает риск неправильной интерпретации в международных операциях.
Более тридцати ключей состояния pool и cluster дают детальную первопричину
Доступны 30+ ключей состояния, таких как poolDisabled, allBeDown, noBeGiven, beDown, beStateUnknown, beMaint, poolDown, poolInterfaceAbsent, zoneClosed, clusterIpBoth, clusterIpPossibleCollide, clusterIpSwitched и clusterIpNone. Эти ключи делают текст оповещения более описательным. Оператор получает не просто сообщение «сервис неисправен»; он видит и тип проблемы. Время реагирования сокращается.
silentAtNight контролирует поведение каналов в тихие часы
С помощью silentAtNight определённые уведомления могут быть приглушены в ночные часы. Это не означает полного исчезновения события; оно может продолжать отображаться в UI или быть включено в утреннюю сводку. Для критических событий можно применить отдельную политику каналов, чтобы действительно важные оповещения всё же доставлялись. Усталость от оповещений снижается, при этом операционная видимость сохраняется.
При приближении срока действия сертификата может генерироваться автоматическое предупреждение
С помощью поля notifyDaysBeforeCertificateExpiry можно генерировать предупреждение за определённое число дней до даты истечения сертификата. Например, за 30 дней можно отправить email или UI-уведомление. Благодаря этому операция обновления сертификата не откладывается на последний день. Забывчивость, способная вызвать перебой TLS, выявляется на раннем этапе.
Модель contact group обеспечивает рассылку на уровне пользователя и команды
Участники contact group могут определяться адресами email, номерами SMS и информацией о типе пользователя. Уведомления могут направляться отдельному пользователю, группе команды или типу пользователя. Эта модель упрощает раздельное таргетирование дежурной команды, SOC, SRE или групп руководителей. Изменения в составе людей можно вносить, не нарушая политику каналов.
Конфигурация SMTP соответствует корпоративной email-инфраструктуре
Можно настроить SMTP host, port, authentication, username, password, безопасность TLS, проверку сертификата, sender name, sender address, cc, bcc, attachment и параметры HTML-сообщения. Значение timeout email-соединения можно держать на уровне 10 секунд. Эта структура упрощает интеграцию с существующим mail relay или SMTP-инфраструктурой организации. Email-уведомления можно адаптировать к брендовым и политикам безопасности.
Архив логов хранит историю оповещений и уведомлений в сжатом архиве
Логи оповещений и уведомлений могут архивироваться под отдельными именами. С помощью zip-сжатия и высокого уровня сжатия прошлые события могут храниться для аудита и анализа. В процессах PCI, управления изменениями или пост-инцидентного анализа история уведомлений может использоваться как доказательство. Это может работать совместно с внешними процессами архивирования без потери локальной видимости.
NotificationType различает, является ли событие оповещением, уведомлением или информацией
Поле NotificationType классами A, N и I разделяет alarm, notification и info. Это разделение важно для критичности события и способа его представления пользователю. Не каждое информационное сообщение ведёт себя как оповещение; и не каждое оповещение теряется как обычное уведомление. Поведение UI и внешних каналов может опираться на эту классификацию.
Группировка по Pair ID отслеживает одно семейство событий вместе
Поле pairId в BasicNotification может использоваться для связывания уведомлений, относящихся к одной группе событий. Например, открытие, обновление и закрытие оповещения можно отслеживать в рамках одного семейства событий. Это упрощает совместный просмотр цепочки событий на стороне SIEM или аудита. Вместо отдельных сообщений можно анализировать весь процесс события.
Операционная глубина
Система уведомлений работает вместе со значениями состояния, именами логов, сжатием, безопасностью SMTP и машиной состояний cluster IP.
Значения состояния pool
Значения состояния pool классифицируются как UNKNOWN=-1, OK=0, WARN=1, DISABLED=2, ERR=3 и EVALUATING=4. Эта числовая модель обеспечивает согласованную основу для оценки оповещений и отображения в UI. Состояния рассматриваются не только как текст, но и как значения, по которым можно принимать решения.
Логи оповещений и уведомлений
Логи оповещений могут храниться под именем basic-alarms, логи уведомлений — basic-notifications. Это разделение позволяет отдельно анализировать жизненный цикл события и уведомления, доставленные пользователю. Операционные и аудиторские процессы могут читать разные типы логов в соответствии со своими потребностями.
Сжатие логов
Архивы оповещений и уведомлений могут храниться в формате zip с высоким уровнем сжатия. Это снижает стоимость долгосрочного хранения. Для аудита обеспечивается более удобный доступ к прошлым записям уведомлений.
Каталог предопределённых ключей состояния
Под `_lb.*` находятся 30+ готовых ключей состояния. Эти ключи используются для более детального описания поведения pool, backend, интерфейса, зоны и cluster IP. Текст уведомления и логика принятия решений обогащаются за счёт этих ключей.
Поведение SMTP-соединения
При отправке email значение timeout соединения может быть настроено как 10000 мс. Поведение безопасности TLS и проверки сертификата контролируется пользователем. Это позволяет выполнять интеграцию mail relay в соответствии с требованиями безопасности организации.
Машина состояний cluster IP
Состояния cluster IP интерпретируются отдельной машиной состояний. Такие ситуации, как недоступность IP, состояние интерфейса, возможный конфликт или переход узла, могут преобразовываться в объединённые значения состояния cluster IP. Оповещения failover благодаря этому контексту генерируются точнее.
В каких сценариях используется
Тихое, но видимое управление ночным событием backend down
Когда событие backend down низкой важности возникает в 02:00, silentAtNight может остановить отправку email. Событие остаётся активным в UI и может быть включено в утреннюю сводку. Так лишние ночные оповещения снижаются, при этом событие не исчезает полностью.
Автоматическое предупреждение об обновлении до истечения сертификата
Операционная команда может установить значение notifyDaysBeforeCertificateExpiry равным 30 дням. При приближении срока действия сертификата система генерирует email или UI-уведомление. Снижаются риски обновления в последнюю минуту, способного вызвать перебой TLS.
Доставка события failover cluster IP по критическому каналу
Когда cluster IP переходит на другой узел, может генерироваться событие clusterIpSwitched. Это событие может доставляться операционной команде по SMS, SNMP или через UI. При наступлении failover команда узнаёт о событии в момент его возникновения, а не после.
Передача превышения порога WAAP или трафика в систему управления сетью
При превышении порога request rate, bandwidth, session или new connection может генерироваться SNMP-уведомление. Система управления сетью принимает это событие на свою панель оповещений. Команды безопасности и сетевых операций видят один и тот же порог в общем потоке мониторинга.
Архивирование истории уведомлений для PCI-аудита
Логи оповещений и уведомлений могут храниться как сжатый архив. Во время аудита можно показать, какое событие когда возникло, какой канал был использован и было ли оповещение закрыто. История уведомлений превращается в операционное доказательство.
Отправка оповещений на разных языках многоязычной операционной команде
Пока одна команда получает то же оповещение по email на своём языке, международная операционная команда может получать сообщение на английском. NotificationTranslator генерирует текст события в соответствии с языком пользователя. В международных операциях снижается риск неправильного понимания оповещения.
Часто задаваемые вопросы
Какие каналы уведомлений поддерживаются?
Как работают тихие часы? Событие полностью исчезает?
Что означают 30+ ключей состояния pool?
Как работает жизненный цикл оповещений?
Можно ли отправлять уведомления на разных языках?
Какие варианты есть для конфигурации SMTP и email?
Централизуйте управление событиями с нужным каналом и контекстом
Жизненный цикл оповещений, 30+ ключей состояния, мультиканальность и тихие часы. Покажем на живой установке в вашей среде.