Standard Attributes

Overview

Centralizing logs from various technologies and applications tends to generate tens or hundreds of different attributes in a Log Management environment—especially when many teams’ users, each one with their own personal usage patterns, are working within the same environment.

This can generate confusion. For instance, a client IP might have the following attributes within your logs: clientIP, client_ip_address, remote_address, client.ip, etc.

In this context, the number of created or provided attributes can lead to confusion and difficulty to configure or understand the environment. It is also cumbersome to know which attributes correspond to the the logs of interest and - for instance - correlating web proxy with web application logs would be difficult. Even if technologies define their respective logs attributes differently, a URL, client IP, or duration have universally consistent meanings.

Standard Attributes have been designed to help your organization to define its own Naming Convention and to enforce it as much as possible across users and functional teams. The goal is to define a subset of attributes that would be the recipient of shared semantics that everyone agrees to use by convention.

Log Integrations are natively relying on the default provided set but your organization can decide to extend or modify this list. The standard attribute table is available in Log Configuration pages, along with pipelines, indexes, and archives.

How these Standard Attributes will be suggested or enforced? Administrators have the right to re-copy an existing set of (non-standard) attributes into a standard one so to enforce non compliant logs sources to become compliant without loosing any previous information.

Standard Attribute list

The standard attribute table comes with a set of predefined standard attributes. You can append that list with your own attributes, and edit or delete existing standard attributes:

Add Or Update Standard Attributes

A standard attribute is defined by its:

• Path: The path of the Standard attributes as you would find it in your JSON (e.g network.client.ip)
• Type (string, integer, double, boolean): The type of the attribute which is used to cast element of the remapping list
• Description: Human readable description of the attribute
• Remapping list: Comma separated list of non-compliant attribute that should be remapped to the Standard one

The standard attribute panel pops when you add a new standard attribute or edit an existing one:

Any element of the standard attribute can then be filled or updated. Note: Any updates or additions to standard attributes are only applied to newly ingested logs.

Standard Attribute Remapping Behaviour

After being processed in the pipelines, each log goes through the full list of Standard Attributes. For each entry of the standard attribute table, if the current log has an attribute matching the remapping list, the following is done:

• The first attribute that matches the provided list is remapped, and the value is overridden by the new one if already existing
• Datadog enforces the type of the remapped attribute (if this is not possible, the attribute is skipped and the next matching one of the list is used)
• The original attribute is kept in the log

Important Note: By default, the type of an existing standard attribute is unchanged if the remapping list is empty. Add the standard attribute to its own remapping list to enforce its type.

Validation

To add or update a standard attribute, follow these rules:

• A standard attribute cannot be added in the remapping list of another standard attribute.
• A custom attribute can be remapped to only one standard attribute.
• To respect the JSON structure of the logs, it is not possible to have one standard attribute as the child of another (for example user and user.name cannot be both standard attributes).

Default Standard Attribute List

The default standard attribute list is split into 7 functional domains:

• Network/communications
• HTTP Requests
• Source code
• Database
• Performance
• User related attributes
• Syslog and log shippers

Network

The following attributes are related to the data used in network communication. All fields and metrics are prefixed by network.

Typical integrations relying on these attributes include Apache, Varnish, AWS ELB, Nginx, HAProxy, etc.

HTTP Requests

These attributes are related to the data commonly used in HTTP requests and accesses. All attributes are prefixed by http.

Typical integrations relying on these attributes include Apache, Rails, AWS CloudFront, web applications servers, etc.

Common attributes

URL details attributes

These attributes provide details about the parsed parts of the HTTP URL. They are generally generated thanks to the URL parser. All attributes are prefixed by http.url_details.

User-Agent attributes

These attributes provide details about the meanings of user-agents’ attributes. They are generally generated thanks to the User-Agent parser. All attributes are prefixed by http.useragent_details.

Source code

These attributes are related to the data used when a log or an error is generated via a logger in a custom application. All attributes are prefixed either by logger or error.

Typical integrations relying on these attributes are: Java, NodeJs, .NET, Golang, Python, etc.

Database

Database related attributes are prefixed by db.

Typical integrations relying on these attributes are: Cassandra, MySQL, RDS, Elasticsearch, etc.

Performance

Performance metrics attributes.

We advise you to rely or at least remap on this attribute as Datadog displays and uses it as a default Measure for trace Search.

User related attributes

All attributes and measures are prefixed by usr.

Syslog and log shippers

These attributes are related to the data added by a syslog or a log-shipper agent. All fields and metrics are prefixed by syslog.

Some integrations that rely on these are: Rsyslog, NxLog, Syslog-ng, Fluentd, Logstash, etc.

Further Reading