При создании правил парсинга событий в окне параметров нормализатора на вкладке Схема нормализации вы можете настроить правила приведения поступающих событий к формату KUMA.
Чтобы определить параметры парсинга событий:
Этот параметр недоступен для дополнительных правил парсинга.
Доступные методы парсинга:
Raw
нормализованного события, если в процессе парсинга возникли ошибки. Это значение удобно использовать при отладке службы. В этом случае каждый раз, когда у события есть непустое поле Raw
, это означает, что возникла проблема.Если поля с названиями *Address
или *Date*
не соответствуют правилам нормализации, такие поля игнорируются. При этом не возникает ошибка нормализации и значения полей не попадают в поле Raw
нормализованного события, даже если был указан параметр Сохранить сырое событие → При возникновении ошибок.
Raw
нормализованного события.Этот параметр недоступен для дополнительных правил парсинга.
Extra
. Нормализованные события можно искать и фильтровать по данным, хранящимся в поле Extra
.Фильтрация по данным из поля события Extra
По умолчанию поля не сохраняются.
Этот параметр недоступен для дополнительных правил парсинга.
Этот параметр недоступен для методов парсинга netflow5, netflow9, sflow5, ipfix, sql.
Поле Примеры событий заполняется данными, полученными из сырого события, если парсинг события был выполнен успешно и тип полученных из сырого события данных совпадает с типом поля KUMA.
Например, значение "192.168.0.1", заключенное в кавычки не будет отображено в поле SourceAddress, при этом значение 192.168.0.1 будет отображено в поле Примеры событий.
Подробнее о формате полей см. в статье Модель данных нормализованного события. Описание сопоставления см. в статье Сопоставление полей предустановленных нормализаторов.
Если рядом с названиями полей в столбце Исходные данные нажать на кнопку , откроется окно Преобразование, в котором при нажатии на кнопку Добавить преобразование можно создать правила изменения исходных данных перед тем, как они будут записаны в поля событий KUMA.
В окне Преобразования добавленные правила можно менять местами, перетягивая их за значок , а также удалять с помощью значка
.
DeviceCustom*
и Flex*
, в поле Подпись можно добавить уникальную пользовательскую метку.Новые строки таблицы можно добавлять с помощью кнопки Добавить строку. Строки можно удалять по отдельности с помощью кнопки или все сразу с помощью кнопки Очистить все.
Чтобы KUMA могла выполнить обогащение событий данными про активы, и данные об активах были доступны в карточке алерта при срабатывании корреляционного правила, в таблице Сопоставление вам необходимо настроить сопоставление полей для адреса устройства и имени устройства в зависимости от назначения актива. Например, сопоставление для SourceAddress и SourceHostName, или DestinationAddress и DestinationHostName. В результате обогащения в карточке события появится поле SourceAssetID или DestinationAssetID и ссылка, по которой можно будет перейти в карточку актива. Также в результате обогащения сведения об активе будут доступны в карточке алерта.
Если вы загрузили данные в поле Примеры событий, в таблице отобразится столбец Примеры с примерами значений, переносимых из поля сырого события в поле события KUMA.
Если размер поля события KUMA оказывается меньше длины помещаемого в него значения, значение обрезается до размера поля события.
Расширенная схема события
При нормализации событий, помимо полей стандартной схемы событий KUMA, могут быть использованы поля расширенной схемы событий. Информация о типах полей расширенной схемы событий приведена в таблице далее.
Использование значительного количества уникальных полей расширенной схемы событий может привести к снижению производительности системы, увеличению объема дискового пространства, необходимого для хранения событий, сложности восприятия данных.
Мы рекомендуем предварительно продумать и сформировать минимально необходимый набор дополнительных полей расширенной схемы событий и использовать его в нормализаторах и корреляции.
Для использования полей расширенной схемы событий необходимо выполнить следующее:
Поля расширенной модели данных нормализованного события
Название поля Указывается в параметре Поле KUMA |
Тип данных |
Доступность в нормализаторе |
Описание |
---|---|---|---|
S.< |
Строка |
Все типы |
Поле с типом |
N.< |
Число |
Все типы |
Поле с типом |
F.< |
Число с плавающей точкой |
Все типы |
Поле с типом |
SA.< |
Массив строк |
KV, JSON |
Поле с типом |
NA.< |
Массив целых чисел |
KV, JSON |
Поле с типом |
FA.< |
Массив чисел с плавающей точкой |
KV, JSON |
Поле с типом |
Префиксы S.
, N.
, F.
, SA.
, NA.
, FA.
обязательны при создании полей расширенной схемы событий, префиксы должны использовать только заглавные буквы.
Вместо <
имя поля
>
необходимо задать имя поля. В имени поля допустимо использовать символы английского алфавита, числа. Использование символа "пробел" не допускается.
Нормализатор сохранен, дополнительное поле создано. После сохранение нормализатора дополнительное поле может быть использовано в других нормализаторах.
Примечание: в случае, если данные, находящиеся в поля сырого события, не соответствуют типу поля KUMA, то в процессе нормализации событий значение не будет сохранено. Например, строка test
не может быть помещена в числовое
поле KUMA DeviceCustomNumber1.
С точки зрения нагрузки на сервер хранения при операциях при операциях поиска событий, подготовки отчетов и иных операциями с событиями в хранилище наиболее предпочтительными являются поля схемы событий KUMA, затем идут поля расширенной схемы событий, затем поля Extra.
В начало