You can run the collector as a Daemonset, and utilize the k8s resource attributes to provide additional metadata to the span. You should only be looking this information up for pod's that are running on the same host as the collector processing the spand.
When running as an agent, it is important to apply a discovery filter so that the processor only discovers pods from the same host that it is running on. Not using such a filter can result in unnecessary resource usage especially on very large clusters.
Your other option is to run the collector as a agent, but then you lose the ability to enrich the spans with that data.
How should the problem be solved?
Should be able to configure LINKERD2_PROXY_TRACE_COLLECTOR_SVC_ADDR to utilize the already existing spec.nodeName ENV var.
What problem are you trying to solve?
Linkerd doesnt actually play nicely when using the OTEL Collector.
You can run the collector as a Daemonset, and utilize the k8s resource attributes to provide additional metadata to the span. You should only be looking this information up for pod's that are running on the same host as the collector processing the spand.
Your other option is to run the collector as a agent, but then you lose the ability to enrich the spans with that data.
How should the problem be solved?
Should be able to configure
LINKERD2_PROXY_TRACE_COLLECTOR_SVC_ADDRto utilize the already existingspec.nodeNameENV var.Any alternatives you've considered?
Just deal with broken traces.
How would users interact with this feature?
Ideally as a helm input.
Would you like to work on this feature?
no