← Назад к «Интерфейсы (UI)»

Уведомления

Зачем нужен этот раздел

Уведомления — это способ LSUS проактивно сообщать администратору о событиях, на которые стоит отреагировать: недоступные хосты, истекающие сертификаты, ошибки синхронизации LDAP, новые пакеты в репозиториях.

LSUS сам формирует событие по настроенной категории и доставляет его по выбранным каналам: в интерфейс, на почту или во внешнюю систему по webhook.

infoКратко

  • Где смотреть: колокольчик в шапке интерфейса.
  • Где настраивать: Администрирование → Настройки → Уведомления.
  • Каналы: in-app, email (SMTP), webhook (HTTP POST).

Колокольчик в шапке

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

  • Бейдж непрочитанных — цифра красным поверх колокольчика. Если её нет — всё прочитано.
  • Клик по колокольчику открывает выпадающую панель со списком последних непрочитанных уведомлений: категория, краткий текст, время, иконка по типу.
  • Каждое уведомление в панели можно отметить прочитанным или раскрыть для перехода к связанному объекту (хосту, сайту, сертификату).
  • Полная лента (включая прочитанные и архив) доступна через пункт «Показать все» внизу панели.

Каналы доставки

Уведомление доставляется по всем каналам, включённым для данной категории. Каналы независимы — если, например, SMTP недоступен, in-app всё равно сработает.

Канал Как работает Когда подходит
in-app Появляется в колокольчике. Хранится в базе LSUS. Повседневная работа оператора прямо в интерфейсе.
email Письмо на адреса получателей через настроенный SMTP. Вне интерфейса: дежурный, рассылка группе админов.
webhook HTTP POST с JSON-телом события на внешний URL. Интеграция с Telegram/Slack-ботом, системой инцидентов, дашбордом NOC.

lightbulbSMTP и webhook настраиваются централизованно

Параметры SMTP-сервера (хост, порт, аутентификация, отправитель) и webhook-эндпоинты задаются один раз в настройках уведомлений, а не в каждом правиле. В правиле выбирается только «куда доставить».

Категории событий

LSUS формирует уведомления по следующим категориям. Каждую можно включить/выключить и направить в свой набор каналов.

Категория О чём сообщает Типичный пример
Недоступные хосты Машины, не выходившие на связь дольше порога (по умолчанию > 90 дней). Списанные или забытые машины, требующие чистки или перерегистрации.
Недоступные Site/Edge Site- или Edge-сервер перестал отвечать. Филиал перестал получать обновления — клиенты тянут пакеты из WAN.
Истекающие сертификаты TLS-сертификат Master/Site/Edge приближается к концу срока. Заблаговременное предупреждение до истечения, чтобы успеть перевыпустить.
Новые пакеты в репозиториях В подключённом репозитории появились новые версии пакетов. Готовность к планированию кампании обновлений.
Ошибки LDAP-синхронизации Очередная синхронизация с LDAP-источником завершилась с ошибкой. Каталог недоступен или изменилась схема — автоназначение коллекций может отстать.
LDAP-объекты-orphans В каталоге обнаружены объекты без ожидаемой привязки (orphan-записи). «Висящие» компьютеры/пользователи, требующие разбора в AD/FreeIPA.
Множественный вход Одна учётная запись одновременно активна на нескольких хостах. Хосты с тегом «терминальный сервер» исключаются — на них множественные сессии легальны. Подозрительная или нарушающая политику активность пользователя.
Вход администратора с нового IP Пользователь с ролью администратора вошёл в консоль с адреса, с которого раньше не входил. Первый вход, смена рабочего места или неожиданный доступ к учётке.
Низкие ресурсы Master На сервере Master мало свободного места на диске, ОЗУ или заполнена очередь. Риск остановки фоновых задач и репликации.

infoПорог недоступности хостов

Порог «недоступный» (>90 дней по умолчанию) задаётся в правиле категории. Его можно изменить под свою практику — например, сделать более жёстким (30 дней) для критичных сегментов.

Терминальные серверы и множественный вход

