open-telemetry
[Feature Request] Would it make sense to have a `none` mode for the collector?
Now that we support injecting variables into the pod I'd like to use this functionality without deploying the sidecar.
Reason being, my company writes most of its services in rust, with the rust otel SDK, then we use the resource detector via the agent to get pod details.
Because we also use knative which doesn't support sidecars, and doesn't support the downapi, this doesn't work.
So what I'd personally really like, is if there was a way to inject resource attributes into the pod, so that the application can report them itsself to the collector, without using a sidecar.
Hope this makes sense.
Another option would be to have a "custom" type for the auto instrumentation, that could just be a "noop" essentially. I'm doing something like this today by using the java auto instrumentation for my rust containers, since of course it'll just ignore the java variables.
cc) @rubenvp8510
@edude03 does your data go through OTEL collector?
The collector can make use of https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/k8sattributesprocessor which should be able to derive the k8s resource attributes from the incoming destination.
I do find your proposal useful and I do agree that the Instrumentation kind should be responsible for injecting the resource attributes to the user workload. We could define instrumentation.opentelemetry.io/inject-sdk: "true" that would inject only core SDK configuration (sampler, exporter, resource attrs.)
@pavolloffay I probably should explain what led me here actually. So, my company writes rust services that are instrumented with OTEL. We send the data to the local agent, which runs the k8sattributeprocessor, which then forwards to the global collector(s).
We've recently started using knative, and we'd like to do the same but there are some problems:
- Knative doesn't support the downward API so I can't get the $HOST_IP that way.
- Our version of Kubernetes doesn't have Service Topology Enabled so can't send to the local host that way.
- Knative doesn't support specifying sidecars (but injecting them via a mutating webhook does work, thus why I use the otel operator)
The injector does inject the host IP so we can get it to work that way (and will infact, to pickup host metrics along the way) but yeah I do think having Instrumentation be able to inject vars would be a great feature to have regardless of my maybe unusual use case
The Instrumentation also uses k8s downward API for the resource attributes. Would that work for you?