Pulling refs/heads/main into main

_includes/application-receiver-table.rst

@@ -523,7 +523,7 @@
      -
      -
 
-   * - :ref:`SignalFx Forwarder <signalfx-forwarder>`
+   * - :ref:`signalfx-forwarder`
      - :strong:`X`
      - :strong:`X`
      -

gdi/monitors-databases/postgresql.rst

@@ -6,7 +6,7 @@ PostgreSQL
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the PostgreSQL monitor. See benefits, install, configuration, and metrics
 
-.. note:: You can replace this monitor with the OTel native component ``postgresql`` receiver. See :ref:`postgresql-receiver` for more information.
+.. note:: This integration is deprecated. If you're using the Splunk Distribution of the OpenTelemetry Collector and want to collect PostgreSQL metrics, use the native OTel component :ref:`postgresql-receiver`.
 
 The
 :ref:`Splunk Distribution of OpenTelemetry Collector <otel-intro>`

gdi/monitors-hosts/collectd-df.rst

@@ -1,11 +1,13 @@
 .. _collectd-df:
 
-Collectd df
-===========
+Collectd df (deprecated)
+===============================
 
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the Collectd df plugin monitor. See benefits, install, configuration, and metrics
 
+.. note::  This integration is deprecated in favor of :ref:`filesystems`. 
+
 The
 :ref:`Splunk Distribution of OpenTelemetry Collector <otel-intro>`
 uses the :ref:`Smart Agent receiver <smartagent-receiver>` with the

gdi/monitors-hosts/disk.rst

@@ -1,12 +1,12 @@
 .. _disk:
 
-Disk and partition
-==================
+Disk and partition (deprecated)
+====================================
 
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the disks monitor. See benefits, install, configuration, and metrics
 
-.. note:: If you're using the Splunk Distribution of OpenTelemetry Collector and want to collect disk I/O metrics, use the native OTel component :ref:`host-metrics-receiver`.
+.. note:: This integration is deprecated. If you're using the Splunk Distribution of the OpenTelemetry Collector and want to collect disk I/O metrics, use the native OTel component :ref:`host-metrics-receiver`.
 
 Configuration settings
 ----------------------

gdi/monitors-hosts/host-processload.rst

@@ -1,12 +1,12 @@
 .. _load:
 
-Host process load
-=================
+Host process load (deprecated)
+=================================
 
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the load monitor. See benefits, install, configuration, and metrics
 
-.. note:: If you're using the Splunk Distribution of OpenTelemetry Collector and want to collect CPU load metrics, use the native OTel component :ref:`host-metrics-receiver`.
+.. note:: This integration is deprecated. If you're using the Splunk Distribution of the OpenTelemetry Collector and want to collect CPU load metrics, use the native OTel component :ref:`host-metrics-receiver`.
 
 Configuration options
 ---------------------

gdi/monitors-hosts/interface.rst

@@ -1,12 +1,12 @@
 .. _interface:
 
 Interface traffic (deprecated)
-==============================
+===================================
 
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the interface monitor. See benefits, install, configuration, and metrics
 
-.. note:: This integration is deprecated in favor of the ``net-io`` integration, which uses the ``interface`` dimension to identify the network card instead of the ``plugin_instance`` dimension and provides the same metrics. To learn more, see :ref:`net-io`.
+.. note:: This integration is deprecated in favor of the ``net-io`` integration, which provides the same metrics. ``net-io`` uses the ``interface`` dimension to identify the network card instead of the ``plugin_instance`` dimension. To learn more, see :ref:`net-io`.
 
 Configuration settings
 ----------------------

gdi/monitors-monitoring/signalfx-forwarder.rst

@@ -1,11 +1,13 @@
 .. _signalfx-forwarder:
 
-SignalFx Forwarder
-==================
+SignalFx Forwarder (deprecated)
+==================================
 
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the SignalFX forwarder receiver. See benefits, install, configuration, and metrics
 
