Internal telemetry config options for OTLP export #5986
Conversation
Signed-off-by: Swapnil Kulkarni <[email protected]>
opentelemetrybot
requested review from
a team and
atoulme
and removed request for
a team
|
@codeboten please take a look if this is what you were looking for in #5721 |
|
@codeboten ping :) |
|
@open-telemetry/collector-approvers Could you have a look, please? Thanks! |
| 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) |
There was a problem hiding this comment.
Hmm, could we link to docs page, maybe docs/collector/configuration/#receivers. That page links out to the repo's receiver folder.
@theletterf @tiffany76 @open-telemetry/docs-approvers WDYT?
There was a problem hiding this comment.
Sounds good to me, but I think @jade-guiton-dd's comment below is worth addressing first. This PR's content was purposely removed from the page in a previous PR, and there's been no call to add it back.
| 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. |
There was a problem hiding this comment.
| 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. | |
| Self-monitoring risks impacting the Collector's performance: routing internal | |
| telemetry through the Collector's pipelines can create feedback loops, further | |
| stressing the system. Avoid self-monitoring in production. |
|
This PR seems to add back, verbatim, the section about self-monitoring that was intentionally removed in #5749 to avoid suggesting an unstable setup to users. Do we have a rationale for adding it back? And I don't think the tracking issue is related to this: reading through its history in #5702, it sounds like it was originally about updating the table of configuration options under "Configure internal logs", and adding something similar for traces and metrics. |
Preview: https://deploy-preview-5986--opentelemetry.netlify.app/docs/collector/internal-telemetry/#self-monitoring