Configure the Agent Settings for Monitoring Database
This page provides information about the different agent properties that are used for database monitoring. For configuring the basic agent properties, see Database Agent Configuration Properties.
You can update the following properties using the controller-info.xml file
located in the <db_agent_home>/conf directory.
The following table includes the property names that can be used for any specific database or for all the databases along with the purpose of the properties.
Agent Properties for Monitoring Relational Databases
| Property Name | Database | Purpose | Default Value |
|---|---|---|---|
dbagent.disable.sybase.ase.system.monitoring
| Sybase |
This property specifies whether the agent should disable Sybase. You may want to disable Sybase monitoring with Database Visibility if you are already using other tools to monitor Sybase. Refer to Sybase Database Permissions for information on configuring Sybase permissions. If an agent is run with the
| false |
dbagent.sampling.interval
|
All relational database Note: This property can be used for MongoDB and Couchbase.
| This is the interval at which queries are sampled. The interval can be 1s, 2s,
5s, 10s, 20s, or 30s. For example, if you have configured the property value as
2 , Elapsed Time is displayed for 2s, 4s, 6s, and so on (in the
multiples of 2). | 1 |
dbagent.postgresql.database.size.fetch.timeout.in.hrs
| PostgreSQL | This specifies the frequency of collecting the database size statistics for each Postgres SQL collector. This property is required for the environment where you monitor a Postgres SQL database that includes large number of objects. If the value of this property < 1, then the collector does not fetch the value for the size metric. | 1 |
Agent Properties for Monitoring Cassandra
| Property Name | Purpose | Default Value |
|---|---|---|
dbagent.cassandra.sampling.interval.seconds
|
The interval at which queries are sampled. According to the sampling interval (between 1 and 60), the sampling threshold is set (between 300 ms and 1000 ms). | 10 |
dbagent.cassandra.max.query.execution.time.seconds
|
Maximum query execution time. Queries executing for more than this duration are not be sampled. | 300 |
dbagent.cassandra.query.sampling.limit
|
The maximum number of queries to sample in a single sampling period. If this value is 0, query sampling is disabled. | 100,000 |
dbagent.cassandra.dse.skip.slow.query.table.for.sampling
|
Whether to use sampling from query traces instead of the node_slow_log table for DSE Cassandra. | false |
dbagent.cassandra.apache.sampling.threshold.in.milliseconds
|
Defines the sampling threshold for Apache Cassandra. In other words, queries
taking more than this threshold to execute, are sampled by the database
agent.
Note: This property sets a fixed sampling threshold. To use a dynamic sampling
threshold based on the sampling interval set a negative value to this
property.
|
-1 |
Agent Properties for Monitoring Oracle
These properties can be used to prevent the session related issues.
A session in a database is a server-side resource that is created and managed by the server. The clients, such as Database Agent, can only request for the sessions. The Oracle database server creates sessions to handle client requests. If a client cannot reach the database server, the request to close the session will not be delivered. A bug or an unusual behavior within third-party libraries, such as the JDBC driver or connection pool library, can lead to session issues like session buildup. The database server is required to close idle sessions to free up resources. This is where the database user profile and resource constraints become useful. See Guidelines for Oracle Database Monitoring
| Property Name | Purpose | Default Value |
|---|---|---|
dbagent.database.session.control.enabled
| Enable session count for the monitoring user before starting the collector. | false |
dbagent.database.session.count.check.interval.in.mins
| The interval (in minutes) during which the database count is fetched. No new session count is fetched until this interval is completed. | 45 minutes |
dbagent.database.default.session.count.max
| The maximum number of sessions allowed before the collector starts. The collector will not start if the session count increases this value. The session count limit is at the node level. | 50 |
dbagent.database.default.session.count.max), the collector will not start. The session count check is repeated after the configured interval (as specified in dbagent.database.session.count.check.interval.in.mins).dbagent.database.session.control.enabled property to true at agent startup.Guidelines for Oracle Database Monitoring
Connection Stability between Database Agent and the database instance: The connection between the Database Agent and the database instance being monitored must remain stable. In case of connectivity issues, the Database Agent will attempt to reconnect to the database instance, which is a resource-intensive process.
Frequent connectivity issues may lead to the creation of excessive sessions because requests from the Database Agent to close the already active connections may not reach the database.
- Oracle Database User Account Configuration: The Oracle database user account, which is the AppDynamics Account, used for monitoring should not be mapped to the
DEFAULTprofile. A dedicated profile should be created for the AppDynamics account, with the following resource limits:Resource Name Minimum Value Maximum Value Description Caution SESSIONS_PER_USER 20 30 To limit the maximum sessions that are allowed for the user. To limit the resource utilisation. When limit reaches, any session request will be discarded by the database. This may lead to data gaps in monitoring. However, in ideal scenario, more than 8 to 10 sessions is not required by Database Agent. IDLE_TIME 5 10 To cleanup the idle session that are open due to network issue or termination of Database. See https://oracle-base.com/articles/misc/clearing-down-old-database-sessions This is only for suggesting the database to cleanup the resource and not a complete cleanup. It is the responsibility of the database server to schedule the cleanup when the limit is reached.