opentelemetry-demo
opentelemetry-demo copied to clipboard
open-telemetry
Add dotnet auto instrumentation
Dotnet should have non instrumentation library based auto instrumentation examples.
https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation
My couple cents:
- We should avoid using any undefined/misleading term in this demo project - across the docs, code and communication, e.g. "agent". https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/glossary.md
- We probably need to define "what's the default set of experiences/services/containers", to avoid this demo project becoming too big/complex/slow for average machines to run.
- .NET auto-instrumentation is currently at Beta, I can imagine potential breaking changes, I suggest getting feedback from @open-telemetry/dotnet-instrumentation-maintainers to see if it's a good time or we should defer this to RC or Stable.
SIG Auto Instrumentation .NET meeting notes: if we are able to use .NET Framework 4.6.2+/NET 6/7 we should be fine to include it shortly. We expect 0.5.0 release which will be supporting all modern .NET version (including .NET 7).
Please do not call it "agent".
The upcoming 0.5.0 release will contain many changes in the configuration settings to avoid the possibility of possible breaking changes in future. We will do the best to describe potential problems when upgrading to newer versions in the GitHub Releases and CHANGELOG.md and troubleshooting.md.
Based on the existing feedback we get I would say that it is "production quality".
Questions:
- Is the auto-instrumentation the 'preferred' method of .NET instrumentation?
If yes, then we should replace the library instrumentation with it. If no...
- Should we create a new service to demonstrate the auto-instrumentation, or can we modify the existing service to demonstrate both?
They’re in beta rn so preferred might not be the choice today. @rajkumar-rangaraj thoughts?
.NET Auto-Instrumentation 0.5.0 is the first production-ready (non-beta) release. It is not stable yet. .NET Auto-Instrumentation could be used demonstrate a new service.
I think that we need some brand new service for this purposes. I would like to avoid mixing library instrumentation with auto-instrumentation. It is not typical usage.
Do you have any proposal how to extend this https://opentelemetry.io/docs/demo/architecture/?
I think that we need some brand new service for this purposes. I would like to avoid mixing library instrumentation with auto-instrumentation. It is not typical usage.
Do you have any proposal how to extend this https://opentelemetry.io/docs/demo/architecture/?
There are 3 services written in Go. See: https://opentelemetry.io/docs/demo/service-table/. Maybe we can rewrite one in .NET and use .NET Auto-Instrumentation there?
Is the auto-instrumentation the 'preferred' method of .NET instrumentation?
There is no strong preference. As far as I see, usually devs prefer the manual/SDK way and SREs prefer auto-instrumentation.
The accounting service is essentially a placeholder. We’d more than welcome a rewrite of it. We are trying to avoid adding more services than we currently have due to resource requirements
My two cents is that Auto-instrumentation is not the recommended way, in pretty much any language. If you have access to the code, you should use the method that gives you most control. Once we have the configuration specifications sorted, it shouldn't matter from the outside which is what matters.
Having a service that is auto-instrumented as well as not is something I could get behind to provide both examples, however, not providing a manual instrumentation in the demo would be something I would be against.
I'd also agree with Reiley in that the demo is getting big, and adding essentially a duplication of all languages in an auto-instrumented way would bloat the project for no real benefit in my opinion.
The idea of auto-instrumentation is instrumenting a project that you don't have access to the code for. For that, I'd much prefer to take an existing Microservices based demo and add the operator, rather than use the OpenTelemetry demo for that as it would provide the right sort of message "You can add the operator to any solution and it will "just work" without changing code".
If it wouldn't cause the code to be too messy I'd imagine we could do some sort of conditional enablement of the SDK and have a run-time flag to use auto-instrumentation or library instrumentation.
@martinjt an existing manually instrumented dotnet service exists already, it is not being proposed we replace it or mix instrumentations, we would most likely replace an existing Go service to not increase overall demo size, and many SREs may not have access to the code as you mentioned but also not run on kubernetes.
If we wanted to use the operator in the kubernetes version that is fine and would be great to have. But the regular docker version needs auto instrumentation examples too and the point of the demo is to show how community assets, like dotnet auto instrumentation, work in the “wild”. This isn’t an instrumentation efficiency demo but a showcase
Closing this as part of issue cleanup. If there's anything that needs to be done, please create a new issue.
@austinlparker Can you please reopen it? I do not think creating a new one is a good idea as we would lose the discussion. I think the .NET Automatic Instrumentation SIG may try to address it before KubeCon EU 2024.
CC @open-telemetry/dotnet-instrumentation-approvers
No problem. There's a few places I think would be ideal for this; I might end up putting in a spike together this week for a .NET service that could use the zero-code instrumentation.
@austinlparker, the main blocker for introducing auto-instrumentation is lack of support for ARM64 platform. @RassK is working to cover this in https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/pull/3277.