Unable to instrument system calls in backends for .NET agent
Article ID: 187685
Updated On:
Products
CA Application Performance Management Agent (APM / Wily / Introscope)
CA Application Performance Management (APM / Wily / Introscope)
INTROSCOPE
DX Application Performance Management
Issue/Introduction
Trying to enable System at x.x.x.x backend calls for a .NET agent(tried enabling in webservices.pbd).
Can see the calls made to DB but unable to see the system calls for the same.
Please suggest any check list to instrument the same.
Environment
Release : 10.7.0
Component : APM Agents
Cause
Unknown, document is created for suggested areas of investigation. These areas can be mostly used for Java Agent as well
Resolution
For .NET agents, Socket Tracing is defined in dotnet.pbd. This is the source of metrics of type "Sockets|Client/Server|Host|Port"
Check if the call expected as a backend is already reported under Sockets metrics. If it isn't there, it has not been identified as a socket call.
In the traditional view of agents, having a socket call as a backend, this means that the same application thread that is detected as a Frontend, has, itself, opened a socket connection.
That socket connection can be database or it can be any other sort of remote call, HTTP, TCP, whatever.
If it is not the Frontend thread that opens the socket, then you cannot necessarily expect to see a Backend socket call.
Suggested areas of investigation:
If using a recent version of .NET agent, particularly 10.7, the metric clamp is set to 5000 in IntroscopeAgent.profile
introscope.agent.metricClamp=5000
When the clamp is active, metrics expected to show will not be reported.
Check if the call expected as a backend is already reported under Sockets metrics. If it isn't there, it has not been identified as a socket call.
In the traditional view of agents, having a socket call as a backend, this means that the same application thread that is detected as a Frontend, has, itself, opened a socket connection.
That socket connection can be database or it can be any other sort of remote call, HTTP, TCP, whatever.
If it is not the Frontend thread that opens the socket, then you cannot necessarily expect to see a Backend socket call.
Suggested areas of investigation:
If using a recent version of .NET agent, particularly 10.7, the metric clamp is set to 5000 in IntroscopeAgent.profile
introscope.agent.metricClamp=5000
When the clamp is active, metrics expected to show will not be reported.
With caution, raise the clamp level in multiples of 5000 (this can be a lower or larger amount) but the application needs to be restarted for this to take effect. Do not raise the clamp any higher than necessary as it leads to latency of monitored application and increased load on Enterprise Manager
If a clamp is active, check for a message such as this in the IntroscopeAgent.<application name>log
[WARN] [IntroscopeAgent.Agent] Absolute metric clamp of nnnnn reached, no more metrics can be created. Instrumentation on this application should be reduced.
If using the Introscope Workstation, the APM Status Console would also give details of any active clamps.
Beyond this, it will be more complicated and require understanding of the application itself.
The agent does not, by default monitor a connection pool, so if the connection is not a direct socket but a request to a connection pool, this will not be instrumented.
The closest is connection tracking to get a database connection count
IdentifyInheritedAs: System.Data.IDbConnection SQLAgentConnections
IdentifyInheritedAs: System.Data.Common.DbConnection SQLAgentConnections
To instrument a particular connection pool technology, user would have to know the assembly/method names and try to create instrumentation for it.
If a clamp is active, check for a message such as this in the IntroscopeAgent.<application name>log
[WARN] [IntroscopeAgent.Agent] Absolute metric clamp of nnnnn reached, no more metrics can be created. Instrumentation on this application should be reduced.
If using the Introscope Workstation, the APM Status Console would also give details of any active clamps.
Beyond this, it will be more complicated and require understanding of the application itself.
The agent does not, by default monitor a connection pool, so if the connection is not a direct socket but a request to a connection pool, this will not be instrumented.
The closest is connection tracking to get a database connection count
IdentifyInheritedAs: System.Data.IDbConnection SQLAgentConnections
IdentifyInheritedAs: System.Data.Common.DbConnection SQLAgentConnections
To instrument a particular connection pool technology, user would have to know the assembly/method names and try to create instrumentation for it.
Getting those metrics to show as backends would then take further work, which is beyond the scope of this article.
Further suggestion to look at transaction traces for the application, particularly where the calls to the database are seen.
They should show the Frontend and Backend in the same trace, look for details in the transaction trace in summary view or trace view to see if any socket communications have been traced.
The last point would be to review the AutoProbe and nativeprofiler logs to see which classes/methods are already instrumented, and, which tracers are inserted into them. Confirm there are tracers with reference to Backend in Socket calls.
Further suggestion to look at transaction traces for the application, particularly where the calls to the database are seen.
They should show the Frontend and Backend in the same trace, look for details in the transaction trace in summary view or trace view to see if any socket communications have been traced.
The last point would be to review the AutoProbe and nativeprofiler logs to see which classes/methods are already instrumented, and, which tracers are inserted into them. Confirm there are tracers with reference to Backend in Socket calls.
Feedback
Yes
No
Powered by
