-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Resource Detection for container properties (e.g.container.id
)
#1372
Comments
This seems to be a good feature request.
There is an issue with this approach:
Can anyone help me with this issue? |
This is the comment I have received from @srikanthccv for the above issue:
|
@ocelotl : tagging you here as well |
The ResourceDetection is independent of library instrumentation. You don't need all these issues opened for each framework. Users don't set the tracer provider in each framework separately. It happens once, and the user is expected to provide the |
Hi @srikanthccv , In case of user is not providing the tracer_provider, I was thinking to create one inside I understand that ResourceDetector module is independent of library instrumentation but I wanted to use this module in each framework inside instrumentation only. That was the reason why I had created separate issues for each framework. Also in case of ENV variable approach there are 2 problems:
Please do let me know if you think I have misunderstood anything here. |
No, the instrumentation will not set any (tracer/meter/logger)provider on its own for any reason. In the absence of a tracer provider, it will be all no-op, and it's a design decision.
If you are referring
I don't know of any alternative at the moment. And we don't want to do something that is not spec-compliant. You are free to propose a solution.
Why do you believe this is not the right approach? |
Hey @sanketmehta28 , @srikanthccv , thanks for discussing this. Since I raised this issue a few comments on that matter: A few other language implementations have the support for resource detectors already in place, and took the following approaches to get them loaded:
So independent of the OTEL_RESOURCE_DETECTORS, I see two things that python SIG could implement right now and being spec compliant & consistent with other languages:
Regarding OTEL_RESOURCE_DETECTORS: I assume that Sanket's concern is the following: If I define resource detectors in that list, they have to be part of the application I am using, e.g. the developer made the deliberate choice to add the ContainerResourceDetector (or others) to the application while creating it. I will comment on the same matter at the spec issue: I think it's worth to go back a few steps and re-think how resource detectors are added. |
This is already supported.
By included, you mean they get installed as a part of the distro; it's fine we do this already for instrumentations but including everything, as in all attribute data users have not opted for, is not a good thing. There will also be third-party resource detectors outside this repo which we have no control over, and there needs to be a mechanism to configure them, which is where I bring the feature request to add new env.
I don't get this argument. Let's take what's already spec'd out, When the user configures |
I don't care that much about third-party (aka cloud vendors) resource detectors and more about "standard" ones like container , k8s or other common infrastructure.
I see that you commented on my more lengthy comment over at the spec as well, so let's move that conversation there? |
From a design perspective, we want a solution that works well for the "standard", or otherwise, that doesn't require rethinking when users come to ask for support for the vendor or even their custom detectors.
Sure, I am conveying this is not a new problem - we already have this addressed for other components and let's follow the pattern. |
@srikanthccv , @svrnm : Independent of the ENV var |
Just for the record, discussed in our last SIG, @sanketmehta28 will look into other SIGs implementations maybe they have a way to solve this problem that can work for us  |
Hi All, NodeJS:
DotNet: Java:
GoLang: By looking at the implementation and having discussion with some SIG contributors, it looks like none of them are providing any way to make this feature available in auto instrumentation but only in manual instrumentation using SDK. |
It looks like Java agent is able to collect container.id out of the box (I have updated my last comment accordingly). |
I have checked with @svrnm and came to know that in java agent, they basically load all |
What is it that you refer to here that fails silently?
Whatever we do, It will not be limited just to the traces. The same aggregated resource must be used for all three "signals". I am okay with the idea of using all installed resource detectors, but I think the user should have the option to suppress it if they want to. |
Means it will not fetch the container.id without any error or warning and continue the execution
@srikanthccv : How do you suggest we provide the option to suppress it? |
yeah 🎉 |
Is your feature request related to a problem?
Detecting the id of the container that holds the service instrumented with otel allows end-users to correlate container issues with service issues.
Describe the solution you'd like
I see some of that implemented in the AWS Extension, but I was wondering if there's a way to have this standalone.
Describe alternatives you've considered
Injecting the container id via an environment variable is always possible.
Additional context
Semantic conventions for container resource: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/container.md
A similar implementation exists for Java, JS, .NET & Go already. The .JS is the most advanced since it also works with containers when cgroup v2 is used:
https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/detectors/node/opentelemetry-resource-detector-container/src/detectors/ContainerDetector.ts
We are also currently trying at opentelemetry.io to have per-language pages on resources and used the container detection as an example besides using the environment variable:
open-telemetry/opentelemetry.io#1773
and
https://opentelemetry.io/docs/instrumentation/js/resources/
The text was updated successfully, but these errors were encountered: