Centralizing logs from various technologies and applications can generate tens or hundreds of different attributes in a Log Management environment, especially when many teams are working within the same environment.
For instance, a client IP may have various log attributes:
client.ip, etc. The execution time of a request may be referred to as
Use attributes and aliasing to unify your Logs environment.
Reserved attributes are automatically ingested.
Standard attributes are the backbone of the naming convention for your organization. There is a default set of standard attributes available in the app. However, this list can be customized to create a naming convention for your team.
Use Aliasing once you’ve implemented a naming convention with standard attributes or if you’re trying to create a unique standard facet from multiple log sources. For example, follow the clients most impacted by latencies on a hybrid Apache and Amazon Cloud Front infrastructure, using the standard
Network Client IP facet alongside the standard
duration. Aliasing allows implementation of a naming convention without having to change a team’s technical stack.
Below is a list of reserved attributes that are automatically ingested with logs:
Note: If you’re also collecting traces or metrics, it is recommended to configure unified service tagging. This configuration ties Datadog telemetry together through the use of three standard tags:
version. Refer to the dedicated unified service tagging documentation for more information.
|The name of the originating host as defined in metrics. Datadog automatically retrieves corresponding host tags from the matching host in Datadog and applies them to your logs. The Agent sets this value automatically.|
|This corresponds to the integration name: the technology from which the log originated. When it matches an integration name, Datadog automatically installs the corresponding parsers and facets. For example: |
|This corresponds to the level/severity of a log. It is used to define patterns and has a dedicated layout in the Datadog Log UI.|
|The name of the application or service generating the log events. It is used to switch from Logs to APM, so make sure you define the same value when you use both products.|
|This corresponds to the Trace ID used for traces. It is used to correlate your log with its trace.|
|By default, Datadog ingests the value of the |
Log integrations natively rely on a default set of standard attributes.
Admin users in your organization can curate the 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:
A standard attribute is defined by its:
Path: The path of the attribute promoted as a standard attribute, as you would find it in your JSON (for example:
boolean): The type of the attribute, which is used to cast elements of the remapping list.
Aliasing list: Comma separated list of attributes that should be aliased to it.
Description: Human readable description of the attribute.
The standard attribute panel appears when you add a new standard attribute or edit an existing one:
The default standard attribute list is split into the functional domains:
The following attributes are related to the data used in network communication. All fields and metrics are prefixed by
|The IP address of the client that initiated the TCP connection.|
|The IP address the client connected to.|
|The port of the client that initiated the connection.|
|The TCP port the client connected to.|
|Total number of bytes transmitted from the client to the server when the log is emitted.|
|Total number of bytes transmitted from the server to the client when the log is emitted.|
The following attributes are related to the geolocation of IP addresses used in network communication. All fields are prefixed by
|Name of the country|
|ISO Code of the country (example: |
|ISO code of the continent (|
|Name of the continent (|
|Name of the first subdivision level of the country (example: |
|ISO Code of the first subdivision level of the country (example: |
|The name of the city (example |
These attributes are related to the data commonly used in HTTP requests and accesses. All attributes are prefixed by
|The URL of the HTTP request.|
|The HTTP response status code.|
|Indicates the desired action to be performed for a given resource.|
|HTTP header field that identifies the address of the webpage that linked to the resource being requested.|
|The ID of the HTTP request.|
|The User-Agent as it is sent (raw format). See below for more details.|
|The version of HTTP used for the request.|
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
|The HTTP host part of the URL.|
|The HTTP port part of the URL.|
|The HTTP path part of the URL.|
|The HTTP query string parts of the URL decomposed as query params key/value attributes.|
|The protocol name of the URL (HTTP or HTTPS)|
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
|The OS family reported by the User-Agent.|
|The Browser Family reported by the User-Agent.|
|The Device family reported by the User-Agent.|
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
|The name of the logger.|
|The name of the current thread when the log is fired.|
|The class method name.|
|The version of the logger.|
|The error type or kind (or code is some cases).|
|A concise, human-readable, one-line message explaining the event|
|The stack trace or the complementary information about the error|
Typical integrations relying on these attributes are: Java, NodeJs, .NET, Golang, Python, etc.
Database related attributes are prefixed by
|Database instance name. E.g., in Java, if |
|A database statement for the given database type. E.g., for mySQL: |
|The operation that was performed (“query”, “update”, “delete”,…).|
|User that performs the operation.|
Performance metrics attributes.
|A duration of any kind in nanoseconds: HTTP response time, database query time, latency, etc.|
All attributes and measures are prefixed by
|The user identifier.|
|The user friendly name.|
|The user email.|
These attributes are related to the data added by a syslog or a log-shipper agent. All fields and metrics are prefixed by
|The application name. Generally remapped to the |
|The log severity. Generally remapped to the |
|The log timestamp. Generally remapped to the |
|The environment name where the source of logs come from.|
All attributes and measures are prefixed by
|The DNS query identifier.|
|The queried domain name.|
|A two octet code which specifies the DNS question type.|
|The class looked up by the DNS question (i.e IN when using the internet).|
|The DNS question size in bytes.|
|The IP address that the DNS answers with.|
|A two octet code which specifies the DNS answer type.|
|The class answered by the DNS.|
|The DNS answer size in bytes.|
|The DNS reply code.|
All attributes are prefixed by
|The shared name across events generated by the same activity (e.g.: authentication).|
|The result of the event (e.g. |
Creating an alias for a source attribute that maps to a destination attribute allows logs to carry both the source and destination attributes.
Users can interact with either the aliased (source) or standard (destination) faceted attribute. However, users are encouraged to use the standard facet rather than the aliased one. This provides guidance towards the naming convention, and discourages users from building assets (such as saved views or dashboards) based on non-standard content.
Additional details regarding aliasing:
user.namecannot both be standard attributes).
See the associated documentation for additional information.
Additional helpful documentation, links, and articles: