New component: traceroutereceiver

[atoulme]

The purpose and use-cases of the new component

We often run in situations where the collector is meant to send data to a remote endpoint, and we run in networking issues.

We end up running traceroute to understand the problem.

I think instead having a traceroute receiver showing a trace with each span being a hop would be a valuable outcome.

Example configuration for the component

receivers:
traceroute:
endpoint: example.com

Telemetry data types supported

traces

Code Owner(s)

atoulme

Sponsor (optional)

No response

Additional context

No response

[Aneurysm9]

Shouldn't this be solved by running traceroute from the host running the collector? I don't think the collector needs to be a do-everything-tool. What's next, a ping receiver? cat?

More practically, traceroute, mtr, etc. typically operate by sending multiple ICMP packets with varying TTL which can end up taking different routes at different times and some nodes on that path may not report time exceeded or destination unreachable. This seems like a lot of reinventing the wheel for little apparent gain other than ongoing maintenance burden.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.