You can control the data captured in call graphs with the Call Graph Settings panel.
To configure call graph settings, you need the Configure Call Graph Settings permission.
Call Graph Granularity
To control the granularity for call graphs, use the following settings:
- Control granularity for Methods: To ensure low-performance overhead, choose a threshold in milliseconds for method execution time. Methods taking less than the time specified here are filtered out of the call graphs.
- Control granularity for SQL calls: You can specify a threshold for SQL queries. SQL queries taking less than the specified time in milliseconds are filtered out of the call graphs. See Tune Java Agent Performance.
Only SQL Capture Settings apply to call graph configuration for the Node.js agent.
To access call graph configuration, click Configuration > Instrumentation and choose the Call Graph Settings tab. There are subtabs for each application type.
Exclude Packages or Namespaces from Call Graphs
A call graph can potentially contain hundreds of methods. You can exclude packages (Java) or namespaces (.NET) with classes that you do not want to monitor.
For Java, some packages are excluded by default. These are visible in the Excluded Packages list. The packages that are excluded by default cannot be removed. However, you can include a particular sub-package from an excluded package.
You can customize call graph instrumentation from the call graph instrumentation page. From there, choose from these configuration options:
- Use the Add Custom Package Exclude (Java) or Add Custom Namespace Exclude (.NET) configuration options to exclude specific packages or namespaces from call graphs.
- Use the Add Always Show Package/Class (Java) or Add Always Show Namespace/Class (.NET) configuration options to have a package or namespace always shown in call graphs.
When the Controller constructs a call graph it uses excluded packages and included sub packages to determine which calls to include. However, the Controller includes some calls even if they are listed among the excluded packages. For example, web service calls.
SQL Capture Settings
The SQL capture settings control whether SQL statements are captured and presented in the Controller UI with dynamic parameters bound to their runtime values. For example, consider Java code that constructs a SQL call as follows:
stmt = new PreparedStatement("select * from user where ssn = ?")
With the capture raw SQL option enabled, AppDynamics captures and presents the SQL call in the following form:
select * from user where ssn = '123-123-1234'
If capture raw SQL is disabled, the SQL call appears in its original form, with question mark parameters not bound to values. Disabling capture-raw-sql and using question mark parameters in SQL prepared statements gives you a mechanism for preventing sensitive data from appearing in the Controller UI.
It is important to note that the sensitive values must be parameterized in the original, prepared statement form of the SQL statement, as shown above. The following statement results in the potentially sensitive information (social security number) appearing in the Controller UI whether capture raw SQL is enabled or disabled since the sensitive data is not parameterized.
stmt = new PreparedStatement("select * from user where ssn ='123-123-1234'")
To configure SQL capture settings, in the Call Graph Settings tab, scroll down to the SQL Capture Settings section and choose one of the following options:
Capture Raw SQL: Select this option to have SQL statements that are composed as prepared statements captured with dynamic parameters bound to runtime values. By default, private SQL data and queries that take less than 10 ms are not captured.
You can select this option to capture raw query details for NoSQL databases such as MongoDB, DynamoDB, and CassandraDB and the relational queries will not be scrubbed.
When you enable Capture Raw SQL in .NET environments, the agent captures the parameters for ADO.NET stored procedure calls even though the parameters are not represented by question marks. It does not capture stored procedure local variables that are not available to the CLR.
- Filter Parameter values: Select this option to have SQL statements that are composed as prepared statements captured without dynamic parameters bound to runtime values.