Описание#

Описание продукта Platform V Synapse Messaging (SMB)#

Platform V Synapse Messaging (SMB) представляет собой продукт, обеспечивающий передачу сообщений в шаблоне интеграции Message queue, с развязкой поставщика и потребителя по производительности.

Продукт Platform V Synapse Messaging (SMB) состоит из одного программного компонента Синапс.Брокер сообщений (SMBX), который представляет из себя брокер очередей, построенный на базе опенсорсного продукта Apache ActiveMQ Artemis с дополнительной обвязкой.

Брокеры очередей (брокеры сообщений) помогают справиться с высокой нагрузкой, сокращают время ответа за счет асинхронной обработки и предотвращает потерю информации при сбоях. Использование брокеров очередей особенно актуально в микросервисной архитектуре для асинхронной интеграции.

Брокеры очередей решают следующие задачи:

• асинхронные адресные RPC-вызовы (гарантируется адресная доставка одному потребителю с подтверждением получения);

• сглаживают пики нагрузки благодаря распределению нагрузки в кластере;

• обеспечивают развязку по недоступности, т.к. сообщение хранится на брокере до получения подтверждения о вычитке сообщения.

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

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

Через брокеры очередей реализуются интеграции типа «point-to-point» (точка-точка) и «pub-sub» (публикация-подписка). Рассмотрим подробнее данные типы интеграций.

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

Продукт SMB представляет из себя один или несколько брокеров очередей, развернутых на виртуальных машинах либо в облачной среде, объединенных в кластер, и взаимодействующих между собой через внутренние каналы связи.

Кластер может быть развернут в неперсистентном (сообщения хранятся в памяти брокеров) или же персистентном (сообщения хранятся в очереди, а также записываются на жесткий диск) режимах. Персистентный режим позволяет избежать потери сообщений на брокере кластера в случае системных ошибок и неожиданных падений брокеров кластера.

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

Для обеспечения отказоустойчивости в кластере брокеры могут быть продублированы. Такая мера позволит обеспечить дополнительную защиту от потери данных.

Пример схемы кластера SMB:

На схеме имеется 2 системы-поставщика, которые отправляют сообщения в один из брокеров кластера в разные адреса и очереди.

Сообщения, поступающие от системы «А» будут записываться в одну или несколько очередей «адреса1». Количество очередей, в которые будут записываться сообщения, зависит от типа маршрутизации, установленного на данном адресе.

Благодаря балансировке нагрузки в кластере, сообщения будут перенаправляться на «брокер2» кластера, откуда будут вычитаны системой потребителем консьюмеры «B».

Аналогично, сообщения, поступающие от системы «В», будут перенаправляться по кластерным связям на другие брокера кластера, к которым подключены консьюмеры, настроенные на вычитку из данного адреса/очереди.

Отличие SMBX от опенсорсного продукта Apache ActiveMQ Artemis#

В рамках работ над продуктом SMBX были реализованы новые функции и исправлены ошибки Apache ActiveMQ Artemis.

Новый функционал, отсутствующий в Artemis:#

• формирование событий аудита — для упрощения разбора инцидентов;

• трассировка сообщений — для прослеживания всего их пути внутри кластера;

• сбор метрик подключения и сессий — для мониторинга и администрирования кластера;

• ограничение подключений и скорости отправки сообщений — для регулирования нагрузки на брокера;

• работа с бэкапами — для восстановления работы кластера в случае возникновения инцидентов;

• проверка DN‑сертификата у подключенного клиента или сервера — для управления доступами клиентов к кластеру;

• работа с хранилищем секретов (vault) — для использования внешнего хранилища секретов (паролей и сертификатов);

• шифрование сообщений, пока они находятся в брокере — для безопасного хранения данных;

• клиентские перехватчики — для контроля целостности данных при записи и вычитке сообщений.

Разработана DevOPS обвязка для:#

• развертывания кластера (установка/удаление/масштабирование/бэкапы);

• управления кластером (конфигурации, очереди, адреса, роли, плагины);

• установки в k8s без использования оператора.

Исправленные ошибки Artemis:#

• В web-console добавлена возможность авторизации с помощью TLS-сертификатов, добавлены дополнительные метрики.

• Добавлена настройка в конфигурацию брокера позволяющая избежать проблем, которые возникают при рестарте брокера с новым nodeId на том же host:port:

  • дублирование брокера в топологии со старым/новым nodeId

  • утечка памяти при бесконечном переподключении к брокеру со старым nodeId

  • проблемы с созданием/отсутствием кластерных очередей

• Исправлена редистрибуция сообщений при отправке в ANYCAST очередь по FQQN (Fully Qualified Queue Name).

• Улучшен контроль прав доступа при отправке сообщений в очередь:

  • исправлена проверка прав доступа при отправке сообщений в очередь по FQQN

  • в сообщение об ошибке при отсутствии прав доступа добавлен DN (Distinguished Name) сертификата

• Исправлена ошибка механизма paging из-за которой адрес не прекращает paging при снятых ограничениях.

• Улучшена работа встроенного механизма шифрования паролей в файлах конфигурации, добавлена возможность указать в конфигурации путь до файла с ключом шифрования и алгоритм хеширования паролей.

Адресная модель продукта SMB#

Каждый протокол обмена сообщениями и API, поддерживаемый SMB, определяет свой набор ресурсов для обмена сообщениями.

Основные используемые протоколы взаимодействия:

• JMS или Core протокол;

• STOMP протокол;

• MQTT протокол;

• AMQP протокол.

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

• адрес;

• очередь;

• тип маршрутизации.

Адрес

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

Очередь

Сообщения вычитываются из очереди. Очередь привязана к конкретному адресу. Ей присваивается уникальное имя и тип маршрутизации. К одному адресу может быть привязано ноль или более очередей. Когда сообщение отправляется на адрес, оно направляется в одну или несколько очередей в зависимости от настроенного типа маршрутизации.

Имя очереди должно быть глобально уникальным (например: не может быть очереди с именем «q1» по адресу «a1», а также очереди с именем «q1» по адресу «a2»).

Тип маршрутизации:

Тип маршрутизации определяет, как сообщения направляются с адреса в очередь (очереди), привязанную к этому адресу.

Поддерживаются два различных типа маршрутизации:

• anycast;

• multicast.

Anycast#

Наиболее распространенный вариант использования типа маршрутизации anycast, иногда называемый «точка-точка», предполагает, что приложения получают сообщения из общей очереди по схеме «конкурирующий потребитель» («competing consumer»). Чем больше консьюмеров вычитывают сообщения, тем выше общая пропускная способность передачи сообщений.

Несколько Java-приложений, совместно использующих очередь JMS, являются классическим примером такого варианта использования.

В этом случае брокер настроен, например, с помощью адреса «address1», использует тип маршрутизации anycast только с одной очередью, «q1». Когда продюсер отправляет сообщение по адресу «address1» оно направляется в «q1» и, наконец, отправляется одному из потребителей.

Для большинства протоколов и API, которые поддерживают такой вариант использования (например, JMS, AMQP и т.д.), обычно используется одно и то же имя для адреса и очереди при отправке и вычитки сообщений.

Например, адрес можно назвать «Test1», тогда и очередь будет называться «Test1».

Multicast#

Наиболее распространенный вариант использования семантики многоадресной (multicast) рассылки, иногда называемый публикацией/подпиской или «pub/sub», предполагает, что каждое приложение получает каждое сообщение, отправленное на определенный адрес.

Классическим примером такого варианта использования является использование нескольких приложений по протоколу JMS.

Подписки MQTT — это еще один поддерживаемый пример семантики многоадресной (multicast) рассылки.

В этом случае для брокера настраивается адрес, например «address1», который использует тип многоадресной маршрутизации с двумя очередями, «q1» и «q2».

Когда продюсер отправляет сообщение по адресу «address1», сообщение направляется как в «q1», так и в «q2», так что в конечном итоге оба консьюмера получают одни и те же сообщения.

Интеграция типа «точка-точка» или «point-to-point»#

При данном способе обмена сообщениями сообщение отправляется в очередь системой источником или продюсером. Затем сообщение обычно сохраняется (в памяти или на жестком диске) для обеспечения гарантии доставки, а некоторое время спустя сообщение может быть вычитано системой-потребителем. При наличии подключенных консьюмеров к очереди, в которую поступило сообщение, сообщение вычитывается. После вычитки сообщения консьюмер подтверждает его получение, отправляя подтверждение на брокер. Как только вычитка сообщения подтверждена, оно удаляется из очереди и становится недоступным для повторной доставки. Благодаря этому механизму одно и то же сообщение может быть обработано только одним консьюмером и не хранится дольше необходимого времени, что позволяет существенно экономить ресурсы.

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

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

Отправители (также известные как продюсеры) полностью отделены от получателей (также известных как потребители или консьюмеры) и не знают о существовании друг друга.

Интеграция АС1-АС2#

Основной паттерн интеграции двух АС - поток сообщений распределяется по всем брокерам для отказоустойчивости.

Рекомендации по подключению:

• На каждом брокере в кластере созданы одинаковые адрес::очередь.

• АС поставщик должна использовать как минимум столько же продюсеров, сколько брокеров в кластере. Каждый продюсер должен соединяться с уникальным брокером в кластере. Каждому продюсеру рекомендуется отправлять сообщения в адрес.

• АС потребитель должна использовать как минимум столько же консьюмеров, сколько брокеров в кластере. Каждый консьюмер должен соединяться с уникальным брокером в кластере.

Интеграция клиент-клиент#

Паттерн может использоваться, например, для передачи команд с контроллера на IoT-устройства.

Рекомендации по подключению:

• Используются автоматически созданные адреса::очереди, уникальные на разных брокерах.

• АС поставщик должна использовать как минимум столько же продюсеров, сколько брокеров в кластере. Каждый продюсер должен соединяться с уникальным брокером в кластере. Каждому продюсеру рекомендуется отправлять сообщения в адрес.

• Множество консьюмеров (IoT-устройств) используют для чтения уникальный адрес::очередь. Таким консьюмерам нецелесообразно подключаться одновременно ко всем брокерам в кластере, достаточно переподключения к другому брокеру в случае недоступности текущего.

Интеграция клиент-АС#

Паттерн может использоваться, например, для сбора метрик с IoT-устройств.

Рекомендации по подключению:

• Используются уникальные адреса::очереди на каждом брокере.

• Множество продюсеров (IoT-устройств) используют для записи уникальный адрес::очередь. Таким продюсерам нецелесообразно подключаться одновременно ко всем брокерам в кластере, достаточно переподключения к другому брокеру в случае недоступности текущего.

• АС-потребитель (например сборщик метрик) должна использовать как минимум столько консьюмеров, сколько брокеров в кластере. Каждый консьюмер должен соединяться с уникальным брокером в кластере.

Интеграция типа «публикация-подписка» или «pub-sub»#

С помощью обмена сообщениями «публикация-подписка» многие отправители могут отправлять сообщения объекту на сервере, который часто называется топик.

На топик может быть много подписок (другое название для консьюмер топик).

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

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

Срок действия недолговечной (non-durable) подписки не превышает срока жизни соединения, которое создало эту подписку.

Паттерн может использоваться в случае, если нескольким АС-потребителям требуется чтение одних и тех же сообщений поставщика.

Рекомендации по подключению:

• Используются одинаковые адреса на каждом брокере, очереди автоматически созданные, уникальные на каждом брокере.

• АС поставщик должна использовать как минимум столько же продюсеров, сколько брокеров в кластере. Каждый продюсер должен соединяться с уникальным брокером в кластере. Каждому продюсеру рекомендуется отправлять сообщения в адрес.

• АС потребитель автоматически создает очередь, в которую дублируются все отправленные сообщения. Рекомендуется использовать минимальное количество консьюмеров, т.к. каждый консьюмер получает копию отправленного сообщения и с увеличением количества консьюмеров пропорционально увеличивается нагрузка на кластер.

Механизмы балансировки нагрузки внутри кластера SMB#

Балансировка нагрузки используется для распределения входящих сообщений между несколькими брокерами в кластере. При балансировке продюсер пишет сообщения в адрес. Балансировка регулируется настройкой message_load_balancing в конфигурационном файле broker.xml в блоке cluster-connection:

• если этот параметр установлен в значение OFF, то сообщения никогда не будут перенаправляться на другой узел в кластере;

• если этот параметр установлен в значение ON_DEMAND, сообщения будут перенаправляться только на другие узлы кластера, если адрес, на который они перенаправляются, имеет очереди, имеющие потребителей, и если эти потребители имеют фильтры сообщений (селекторы), по крайней мере один из этих селекторов должен соответствовать сообщению;

