The Call Graph Settings window enables you to configure settings that affect what data is captured in call graphs.
Call Graph Granularity
You can control the granularity for call graphs for the following agents:
- Java Agent
- .NET Agent
- PHP Agent
- Node.js Agent (SQL Capture Settings only)
To control the granularity for call graphs use 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 more than the specified time in milliseconds are filtered out of the call graphs. Also see Tune Java Agent Performance.
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.
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:
With the capture raw SQL option enabled, AppDynamics captures and presents the SQL call in the following form:
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 give 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.
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.
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.
Aggressive Slow Snapshot Collection
AppDynamics monitors the entire course of every transaction, but for those transactions not monitored as part of a diagnostic session or subject to periodic snapshot collection, it retains the call graph segments only after it detects that the transaction is a performance outlier. That is, the transaction has exceeded a slow or stalled transaction thresholds or has experienced an error. Snapshots collected as part of a diagnostic session or as a result of periodic collection have the complete call graph.
With aggressive snapshot collection, however, AppDynamics also retains selected call graph segments that preceded detection of a slow, stall or error transaction condition. These snapshots are labeled as hot spot snapshots in the Call Graph drill down window (see Call Graphs for more information). A hot spot snapshot is a partial snapshot that includes call graph segments from points that precede the detection of the condition, as a result of aggressive slow snapshot collection.
Aggressive snapshot collection works as follows: AppDynamics analyzes performance data for a transaction over a period of time (the previous five hours, by default) and determines which segments of the call graph are slow relative to others. It retains those selected call graph segments, and includes them if the overall transaction has turned out to be slow, stalled, and an error. This enables you to view the parts of the transaction that may be contributing to the condition.
Aggressive snapshot collection is enabled by default. You can disable it from the instrumentation configuration page.
To access the setting, click go to Configuration > Instrumentation, and open the Call Graph Settings tab. The Enable Aggressive Slow Snapshot Collection option appears at the bottom of the page. Disabling this option removes the availability of hot spot call graphs in transaction snapshots.
This configuration affects snapshot collection at the application level. You can also disable this feature at the node level using the enable-hotspot-snapshots node property. The limit for hotspot snapshots is set at 50 per minute, by default. This is a configurable node property named hotspot-snapshots-per-minute. For information about setting node properties see App Agent Node Properties.