Event parsing settings

Expand all | Collapse all

You can configure the rules for converting incoming events to the KUMA format when creating event parsing rules in the normalizer settings window, on the Normalization scheme tab. Available event parsing settings are listed in the table below.

Available event parsing settings

Setting

Description

Name

Name of the parsing rule. Maximum length of the name: 128 Unicode characters. The name of the main parsing rule is used as the name of the normalizer.

Required setting.

Tenant

The name of the tenant that owns the resource.

This setting is not available for extra parsing rules.

Parsing method

The type of incoming events. Depending on the selected parsing method, you can use the predefined event field matching rules or define your own rules. When you select some parsing methods, additional settings may become available they you must specify. Available parsing methods:

  • json
  • cef
  • regexp
  • syslog
  • csv
  • kv
  • xml
  • netflow5
  • netflow9
  • sflow5
  • ipfix
  • sql

Required setting.

Keep raw event

Keeping raw events in the newly created normalized event. Available values:

  • Don't save—do not save the raw event. This is the default setting.
  • Only errors—save the raw event in the Raw field of the normalized event if errors occurred when parsing it. This value is useful for debugging because an event having a non-empty Raw field indicates a problem.

    If fields containing the names *Address or *Date* do not comply with normalization rules, these fields are ignored. No normalization error occurs in this case, and the values of the fields are not displayed in the Raw field of the normalized event even if the Keep raw eventOnly errors option was selected.

  • Always—always save the raw event in the Raw field of the normalized event.

Required setting. This setting is not available for extra parsing rules.

Keep extra fields

Keep fields and values for which no mapping rules are configured. This data is saved as an array in the Extra event field. Normalized events can be searched and filtered based on the data stored in the Extra field.

Filtering based on data from the Extra event field

By default, no extra fields are saved.

Required setting.

Description

Description of the resource. Maximum length of the description: 4000 Unicode characters.

This setting is not available for extra parsing rules.

Event examples

Example of data that you want to process.

This setting is not available for the following parsing methods: netflow5, netflow9, sflow5, ipfix, and sql.

If the event was parsed successfully, and the type of the data obtained from the raw event matches the type of the KUMA field, the Event examples field is filled with data obtained from the raw event. For example, the "192.168.0.1" value in quotation marks does not appear in the SourceAddress field. However, the 192.168.0.1 value is displayed in the Event examples field.

Mapping

Settings for configuring the mapping of source event fields to fields of the event in the KUMA format:

  • Source lists the names of the raw event fields that you want to convert into KUMA event fields.

    Next to field names in the Source column, clicking wrench-new opens the Conversion window, in which you can click Add conversion to create rules for modifying the source data before writing them to the KUMA event fields. You can reorder and delete created rules. To change the position of a rule, click DragIcon next to it. To delete a rule, click cross-black next to it.

    Available conversions

  • KUMA field lists fields of KUMA events. You can search for fields by entering their names.
  • Label is a unique custom label for event fields that begin with DeviceCustom* and Flex*.

You can add new table rows or delete table rows. To add a new table row, click Add row. To delete a single row in the table, click cross next to it. To delete all table rows, click Clear all.

If you have loaded data into the Event examples field, the table will have an Examples column containing examples of values carried over from the raw event field to the KUMA event field.

If the size of the KUMA event field is less than the length of the value placed in it, the value is truncated to the size of the event field.

Extended event schema

When normalizing events, extended event schema fields can be used in addition to standard KUMA event schema fields. When using extended event schema fields, the general limit for the maximum size of an event that can be processed by the collector is the same, 4 MB. Information about the types of extended event schema fields is shown in the table below.

Using many unique fields of the extended event schema can reduce the performance of the system, increase the amount of disk space required for storing events, and make the information difficult to understand.

We recommend consciously choosing a minimal set of additional fields of the extended event schema that you want to use in normalizers and correlation.

To use the fields of the extended event schema:

  1. Open an existing normalizer or create a new normalizer.
  2. Specify the basic settings of the normalizer.
  3. Click Add row.
  4. For the Source setting, enter the name of the source field in the raw event.
  5. For the KUMA field, specify the name of the extended event schema field to be created.

    Fields of the extended data model of normalized events:

  6. Click OK, then click Save to save the event normalizer.

The normalizer is saved, and the additional field is created. After saving the normalizer, the additional field can be used in other normalizers and KUMA resources.

If the data in the fields of the raw event does not match the type of the KUMA field, the value is not saved during the normalization of events if type conversion cannot be performed. For example, the string test cannot be written to the DeviceCustomNumber1 KUMA field of the Number type.

If you want to minimize the load on the storage server when searching events, preparing reports, and performing other operations on events in storage, use KUMA event schema fields as your first preference, extended event schema fields as your second preference, and the Extra fields as your last resort.

Page top