Good day everyone,
We use Elastic APM with dotnet agent for couple of months, it does a great job.
Recently we decided to adopt some third party framework which we cannot change the source code, so I came across to these solution
Profiler Auto instrumentation | APM .NET Agent Reference [1.12] | Elastic
After setting it up in my local, It show only CPU and memory metric in Kibana. At the moment I could not find any video/picture that show the expected output.
Should a trace appear or it only able to get the service metric ?
Thank you for your interest in Elastic APM.
The Metrics overview page which is shown in the screenshot provides agent-specific metrics, which lets you perform more in-depth root cause analysis investigations within the APM app. You can find more information about metrics in the Kibana guide.
Transactions for a particular service should normally be displayed in the Transactions tab.
Thanks for your response, yeah all other service displayed in the transaction tab because we put apm agent inside the startup code.
Btw my point is, does the transaction still captured if use elastic automatic instrumentation approach(no code changes) instead of putting apm agent init inside the startup code (because we don't have access to the third party startup code) ?
There's no example output in the guide Profiler Auto instrumentation | APM .NET Agent Reference [1.12] | Elastic
Note In my example only metric captured
what kind of application do you use?
I think you may run into a limitation of the profiler - which is beta at this point.
I suspect you run an ASP.NET Core app - is my guess correct? If so, then the issue can be that the profiler at this point does not turn on auto instrumentation for ASP.NET Core. And that can be the reason why you don't see the transaction.
Yup, I'm using Asp.net core.
So i it is because beta stage?
After it is in stable state, will automatic instrumentation display the transaction?
So i it is because beta stage?
Yes - or to be specific mainly because so far we did not really focus on this setup with the profiler.
Long term we definitely want to cover this with the profiler - yes.
Could you maybe elaborate on your use case? Because maybe this could be covered without the profiler as well.
Here is specifically what I'd like to understand:
- Is this a whole application where you can't change the source code (and due to that you cant register the agent by adding the required C# code)?
- Or is it about that you use some library which you don't have the source code for and you want visibility into that library (but overall for the app you still have source code, except 1 specific library)?
If it's option 1, then there is another way to register the agent without code change - that's not the profiler based option, but it works similar from the configuration's point of view, here are the details: .NET Core | APM .NET Agent Reference [1.12] | Elastic - this is tested with ASP.NET Core.
We are in scenario 1.
We are using a ready made product and only able to build custom module around it.
So there is another approach, will try that out, thanks for your suggestion
@GregKalapos FYI it works, thanks
I suggest to hide automatic profiler doc temporary if it's not completed yet
This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.