[BUG] only last serie exposed between scrap when metric.scrapInterval is higher than global scrapInterval

[MansuyDavid]

Description

when metrics have a greater scrap interval than the global scrap interval, AND they create several series => The exporter only expose the last serie if last database scrapp was done without this metric.

Steps to Reproduce

I have a global scrap interval of 1m.
and one metric that has a scrap interval of 5m
this metric generate several series (label "table_name" is different between each serie)
example of config :

#oracledb_metric_check_purge
  - context: metric_check
    labels:
      - table_name
    request: |
      select table_name, purge from infogerance.oracle_metric_check_purge
    metricsdesc:
      purge: check purge by table
    scrapeinterval: 5m
    querytimeout: 30s
    databases: ['oracle_PROD_1']

result of the request is :

when i call REST api of the exporter after the request is done i get

# HELP oracledb_metric_check_purge check purge by tables
# TYPE oracledb_metric_check_purge gauge
oracledb_metric_check_purge{database="oracle_PROD_1",table_name="AMD_PALLET_LABEL"} 0 
oracledb_metric_check_purge{database="oracle_PROD_1",table_name="AMD_PRINTED_TRACKING_LABELS"} 0
oracledb_metric_check_purge{database="oracle_PROD_1",table_name="AMD_SHP_LABEL"} 0 
[...]
oracledb_metric_check_purge{database="oracle_PROD_1",table_name="MFC_MM_TRACE_DETAIL"} 0 

when I call REST api of the exporter, after a scrap where this metric was not executed, only the "last" serie is given :

# HELP oracledb_metric_check_purge check purge by tables
# TYPE oracledb_metric_check_purge gauge
oracledb_metric_check_purge{database="oracle_PROD_1",table_name="AMD_PRINTED_TRACKING_LABELS"} 0

This is the "last" serie regarding the result of the SQL request, but prometheus expose metrics alphabetically ordered.

Expected Behavior

always see all series of the metric, no mater when i called the REST api of the exporter

Environment

• OS: docker
• Oracle Database version: no mater
• Exporter version: 2.1.0

[anders-swanson]

Ahhh, I think I know the problem. We aren't caching the metric properly for this scenario. Thanks for reporting this.

[anders-swanson]

The scrape cache is changed from a map of metric fqdn -> metric to a slice of metrics - the fqdn was not unique key :)