From c1ec31f78147deaebe6ed8bf509675e9409a02e7 Mon Sep 17 00:00:00 2001
From: Alex Boten <223565+codeboten@users.noreply.github.com>
Date: Mon, 9 Dec 2024 11:29:25 -0800
Subject: [PATCH] remove suggestion to process internal telemetry through
 collector

The following PR removes the suggestion in the documentation to send
the Collector's internal telemetry through the Collector's pipelines.
As the warning suggests, doing this is risky and we likely don't want
to recommend users do this.

Signed-off-by: Alex Boten <223565+codeboten@users.noreply.github.com>
---
 .../en/docs/collector/internal-telemetry.md   | 79 ++++---------------
 1 file changed, 16 insertions(+), 63 deletions(-)

diff --git a/content/en/docs/collector/internal-telemetry.md b/content/en/docs/collector/internal-telemetry.md
index f125988bdbe8..473de3f2ea06 100644
--- a/content/en/docs/collector/internal-telemetry.md
+++ b/content/en/docs/collector/internal-telemetry.md
@@ -43,6 +43,22 @@ service:
                 port: 8888
 ```
 
+Alternatively, the Collector can push its internal metrics via
+to an OTLP backend via the following configuration:
+
+```yaml
+
+service:
+  telemetry:
+    metrics:
+      readers:
+        - periodic:
+            exporter:
+              otlp:
+                protocol: grpc/protobuf
+                endpoint: http://localhost:14317
+```
+
 You can adjust the verbosity of the Collector metrics output by setting the
 `level` field to one of the following values:
 
@@ -151,69 +167,6 @@ Note that the `tracer_provider` section there corresponds to `traces` here.
 [kitchen-sink-config]:
   https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/kitchen-sink.yaml
 
-### Self-monitoring
-
-The Collector can be configured to push its own telemetry to an
-[OTLP receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver)
-and send the data through configured pipelines. In the following example, the
-Collector is configured to push metrics, traces, and logs every 10s using OTLP
-gRPC to `localhost:14317`:
-
-```yaml
-receivers:
-  otlp/internal:
-    protocols:
-      grpc:
-        endpoint: localhost:14317
-exporters:
-  debug:
-service:
-  pipelines:
-    metrics:
-      receivers: [otlp/internal]
-      exporters: [debug]
-    traces:
-      receivers: [otlp/internal]
-      exporters: [debug]
-  telemetry:
-    metrics:
-      readers:
-        - periodic:
-            interval: 10000
-            exporter:
-              otlp:
-                protocol: grpc/protobuf
-                endpoint: http://localhost:14317
-    traces:
-      processors:
-        - batch:
-            exporter:
-              otlp:
-                protocol: grpc/protobuf
-                endpoint: http://localhost:14317
-    logs:
-      processors:
-        - batch:
-            exporter:
-              otlp:
-                protocol: grpc/protobuf
-                endpoint: http://localhost:14317
-```
-
-{{% alert title="Caution" color="warning" %}}
-
-When self-monitoring, the Collector collects its own telemetry and sends it to
-the desired backend for analysis. This can be a risky practice. If the Collector
-is underperforming, its self-monitoring capability could be impacted. As a
-result, the self-monitored telemetry might not reach the backend in time for
-critical analysis.
-
-Moreover, sending internal telemetry through the Collector's own pipelines can
-create a continuous loop of spans, metric points, or logs, putting undue strain
-on the Collector's performance. This setup should not be used in production.
-
-{{% /alert %}}
-
 ## Types of internal telemetry
 
 The OpenTelemetry Collector aims to be a model of observable service by clearly