From 1779f5043843981f743c18248a056bd3c163a816 Mon Sep 17 00:00:00 2001 From: Jack Berg Date: Mon, 23 Sep 2024 17:59:21 -0500 Subject: [PATCH 1/3] Add details on OTLP supported attribute types --- .../best-practices/opentelemetry-best-practices-logs.mdx | 2 ++ .../opentelemetry-best-practices-metrics.mdx | 2 ++ .../opentelemetry-best-practices-traces.mdx | 2 ++ .../opentelemetry/best-practices/opentelemetry-otlp.mdx | 8 ++++++++ 4 files changed, 14 insertions(+) diff --git a/src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-logs.mdx b/src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-logs.mdx index f235a375f91..f782ab8ba6b 100644 --- a/src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-logs.mdx +++ b/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. diff --git a/src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-metrics.mdx b/src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-metrics.mdx index 28dc3489802..5df19d6ea72 100644 --- a/src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-metrics.mdx +++ b/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: diff --git a/src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-traces.mdx b/src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-traces.mdx index 0202c28fae2..21538adc9bc 100644 --- a/src/content/docs/opentelemetry/best-practices/opentelemetry-best-practices-traces.mdx +++ b/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. diff --git a/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx b/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx index 72884f39a4a..9e0b01d0fe1 100644 --- a/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx +++ b/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx @@ -283,6 +283,14 @@ 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 arrays of integers. 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. + +**NOTE**: 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`](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. + ## OTLP response payloads [#payloads] Please note the following details regarding New Relic OTLP endpoint response payloads: From 1b146ee892be3b0121f48903e76383fe9dd8d5d9 Mon Sep 17 00:00:00 2001 From: jack-berg <34418638+jack-berg@users.noreply.github.com> Date: Tue, 24 Sep 2024 09:44:57 -0500 Subject: [PATCH 2/3] Update src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx --- .../docs/opentelemetry/best-practices/opentelemetry-otlp.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx b/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx index 9e0b01d0fe1..d3b6a6fe890 100644 --- a/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx +++ b/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx @@ -285,7 +285,7 @@ New Relic uses [OTLP release v0.18.0](https://github.com/open-telemetry/opentele ## 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 arrays of integers. 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. +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. From dbec9bcf22ef50a959b10cdd05573ce891762921 Mon Sep 17 00:00:00 2001 From: cbehera-newrelic Date: Tue, 24 Sep 2024 22:55:38 +0530 Subject: [PATCH 3/3] Update opentelemetry-otlp.mdx Added a callout (Note) --- .../docs/opentelemetry/best-practices/opentelemetry-otlp.mdx | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx b/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx index d3b6a6fe890..2279dc41fd0 100644 --- a/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx +++ b/src/content/docs/opentelemetry/best-practices/opentelemetry-otlp.mdx @@ -289,7 +289,10 @@ Attributes are a recurring concept in OpenTelemetry and OTLP. OpenTelemetry has 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. -**NOTE**: 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`](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. + +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`](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. + + ## OTLP response payloads [#payloads]