AppDynamics switched from Semantic Versioning to Calendar Versioning starting in February 2020 for some agents and March 2020 for the entire product suite.

    Skip to end of metadata
    Go to start of metadata

    You are viewing an old version of this page. View the current version.

    Compare with Current View Page History

    Version 1 Next »

    On this page:

    Related pages:

    Your Rating:
    1 Star2 Star3 Star4 Star5 Star
    6 rates

    Components of Database Visibility

    AppDynamics Database Visibility consists of four main components: 

    1. Database Agent
    2. Collector
    3. Controller
    4. Events Service (on-premises only)

    Database Agent

    The AppDynamics Database Agent is a standalone Java program that collects performance metrics about your database instances and database servers. A database agent running on a typical machine with 16 GB of memory can monitor about 25 database instances. On larger machines, a database agent can monitor up to 200 database instances. To monitor 100+ database instances, increase the initially allocated heap size for the Database Agent JVM. 

    You can deploy the Database Agent on any machine running Java 1.7 or higher. The machine must also have network access to the AppDynamics Controller and the database instance that you want to be monitored. 


    The Database Agent Collector is the process that runs within the Database Agent to collect performance metrics about your database instances and database servers. One Collector collects metrics for one database instance. Multiple collectors can run in one Database Agent.

    AppDynamics Database Visibility detects when a database backend has matching credentials with a database server being monitored by a Collector. Database Visibility automatically associates the backend with the collector, so you can view its performance with the Application Flow Map, Tier Flow Map, or Node Flow Map.


    The Controller is the central interface where you can see all your database instance and database server performance metrics. 

    The following types of information are sent to the Controller:

    • Database-level metrics, such as number of queries processed and other database statistics
    • Names and attributes of all sessions, clients, queries, and other objects on the monitored system

    Events Service

    If you are using the on-premises version of Database Visibility, you must install the Events Service, which stores high volumes of metric data.

    The following types of information are sent to the Events Service:

    • The time each query spends in each wait state
    • Individual query statistics for databases that support it
    • Information about individual execution plans in databases that support it

    • No labels