Versions Compared

Version Old Version 7 New Version 8
Changes made by

Laszlo Frazer

Laszlo Frazer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Processors are selected in the type section within file_format. The processor must match the format of the event in the queue.

type - A string specifying which processor to use.

dict_processor – processor for logs that comes as python dictionary objects, i.e. in direct mode
Rw ui textbox macro

file_format

single_json_object - Logs are stored as/in a JSON object.

single_json_object_processor config options:

  • key -(string) The key of where the list of logs is stored.

Code Block
config: {"key": "log"}
fileobj:  {..."log": {...}}

unseparated_json_processor - Logs are stored as/in JSON objects, which are written in a text file with no separator.

unseparated_json config options:

  • key - (string) where the log is stored

  • include (dict: maps names of keys outside of inner part to be included, which can be renamed).

If there is no key, that is, the whole JSON object is the desired log, set "flat": true

See aws_config_collector for example:

Code Block
fileobj:  {...}{...}{...}

text_file_processor - logs are stored as text files, potentially with lines and fields separated with e.g. commas and newlines

text_file config options: includes options for how lines and records are separated (e.g. newline, tab, comma), good for csv style data.

line_split_processor –- logs stored in a newline separated file, works more quickly than separated_json_processor

config options: “json”: true or false. If setting json to true, assumes that logs are newline-separated json, and allows them to be parsed by the collector therefore enabling record-field mapping

separated_json_processor – logs stored as many json objects that have some kind of separator

config options: specify the separator e.g. “separator”: “||”. the default is newline if left unused.

Code Block
fileobj:  {...}||{...}||{...}

jamf_processor – special processor for JAMF logs

aws_access_logs_processor – special processor for AWS access logs

windows_security_processor – special processor for Windows Security logs

vpc_flow_processor – special processor for VPC Flow logs

json_line_arrays_processor – processor for unseparated json objects that are on multiple lines of a single file.

Code Block
fileobj:  {...}{...}
{...}{...}{...}
{...}
json_array_ instead.The unseparated_json_processor with an

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 Python dict which renames JSON keys. The rename parameter can rename keys selected by the key parameter.

split_or_unseparated_processor

Selects the processor by detecting \n.

aws_access_logs_processor

For AWS access logs and \n splits.

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.

bluecoat_processor

For Bluecoat recipe.

json_object_to_linesplit_processor

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

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 orjson raw_decode. The key string parameter or keys array parameter are permitted.

json_line_arrays_processor

Processes JSON separated by \n. Use parameter is permitted. The parameter may be a string or array. The include parameter is permitted. It a Python dict 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

jamf_processor

Jamf log processing.

parquet_processor

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

guardduty_processor

For GuardDuty processors.

vpc_flow_processor

VPC service processor.

alt_vpc_flow_processor

Used for exception handling.

kolide_processor

For Kolide service.

json_array_vpc_processor

VPC service processor.

rds_processor

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

unseparated_json_processor_extract_key

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

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

The configuration

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

will send

send to devo

to Devo.

More on processors:

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.

More on processors:

file_format

type - A string specifying which processor to use.

config - a dictionary of information the specified file_format processor needs

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).

For example, we may want to parse something and call it type by getting type from a certain key in the record (which may be multiple layers deep).

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

The keys are a list of how to find a value and handle nesting (essentially, defining a path through the data).

Suppose we have logs that look like this:

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

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

Code Block
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:

Code Block
{“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.

Let’s say you have a log in JSON format like this which will be set to Devo:

Code Block
{“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.

Now let’s say you want to change the tag dynamically based on that value. You could 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.

Now let’s say you want to filter out (not send) any records which have the type security_log. You could write a line_filter_rule as follows:

Code Block
{"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.

Let’s say you have 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:

Code Block
"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:

Code Block
filename.split(“/”)[1]

Tagging

Tagging can be done in many different ways. One way tagging works is by using the file field definitions:

Code Block
  "file_field_definitions": {
    "log_type": [
      {
        "operator": "split",
        "on": "/",
        "element": 2
      }
    ]
  },

These are the elements of the filename object:

If you look at the highlighted object filename, you can see that we are splitting and looking for the 2nd value. This starts at 0 like arrays. So:

  • 0 = cequence-data

  • 1 = cequence-devo-6x-NAieMI

  • 2 = detector

"routing_template": "my.app.test_cequence.[file-log_type]"

Our final tag is my.app.test_cequence.detector

Here is another example:

file_field_definitions

Defined as a dictionary mapping of variable names (you decide) that lists parsing rules.

Each parsing rule has an operator with its own keys. Parsing rules are applied in the order they are listed in the configuration.

  • The split operator uses the on and element keys. The file name will split into pieces considering the character or character sequence specified in the on key, and will extract whatever it is at the specified element index, as in the example below.

  • The replace operator uses the to_replace and replace_with keys.

For example, if your filename is server_logs/12409834/ff.gz, this configuration would store the log_type as serverlogs:

Code Block
"file_field_definitions": 
{
	"log_type": [{"operator": "split", "on": "/", "element": 0}, {"operator": "replace", "to_replace": "_", "replace_with": ""}]
}

routing_template

A string defining how to build the tag to send each message, for example, my.app.wow.[record-type].[file-log_type]

If the type extracted during record_field_mapping was null, the record would be sent to the tag my.app.wow.null

Options for filtering

Line-level filters

These are a list of rules for filtering out single events.

...