Log Record Fields

Original log entry text, UTF-8 encoded

This field may be absent or empty if a non-empty structured field is present. See the description of structured for more.

Original log entry as a structured object.

This field may be present if the forwarder was configured to parse structured JSON logs. If the original log entry was a valid structured log, this field will contain an equivalent JSON structure. Otherwise this field will be empty or absent, and the message field will contain the original log message. The structured field includes the same sub-fields as the original log message.

The type of log, a string that begins with "application", "infrastructure" or "audit".

The log_type field may contain one of these strings, or may have additional dot-separated components, for example "infrastructure.container" or "infrastructure.node".

A UTC value that marks when the log payload was created or, if the creation time is not known, when the log payload was first collected. The “@” prefix denotes a field that is reserved for a particular use. By default, most tools look for “@timestamp” with ElasticSearch.

The name of the host where this log message originated. In a Kubernetes cluster, this is the same as kubernetes.host.

The IPv4 address of the source server. Can be an array.

The IPv6 address of the source server, if available. Can be an array.

The logging level from various sources, including rsyslog(severitytext property), python’s logging module, and others.

The following values come from syslog.h, and are preceded by their numeric equivalents:

The two following values are not part of syslog.h but are widely used:

Map the log levels or priorities of other logging systems to their nearest match in the preceding list. For example, from python logging, you can match CRITICAL with crit, ERROR with err, and so on.

The process ID of the logging entity, if available.

The name of the service associated with the logging entity, if available. For example, syslog’s APP-NAME and rsyslog’s programname properties are mapped to the service field.

Optional. An operator-defined list of tags placed on each log by the collector or normalizer. The payload can be a string with whitespace-delimited string tokens or a JSON list of string tokens.

The path to the log file from which the collector read this log entry. Normally, this is a path in the /var/log file system of a cluster node.

The offset value. Can represent bytes to the start of the log line in the file (zero- or one-based), or log line numbers (zero- or one-based), so long as the values are strictly monotonically increasing in the context of a single log file. The values are allowed to wrap, representing a new version of the log file (rotation).

The namespace for Kubernetes-specific metadata

The namespace for openshift-logging specific metadata

Contains common fields specific to systemd journal. For more information please see https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html Applications may write their own fields to the journal. These will be available under the systemd.u namespace. RESULT and UNIT are two such fields.

Audit events converted with aushape. For more information please see https://github.com/Scribery/aushape