Merge pull request #5725 from jack-berg/otlp-infinite-tracing

Add more detail on otlp infinite tracing

src/content/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-concepts.mdx

@@ -32,7 +32,7 @@ The following suites of attributes are defined by the [OpenTelemetry resource se
   * `service.* attributes`
     * `service.name` attribute is required to associate your resource with an entity in the UI
     * `service.instance.id` is required for certain panes to light up
-  * `telemetry.sdk.language=java` is required to see data in the JVM section 
+  * `telemetry.sdk.language=java` is required to see data in the JVM section
 
 ## Batching [#batching]
 
@@ -85,7 +85,7 @@ The `startTimeUnixNano` and `endTimeUnixNano` fields on spans are required accor
 
 The `timeUnixNano` field on span events is required. When `timeUnixNano` is not present, the span event is dropped and a [`NrIntegrationError`](/docs/telemetry-data-platform/manage-data/nrintegrationerror/) is created.
 
-The `traceId` and `spanId` fields on spans are required according to the OpenTelemetry protocol for [trace data](https://github.com/open-telemetry/opentelemetry-proto/blob/74e38fb4882dd500d77b757d44e97de296c65b05/opentelemetry/proto/trace/v1/trace.proto#L73-L84). When `traceId` or `spanId` are not present, the span is dropped and a [`NrIntegrationError`](/docs/telemetry-data-platform/manage-data/nrintegrationerror/) is created. 
+The `traceId` and `spanId` fields on spans are required according to the OpenTelemetry protocol for [trace data](https://github.com/open-telemetry/opentelemetry-proto/blob/74e38fb4882dd500d77b757d44e97de296c65b05/opentelemetry/proto/trace/v1/trace.proto#L73-L84). When `traceId` or `spanId` are not present, the span is dropped and a [`NrIntegrationError`](/docs/telemetry-data-platform/manage-data/nrintegrationerror/) is created.
 
 ### Sampling [#sampling]
 
@@ -118,25 +118,28 @@ Check out this documentation about how to configure different types of sampling:
     id="infinite-tracing"
     title="New Relic tail-based sampling with Infinite Tracing"
   >
-  Infinite Tracing is New Relic's tail-based sampling option. You can use this in conjunction with your OpenTelemetry instrumented services. In setting up Infinite Tracing, you need to override the default span endpoint and send telemetry data to the New Relic trace observer:
+  Infinite Tracing is New Relic's tail-based sampling option. You can use this in conjunction with your OpenTelemetry instrumented services. In setting up Infinite Tracing, you need to configure applications (or the collector) to export trace data to the New Relic trace observer using OTLP gRPC:
 
   1. Follow the steps in [Set up the trace observer](/docs/distributed-tracing/infinite-tracing/set-trace-observer/) to get the value for <var>YOUR_TRACE_OBSERVER_URL</var>.
-  2. Use the value of <var>YOUR_TRACE_OBSERVER_URL</var> to configure your integration.
-  3. Since you want New Relic to analyze all your traces, make sure to verify that your OpenTelemetry integrations use the `AlwaysOn` sampler.
+  2. As you complete the steps in the [quick start guide](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-quick-start/#review-settings), use the value of <var>YOUR_TRACE_OBSERVER_URL</var> to configure your integration. `YOUR_TRACE_OBSERVER_URL` follows the form `https://{trace-observer}:443/trace/v1`. When setting the OTLP gRPC endpoint, strip off the `/trace/v1` suffix, resulting in a URL of the form `https://{trace-observer}:443`.
+  3. Since you want New Relic to analyze all your traces, make sure to verify that all applications involved in the trace have [configured](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md) the OpenTelemetry SDK with a sampler which allows tail-based sampling. The default the `parent_based_always_on` as well as the `always_on` samplers are good choices.
+
+
+  Note that only trace data can be sent to trace observer endpoints. Your application (or collector) will need to separately configure export strategies for OpenTelemetry metrics and logs.
   </Collapser>
 </CollapserGroup>
 
 ## Metrics [#metrics]
 
-OpenTelemetry metrics are largely compatible with New Relic dimensional metrics. We support OpenTelemetry metrics v0.10. All of the supported metric types include an independent set of associated attributes (name-value pairs) which map directly to dimensions you can use to facet or filter metric data at query time. OpenTelemetry metrics are accompanied by a set of [resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-sdk) attributes that identify the originating entity that produced them and map to dimensions for faceting and filtering. 
+OpenTelemetry metrics are largely compatible with New Relic dimensional metrics. We support OpenTelemetry metrics v0.10. All of the supported metric types include an independent set of associated attributes (name-value pairs) which map directly to dimensions you can use to facet or filter metric data at query time. OpenTelemetry metrics are accompanied by a set of [resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-sdk) attributes that identify the originating entity that produced them and map to dimensions for faceting and filtering.
 
 The OpenTelemetry [data model](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/datamodel.md#metric-points) for metrics defines a number of different metric types: sum, gauge, histogram, and summary.
 
 ### Sum metrics [#sums]
 
-OpenTelemetry sums are a scalar metric that is the sum of all data points over a given time window. Sums have a notion of [temporality](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/datamodel.md#temporality) indicating whether reported values incorporate previous measurements (cumulative temporality) or not (delta temporality). 
+OpenTelemetry sums are a scalar metric that is the sum of all data points over a given time window. Sums have a notion of [temporality](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/datamodel.md#temporality) indicating whether reported values incorporate previous measurements (cumulative temporality) or not (delta temporality).
 
-In addition, sums can either be monotonic (only go up or only go down) or non-monotonic (go up and down). 
+In addition, sums can either be monotonic (only go up or only go down) or non-monotonic (go up and down).
 
 #### Delta sums [#delta]
 
@@ -159,15 +162,15 @@ OpenTelemetry gauge metric data points represent a sampled value at a given time
 
 ### Histogram metrics [#otel-histogram]
 
-OpenTelemetry [histograms](https://github.com/open-telemetry/opentelemetry-specification/blob/87a5ed7f0d4c403e2b336f275ce3e7fd66a8041b/specification/metrics/datamodel.md#histogram) compactly represent a population of recorded values along with a total count and sum. Optionally, histograms may include a series of buckets with explicit bounds and a count value for that bucket’s population. 
+OpenTelemetry [histograms](https://github.com/open-telemetry/opentelemetry-specification/blob/87a5ed7f0d4c403e2b336f275ce3e7fd66a8041b/specification/metrics/datamodel.md#histogram) compactly represent a population of recorded values along with a total count and sum. Optionally, histograms may include a series of buckets with explicit bounds and a count value for that bucket’s population.
 
 OpenTelemetry histograms are converted to New Relic’s [distribution](https://docs.newrelic.com/docs/telemetry-data-platform/understand-data/metric-data/metric-data-type/#metric-types) metric type, which is backed by a scaled exponential base 2 histogram (see [NrSketch](https://github.com/newrelic-experimental/newrelic-sketch-java#new-relic-sketch) for a more thorough explanation).
 
 Counts from OpenTelemetry histogram buckets are assigned to New Relic’s distribution metric buckets using linear interpolation. Also, OpenTelemetry has negative and positive infinity bound buckets which we represent in New Relic as zero-width buckets. We do this because we do not have a representation for negative and positive infinity. For example, an OpenTelemetry bucket with bounds [-∞, 10) will be represented by a [10,10) zero width New Relic bucket. You may see exaggerated bucket counts at the endpoints of your distribution due to this translation.
 
 ### Summary metrics [#summary-metric]
 
-OpenTelemetry summary metric data points are used to represent quantile summaries (for example, P99 latency). These map directly to the New Relic summary metric type. 
+OpenTelemetry summary metric data points are used to represent quantile summaries (for example, P99 latency). These map directly to the New Relic summary metric type.
 
 Summary metric data points include count, sum, and quantile values, with 0.0 as min and 1.0 as max. OpenTelemetry provides summary metrics for compatibility with other formats.
 
@@ -226,7 +229,7 @@ SELECT derivative(totalApiBytesSent, 1 second) FROM Metric TIMESERIES 5 MINUTES
 
 #### Query gauge metrics [#query-gauges]
 
-When New Relic converts cumulative sums to gauges, you can query them using either the [`latest()`](/docs/query-your-data/nrql-new-relic-query-language/get-started/nrql-syntax-clauses-functions/#latest) or [`derivative()`](/docs/query-your-data/nrql-new-relic-query-language/get-started/nrql-syntax-clauses-functions/#derivative) NRQL functions. The function you choose depends on whether you want to see the raw value or compute the rate of change. 
+When New Relic converts cumulative sums to gauges, you can query them using either the [`latest()`](/docs/query-your-data/nrql-new-relic-query-language/get-started/nrql-syntax-clauses-functions/#latest) or [`derivative()`](/docs/query-your-data/nrql-new-relic-query-language/get-started/nrql-syntax-clauses-functions/#derivative) NRQL functions. The function you choose depends on whether you want to see the raw value or compute the rate of change.
 
 #### Query histogram metrics [#query-histograms]
 
@@ -262,7 +265,7 @@ FROM Metric SELECT histogram(test.histogram, buckets: 100, width: 1000) FACET di
 
 <Callout variant="important">
  The TIMESERIES keyword is not supported for New Relic histograms.
-</Callout> 
+</Callout>
 
 ## Logs [#logs]
 

src/content/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-legacy-new-relic-exporters.mdx

@@ -13,34 +13,27 @@ redirects:
   - /docs/integrations/open-source-telemetry-integrations/troubleshooting/troubleshoot-opentelemetry-exporter/
 ---
 
-New Relic published a number of exporters that are used to send OpenTelemetry data over New Relic's proprietary protocol. These exporters are being deprecated in favor of sending data to New Relic using the OpenTelemetry protocol.
+New Relic published a number of exporters that are used to send OpenTelemetry data over New Relic's proprietary protocol. These exporters are deprecated in favor of sending data to New Relic using the OpenTelemetry protocol.
 
 <Callout variant="important">
 The exporters are listed here for reference. To migrate off these exporters, follow our [quick start guide](/docs/integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-quick-start).
 </Callout>
 
 ## New Relic Language Exporters [#newrelic-language-exporters]
 
-As mentioned above, our language-specific exporters are being deprecated. These exporters allowed applications to export OpenTelemetry data directly to New Relic. The [New Relic OTLP endpoint](#native-otlp) makes this strategy obsolete since it allows applications to export data to New Relic's proprietary endpoints.
+As mentioned above, our language-specific exporters are deprecated. These exporters allowed applications to export OpenTelemetry data directly to New Relic. The [New Relic OTLP endpoint](#native-otlp) makes this strategy obsolete since it allows applications to export data to New Relic's proprietary endpoints.
 
 The exporters and their maintenance status are as follows:
 
-- [Go](https://github.com/newrelic/opentelemetry-exporter-go): To be archived soon
+- [Go](https://github.com/newrelic/opentelemetry-exporter-go): Archived
 - [Java](https://github.com/newrelic/opentelemetry-exporter-java): Archived
 - [Python](https://github.com/newrelic/opentelemetry-exporter-python): Archived
-- [.NET](https://github.com/newrelic/newrelic-telemetry-sdk-dotnet/tree/main/src/NewRelic.OpenTelemetry): To be archived soon
-
-## New Relic Exporter for the OpenTelemetry Collector [#newrelic-collector-exporter]
-
-If you deployed your own collector with a New Relic exporter, we'll continue to support this exporter at least until the native OTLP ingest is beyond pre-release. We encourage you to migrate to the OTLP exporter in your collector. If you need help with that see our [quick start guide](/docs/integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-quick-start#collector).
-
-If you still need information about the New Relic Exporter, see the [opentelemetry-collector-contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/newrelicexporter) repository.
-
-The [OpenTelemetry Collector with New Relic Exporter](https://github.com/newrelic/newrelic-opentelemetry-examples/tree/main/collector/nr-exporter-docker) example demonstrates what such a setup might look like.
+- [.NET](https://github.com/newrelic/newrelic-telemetry-sdk-dotnet/tree/main/src/NewRelic.OpenTelemetry): Archived
+- [Collector](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/newrelicexporter): Deprecated for removal May 1st, 2022.
 
 ## Endpoint configuration for New Relic exporters [#h2-change-endpoints]
 
-You can change the New Relic endpoints where you send your data. 
+You can change the New Relic endpoints where you send your data.
 
 ### US endpoints [#default-endpoints]