Правила принадлежности к тенантам
Правила наследования тенанта
Важно отслеживать, какому тенанту принадлежат создаваемые в KUMA объекты: от этого зависит, кто к ним будет иметь доступ и взаимодействие с какими объектами можно настроить. Правила определения тенанта:
- Тенант объекта (например, сервиса или ресурса) определяется пользователем при его создании.
После создания объекта выбранный для него тенант невозможно изменить. Ресурсы, однако, можно экспортировать, а затем импортировать в другой тенант.
- Тенант алерта и корреляционного события наследуется от создавшего их коррелятора.
Название тенанта указывается в поле события
TenantId
. - Если события разных тенантов, обрабатываемых одним коррелятором, не смешиваются, создаваемые коррелятором корреляционные события наследуют тенант события.
- Тенант инцидента наследуется от алерта.
Примеры мультитенантных взаимодействий
Мультитенантность в KUMA дает возможность централизованно расследовать алерты и инциденты, возникающие в разных тенантах. Ниже приведены сценарии, по которым можно проследить, к каким тенантам принадлежат создаваемые объекты.
При корреляции событий от разных тенантов в общем потоке не следует группировать события по тенанту: то есть не нужно в правилах корреляции в поле Группирующие поля указывать поле события TenantId
. Группировка событий по тенанту необходима, только если нужно не смешивать события от разных тенантов.
Сервисы, которые должны быть размещены на мощностях главного тенанта, разворачиваются только пользователями с ролью главный администратор.
- Корреляция событий в рамках одного тенанта, коррелятор выделен для этого тенанта и развернут на его стороне
- Корреляция событий в рамках одного тенанта, коррелятор выделен для этого тенанта и развернут на стороне главного тенанта
- Централизованная корреляция событий, поступающих от разных тенантов
- Тенант коррелирует свои события, но в главном тенанте дополнительно осуществляется централизованная корреляция событий
- Один коррелятор для двух тенантов