anders-swanson
commented
2 months ago @priyanshishah-oracle multiple custom metrics files can be supplied in a comma separated list:
CUSTOM_METRICS=custom-metrics-example/custom-metrics.toml,custom-metrics-example/metric-dual-example.toml
Documentation updated accordingly, no code change was required: https://github.com/oracle/oracle-db-appdev-monitoring?tab=readme-ov-file#custom-metrics
1. Timeout granularity:
Some SQL statements will have longer runtimes or higher volatility in runtimes. These longer runtimes might be across the board, or just on a subset of host environments with certain characteristics (e.g. orders of magnitude more tablespaces on certain hosts/applications can impact tablespace infrastructure focused queries). As the number of queries in a config file grows, the current solution of increasing the timeout for every query in the config file has the potential issue of allowing the confg file to run very, very long. It is allowed to run up to the timeout value for every SQL statement. A few ways this could be dealt with include:
These potential solutions are not exclusionary and each provides different benefits.
2. Frequency of SQL statement execution:
Some SQL statements do not need to be executed as frequently as others. Many need to be run at the typical 3 minute scrape frequency. Others might need to be run only once every 30 minutes. Being able to account for these differences would reduce load on the hosts. Possible solutions include: