モニタリングデータベースのエージェント設定の構成
このページでは、データベースモニタリングに使用されるさまざまなエージェントプロパティに関する情報を示します。基本的なエージェントのプロパティの設定については、 「データベースエージェントの設定プロパティ」を参照してください。
<db_agent_home>/conf ディレクトリにある controller-info.xml ファイルを使用して、次のプロパティを更新できます。
次の表には、プロパティの目的に合わせて、特定のデータベースまたはすべてのデータベースに使用できるプロパティ名が含まれています。
リレーショナルデータベースをモニタリングするためのエージェントプロパティ
| プロパティ名 | データベース | 目的 | デフォルト値 |
|---|---|---|---|
dbagent.disable.sybase.ase.system.monitoring | Sybase |
このプロパティで、エージェントが Sybase を無効にする必要があるかどうかを指定します。Sybase をモニタするために他のツールをすでに使用している場合は、データベースの可視性を使用した Sybase モニタリングを無効にすることができます。Sybase 権限の構成の詳細については、Sybase データベースの権限を参照してください。 エージェントが
| false |
dbagent.sampling.interval |
すべてのリレーショナルデータベース 注: このプロパティは、MongoDB および Couchbase に使用できます。
| これは、クエリがサンプリングされる間隔です。間隔には、1 秒、2 秒、5 秒、10 秒、20 秒、または 30 秒を指定できます。たとえば、プロパティ値を 2 に設定した場合、[]は、2 の倍数で 2 秒、4 秒、6 秒のように表示されます。 | 1 |
dbagent.postgresql.database.size.fetch.timeout.in.hrs | PostgreSQL | Postgres SQL コレクタごとにデータベースサイズの統計を収集する頻度を指定します。このプロパティは、多数のオブジェクトを含む Postgres SQL データベースをモニターする環境に必要です。このプロパティの値が 1 未満の場合、コレクタはサイズメトリックの値を取得しません。 | 1 |
Cassandra をモニタリングするエージェントプロパティ
| プロパティ名 | 目的 | デフォルト値 |
|---|---|---|
dbagent.cassandra.sampling.interval.seconds |
クエリがサンプリングされる間隔。サンプリング間隔(1 ~ 60)に応じて、サンプリングしきい値が設定されます(300 ~ 1000 ミリ秒)。 | 10 |
dbagent.cassandra.max.query.execution.time.seconds |
クエリの最大実行時間。この期間を超えて実行されるクエリはサンプリングされません。 | 300 |
dbagent.cassandra.query.sampling.limit |
単一のサンプリング期間でサンプリングされるクエリの最大数。この値が 0 の場合、クエリのサンプリングは無効になります。 | 100,000 |
dbagent.cassandra.dse.skip.slow.query.table.for.sampling |
サンプリングを DSE Cassandra の node_slow_log table ではなくクエリトレースから使用するかどうかを決定します。 | false |
dbagent.cassandra.apache.sampling.threshold.in.milliseconds |
Apache Cassandra のサンプリングしきい値を定義します。つまり、このしきい値を超えて実行するクエリは、データベースエージェントによってサンプリングされます。 注: このプロパティで、固定サンプリングしきい値を設定します。サンプリング間隔に基づいて動的サンプリングしきい値を使用するには、このプロパティに負の値を設定します。
|
-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.