How does this Dynatrace extension collect data from my databases?
This extension will run from your Dynatrace ActiveGates and connect to the configured databases. Once the connection has been established, the extension will regularly run queries on the database to gather performance and health metrics, reporting the results back to Dynatrace.
Only SELECT
queries are executed to collect data, and the vast majority of these will be selecting GV$
or V$
views. To see exactly which queries are executed, please download the extension yaml
artifact by going to Release notes, opening a release and pressing the Download version
button.
How often are these monitoring queries executed?
From version 3.2.0
onwards, query execution frequency is controlled by the configuration variables query-interval
and heavy-query-interval
. Most of the queries executed by the extension will run every query-interval
minutes (with a default of 1 minute), while the queries under
asm (detailed)
tablespaces
tablespaces (detailed)
Blocked sessions
TopN
will run every heavy-query-interval
minutes (with a default of 5 minutes).
For older versions, most queries run every minute, with exceptions for the heavy queries mentioned above, which run every 5 minutes.
How do I adjust query timeout?
By default, the extension's monitoring queries will timeout after 10 seconds. For a couple of selected queries, the long-running-query-timeout
variable allows you to specify, in seconds, the timeout for the queries in the following feature sets:
asm (detailed)
tablespaces
tablespaces (detailed)
TopN
What is the difference between Feature set
and Feature set (detailed)
The following feature sets have both a regular version and a detailed versions. These can be enabled or disabled in accordance to your specific use-case:
asm
and asm (detailed)
- Due to the high license consumption associated with monitoring thousands of ASM disks, the
asm
feature set captures only ASM disk group data, while the asm (detailed)
feature set captures data for all disks. Both feature sets can be enabled at the same time.
waitEvents
and waitEvents (detailed)
- To control license consumption, the
waitEvents
feature set will collect wait time metrics aggregated by wait class, while the waitEvents (detailed)
feature set collects metrics for the top 20 wait events.
tablespaces
and tablespaces (detailed)
- Due to high the CPU consumption caused by joining tablespace metrics with datafile data, the
tablespaces
feature set does not collect the com.dynatrace.extension.sql-oracle.tablespaces.allocatedSpace
metric coming from CDB_DATA_FILES
(which tablespaces (detailed)
does). Furthermore, the tablespaces
feature set only collects data for tablespaces with more than 50% used space (as reported by CDB_TABLESPACE_USAGE_METRICS
), while the tablespaces (detailed)
feature set collects metrics for all tablespaces. Only one of these feature sets should be enabled at any given time.
Why am I missing Dataguard metrics?
For some of the Dataguard metrics, not seeing any data is the correct behavior and it means the Data guard deployment is working as expected. The following metrics will only show datapoints in case there are issues which need further investigation:
- NOLOGGING activity will record a metric datapoint whenever there are operations executed against the database which will not generate redo log records. This requires investigation because from a Data guard perspective the mechanism is completely bypassed when such activity occurs, leaving the standby vulnerable until these files are manually refreshed.
- Dataguard severe events will record a metric datapoint whenever Data guard reports a fatal or severe event. In such a situation, the metric dimensions will carry the event message/description which should be further investigated on the Database instance.
- Archive destination status will record a metric datapoint whenever the Database's archive destinations are reporting an Invalid or Error status. The metric dimensions will show a description of the status as well as point to the archive destination which reported the error.
Why am I missing CPU usage metrics?
The com.dynatrace.extension.sql-oracle.cpu.backgroundTotal
and com.dynatrace.extension.sql-oracle.cpu.foregroundTotal
metrics are collected from the GV$METRIC
view filtering by metric group name System Metrics Long Duration
(Group ID 2). Since metrics for this group are only populated at the CDB level, these two metrics will only be collected when the extension is configured to connect to the CDB and not the PDB.
If you are missing these two metrics, please double-check your connection configuration and ensure that the extension configuration is pointing to the CDB.
Why do I see duplicate entities?
When monitoring RAC setups, node discovery is done automatically based on the data collected from the GV$ views. The monitoring configuration should be configured only for the listener in front of the cluster, and not for each individual cluster node. If you are seeing duplicate clusters or nodes, please ensure that you have configured the extension to connect to the cluster listener, and not to each individual node.
Also, confirm that the extension is configured to connect to the CDB, and not the individual PDBs.
Why am I not seeing my databases?
When there is no data at all for a whole database, the most likely scenario is that there was some problem in the connection between the ActiveGate and the database server to be monitored.
-
First, ensure that the connection details (hostname/IP, port, service name/SID) were correctly configured and that the user account provided to the extension has the permissions to establish a session.
-
Next, confirm that a connection can be established from the ActiveGate server to the Database server, and that there are no firewalls blocking the connection. Use the Dynatrace DB connection check tool, to ensure the JDBC can establish a connection.
If you are missing data only for a specific metric, or set of metrics, it may be a problem related to the permissions granted to the user account. Please ensure that all the required permissions highlighted on the Hub tile are provided. The ActiveGate logs will also indicate if an error occurred during the execution of monitoring query.
In some cases, a missing metric might indicate the extension was not properly configured (CDB vs. PDB, for example). Given that some metrics work on the CDB level, not the PDB – it can cause confusion. Please double-check your connection configuration and ensure that the extension configuration is pointing to the CDB, as mentioned above.
Where do I look for diagnostic logs?
You can find detailed error messages in the ActiveGate logs. Most logs can be found under the ActiveGate logs directory on the server itself.
- Alternatively, directions on how to collect diagnostics remotely which include relevant logs, is described in the documentation here.