• если этот параметр установлен в значение OFF_WITH_REDISTRIBUTION, то, как и при значении OFF, сообщения изначально не будут маршрутизироваться на другие узлы в кластере. Однако, если предусмотрена редистрибуция, она может перенаправлять сообщения обычным способом.

С помощью редистрибуции сообщений может быть сконфигурирована автоматическая редистрибуция сообщений из очередей, которые не имеют потребителей или потребителей с фильтрами, которые не соответствуют сообщениям. Сообщения перенаправляются на другие узлы кластера, которые имеют соответствующих потребителей. Чтобы включить редистрибуцию, параметр message-load-balancing должен быть установлен в значение ON_DEMAND или OFF_WITH_REDISTRIBUTION.

Редистрибуция сообщений может быть сконфигурирована так, чтобы она начинала действовать немедленно после обнаружения необходимости редистрибуции, или настроить задержку перед редистрибуцией с помощью параметра redistribution-delay в файле broker.xml в блоке address-settings:

<address-settings>
   <address-setting match="#">
      <redistribution-delay>0</redistribution-delay>
   </address-setting>
</address-settings>

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

Запуск редистрибуции:

• Редистрибуция запускается отдельно для каждой очереди.

• Редистрибуция запускается только в том случае, если на локальной очереди нет консьюмеров.

• Редистрибутор у очереди в единственном экземпляре, независимо от кол-ва брокеров в кластере.

• Редистрибуция запускается при получении одного из трех типов уведомлений:

  • BINDING_ADDED, при условии что брокер знает о наличии такой же очереди на других брокерах (наличие RemoteBinding в адресе) и у этих очередей есть консьюмеры;

  • CONSUMER_CREATED, при условии, что консьюмер создан на другом брокере;

  • CONSUMER_CLOSED, при условии, что консьюмер был закрыт на локальном брокере и кол-во консьюмеров <=0.

Общие условия запуска редистрибуции

Важно: Механизмы балансировки и редистрибуции негативно влияют на производительность брокеров и могут выступать узким местом при передаче сообщений между брокерами, т.к. отправка сообщений на другой брокер производится одним продюсером в один поток. В связи с этим рекомендуется подключать консьюмеры ко всем брокерам в кластере и полагаться на механизмы балансировки/редистрибуции только при нештатных ситуациях (например временная потеря соединения с брокером или плановая перезагрузка консьюмеров).

Сообщения#

Типы сообщений#

Сообщения, передаваемые в SMBX, могут быть определены как обычные (regular) и большие (large) сообщения. Это применимо для протоколов Core и AMQP.

Любое сообщение больше заданного размера будет считается большим сообщением. Большие сообщения при отправке на брокер будут разделены и отправлены в виде пачек фрагментами. Размер большого сообщения определятся параметром minLargeMessageSize на Core протоколе (по умолчанию равен 100KiB) и amqpMinLargeMessageSize на протоколе AMQP (по умолчанию — 102400 (100Кб)).

Большие сообщения хранятся в отдельной директории на сервере, данный параметр указывается в основном файле конфигурации broker.xml.

Истечение срока действия сообщения#

Сообщения могут быть установлены с необязательным параметром время жизни (time-to-live) при их отправке.

SMBX не доставит сообщению потребителю после того, как время его жизни истечет. Если сообщение не было доставлено к тому времени, когда достигнут предел времени его жизни, сервер может сбросить его.

Для адреса в SMBX может быть задан параметр времени жизни, и когда сообщение превысит предел time-to-live, оно будет удалено из очереди и отправлено в специальный адрес expiry address. Многие очереди могут быть привязаны к expiry address. В дальнейшем сообщения из этого адреса могут быть вычитаны и использованы для дальнейшей экспертизы.

Также на Core протоколе можно задать время жизни непосредственно на самом сообщении, на продюсере,

Гарантии доставки и коммиты#

Завершение транзакции#

При записи или откате транзакции в SMBX запрос на совершение или откат отправляется на сервер, и дальнейший вызов будет блокироваться на стороне клиента, пока не будет получен ответ с сервера, что коммит записи или отката транзакции был выполнен.

Когда на сервере будет получен коммит о записи или откате, он будет записан в журнале и в зависимости от значения параметра journal-sync-transactional сервер гарантирует, что коммит или откат записан в брокер ДО отправки ответа клиенту. Если этот параметр имеет значение false, то коммит о записи или откате транзакции может на самом деле не быть записан на брокер до тех пор, пока не будет отправлен ответ клиенту. В случае сбоя сервера это может означать, что коммит о записи или откате транзакции не будет записан на сервер. Значение по умолчанию этого параметра true, поэтому клиент может быть уверен, что все коммиты о записи транзакции или откате сохранились в брокере к тому времени, когда вернулся ответ о записи или откате транзакции.

Установка этого параметра в значение false может повысить производительность за счет некоторой потери долговечности транзакций.

Этот параметр установлен в конфигурационном файле broker.xml.

Нетранзакционная отправка сообщений#

Если при отправке сообщений на сервер используется не транзакционный способ, smbx может быть настроен на блокировку вызова для отправки до тех пор, пока сообщение действительно не достигнет сервера, после чего уже будет отправлен ответ обратно клиенту. Это может быть настроено отдельно для долговечных (durable) и недолговечных (non-durable) сообщений и определяется следующими двумя параметрами URL:

• blockOnDurableSend — если параметр установлен в true, то все вызовы для отправки durable сообщений в нетранзакционных сессиях будут заблокированы до тех пор, пока сообщение не достигнет сервера, и ответ будет отправлен обратно. Значение по умолчанию — true.

• blockOnNonDurableSend — если этот параметр установлен в true, то все вызовы отправки non-durable сообщений в нетранзакционных сессиях будут блокироваться до тех пор, пока сообщение не достигнет сервера, и ответ будет отправлен обратно. Значение по умолчанию — false.

Установка этих параметров в True может снизить производительность, так как каждая отправка требует полного кругового путешествия по сети (network round trip), прежде чем можно будет выполнить следующую отправку. Это означает, что производительность отправки сообщений будет ограничена временем полного путешествия (Round Trip Time – RTT) по вашей сети, а не пропускной способностью вашей сети. Для лучшей производительности мы рекомендуем отправлять сообщения группой вместе в транзакции (batch) за один транзакционный сеанс, поскольку тогда коммит на запись или откат делается не на каждую отправку, или использовать расширенную асинхронную функцию подтверждений (asynchronous send acknowledgements feature).

Когда сервер получает сообщение, отправленное из нетранзакционной сессии, и это сообщение долговечное(durable) и сообщение направлено как минимум в одну долгосрочную (durable) очередь, то сервер персистирует сообщение в постоянном хранилище. Если параметр журнала journal-sync-non-transactional установлен в true, сервер не отправит ответ клиенту, пока сообщение не будет персистировано на брокере, и сервер не имеет гарантии того, что данные сохранены на диск. Значение по умолчанию для этого параметра — true.

Нетранзакционные подтверждения#

Если вы подтверждаете доставку сообщения на стороне клиента, используя не транзакционные сессии, SMBX может быть настроен на блокировку вызова подтверждения до тех пор, пока подтверждение не достигнет сервера, а ответ будет отправлен обратно клиенту. За это отвечает параметр BlockonAckNowledge. Если он установлен в true, то все вызовы подтверждений в нетранзакционных сессиях будут блокироваться до тех пор, пока подтверждение не достигнет сервера, и не будет отправлен ответ обратно. Данный параметр необходимо установить в true, если необходимо реализовать строгую at most once политику доставки. Значение по умолчанию false.

Маршрутизация сообщений#

Продукт SMB поддерживает возможность маршрутизации (фильтрации) сообщений с использованием выражений фильтрации. Фильтры можно применять в двух местах — в очереди и на consumer.

Фильтрация сообщений в очереди превышает производительность по сравнению с фильтрацией на consumer, поскольку сообщения не нужно сканировать. Однако фильтр очереди менее гибконастраеваемый, чем фильтр на consumer.

Фильтр на очереди#

Когда к очереди применяется фильтр, сообщения фильтруются перед их отправкой в очередь. Чтобы добавить фильтр, используется элемент filter при настройке очереди. Данный фильтр гарантирует, что в эту очередь будут отправляться только сообщения с атрибутом «color=“red“».

Пример:

<addresses>
   <address name="filter">
      <anycast>
         <queue name="filter">
            <filter string="color='red'"/>
         </queue>
      </anycast>
   </address>