На терминальных серверах (RDS, xRDP, Citrix и подобных) один пользователь легально работает одновременно с другими — это штатный режим работы, а не нарушение. Без исключения такие хосты давали бы ложные срабатывания категории «Множественный вход»: сканер видел бы пользователя активным сразу на нескольких машинах и генерировал бы уведомление на каждый вход.

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

lightbulbКак настроить

  1. Перейдите в раздел «Хосты».
  2. Создайте тег с именем «терминальный сервер» (регистр не важен).
  3. Назначьте этот тег всем хостам, которые являются терминальными серверами.

После этого множественные входы пользователей на эти хосты перестанут генерировать уведомления. Подробнее о работе с тегами — в разделе «Хосты».

infoИмя тега по умолчанию

Имя тега «терминальный сервер» — значение по умолчанию. При необходимости его можно переопределить переменной окружения LSUS_MULTI_LOGIN_TERMINAL_TAG на сервере (например, задать английское имя или другой термин, принятый в организации). Пустое значение переменной отключает исключение — все хосты будут учитываться в детекции. Изменение применяется после перезапуска сервера.

Администрирование уведомлений

Настройка находится в Администрирование → Настройки → Уведомления и разбита на четыре подвкладки: Правила, Транспорты, Исключения, История.

Правила по категориям

Таблица сгруппирована по смыслу (инфраструктура, каталог, конфигурации). В строке сразу меняются включение и важность; остальные параметры открываются кнопкой редактирования.

Поле правила Назначение
Категория Предопределённое событие. Подсказка и технический ключ — при наведении.
Вкл. Выключенная категория не создаёт событий.
Важность Информация / предупреждение / критично — как событие выглядит в колокольчике.
Каналы Колокольчик, email, webhook. Иконка подсвечена, если канал включён.
Получатели Все администраторы, конкретная роль или «по праву» (RBAC).
Дедупликация Не повторять то же событие чаще, чем раз в N минут (в карточке правила).
Авто-закрытие Снять уведомление, когда причина исчезла (в карточке правила).

SMTP и webhook в правиле не настраиваются: выбираются уже созданные транспорты.

Транспорты

Список каналов доставки: несколько SMTP и webhook. Параметры задаются в модалке. Кнопка «Проверить» отправляет тестовое сообщение — используйте её сразу после настройки, до включения правил на боевой режим.

Исключения (ignore-list)

Список шаблонов в стиле fnmatch (как в shell: *, ?, [...]), которые исключают объекты из уведомлений выбранной категории.

Например:

Шаблон Что исключает
*.test.example.com Все тестовые машины — не уведомлять об их недоступности.
old-vm-* Списанные ВМ с известным префиксом.
CN=service-* Сервисные учётные записи из множественного входа.

lightbulbЗачем нужен ignore-list

На больших парках всегда есть «шумные» объекты (тестовые стенды, старые ВМ), для которых постоянно срабатывают одни и те же уведомления. Ignore-list глушит именно их, не отключая категорию целиком.

История отправок

История — журнал попыток доставить уведомление по email или webhook.

  • В таблице: время, канал и транспорт, статус (отправлено / в очереди / ошибка), заголовок, краткий ответ.
  • Клик по строке открывает полный ответ сервера. Для ошибочных отправок есть кнопка «Повторить».
  • Параллельно LSUS сам повторяет неудачную доставку несколько раз с задержкой.

lightbulbПорядок разбора «уведомление не пришло»

  1. Откройте История, найдите событие по времени.
  2. Посмотрите статус и полный ответ в карточке строки.
  3. Если отправки не было — проверьте, что категория включена, выбран транспорт и объект не попал в исключения.
  4. Если ошибка транспорта — нажмите «Проверить» в карточке транспорта.

Права доступа

Действие Permission key
Просмотр своих уведомлений (колокольчик) notifications.list.view
Просмотр/управление настройками уведомлений admin.settings.operate
Просмотр Outbox admin.settings.view

infoГде настраивать

Уведомления — вложенный раздел подвкладки «Настройки» вкладки Администрирование. Права на управление наследуют admin.settings.operate, как и остальные подразделы «Настроек».