Event Fields

edit

The event fields are used for context information about the log or metric event itself.

A log is defined as an event containing details of something that happened. Log events must include the time at which the thing happened. Examples of log events include a process starting on a host, a network packet being sent from a source to a destination, or a network connection between a client and a server being initiated or closed. A metric is defined as an event containing one or more numerical or categorical measurements and the time at which the measurement was taken. Examples of metric events include memory pressure measured on a host, or vulnerabilities measured on a scanned host.

Event Field Details

edit
Field Description Level

event.action

The action captured by the event.

This describes the information in the event. It is more specific than event.category. Examples are group-add, process-started, file-created. The value is normally defined by the implementer.

type: keyword

example: user-password-change

core

event.category

Event category.

This contains high-level information about the contents of the event. It is more generic than event.action, in the sense that typically a category contains multiple actions. Warning: In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution.

type: keyword

example: user-management

core

event.code

Identification code for this event, if one exists.

Some event sources use event codes to identify messages unambiguously, regardless of message language or wording adjustments over time. An example of this is the Windows Event ID.

type: keyword

example: 4648

extended

event.created

event.created contains the date/time when the event was first read by an agent, or by your pipeline.

This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event.

In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent’s or pipeline’s ability to keep up with your event source.

In case the two timestamps are identical, @timestamp should be used.

type: date

example: 2016-05-23 08:05:34.857000

core

event.dataset

Name of the dataset.

If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from.

It’s recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name.

type: keyword

example: apache.access

core

event.duration

Duration of the event in nanoseconds.

If event.start and event.end are known this value should be the difference between the end and start time.

type: long

core

event.end

event.end contains the date when the event ended or when the activity was last observed.

type: date

extended

event.hash

Hash (perhaps logstash fingerprint) of raw field to be able to demonstrate log integrity.

type: keyword

example: 123456789012345678901234567890ABCD

extended

event.id

Unique ID to describe the event.

type: keyword

example: 8a4f500d

core

event.ingested

Timestamp when an event arrived in the central data store.

This is different from @timestamp, which is when the event originally occurred. It’s also different from event.created, which is meant to capture the first time an agent saw the event.

In normal conditions, assuming no tampering, the timestamps should chronologically look like this: @timestamp < event.created < event.ingested.

type: date

example: 2016-05-23 08:05:35.101000

core

event.kind

The kind of the event.

This gives information about what type of information the event contains, without being specific to the contents of the event. Examples are event, state, alarm. Warning: In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution.

type: keyword

example: state

extended

event.module

Name of the module this data is coming from.

If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), event.module should contain the name of this module.

type: keyword

example: apache

core

event.original

Raw text message of entire event. Used to demonstrate log integrity.

This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source.

type: keyword

example: Sep 19 08:26:10 host CEF:0&#124;Security&#124; threatmanager&#124;1.0&#124;100&#124; worm successfully stopped&#124;10&#124;src=10.0.0.1 dst=2.1.2.2spt=1232

core

event.outcome

The outcome of the event.

If the event describes an action, this fields contains the outcome of that action. Examples outcomes are success and failure. Warning: In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution.

type: keyword

example: success

extended

event.provider

Source of the event.

Event transports such as Syslog or the Windows Event Log typically mention the source of an event. It can be the name of the software that generated the event (e.g. Sysmon, httpd), or of a subsystem of the operating system (kernel, Microsoft-Windows-Security-Auditing).

type: keyword

example: kernel

extended

event.risk_score

Risk score or priority of the event (e.g. security solutions). Use your system’s original value here.

type: float

core

event.risk_score_norm

Normalized risk score or priority of the event, on a scale of 0 to 100.

This is mainly useful if you use more than one system that assigns risk scores, and you want to see a normalized value across all systems.

type: float

extended

event.sequence

Sequence number of the event.

The sequence number is a value published by some event sources, to make the exact ordering of events unambiguous, regarless of the timestamp precision.

type: long

extended

event.severity

The numeric severity of the event according to your event source.

What the different severity values mean can be different between sources and use cases. It’s up to the implementer to make sure severities are consistent across events from the same source.

The Syslog severity belongs in log.syslog.severity.code. event.severity is meant to represent the severity according to the event source (e.g. firewall, IDS). If the event source does not publish its own severity, you may optionally copy the log.syslog.severity.code to event.severity.

type: long

example: 7

core

event.start

event.start contains the date when the event started or when the activity was first observed.

type: date

extended

event.timezone

This field should be populated when the event’s timestamp does not include timezone information already (e.g. default Syslog timestamps). It’s optional otherwise.

Acceptable timezone formats are: a canonical ID (e.g. "Europe/Amsterdam"), abbreviated (e.g. "EST") or an HH:mm differential (e.g. "-05:00").

type: keyword

extended

event.type

Reserved for future usage.

Please avoid using this field for user data.

type: keyword

core