Ingest OTLP logs

• Latest Dynatrace
• Reference
• 3-min read
• Updated on Feb 06, 2026

OpenTelemetry supports attributes at different levels in an OpenTelemetry log request, such as the resource level, scope level, and record level.

The Log ingestion API collects and attempts to automatically transform log data.

Data transformation

Each log record from the ingested batch is mapped to a single Dynatrace log record, which contains three special attributes: timestamp, loglevel, content, and a set of other key-value attributes. These properties are set based on keys present in the input object as follows.

Timestamp

Log level

Content

Attributes

All attributes should preferably map to semantic attributes for Dynatrace to interpret them correctly.

Data types

Dynatrace supports OpenTelemetry data types as described in the sections below.

Scalar value

Scalar values are transformed as follows:

Byte array

Byte arrays are converted to base64-encoded strings. For example, the following array

[0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64]

is transformed and ingested as aGVsbG8gd29yZA==.

Array

Array attribute values are converted to arrays of a uniform type. The target type is chosen according to the following rules:

Map

Map processing depends on the data model used. See Log ingestion API processing below for more details.

Ingestion limits

See Log Management and Analytics default limits and Log Monitoring default limits (Logs Classic) for the limits applied to ingested log requests, their attributes, and their attribute values.

Log ingestion API processing

There are two data models that identify how structured logs are processed by log ingestion endpoints: raw and flattened. The difference between the two is in how attributes with object/dictionary values are transformed.

Raw data model

The raw data model transforms the content of structured logs as described in the sections below. All the following examples apply to Log ingestion API endpoints available on Environment ActiveGateand SaaS.

Maps and arrays in attributes

For the raw data model, the map attribute values are turned into a JSON string, and the array attribute values are turned into an array of the uniform type.

body: "Hello world!"
Resource:
- "any-attr-type-3": {"3" = "c"}
Scope:
- "any-attr-type-2": {"2" = "b"}
Attributes:
- "any-attr-type-1": {"1" = "a"}
- "any-attr-type-4":
  [ "val1", 10, -123.456, false, 0x01020304 ]

“content”: "Hello world!"
"any-attr-type-1": "{\"1\": \"a\"}"
"any-attr-type-2": "{\"2\": \"b\"}"
"any-attr-type-3": "{\"3\": \"c\"}"
"any-attr-type-4":
  ["val1", "10", "-123.456", "false", "AQIDBA=="]

KeyValue {
  key: "test"
  value: {
    kvlist_value: {
      values: [
        {
          key: "attribute"
          value: {
            kvlist_value: {
              values: [
                  { key: "one", value: { string_value: "value 1" } },
                  { key: "two", value: { string_value: "value 2" } }
                ]
              }
          }
        }
      ]
    }
  }
}

"test": "{ \"attribute\": {\"one\": \"value 1\", \"two\": \"value 2\" } }"

Map in body

In this case, the Body field of the input log record is converted to a JSON string.

Body:
  {
     "content" = "Hello World!",
     "my-body-attr-1": "abc",
     "my-body-nested-1": {
        "subkey": "val"
     },
     "@timestamp": "2025-06-01 13:01:02.123",
     "loglevel": "INFO"
  }

"content": "{ \"content\" = \"Hello World!\",
    \"my-body-attr-1\": \"abc\",
    \"my-body-nested-1\": {
      \"subkey\": \"val\"
    },
    \"@timestamp\": \"2025-06-01 13:01:02.123\",
    \"loglevel\": \"INFO\"
  }"

Body as array

In this case, the array in the body is stringified.

Body:
  [ "string-val", true, 12, 12.34, 0x6279746573 ]

"content": "[\"string-val\",true,12,12.34,\"Ynl0ZXM=\"]"
...

Name conflicts

In the raw data model, OTLP resource attributes and OTLP attributes are copied into Dynatrace top-level attributes, and the OTLP body is copied into the content.

Dynatrace prefixes duplicate attributes with an incrementing counter, for example overwritten1.myattribute. The counter value indicates how many times the attribute has been encountered as a duplicate. This avoids name collisions when attributes at different OTLP levels share the same name.

