@@ -43,6 +43,22 @@ service:
43
43
port : 8888
44
44
` ` `
45
45
46
+ Alternatively, the Collector can push its internal metrics via
47
+ to an OTLP backend via the following configuration:
48
+
49
+ ` ` ` yaml
50
+
51
+ service :
52
+ telemetry :
53
+ metrics :
54
+ readers :
55
+ - periodic :
56
+ exporter :
57
+ otlp :
58
+ protocol : grpc/protobuf
59
+ endpoint : http://localhost:14317
60
+ ` ` `
61
+
46
62
You can adjust the verbosity of the Collector metrics output by setting the
47
63
` level` field to one of the following values:
48
64
@@ -151,69 +167,6 @@ Note that the `tracer_provider` section there corresponds to `traces` here.
151
167
[kitchen-sink-config] :
152
168
https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/kitchen-sink.yaml
153
169
154
- # ## Self-monitoring
155
-
156
- The Collector can be configured to push its own telemetry to an
157
- [OTLP receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver)
158
- and send the data through configured pipelines. In the following example, the
159
- Collector is configured to push metrics, traces, and logs every 10s using OTLP
160
- gRPC to `localhost:14317` :
161
-
162
- ` ` ` yaml
163
- receivers:
164
- otlp/internal:
165
- protocols:
166
- grpc:
167
- endpoint: localhost:14317
168
- exporters:
169
- debug:
170
- service:
171
- pipelines:
172
- metrics:
173
- receivers: [otlp/internal]
174
- exporters: [debug]
175
- traces:
176
- receivers: [otlp/internal]
177
- exporters: [debug]
178
- telemetry:
179
- metrics:
180
- readers:
181
- - periodic:
182
- interval: 10000
183
- exporter:
184
- otlp:
185
- protocol: grpc/protobuf
186
- endpoint: http://localhost:14317
187
- traces:
188
- processors:
189
- - batch:
190
- exporter:
191
- otlp:
192
- protocol: grpc/protobuf
193
- endpoint: http://localhost:14317
194
- logs:
195
- processors:
196
- - batch:
197
- exporter:
198
- otlp:
199
- protocol: grpc/protobuf
200
- endpoint: http://localhost:14317
201
- ` ` `
202
-
203
- {{% alert title="Caution" color="warning" %}}
204
-
205
- When self-monitoring, the Collector collects its own telemetry and sends it to
206
- the desired backend for analysis. This can be a risky practice. If the Collector
207
- is underperforming, its self-monitoring capability could be impacted. As a
208
- result, the self-monitored telemetry might not reach the backend in time for
209
- critical analysis.
210
-
211
- Moreover, sending internal telemetry through the Collector's own pipelines can
212
- create a continuous loop of spans, metric points, or logs, putting undue strain
213
- on the Collector's performance. This setup should not be used in production.
214
-
215
- {{% /alert %}}
216
-
217
170
# # Types of internal telemetry
218
171
219
172
The OpenTelemetry Collector aims to be a model of observable service by clearly
0 commit comments