Параметры парсинга событий

Развернуть все | Свернуть все

При создании правил парсинга событий в окне параметров нормализатора на вкладке Схема нормализации вы можете настроить правила приведения поступающих событий к формату KUMA.

Чтобы определить параметры парсинга событий:

  1. В поле Имя (обязательное поле) введите уникальное имя правила парсинга. Имя должно содержать от 1 до 128 символов Юникода. Название основного правила парсинга будет использоваться в качестве названия нормализатора.
  2. В поле Тенант (обязательное поле) введите имя тенанта, которому принадлежит ресурс.

    Этот параметр недоступен для дополнительных правил парсинга.

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

    Доступные методы парсинга:

    • json
    • cef
    • regexp
    • syslog
    • csv
    • kv
    • xml
    • netflow5
    • netflow9
    • sflow5
    • ipfix
    • sql – этот метод становится доступным, только при использовании коннектора типа sql
  4. В раскрывающемся списке Сохранить сырое событие укажите, надо ли сохранять сырое событие во вновь созданном нормализованном событии. Доступные значения:
    • Не сохранять – не сохранять сырое событие. Это значение используется по умолчанию.
    • При возникновении ошибок – сохранять сырое событие в поле Raw нормализованного события, если в процессе парсинга возникли ошибки. Это значение удобно использовать при отладке службы. В этом случае каждый раз, когда у события есть непустое поле Raw, это означает, что возникла проблема.

      Если поля с названиями *Address или *Date* не соответствуют правилам нормализации, такие поля игнорируются. При этом не возникает ошибка нормализации и значения полей не попадают в поле Raw нормализованного события, даже если был указан параметр Сохранить сырое событиеПри возникновении ошибок.

    • Всегда – сохранять сырое событие в поле Raw нормализованного события.

    Этот параметр недоступен для дополнительных правил парсинга.

  5. В раскрывающемся списке Сохранить дополнительные поля выберите, требуется ли сохранять поля сырого события в нормализованном событии, если для них не были настроены правила сопоставления (см. ниже). Данные сохраняются в поле события Extra. Нормализованные события можно искать и фильтровать по данным, хранящимся в поле Extra.

    Фильтрация по данным из поля события Extra

    По умолчанию поля не сохраняются.

  6. В поле Описание укажите описание ресурса: до 4000 символов Юникода.

    Этот параметр недоступен для дополнительных правил парсинга.

  7. При необходимости поле Примеры событий укажите пример данных, которые вы хотите обработать.

    Этот параметр недоступен для методов парсинга netflow5, netflow9, sflow5, ipfix, sql.

    Поле Примеры событий заполняется данными, полученными из сырого события, если парсинг события был выполнен успешно и тип полученных из сырого события данных совпадает с типом поля KUMA.

    Например, значение "192.168.0.1", заключенное в кавычки не будет отображено в поле SourceAddress, при этом значение 192.168.0.1 будет отображено в поле Примеры событий.

  8. В таблице Сопоставление настройте сопоставление полей сырого события с полями событий в формате KUMA:
    1. В столбце Исходные данные укажите название поля сырого события, которое вы хотите преобразовать в поле события KUMA.

      Подробнее о формате полей см. в статье Модель данных нормализованного события. Описание сопоставления см. в статье Сопоставление полей предустановленных нормализаторов.

      Если рядом с названиями полей в столбце Исходные данные нажать на кнопку wrench-new, откроется окно Преобразование, в котором при нажатии на кнопку Добавить преобразование можно создать правила изменения исходных данных перед тем, как они будут записаны в поля событий KUMA.

      Доступные преобразования

      В окне Преобразования добавленные правила можно менять местами, перетягивая их за значок DragIcon, а также удалять с помощью значка cross-black.

    2. В столбце Поле KUMA в раскрывающемся списке выберите требуемое поле события KUMA. Поля можно искать, вводя в поле их названия.

      Рекомендации для полей столбцов KUMA

    3. Если название поля события KUMA, выбранного на предыдущем шаге, начинается с DeviceCustom* и Flex*, в поле Подпись можно добавить уникальную пользовательскую метку.

    Новые строки таблицы можно добавлять с помощью кнопки Добавить строку. Строки можно удалять по отдельности с помощью кнопки X. или все сразу с помощью кнопки Очистить все.

    Чтобы KUMA могла выполнить обогащение событий данными про активы, и данные об активах были доступны в карточке алерта при срабатывании корреляционного правила, в таблице Сопоставление вам необходимо настроить сопоставление полей для адреса устройства и имени устройства в зависимости от назначения актива. Например, сопоставление для SourceAddress и SourceHostName, или DestinationAddress и DestinationHostName. В результате обогащения в карточке события появится поле SourceAssetID или DestinationAssetID и ссылка, по которой можно будет перейти в карточку актива. Также в результате обогащения сведения об активе будут доступны в карточке алерта.

    Если вы загрузили данные в поле Примеры событий, в таблице отобразится столбец Примеры с примерами значений, переносимых из поля сырого события в поле события KUMA.

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

Расширенная схема события

При нормализации событий, помимо полей стандартной схемы событий KUMA, могут быть использованы поля расширенной схемы событий. Информация о типах полей расширенной схемы событий приведена в таблице далее.

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

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

Для использования полей расширенной схемы событий необходимо выполнить следующее:

Префиксы S., N., F., SA., NA., FA. обязательны при создании полей расширенной схемы событий, префиксы должны использовать только заглавные буквы.

Вместо <имя поля> необходимо задать имя поля. В имени поля допустимо использовать символы английского алфавита, числа. Использование символа "пробел" не допускается.

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

Примечание: в случае, если данные, находящиеся в поля сырого события, не соответствуют типу поля KUMA, то в процессе нормализации событий значение не будет сохранено. Например, строка test не может быть помещена в числовое поле KUMA DeviceCustomNumber1.

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

В начало