Merge pull request #18747 from jack-berg/otlp-attribute-types

Add details on OTLP supported attribute types

src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-logs.mdx

@@ -187,6 +187,8 @@ New Relic maps OTLP log records to the `Log` data type. The table below describe
 
 **[1]** In case of conflict in resource attributes, scope attributes, log record attributes, top level log record fields, and parsed attributes from the `LogRecord.body` **[3]**, the order of precedent (highest to lowest) is: parsed attributes from `LogRecord.body` -> top level `LogRecord.*` fields > `LogRecord.attributes` > `ScopeLogs.InstrumentationScope.attributes` > `ResourceLogs.Resource.attributes`.
 
+See [OTLP attribute types](/docs/opentelemetry/best-practices/opentelemetry-otlp/#otlp-attribute-types) for details on New Relic OTLP endpoint supported attribute types.
+
 **[2]** If `LogRecord.time_unix_nanos` is not present, `timestamp` is set to the time New Relic received the data.
 
 **[3]** [Log parsing](/docs/logs/ui-data/parsing/) is applied to the `LogRecord.body` to attempt to extract attributes from plain log text. For example, if a JSON structured log format is used, the key / values become attributes on the resulting log. This is particularly useful when collecting logs from files or `stdout`. In this case, it's common to have no resource attributes associated with the log record (required for [APM service correlation](#service-correlation)) and no value for `LogRecord.trace_id` / `LogRecord.span_id` (required for [trace correlation](#trace-correlation)). Correlation will function as intended if the required fields can be successfully parsed.

src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-metrics.mdx

@@ -354,6 +354,8 @@ New Relic maps OTLP metrics to the [`Metric` data type](/docs/data-apis/understa
 
 **[1]**: In case of conflict in resource attributes, scope attributes, metric point attributes, and top level metric fields, the order of precedent (highest to lowest) is: top level `Metric.*` fields > `Metric.*.data_points.attributes` > `ScopeMetrics.InstrumentationScope.attributes` > `ResourceMetrics.Resource.attributes`.
 
+See [OTLP attribute types](/docs/opentelemetry/best-practices/opentelemetry-otlp/#otlp-attribute-types) for details on New Relic OTLP endpoint supported attribute types.
+
 ### OTLP sum metrics [#otlp-sum]
 
 OTLP [sum metrics](https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/metrics/v1/metrics.proto#L217-L226) represent the sum of measurements over time. Sums include an [`aggregation_temporality`](#aggregation-temporality) field and an `is_monotonic` field, which indicates whether the values are monotonically increasing (i.e. can only go up) or not (i.e. can go up and down). The following table describes how New Relic treats different sum varieties:

src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-traces.mdx

@@ -258,6 +258,8 @@ New Relic maps OTLP spans to the `Span` data type. The table below describes how
 
 **[1]** In case of conflict in resource attributes, scope attributes, span attributes, and top level span fields, the order of precedent (highest to lowest) is: top level `Span.*` fields > `Span.attributes` > `ScopeSpans.InstrumentationScope.attributes` > `ResourceSpans.Resource.attributes`.
 
+See [OTLP attribute types](/docs/opentelemetry/best-practices/opentelemetry-otlp/#otlp-attribute-types) for details on New Relic OTLP endpoint supported attribute types.
+
 ## Span links support [#span-links-support]
 
 OpenTelemetry [span links](https://opentelemetry.io/docs/concepts/signals/traces/#span-links) are not currently supported by New Relic.

src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx

@@ -283,6 +283,17 @@ The mechanism to configure the endpoint will vary, but OpenTelemetry language SD
 
 New Relic uses [OTLP release v0.18.0](https://github.com/open-telemetry/opentelemetry-proto/releases/tag/v0.18.0). Later versions are supported but new features are not yet implemented. Experimental features which were are no longer available in 0.18.0 are not supported.
 
+## OTLP attribute types [#otlp-attribute-types]
+
+Attributes are a recurring concept in OpenTelemetry and OTLP. OpenTelemetry has a [standard attribute](https://opentelemetry.io/docs/specs/otel/common/#standard-attribute) definition, stating that attribute values are primitives (string, boolean, double floating point, 64-bit integer) or homogeneous arrays of primitives. However, at the OTLP protocol level, attributes are represented using a more expansive [`AnyValue`](https://github.com/open-telemetry/opentelemetry-proto/blob/4f69356d853029975649c3f38b06fc77d77975fc/opentelemetry/proto/common/v1/common.proto#L28-L40) definition. Because of this, it's possible for OTLP clients to send attributes which do not conform to OpenTelemetry standard definition.
+
+The New Relic OTLP endpoint supports the standard attribute definition. Complex types like maps of maps, object arrays, and heterogeneous arrays are not supported. The OpenTelemetry SDKs should only produce data which conforms to the standard attribute definition.
+
+<Callout variant="important">
+While the standard attribute definition is generally used, log record attributes are exceptional and support complex values (i.e. log record attributes type is [`map<string, any>`](https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-attributes)). Despite this, New Relic currently only supports log record attributes which conform to the standard attribute definition.
+</Callout>
+
+
 ## OTLP response payloads [#payloads]
 
 Please note the following details regarding New Relic OTLP endpoint response payloads: