Merge pull request #2536 from splunk/urbiz-OD6209-deprecate-sapm

[OD6209]: Deprecate SAPM

Author: aurbiztondo-splunk

_includes/collector-config-ootb.rst

@@ -165,15 +165,15 @@ The following diagram shows the default traces pipeline:
 
       subgraph Exporters
          direction LR
-         traces/sapm:::exporter
+         traces/otlphttp:::exporter
          traces/signalfx/out:::exporter
       end
 
       %% Connections beyond categories are added later
       traces/jaeger --> traces/memory_limiter
       traces/otlp --> traces/memory_limiter
       traces/zipkin --> traces/memory_limiter
-      traces/resourcedetection --> traces/sapm
+      traces/resourcedetection --> traces/otlphttp
       traces/resourcedetection --> traces/signalfx/out
 
 Learn more about these receivers:

apm/apm-spans-traces/span-formats.rst

@@ -16,13 +16,14 @@ For more information on the ingest API endpoints, see :new-page:`Send APM traces
 Span formats compatible with the OpenTelemetry Collector
 ================================================================
 
-The Splunk Distribution of the OpenTelemetry Collector can collect spans in the following format:
+The Splunk Distribution of the OpenTelemetry Collector can collect spans in the following formats:
 
 - Jaeger: gRPC and Thrift
 - Zipkin v1, v2 JSON
-- Splunk APM Protocol (SAPM)
 - OpenTelemetry Protocol (OTLP)
 
+.. note:: Splunk APM Protocol (SAPM) components are deprecated. Use the OTLP format instead.
+
 The following examples show how to configure receivers in the collector configuration file. You can use multiple receivers according to your needs.
 
 .. tabs::
@@ -51,14 +52,6 @@ The following examples show how to configure receivers in the collector configur
          zipkin:
             endpoint: 0.0.0.0:9411
 
-   .. code-tab:: yaml SAPM
-
-      # To receive spans in SAPM format
-
-      receivers:
-         sapm:
-            endpoint: 0.0.0.0:7276
-
    .. code-tab:: yaml OTLP
 
       # To receive spans in OTLP format
@@ -85,14 +78,12 @@ The ingest endpoint for Splunk Observability Cloud at ``https://ingest.<realm>.s
 * OTLP at ``/v2/trace/otlp`` with ``Content-Type:application/x-protobuf``
 * Jaeger Thrift with ``Content-Type:application/x-thrift``
 * Zipkin v1, v2 with ``Content-Type:application/json``
-* SAPM with ``Content-Type:application/x-protobuf``
 
 In addition, the following endpoints are available:
 
 * OTLP at ``/v2/trace/otlp`` with ``Content-Type:application/x-protobuf``
 * Jaeger Thrift at ``/v2/trace/jaegerthrift`` with ``Content-Type:application/x-thrift``
 * Zipkin v1, v2 at ``/v2/trace/signalfxv1`` with ``Content-Type:application/json``
-* SAPM at ``/v2/trace/sapm`` with ``Content-Type:application/x-protobuf``
 
 For more information on the ingest API endpoints, see :new-page:`Send APM traces <https://dev.splunk.com/observability/docs/apm/send_traces/>`. 
 

gdi/get-data-in/application/otel-dotnet/sfx/troubleshooting/common-dotnet-troubleshooting.rst

@@ -69,9 +69,9 @@ Traces don't appear in Splunk Observability Cloud
 If traces from your instrumented application or service are not available in Splunk Observability Cloud, verify the OpenTelemetry Collector configuration:
 
 * Make sure that the Splunk Distribution of OpenTelemetry Collector is running.
-* Make sure that a ``zipkin`` receiver and a ``sapm`` exporter are configured.
+* Make sure that a ``zipkin`` receiver and an ``otlp`` exporter are configured.
 * Make sure that the ``access_token`` and ``endpoint`` fields are configured.
-* Check that the traces pipeline is configured to use the ``zipkin`` receiver and ``sapm`` exporter.
+* Check that the traces pipeline is configured to use the ``zipkin`` receiver and ``otlp`` exporter.
 
 Metrics don't appear in Splunk Observability Cloud
 ==================================================================

gdi/monitors-cloud/heroku.rst

@@ -9,7 +9,7 @@ Heroku
 The Splunk OpenTelemetry Connector for Heroku is a buildpack for the Splunk Distribution of the OpenTelemetry Collector. The buildpack installs
 and runs the Splunk OpenTelemetry Connector on a Dyno to receive, process and export metric and trace data for Splunk Observability Cloud:
 
--  Splunk APM through the ``sapm`` exporter. The ``otlphttp`` exporter can be used with a custom configuration.
+-  Splunk APM through the ``otlphttp`` exporter.
 -  Splunk Infrastructure Monitoring through the ``signalfx`` exporter.
 
 See :ref:`otel-intro` to learn more.

gdi/opentelemetry/collector-addon/collector-addon-install.rst

@@ -45,7 +45,7 @@ Follow these steps to install the Splunk Add-on for OpenTelemetry Collector to a
 
 #. In Splunk_TA_otel/local, create or open the access_token file, and replace the existing contents with the token value you copied from Splunk Observability Cloud. Save the updated file.
 
-#. In :strong:`Splunk Observability Cloud`, select your name, then select the Organization tab to verify that the realm value in the realm and sapm-endpoint files in your local folder reflect the value shown in Splunk Observability Cloud. Save any changes you make in the local files.
+#. In :strong:`Splunk Observability Cloud`, select your name, then select the Organization tab to verify that the realm value in the realm and ingest endpoints files in your local folder reflect the value shown in Splunk Observability Cloud. Save any changes you make in the local files.
 
 #. Restart Splunkd. Your Add-on solution is now deployed. 
 
@@ -75,7 +75,7 @@ Follow these steps to install the Splunk Add-on for the OpenTelemetry Collector
 
 #. In Splunk_TA_otel/local, create or open the access_token file, and replace the existing contents with the token value you copied from Splunk Observability Cloud. Save the updated file.
 
-#. In :strong:`Splunk Observability Cloud`, select your name, then select the Organization tab to verify that the realm value in the realm and sapm-endpoint files in your local folder match the value shown in Splunk Observability Cloud. Save any changes you make in the local files.
+#. In :strong:`Splunk Observability Cloud`, select your name, then select the Organization tab to verify that the realm value in the realm and ingest endpoints files in your local folder match the value shown in Splunk Observability Cloud. Save any changes you make in the local files.
 
 #. In :strong:`Splunk Web`, select :guilabel:`Settings > Forwarder Management` to access your deployment server.
 

gdi/opentelemetry/collector-kubernetes/k8s-troubleshooting/troubleshoot-k8s-sizing.rst

@@ -50,17 +50,17 @@ For example:
 
 .. code-block:: 
 
-  2021-11-12T00:22:32.172Z	info	exporterhelper/queued_retry.go:325	Exporting failed. Will retry the request after interval.	{"kind": "exporter", "name": "sapm", "error": "server responded with 429", "interval": "4.4850027s"}
-  2021-11-12T00:22:38.087Z	error	exporterhelper/queued_retry.go:190	Dropping data because sending_queue is full. Try increasing queue_size.	{"kind": "exporter", "name": "sapm", "dropped_items": 1348}
+  2021-11-12T00:22:32.172Z	info	exporterhelper/queued_retry.go:325	Exporting failed. Will retry the request after interval.	{"kind": "exporter", "name": "otlphttp", "error": "server responded with 429", "interval": "4.4850027s"}
+  2021-11-12T00:22:38.087Z	error	exporterhelper/queued_retry.go:190	Dropping data because sending_queue is full. Try increasing queue_size.	{"kind": "exporter", "name": "otlphttp", "dropped_items": 1348}
 
-If you can't fix throttling by bumping limits on the backend or reducing amount of data sent through the Collector, you can avoid OOMs by reducing the sending queue of the failing exporter. For example, you can reduce ``sending_queue`` for the ``sapm`` exporter:
+If you can't fix throttling by bumping limits on the backend or reducing amount of data sent through the Collector, you can avoid OOMs by reducing the sending queue of the failing exporter. For example, you can reduce ``sending_queue`` for the ``otlphttp`` exporter:
 
 .. code-block:: yaml
 
   agent:
     config:
       exporters:
-        sapm:
+        otlphttp:
           sending_queue:
             queue_size: 512
 

gdi/opentelemetry/components/attributes-processor.rst

@@ -83,7 +83,7 @@ You can then add the attributes processors to any compatible pipeline. For examp
         - memory_limiter
         - batch
         - resourcedetection
-        exporters: [sapm, signalfx]
+        exporters: [otlphttp, signalfx]
       metrics:
         receivers: [hostmetrics, otlp, signalfx]
         processors:

gdi/opentelemetry/components/filter-processor.rst

@@ -86,7 +86,7 @@ You can then add the filter processors to any compatible pipeline. For example:
          - memory_limiter
          - batch
          - resourcedetection
-         exporters: [sapm, signalfx]
+         exporters: [otlphttp, signalfx]
        metrics:
          receivers: [hostmetrics, otlp, signalfx]
          processors:

gdi/opentelemetry/components/groupbyattrs-processor.rst

@@ -70,7 +70,7 @@ Use the processor to perform the following actions:
 * :ref:`Compact multiple records <groupbyattrs-processor-compact>` that share the same ``resource`` and ``InstrumentationLibrary`` attributes but are under multiple ``ResourceSpans`` or ``ResourceMetrics`` or ``ResourceLogs`` into a single ``ResourceSpans`` or ``ResourceMetrics`` or ``ResourceLogs``, when an empty list of keys is provided. 
 
   * This happens, for example, when you use the ``groupbytrace`` processor, or when data comes in multiple requests. 
-  * If you compact data it takes less memory, it's more efficiently processed and serialized, and the number of export requests is reduced, for example if you use the ``sapm`` exporter. See more at :ref:`splunk-apm-exporter`.
+  * If you compact data it takes less memory, it's more efficiently processed and serialized, and the number of export requests is reduced.
 
 .. tip:: Use the ``groupbyattrs`` processor together with ``batch`` processor, as a consecutive step. Grouping records together under matching resource and/or InstrumentationLibrary reduces the fragmentation of data.
 

gdi/opentelemetry/components/jaeger-receiver.rst

@@ -94,7 +94,7 @@ The Jaeger receiver uses helper files for additional capabilities:
 Remote sampling
 -----------------------------------------------
 
-Since version 0.61.0, remote sampling is no longer supported. Instead, since version 0.59.0, use the ``jaegerremotesapmpling`` extension for remote sampling.
+Since version 0.61.0, remote sampling is no longer supported. Instead, since version 0.59.0, use the ``jaegerremotesampling`` extension for remote sampling.
 
 .. _jaeger-receiver-settings: