Capturing Unrecognized ADO.NET Calls With Custom Instrumentation

[Sean.Stanford]

Catching missing ADO.NET backend calls with custom instrumentation

Use Case

You are a developer, AppDynamics administrator, or application owner who is interested in capturing a full call stack involving ADO.NET that may be missing visibility into some exit calls.

Background

This issue mainly occurs with Oracle database backend calls but has been seen in calls to other database types such as MSSQL and DapperDB. This may also occur on other types of ADO.NET database backend calls, but those were not encountered during research for this article. The specific issue being covered here occurs when an ADO.NET method exit call requests a database-specific method such as Oracle.DataAccess.Client.OracleDataAdapter:Fill that internally invokes a method that we detect normally such as Oracle.DataAccess.Client.OracleCommand:ExecuteReader. 

Depending on how the transaction flows, we may not register the call to the ExecuteReader native method without custom instrumentation as well. The .NET agent does not catch the call to ExecuteReader (or another internally called method) that results in the exit call to the database instance. This results in some call stacks that expose the database backend and queries flowing to it, while other call stacks only show exit calls to ExecuteReader and nothing is exposed for the DataAdapter call. With the proper custom instrumentation in place, we can retrieve both the exit calls and the SQL queries involved in call stacks going forward.

Other Possible Causes

You may have inadvertently assigned the backend that resolves to the database in question to an incorrect tier under Tiers/Actions/Backends Resolving To This Tier. If this is the case, simply delete the backend in question from the Resolve To Tier configuration and you should see it start to populate on the correct tier. This may also happen if you are making a WCF (Windows Communication Foundation) exit call using a TCP binding. If this is the case, you may need to enable the enable-soap-header-correlation node property and restart the agent coordinator service. This can also result from improperly instrumented asynchronous transactions. Please see Asynchronous Transaction documentation at docs.appdynamics.com to correct this:

• Asynchronous Exit Points for .NET
• Asynchronous Transaction Demarcators
• Diagnostic Sessions

Targeted Resolution

In the following steps, we will be using the Oracle methods mentioned above. To resolve this issue, you must configure a custom exit point with a split transaction, as well as some custom data for the transaction snapshot section as follows:

1. Enter the Application view for the affected application.
   
   
2. Select Configuration, then Instrumentation.
   
   
3. From the Backend Detection menu, select .NET from the top menu. Then select ADO.NET from the Automatic Backend Discovery menu.
   
   
4. Select the + symbol below Custom Exit Points.
   
   
5. Fill in the needed Name, Type, Class, Is This Method Overloaded checkbox (if needed), and Parameter entry if needed.
   
   
6. Next, proceed to the "Calls to the specified class and method name can be further split based by a combination of method parameters and return value" section. Add a custom exit point identifier with the appropriate configuration like this example.
   • Display Name - Database
   • Collect Data From – Invoked Object
   • Operation on Invoked Object – DbConnection.Database
     
     
     

7. Next, configure Snapshot Data based on the following example:
   • Display Name – CommandText
   • Collect Data From – Invoked Object
   • Operation on Invoked Object -  CommandText 
     

Conclusion

Once this configuration is complete, all calls to the backend in question as well as the Command Text (for this example this should be the SQL query issued to the backend) should begin to appear in the call graphs in the Transaction Snapshots for any Business Transactions making calls to the method specified in the above configuration. This can be repeated for any ADO.NET backends that are missing calls in the call graph section of a Transaction Snapshot. Please contact AppDynamics Support for any further issues or concerns.