+.. note:: This integration is deprecated. If you're using the Splunk Distribution of the OpenTelemetry Collector and want to forward data to Splunk Observability Cloud, use the native OTLP receiver. See more at :new-page:`OTLP receiver <https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver>` GitHub documentation.
+
 The
 :ref:`Splunk Distribution of OpenTelemetry Collector <otel-intro>`
 uses the :ref:`Smart Agent receiver <smartagent-receiver>` with the

gdi/monitors-prometheus/prometheus-generic.rst

@@ -67,7 +67,7 @@ Next, activate the ``metrics`` pipeline:
 .. code:: yaml
 
    metrics:
-      receivers: [hostmetrics, otlp, signalfx, smartagent/signalfx-forwarder, prometheus/flink]
+      receivers: [hostmetrics, otlp, signalfx, prometheus/flink]
 
 Settings
 ======================

gdi/opentelemetry/components/attributes-processor.rst

@@ -74,15 +74,15 @@ You can then add the attributes processors to any compatible pipeline. For examp
    service:
      pipelines:
        traces:
-         receivers: [jaeger, otlp, smartagent/signalfx-forwarder, zipkin]
+         receivers: [jaeger, otlp, zipkin]
          processors:
          - attributes/traces
          - memory_limiter
          - batch
          - resourcedetection
          exporters: [sapm, signalfx]
        metrics:
-         receivers: [hostmetrics, otlp, signalfx, smartagent/signalfx-forwarder]
+         receivers: [hostmetrics, otlp, signalfx]
          processors:
          - attributes/metrics
          - memory_limiter

gdi/opentelemetry/components/filter-processor.rst

@@ -80,15 +80,15 @@ You can then add the filter processors to any compatible pipeline. For example:
    service:
      pipelines:
        traces:
-         receivers: [jaeger, otlp, smartagent/signalfx-forwarder, zipkin]
+         receivers: [jaeger, otlp, zipkin]
          processors:
          - filter/traces
          - memory_limiter
          - batch
          - resourcedetection
          exporters: [sapm, signalfx]
        metrics:
-         receivers: [hostmetrics, otlp, signalfx, smartagent/signalfx-forwarder]
+         receivers: [hostmetrics, otlp, signalfx]
          processors:
          - filter/includemetrics
          - filter/excludemetrics

gdi/opentelemetry/components/logging-exporter.rst

@@ -40,14 +40,14 @@ To activate the logging exporter, add it to any pipeline you want to diagnose. F
    service:
      pipelines:
        traces:
-         receivers: [jaeger, otlp, smartagent/signalfx-forwarder, zipkin]
+         receivers: [jaeger, otlp, zipkin]
          processors:
          - memory_limiter
          - batch
          - resourcedetection
          exporters: [sapm, signalfx, logging]
        metrics:
-         receivers: [hostmetrics, otlp, signalfx, smartagent/signalfx-forwarder]
+         receivers: [hostmetrics, otlp, signalfx]
          processors: [memory_limiter, batch, resourcedetection]
          exporters: [signalfx, logging]
        logs:

gdi/opentelemetry/components/smartagent-receiver.rst

@@ -77,7 +77,7 @@ For a list of monitor data sources, see :ref:`monitor-data-sources`.
 Get started
 ======================
 
-By default, the Splunk Distribution of OpenTelemetry Collector includes the Smart Agent receiver with the ``signalfx-forwarder`` and ``processlist`` monitors when deploying in host monitoring (agent) mode. See :ref:`otel-deployment-mode` for more information.
+By default, the Splunk Distribution of OpenTelemetry Collector includes the Smart Agent receiver with the ``processlist`` monitor when deploying in host monitoring (agent) mode. See :ref:`otel-deployment-mode` for more information.
 
 For each Smart Agent monitor you want to add to the Collector, add a Smart Agent receiver. After you've configured a Smart Agent monitor in the Collector, each Smart Agent receiver behaves like the corresponding Smart Agent monitor. 
 
@@ -112,7 +112,7 @@ You can then add the receiver to any compatible pipeline. For example:
 
 If you use a monitor that updates dimension properties or tags, for example ``postgresql``, add the name of your SignalFx exporter in the ``dimensionClients`` field in Smart Agent receiver configuration block. If you don't set any exporter in the ``dimensionClients`` field, the receiver tries to use the pipeline to which it's connected. If you don't require dimension updates, you can use an empty array (``[]``) to deactivate it.
 
-.. caution:: Don't remove the ``smartagent/signalfx-forwarder`` and ``smartagent/processlist`` receivers from the configuration. System processes and Smart Agent telemetry depend on both receivers's configurations.
+.. caution:: Don't remove the ``smartagent/processlist`` receiver from the configuration. System processes and Smart Agent telemetry depend on the receiver's configuration.
 
 .. _otel-sareceiver-extrametrics:
 

gdi/opentelemetry/components/transform-processor.rst

@@ -63,15 +63,15 @@ You can then add the transform processor to any compatible pipeline. For example
    service:
      pipelines:
        traces:
-         receivers: [jaeger, otlp, smartagent/signalfx-forwarder, zipkin]
+         receivers: [jaeger, otlp, zipkin]
          processors:
          - transform
          - memory_limiter
          - batch
          - resourcedetection
          exporters: [sapm, signalfx]
        metrics:
-         receivers: [hostmetrics, otlp, signalfx, smartagent/signalfx-forwarder]
+         receivers: [hostmetrics, otlp, signalfx]
          processors:
          - transform
          - memory_limiter

gdi/opentelemetry/configure-the-collector-ootb.rst

@@ -116,7 +116,6 @@ The following diagram shows the default metrics pipeline:
          metrics/hostmetrics:::receiver
          metrics/otlp:::receiver
          metrics/signalfx/in:::receiver
-         metrics/smartagent/signalfx-forwarder:::receiver
          metrics/internal/prometheus/internal:::receiver
       end
 
@@ -137,17 +136,13 @@ The following diagram shows the default metrics pipeline:
       metrics/resourcedetection --> metrics/signalfx/out
       metrics/otlp --> metrics/memory_limiter
       metrics/signalfx/in --> metrics/memory_limiter
-      metrics/smartagent/signalfx-forwarder --> metrics/memory_limiter
       metrics/internal/prometheus/internal --> metrics/internal/memory_limiter
       metrics/internal/resourcedetection --> metrics/internal/signalfx/out
 
-
-
 Learn more about these receivers:
 
 * :ref:`host-metrics-receiver`
 * :ref:`signalfx-receiver`
-* :ref:`signalfx-forwarder`
 * :ref:`prometheus-receiver`
 
 Learn more about these processors:
@@ -183,7 +178,6 @@ The following diagram shows the default traces pipeline:
          direction LR
          traces/jaeger:::receiver
          traces/otlp:::receiver
-         traces/smartagent/signalfx-forwarder:::receiver
          traces/zipkin:::receiver
       end
 
@@ -201,7 +195,6 @@ The following diagram shows the default traces pipeline:
       %% Connections beyond categories are added later
       traces/jaeger --> traces/memory_limiter
       traces/otlp --> traces/memory_limiter
-      traces/smartagent/signalfx-forwarder --> traces/memory_limiter
       traces/zipkin --> traces/memory_limiter
       traces/resourcedetection --> traces/sapm
       traces/resourcedetection --> traces/signalfx/out
@@ -210,7 +203,6 @@ The following diagram shows the default traces pipeline:
 Learn more about these receivers:
 
 * :ref:`jaeger-grpc`
-* :ref:`signalfx-forwarder`
 
 Learn more about these processors:
 

gdi/opentelemetry/exposed-endpoints.rst

@@ -39,7 +39,7 @@ See the table for a complete list of exposed ports and endpoints:
   * - ``http(s)://localhost:8006``
     - Fluent forward receiver
   * - ``http(s)://0.0.0.0:9080``
-    - Smart Agent receiver with :new-page:`SignalFx Forwarder <https://docs.splunk.com/Observability/gdi/signalfx-forwarder/signalfx-forwarder.html>` monitor type
+    - Smart Agent receiver with :new-page:`SignalFx Forwarder <https://docs.splunk.com/Observability/gdi/signalfx-forwarder/signalfx-forwarder.html>` monitor type (deprecated)
   * - ``http(s)://0.0.0.0:9411/api/[v1|v2]/spans``
     - Zipkin receiver supporting V1 and V2
   * - ``http(s)://0.0.0.0:9943``

gdi/opentelemetry/smart-agent-migration-monitors.rst

@@ -23,7 +23,7 @@ For each Smart Agent monitor you want to add to the Collector, add a ``smartagen
 
 Instead of using ``discoveryRule``, use the Collector receiver creator and observer extensions. See :ref:`receiver-creator-receiver` for more information.
 
-If you're using a SignalFx Forwarder monitor, add it to both a ``traces`` and a ``metrics`` pipeline, and use a Sapm exporter and a SignalFx exporter, as each pipeline's exporter, respectively. See more on :ref:`exporters <collector-components-processors>`.
+If you're using a SignalFx Forwarder monitor (deprecated), add it to both a ``traces`` and a ``metrics`` pipeline, and use a Sapm exporter and a SignalFx exporter, as each pipeline's exporter, respectively. See more on :ref:`exporters <collector-components-processors>`.
 
 Configure metrics
 ------------------------------
@@ -64,8 +64,6 @@ Example
 
 
    receivers:
-      smartagent/signalfx-forwarder:
-         type: signalfx-forwarder
       smartagent/postgresql:
          type: postgresql
          host: mypostgresinstance
@@ -100,7 +98,7 @@ Example
             receivers:
                - smartagent/postgresql
                - smartagent/kafka
-               - smartagent/signalfx-forwarder
+               - otlp
             processors:
                - resourcedetection
             exporters:
@@ -114,7 +112,7 @@ Example
                - signalfx
          traces:
             receivers:
-               - smartagent/signalfx-forwarder
+               - otlp
             processors:
                - resourcedetection
             exporters:

gdi/opentelemetry/smart-agent-migration-process.rst

@@ -231,8 +231,6 @@ The following is an example YAML configuration file with default values where ap
    configDir: "/tmp/signalfx-agent/collectd"
 
    monitors:
-      - type: signalfx-forwarder
-         listenAddress: 0.0.0.0:9080
       - type: collectd/activemq
          discoveryRule: container_image =~ "activemq" && private_port == 1099
          extraDimensions:
@@ -248,7 +246,7 @@ The following is an example YAML configuration file with default values where ap
 
 .. _use-translatefx:
 
-4. Translate the Smart Agent configuration file using translatesfx
+1. Translate the Smart Agent configuration file using translatesfx
 =====================================================================================
 
 ``translatesfx`` is a command-line tool provided by Splunk Observability Cloud that helps you translate your existing Smart Agent YAML configuration file into a configuration that can be used by the Collector. To learn how to use it, see :ref:`Configuration translation tool <otel-translation-tool>`.

gdi/smart-agent/smart-agent-resources.rst

@@ -41,7 +41,7 @@ Check exposed ports
 Before installing the Smart Agent, check exposed ports to make sure your environment doesn't have conflicts. You can change the ports in the Smart Agent configuration.
 
 * Port 8095 is the default port that the internal status server listens on. Configure port 8095 using the ``internalStatusPort`` option.
-* Port 9080 is the default port that the server listens on. Configure port 9080 using the ``listenAddress`` option. The ``listenAddress`` option is a configurable option for the ``trace-forwarder`` and ``signalfx-forwarder`` monitors.
+* Port 9080 is the default port that the server listens on. Configure port 9080 using the ``listenAddress`` option. The ``listenAddress`` option is a configurable option for the ``trace-forwarder`` monitor.
 
 Install the Smart Agent
 ============================================