Flattened data model

With the flattened data model, the content of structured logs is transformed as described in the sections below. All the following examples apply to Log ingestion API endpoints available on Environment ActiveGate and SaaS.

Maps and arrays in attributes

In this case, the map attribute values are flattened, i.e. replaced with keys concatenated using a dot (.) until a simple value is reached in the hierarchy, and the array attribute values are turned into a custom string.

body: "Hello world!"
Resource:
- "any-attr-type-3": {"3" = "c"}
Scope:
- "any-attr-type-2" : {"2" = "b"}
Attributes:
- "any-attr-type-1" : {"1" = "a"}
- "any-attr-type-4" :
  [ "val1", 10, -123.456, false, 0x01020304 ]

“content”: "Hello world!"
"any-attr-type-1.1": "a"
"any-attr-type-2.2": "b"
"any-attr-type-3.3": "c"
"any-attr-type-4":
  ["val1", 10, -123.456, false, "AQIDBA=="]

Flattening proceeds up to the maximum nesting level specified by the Nested objects limit. Structures nested deeper than this are replaced with the string value <truncated due to nesting limit>. See the Ingestion limits section for details.

Map in body

In this case, the map attributes are merged with the log record.

Body:
  {
     "content" = "Hello World!",
     "my-body-attr-1": "abc",
     "my-body-nested-1": {
        "subkey": "val"
     },
     "@timestamp": "2025-06-01 13:01:02.123",
     "loglevel": "INFO"
  }
Attributes:
- "any-attr-type-1" : "my-attr"

"content": "Hello world!"
"timestamp": "2025-06-01 13:01:02.123"
"loglevel": "INFO"

"any-attr-type-1": "my-attr"
"my-body-attr-1": "abc"
"my-body-nested-1.subkey": "val"

Body as array

In this case, the array in the body is stringified.

Body:
  [ "string-val", true, 12, 12.34, 0x6279746573 ]

"content": "[\"string-val\",true,12,12.34,\"Ynl0ZXM=\"]"
...

Content-related behavior:

If the Body field is of kvlist_value type (a list of key-value pairs), the structure is processed in the same way as log record attributes, including flattening and conflict resolution.

Attributes found in Body may also be used for setting the timestamp, loglevel, and content attributes of the log record, as described below.

Timestamp

Log level

Content

Name conflicts

When attributes are saved in a flattened fashion on the Dynatrace side, there may be name collisions if attributes on different levels share the same name. Dynatrace resolves this by prefixing duplicate attributes with overwritten[COUNTER].. The counter value indicates how many times the attribute name has been already encountered as a duplicate.

For example, if you have three attributes all named my.attribute on the resource, scope, and log levels:

Additional attributers handling

The Log ingestion API additionally accepts log attributes through:

These attributes are merged with those provided in the OpenTelemetry log request according to the rules described below.

Query parameter attributes

Example

otlphttp:
  logs_endpoint: /api/v2/otlp/v1/logs?env=prod&env=blue&team=payments

Body: "Hello World!"

{
  "content": "Hello World!",
  "env": ["prod", "blue"],
  "team": "payments"
}

Header-based attributes (X-Dynatrace-Attr)

The API supports a special header for passing additional attributes:

otlphttp:
  endpoint: /api/v2/otlp
  headers:
    X-Dynatrace-Attr: region=eu-central-1&team=core

Rules:

Attributes precedence rules

When attributes appear in multiple places, the Log ingestion API applies attribute precedence while still preserving body values for auditability. The attributes are applied in the following order:

Override behavior

When attributes from query parameters or the header override log request attributes:

Example

otlphttp:
  logs_endpoint: /api/v2/otlp/v1/logs?team=frontend

Body: "Hello World!"
Attributes:
  - "team": "backend"

{
  "content": "Hello World!",
  "team": "frontend",
  "overwritten1.team": "backend"
}

Billing behavior

Attributes provided through query parameters or headers are included in billing calculations.

For multi-value attributes, the attribute key contributes to billing only once, regardless of how many values are present.