@@ -65,46 +65,6 @@ service:
65
65
level: detailed
66
66
` ` `
67
67
68
- The Collector can also be configured to push its own metrics to an
69
- [OTLP receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver)
70
- and send them through configured pipelines. In the following example, the
71
- Collector is configured to push metrics every 10s using OTLP gRPC to
72
- `localhost:14317` :
73
-
74
- ` ` ` yaml
75
- receivers:
76
- otlp/internal_metrics:
77
- protocols:
78
- grpc:
79
- endpoint: localhost:14317
80
- exporters:
81
- debug:
82
- service:
83
- pipelines:
84
- metrics:
85
- receivers: [otlp/internal_metrics]
86
- exporters: [debug]
87
- telemetry:
88
- metrics:
89
- readers:
90
- - periodic:
91
- interval: 10000
92
- exporter:
93
- otlp:
94
- protocol: grpc/protobuf
95
- endpoint: localhost:14317
96
- ` ` `
97
-
98
- {{% alert title="Caution" color="warning" %}}
99
-
100
- When self-monitoring, the Collector collects its own telemetry and sends it to
101
- the desired backend for analysis. This can be a risky practice. If the Collector
102
- is underperforming, its self-monitoring capability could be impacted. As a
103
- result, the self-monitored telemetry might not reach the backend in time for
104
- critical analysis.
105
-
106
- {{% /alert %}}
107
-
108
68
# ## Configure internal logs
109
69
110
70
Log output is found in `stderr`. You can configure logs in the config
@@ -144,6 +104,94 @@ journalctl | grep otelcol | grep Error
144
104
145
105
{{% /tab %}} {{< /tabpane >}}
146
106
107
+ # ## Configure internal traces
108
+
109
+ The Collector does not expose traces by default, but it can be configured to.
110
+
111
+ {{% alert title="Caution" color="warning" %}}
112
+
113
+ Internal tracing is an experimental feature, and no guarantees are made as to
114
+ the stability of the emitted span names and attributes.
115
+
116
+ {{% /alert %}}
117
+
118
+ The following configuration can be used to emit internal traces from the
119
+ Collector to an OTLP/gRPC backend :
120
+
121
+ ` ` ` yaml
122
+ service:
123
+ telemetry:
124
+ traces:
125
+ processors:
126
+ - batch:
127
+ exporter:
128
+ otlp:
129
+ protocol: grpc/protobuf
130
+ endpoint: https://backend:4317
131
+ ` ` `
132
+
133
+ See the [example configuration][kitchen-sink-config] for additional options.
134
+ Note that the `tracer_provider` section there corresponds to `traces` here.
135
+
136
+ [kitchen-sink-config] :
137
+ https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/kitchen-sink.yaml
138
+
139
+ # ## Self-monitoring
140
+
141
+ The Collector can be configured to push its own telemetry to an
142
+ [OTLP receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver)
143
+ and send the data through configured pipelines. In the following example, the
144
+ Collector is configured to push metrics and traces every 10s using OTLP gRPC to
145
+ `localhost:14317` :
146
+
147
+ ` ` ` yaml
148
+ receivers:
149
+ otlp/internal:
150
+ protocols:
151
+ grpc:
152
+ endpoint: localhost:14317
153
+ exporters:
154
+ debug:
155
+ service:
156
+ pipelines:
157
+ metrics:
158
+ receivers: [otlp/internal]
159
+ exporters: [debug]
160
+ traces:
161
+ receivers: [otlp/internal]
162
+ exporters: [debug]
163
+ telemetry:
164
+ metrics:
165
+ readers:
166
+ - periodic:
167
+ interval: 10000
168
+ exporter:
169
+ otlp:
170
+ protocol: grpc/protobuf
171
+ endpoint: localhost:14317
172
+ traces:
173
+ processors:
174
+ batch:
175
+ exporter:
176
+ otlp:
177
+ protocol: grpc/protobuf
178
+ endpoint: localhost:14317
179
+ ` ` `
180
+
181
+ {{% alert title="Caution" color="warning" %}}
182
+
183
+ When self-monitoring, the Collector collects its own telemetry and sends it to
184
+ the desired backend for analysis. This can be a risky practice. If the Collector
185
+ is underperforming, its self-monitoring capability could be impacted. As a
186
+ result, the self-monitored telemetry might not reach the backend in time for
187
+ critical analysis.
188
+
189
+ Moreover, sending internal telemetry through the Collector's own pipelines can
190
+ create a continuous loop of spans, metric points, or logs, putting undue strain
191
+ on the Collector's performance. This setup should not be used in production.
192
+
193
+ {{% /alert %}}
194
+
147
195
# # Types of internal telemetry
148
196
149
197
The OpenTelemetry Collector aims to be a model of observable service by clearly
0 commit comments