Page Comparison

split_or_unseparated_processor

Selects the processor by detecting \n. If unsure, this processor is recommended.

line_split_processor

Split an object into logs at each \n character using Python splitlines. Optionally, the log can be split using:

• chunks, a boolean parameter which enables the remaining parameters.

• indices, a Python integer array which selects lines from the object.

• substrings, a Python string array which selects lines from the object containing the configured strings.

• regex, a Python string array which selects lines from the object using python re.findall.

text_file_processor

Finds header information and adds it to each event. The line_separator parameter is required. The header can be identified using one of these parameters.

• header (boolean) and header_field_separator to get headers from the first line of data.

• field_names for a manual header.

• field_separator for numbered fields.

Additionally, if use_json is true, Python orjson will convert the data to JSON.

unseparated_json_processor

Split a JSON array into individual Devo events with Python raw_decode. The key parameter is permitted. The parameter may be a string or array. The include parameter is permitted. It a dictionary which renames JSON keys. The rename parameter can rename keys selected by the key parameter.

single_json_object_processor

For messages containing one JSON object. Uses Python orjson to process a single JSON object. Not for arrays. The key parameter is permitted.

separated_json_processor

Similar to other separators. The default separator is \n. The separator parameter is permitted.

json_object_to_linesplit_processor

Split by configured value. The key string parameter or keys array parameter are permitted.

unseparated_json_processor_extract_key

The unseparated_json_processor with an additional extraction_key parameter permitted. Use this when filtering on two levels of JSON keys.

If the log message has this format

{
  "id": 1,
  "timestamp": 2,
  "logEvents": {
    "another_id": 3,
    "another_timestamp": 4,
    "message": "send to devo"
  }
} 

The configuration

"file_format": {
  "type": "unseparated_json_processor_extract_key",
  "config": {
    "key": "logEvents",
    "extraction_key": "message"
  }
},

will send

send to devo

to Devo.

json_array_processor

Split a JSON array into individual Devo events with Python orjson. The key string parameter or keys array parameter are permitted.

json_line_arrays_processor

Processes JSON separated by \n. Use separated_json_processor instead.

aws_access_logs_processor

For AWS access logs and \n splits.

bluecoat_processor

Bluecoat.

jamf_processor

Jamf logs.

parquet_processor

Parquet processing using Python pandas.read_parquet. The data is converted to JSON.

guardduty_processor

For GuardDuty processors.

vpc_flow_processor

AWS VPC.

alt_vpc_flow_processor

Used for exception handling.

kolide_processor

For Kolide.

json_array_vpc_processor

AWS VPC.

rds_processor

RDS processor for the RDS service unseparated_json_processor. Use this if the events come in one massive JSON object.

windows_security_processor

Windows security logs.

file_format

type A string specifying which processor to use, from the list above.

config A dictionary of the processor’s parameters.

record_field_mapping

A dictionary where each key defines a variable that can be parsed out from each record (which may be referenced later in filtering).

To parse something and call it type by getting type from a certain key in the record (which may be multiple layers deep).

{"type": {"keys": ["file", "type"]},	"operations": []	}

Suppose we have logs that look like this:

{“file”: {“type”: { “log_type” : 100}}}

To get the log_type, we should list all the keys needed to parse through the JSON in order:

keys: [“file”, “type”, “log_type”]

In many cases, you will probably only need one key, for example, in a flat JSON that isn’t nested:

{“log_type”: 100, “other_info”: “blah” ….}

Here you would just specify keys: ["log_type"]. There are some operations that can be used to further alter the parsed information (like split and replace).

This snippet would grab whatever is located at log["file"]["type"] and name it as type. record_field_mapping defines variables by taking them from logs, and these variables can then be used for filtering.

If you have a log in JSON format like this which will be set to Devo:

{“file”: {“value”: 0, “type”: “security_log”}}

Specifying type in record_field_mapping will allow the collector to extract the security_logand save it as type.

To change the tag using a field mapping, change the routing_template to something like my.app.datasource.[record-type]. In the case of the log above, it would be sent to my.app.datasource.security_log.

To filter out (not send) any records which have the type security_log, write a line_filter_rule as follows:

{"source": "record", "key": "type", "type": "match", "value": "security_log" } 

• We specified the source as record because we want to use a variable from the record_field_mapping.

• We specified the key as type because that is the name of the variable we defined.

• We specified type as match because any record matching this rule we want to filter out.

• And we specified the value as security_log because we specifically do not want to send any records with the type equalling security_log.

The split operation is the same as if you ran the Python split function on a string.

Given a filename logs/account_id/folder_name/filename and you want to save the account_id as a variable to use for tag routing or filtering.

You could write a file_field_definition like this:

"account_id": [{"operator": "split", "on": "/", "element": 1}]

This would store a variable called account_id by taking the entire filename and splitting it into pieces based on where it finds backslashes, then take the element as position one. In Python, it would look like this:

filename.split(“/”)[1]