Global field reference

The following reference contains a list of global fields that have a well defined semantic meaning in Dynatrace and can be used across different monitoring types. The fields are organized in namespaces that are separated with dots.

Top level fields

The top level fields contain generally relevant information for all monitoring data

Adobe

Fields

Aggregation

OneAgent might aggregate spans having the same parent span into a single one. The aggregated span contains attributes to indicated that aggregation happened and to allow to reconstruct details.

For aggregated spans the start_time holds the earliest start_time, end_time holds the latest end_time of all aggregated spans.

Fields

Apache HTTP Server

Fields

Apache Spark

Fields

Apache Tomcat

Fields

App

The app namespace contains information on the application sending the event.

Fields

Artifact

The artifact namespace contains information about software artifacts.

Fields

ASP.NET Core

Fields

Authentication

Authentication type and method used to login to a Dynatrace system.

Fields

authentication.grant.type MUST be one of the following:

authentication.type MUST be one of the following:

authentication.client.id and authentication.token MUST follow the Dynatrace token format definition.

Specifically, authentication.client.id MUST be prefixed with dt0s02.

Availability

Information about entity availability. Sample usage is reporting hosts and PGI-s availability by OS Agent. Value of availability.state can be used for calculating aggregate availability (dividing count of "successful" requests by count of all requests). With constant frequency of requests it can be treated as a time-base availability, showing percentage of time that the monitored entity was available.

Fields

availability.state has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

Amazon Web Services (AWS)

Fields that can come from applications running on AWS.

Fields

Resource attributes

aws.lambda.initialization_type has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

Span attributes

Azure

Fields that can come from applications running on Azure.

Fields

Resource attributes

BOSH

Fields that are integral to applications managed by BOSH.

Fields

Resource attributes

Browser

The browser namespace contains information on the browser running an application.

Fields

Captured Attributes

Span scoped attributes (e.g. method parameters, return values, class names, …) captured by the OneAgent based on a request attribute rule. The actual name of the attribute is the prefix "captured_attribute" plus the "request attribute name" defined in the request attributes configuration. In contrast to request attributes, captured attributes contain the raw values reported by the OneAgent at the location (i.e. on the active span) where they appeared. No aggregation (first/last value, distinct values, ...), type conversion or normalization is performed on them. They are the basis for request attributes.

Fields

Cassandra

Fields

Continuous Integration/Continuous Deployment

The cicd namespace contains information about Continuous Integration and Continuous Deployment systems.

Fields

cicd.pipeline.run.outcome has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

Client

The client namespace contains information on the initiator of a network connection.

Fields

Cloud

Fields related to cloud deployments that can be used across different providers.

Fields

cloud.platform MUST be one of the following:

cloud.provider has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

Cloudfoundry

Fields

Code

Fields

Coldfusion

Fields

Compilation Timings

For some technologies compilation of code might be a significant contributor to request execution time. Compilation timings provide insight into this, where available.

Fields

Container

Fields

CICS Transaction Gateway

CTG (shorthand for "CICS Transaction Gateway") is a connector for enterprise modernization of CICS assets. It empowers various application platforms, such as Java servlets, to incorporate CICS programs.

CICS (shorthand for "Customer Information Control System") is a middleware to support rapid, high-volume online transaction processing on IBM mainframe systems on z/OS. CTG features a client and a server, which communicate via so-called GatewayRequests.

Fields

ctg.request.type MUST be one of the following:

Custom Services

Fields

Database

Fields

db.system has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

Deployment Attributes

Fields

Device

The device namespace contains information on the device running an application. This should only be used for end-user devices or devices outside of a private infrastructure. In line with the naming conventions and guidelines, we are in this case adhering to the emerging Open Telemetry convention around this, with some additions.

Fields

Disk

Fields describing a disk.

Fields

Resource attributes

DL/I Database Attachment

Fields

db.dli.pcb_type MUST be one of the following:

Dotnet

Fields

Dynatrace ActiveGate

Metadata with ActiveGate realated information.

Fields

dt.active_gate.working_mode MUST be one of the following:

API connector fields

dt.active_gate.api_connector.pipeline_status MUST be one of the following:

Dynatrace OneAgent Metadata

Metadata of the OneAgent module that reported a signal. These attributes are what one would also see in OneAgent Health.

Fields

dt.agent.module.type has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

Davis metadata

Some attributes are used in the context of the Davis engine.

Fields

Configuration fields

These fields can be set in events to influence the Davis engine behavior.

System fields

These fields can be set by Davis routines.

Dynatrace Entity IDs

The Dynatrace OneAgent associates monitoring data with a so called Monitored Entity ID (ME ID). On OneAgent monitored environments, whenever ME IDs are accessible within the monitored system they should be used to enrich monitoring data to facilitate correlations with data primarily addressed through ME IDs coming from other channels.

The structure for keys that signify entity IDs is dt.entity.{type of entity}. The value associated with such a key must be valid Dynatrace entity identifier (see Monitored entities API).

To allow linking Entity IDs across various different monitoring artifacts (logs, metrics, etc.), all string representations of Entity IDs are required to follow a canonical form, which for all current entities is defined as PREFIX-0123456789ABCDEF.

Consumers should treat the token as an opaque value and must not infer any semantics on the ID itself. Producers need to match the Entity ID that is being returned by Dynatrace Entity API verbatim.

Producers of string representation must treat the string as if it was parsed case-sensitively, even though some parts of the product may be more lenient. The structure of the entity ID is currently as follows: <ID-NAMESPACE>-<16-digit-hex-string>. The <ID-NAMESPACE> is type specific but cannot be used to determine the actual entity type reliably, especially in cases of CUSTOM_DEVICE. The <16-digit-hex-string> needs to be zero-padded (prefix) to a length of 16 digits and must use upper case letters A-F.

Current entity IDs in cannonical form can be represented structurally with the following regular expression: [A-Z][A-Z_]*-[0-9A-F]{16}.

Additional characters or changes in the format may happen in the future but will not invalidate existing IDs or ID generation rules.

When adding a name to an entity ID via the Grail function entityName, by default, the name of the respective entity will be represented as dt.entity.{type of entity}.name. Similarly, further entity attributes can be added via the Grail function entityAttr, resulting in additional field(s) following the naming convention dt.entity.{type of entity}.{name of attribute}.

Fields

Dynatrace Extensions

Additional extension information sent via self-monitoring.

Fields

dt.extension.status has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

Process Grouping Fields

Attributes used for Process Group enrichment in extensions.

Dynatrace ingest fields

Attributes defined in this namespace are used by Dynatrace to describe different aspects of the ingested data.

Fields

dt.ingest.format MUST be one of the following:

dt.ingest.warnings MUST contain only values from the following list:

Dynatrace

Fields

dt.metrics.source has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

Dynatrace OpenPipeline fields

Fields defined in this namespace are used by Dynatrace to describe various aspects of the data ingested through OpenPipeline, providing detailed insights into the ingestion process.

Fields

Dynatrace RUM

The dt.rum namespace contains Dynatrace RUM specific fields.

Fields

Settings

Fields for referencing Settings 2.0 objects, schemas and scopes.

Considerations on which fields to use

Although the dt.settings.object_id is enough to identify a specific settings value within a dynatrace environment, adding explicit information about the schema, scope and/or scope type can be useful nonetheless. If your use-case will only ever involve a single schema, scope type and/or scope, documenting this is good enough - if multiple schemas, scope types and/or scopes can be involved, filling the corresponding fields is strongly recommended.

dt.settings.references can be used if multiple settings objects need to be referenced. In that case, each entry in the array can hold a reference to a single settings object.

Top level fields

The top level fields contain generally relevant information for all monitoring data.

Dynatrace Synthetic

The dt.synthetic namespace contains Dynatrace synthetic specific fields.

Fields

dt.synthetic.failed_execution.execution.stage MUST be one of the following:

Dynatrace system fields

The namespace dt.system is reserved for Grail. These fields cannot be ingested but instead will be set by Grail directly. Every record that is fetched from Grail provides these fields, but by default they are hidden. You can display them by using the fieldsAdd command.

Example query:

// display the bucket for each log record
fetch logs
| fieldsAdd dt.system.bucket

Fields

dt.system.monitoring_source MUST be one of the following:

dt.system.storage_interval MUST be one of the following:

Dynatrace specific tracing fields

Fields defined in this namespace are used by Dynatrace to describe different aspects of the context propagation between spans.

Fields

dt.tracing.custom_link.type MUST be one of the following:

dt.tracing.link.direction MUST be one of the following:

Elasticsearch

Fields

Endpoint

Endpoints define the public interface of services.

Fields

Entity fields

Fields that describe entities.

Equinox

Fields

ESB

Fields

Event

The event namespace contains common identification, categorization and context on events in Dynatrace.

Fields