Search

Chapter 15. Log Record Fields

download PDF

The following fields can be present in log records exported by the logging. Although log records are typically formatted as JSON objects, the same data model can be applied to other encodings.

To search these fields from Elasticsearch and Kibana, use the full dotted field name when searching. For example, with an Elasticsearch /_search URL, to look for a Kubernetes pod name, use /_search/q=kubernetes.pod_name:name-of-my-pod.

The top level fields may be present in every record.

message

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

Data type

text

Example value

HAPPY

structured

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 can have any subfields that are included in the log message, there are no restrictions defined here.

Data type

group

Example value

map[message:starting fluentd worker pid=21631 ppid=21618 worker=0 pid:21631 ppid:21618 worker:0]

@timestamp

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.

Data type

date

Example value

2015-01-24 14:06:05.071000000 Z

hostname

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

Data type

keyword

ipaddr4

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

Data type

ip

ipaddr6

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

Data type

ip

level

The logging level from various sources, including rsyslog(severitytext property), a Python logging module, and others.

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

  • 0 = emerg, system is unusable.
  • 1 = alert, action must be taken immediately.
  • 2 = crit, critical conditions.
  • 3 = err, error conditions.
  • 4 = warn, warning conditions.
  • 5 = notice, normal but significant condition.
  • 6 = info, informational.
  • 7 = debug, debug-level messages.

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

  • 8 = trace, trace-level messages, which are more verbose than debug messages.
  • 9 = unknown, when the logging system gets a value it doesn’t recognize.

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.

Data type

keyword

Example value

info

pid

The process ID of the logging entity, if available.

Data type

keyword

service

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.

Data type

keyword

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.