[FEATURE] config "metric.databases= [ ]" => don't use metric on any database

[MansuyDavid]

Summary

Having the possibility that some metric defined in default-metrics or custom-metrics will not run in any database.
By using "metric.databases=[ ]"

Motivation

I have a automatic deployment of this exporter (with Ansible) with predefined config files.
Because of multiple databases version that can be scrapped i need to execute some queries on some db and others queries on others db.
For example
Request 1 : to execute on oracle 19
Request 2 : to execute on oracle 12

some of my customers have only one version.
so if i can have the same metric config file, with just the "databases" attribute empty for the non needed version, it will be easier to manage it.

Proposed Solution

use the existing metric.databases attribute.
no change : if not defined, metric will be used for all db
no change : if defined "not empty", metric will be used on listed db
change asked : if defined "empty", metric will be used on no db.

Alternatives Considered

This problem is bypassed today by having the whole [[metric]] bloc not written when no db execution is needed.
But this make the ansible template in jinja2 a lot heavier/ugly/difficult to maintain.

Additional Context

[anders-swanson]

Hi @MansuyDavid, interesting to hear you're using the exporter against 12c :)

I'm not opposed to this, but would like to hear why removing the metric entirely isn't a good enough solution. Another option we've been considering is allowing databases to include their own metric files, but this may cause some other confusion.

For example (and this is just an example, it is not implemented)

databases:
  mydb:
    metrics: [mydb.toml]

[MansuyDavid]

If you want to know we still have one customer with 11c 😉

why removing the metric entirely isn't a good enough solution

In fact this is a good solution when looking at the exporter only.
But all the exporters i use (17 today) are configured in automatic from a "template" by Ansible.
so i need to tell ansible to "not write this blocks if foo var is empty"

Here is an example with and without this new feature for 4 types of db (prod/test ; 12/19) (but i in real life i have about 6-8 types of DB);

Template with the new feature :

[[metric]]
....
databases = [ {{ databases_production_version_12 }} ]
...
[[metric]]
....
databases = [ {{ databases_test_version_12 }} ]
...
[[metric]]
....
databases = [ {{ databases_production_version_19 }} ]
...
[[metric]]
....
databases = [ {{ databases_test_version_19 }} ]
...

Template without the new feature :

{% if databases_production_version_12 is defined and databases_production_version_12 | length > 0 %}
[[metric]]
....
databases = [ {{ databases_production_version_12 }} ]
...
{% endif %}
{% if databases_test_version_12 is defined and databases_test_version_12 | length > 0 %}
[[metric]]
....
databases = [ {{ databases_test_version_12 }} ]
...
{% endif %}
{% if databases_production_version_19 is defined and databases_production_version_19 | length > 0 %}
[[metric]]
....
databases = [ {{ databases_production_version_19 }} ]
...
{% endif %}
{% if databases_test_version_19 is defined and databases_test_version_19 | length > 0 %}
[[metric]]
....
databases = [ {{ databases_test_version_19 }} ]
...
{% endif %}

You see how the readability and maintainance of that is harder. that's why i wish this feature.

[anders-swanson]

OK, that makes sense. Semantically, it seems correct that an empty database array would mean scrape from no databases, so I'm not opposed. It's a minor logic change that we can add in the next release.

[MansuyDavid]

Hello,

It seems that this created a side effect.
when context is the same for 2 request the second overrides the first (but perhaps it's not a bug but a feature?)

metrics:
#oracledb_database_status
#oracledb_database_log_mode
#oracledb_database_current_scn
  - context: database
    labels:
      - server_name
      - database_name
      - db_role
      - open_mode
      - edition
      - version_full
    request: |
      SELECT ... -- specific for version 19 and above
      from ...
    metricsdesc:
      status: database status
      log_mode: log mode for database
      current_scn: current scn for database
      last_applied: last applied sequence.
    ignorezeroresult: true
    databases: ['oracle_PROD_1', 'oracle_STDBY_1', 'oracle_TEST_1', 'oracle_RECETTE2_1', 'oracle_MASSTEST_1']
##############################################
#oracledb_database_status
#oracledb_database_log_mode
#oracledb_database_current_scn
#oracledb_database_last_applied
  - context: database
    labels:
      - server_name
      - database_name
      - db_role
      - open_mode
      - edition
      - version_full
    request: |
      SELECT ... --specific for version 11 or 12
      FROM ...
    metricsdesc:
      status: database status
      log_mode: log mode for database 
      current_scn: current scn for database
      last_applied: last applied sequence.
    ignorezeroresult: true
    databases: []

with this example, the exporter do not expose oracledb_database_status and others.
But if i change the second context, the exporter expose oracledb_database_status and others.

It seems that if i keep the same context, but add one of the db in the second list, all is well exposed (and the db in double is shown in double as the labels are a little different)

I don't get the logic behind, but you will know it better i think.

[anders-swanson]

A metric with the same context and description won't be considered unique unfortunately by the exporter, let me see if I can adjust that so metrics like these are considered unique.