</addresses>

Фильтр на консьюмере#

Фильтры на consumer применяются после того, как сообщения будут перенаправлены в очередь, и определяются с использованием соответствующих клиентских API.

Примере JMS:

1. Сначала определяется адрес с одной очередью без применения фильтра в конфигурационном файле etc/broker.xml:

<addresses>
   <address name="filter">
      <anycast>
         <queue name="filter"/>
      </anycast>
   </address>
</addresses>

2. Затем отправляется несколько сообщений в эту очередь:

...
// Send some messages
for (int i = 0; i < 3; i ++) {
  TextMessage redMessage = senderSession.createTextMessage("Red");
  redMessage.setStringProperty("color", "red");
  producer.send(redMessage)
 
  TextMessage greenMessage = senderSession.createTextMessage("Green");
  greenMessage.setStringProperty("color", "green");
  producer.send(greenMessage)
}

В очередь будет записано 6 сообщений: «red, green, red, green, red, green».

3. Далее создается консьюмер с фильтром «color=“red“»:

MessageConsumer redConsumer = redSession.createConsumer(queue, "color='red'");

Согласно фильтру, консьюмер будет вычитывать только сообщения, имеющие атрибут «color=“red“». Таким образом, консьюмер получит только три сообщения: «red, red, red», а в очереди останутся три сообщения «green, green, green».

UI администрирования#

Для мониторинга работы кластера администратором может быть использован UI hawtio.

Hawtio — это универсальная веб-консоль для мониторинга и управления java процессом с множеством плагинов и возможностью расширения плагинами пользователя.

Консоль работает без отдельного сервера, запуская встроенный веб-сервер.

Вход в консоль осуществляется по сертификату пользователя (администратора), доступная функциональность в консоли настраивается через настройку ролевой модели SMBX.

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

Интеграции с внешними системами#

Компонент SMBX позволяет опционально настроить интеграции с дополнительными сервисными системами:

• системой аудита;

• системой журналирования;

• системой управления ключами и сертификатами;

• системой мониторинга;

• системой проксирования авторизационных данных.

В конфигурационных файлах задаются соответствующие блоки настроек.

Система аудита#

Система аудита предназначена для отслеживания значимых изменений в состоянии ПО, обычно с точки зрения работоспособности или безопасности.

Продукт SMB имеет свою метамодель, где перечислен набор событий и передаваемые в них данные.

Типовыми событиями являются:

• старт приложения;

• перезапуск приложения;

• критические ошибки в работе приложения;

• идентификация, аутентификация и авторизация пользователей;

• изменение значимых конфигурационных данных;

• и др.

При необходимости набор событий аудита может быть доработан.

Отправка событий и метамодели возможна либо на REST-endpoint, либо в топики Kafka. На случай, если подключенная система аудита окажется недоступна, есть возможность настраивать буферы, где события будут храниться до восстановления подключения. В качестве буферов могут быть использованы память, файл и топик Kafka.

Система журналирования#

Принимает записи логирования. Продукт SMB умеет выполнять логирование в файл на файловой системе либо в топик Kafka.

Система управления ключами и сертификатами#

Продукт SMB умеет работать с системами на основе Hashicorp Vault. Предполагает выпуск либо хранение ключей/сертификатов/секретов на стороне HashiCorp Vault.

Система мониторинга#

Продукт SMB умеет отдавать JMX-метрики. В качестве нативной системы мониторинга рекомендуется использовать компонент EDMN продукта Platform V Synapse Event-domain management (EDM).

Также можно настроить произвольную систему мониторинга, собирающую метрики через преднастроенные JMX-порты, например, Grafana, Prometheus и др.

Система проксирования авторизационных данных#

Продукт SMB поддерживает интеграцию с Keycloak.

Возможности, предоставляемые данной системой, достаточно широки:

• регистрация пользователей;

• авторизация через соц.сети;

• Single Sign-On / Sign-Off для всех приложений одного Realm;

• выдача JSON Web Token подлинности аккаунтам;

• двухфакторная аутентификация;

• интеграция со службами каталогов (LDAP-сервером);

• брокер Kerberos;

• поддержка разных Realm, с возможностью настройки внешнего вида страницы логина для каждой области.

Для продукта SMB используется Keycloak как опциональное решение для авторизации в UI администратора.