v0.10.0 seems to have broken the configuration

[woutersmit]

Describe the bug
v0.10.0 seems to have broken the configuration

To Reproduce
Steps to reproduce the behavior:

1. Upgrade to 0.10.0
2. Append '-log.level debug'
3. Start app
4. See error

ts=2023-03-27T12:05:07.792Z caller=klog.go:108 level=warn func=Warningf msg="Starting SQL exporter (version=0.10.0, branch=HEAD, revision=3e9475ff001b3ab1c246ac97892e1f9cd02bd364) (go=go1.20.1, platform=linux/amd64, user=root@buildkitsandbox, date=20230228-23:45:09)"
ts=2023-03-27T12:05:07.792Z caller=klog.go:84 level=debug func=Infof msg="Loading configuration from /etc/sql_exporter/sql_exporter.yml"
ts=2023-03-27T12:05:07.793Z caller=klog.go:84 level=debug func=Infof msg="Loaded collector 'mssql_standard' from /etc/sql_exporter/collectors/mssql_standard.collector.yml"
ts=2023-03-27T12:05:07.795Z caller=klog.go:143 level=error func=Fatalf msg="Error creating exporter: unknown collector \"mssql_standard\" referenced in target"

Expected behavior
Run with configuration loaded.

Configuration
Take example configuration

[mkaindl]

May I ask why you closed this issue? I encounter the same bug. More explicitly, it seems to be triggered as soon as there is more than one targets.collectors item configured. This is probably a regression introduced by #194.

[woutersmit]

I had multiple issues with upgrading to v0.10.0. Finally found a workaround but forgot to re-open this issue. It is definitely something with globbing and multiple collector files.

To workaround this issues I had to:

• Split up customized collector files in different directories
• Prefix name of customized collector with 'mssql_'

sql_exporter.yml

    target:
      collectors: [mssql_*]

    collector_files: 
      - "mssql_standard.collector.yml"
      - "directory/another.collector.yml"

directory/another.collector.yml

collector_name: mssql_another_collector

[burningalchemist]

@woutersmit @mkaindl

Hi folks, I'll have a look into the issue. Could you please provide any additional details or error logs if there are any? Thanks! 🙂👍

Please file any other issues as well. If you're affected by the release, I'd suggest staying in 0.9 version for the time being.

[mkaindl]

Hi @burningalchemist, thanks a lot for looking into this.

Reproduction of the bug

• Configuration in prometheus-sql-exporter.yaml:

target:
  data_source_name: "mysql+unix://user:password@/var/lib/mysql/mysql.sock/db"
  collectors: [collector_a, collector_b]

collectors:
  - collector_name: collector_a
    metrics:
      - metric_name: sql_collector_debug_a
        type: gauge
        help: Overall number of tables in the DB.
        values:
          - total_number_of_tables
        query: |
          SELECT count(*) AS total_number_of_tables
          FROM INFORMATION_SCHEMA.TABLES

  - collector_name: collector_b
    metrics:
      - metric_name: sql_collector_debug_b
        type: gauge
        help: Overall number of tables in the DB.
        values:
          - total_number_of_tables
        query: |
          SELECT count(*) AS total_number_of_tables
          FROM INFORMATION_SCHEMA.TABLES

• Result: the exporter fails to start.
• Debug log:

{"caller":"klog.go:108","func":"Warningf","level":"warn","msg":"Starting SQL exporter (version=0.10.0, branch=HEAD, revision=3e9475ff001b3ab1c246ac97892e1f9cd02bd364) (go=go1.19.6, platform=linux/amd64, ..."}
{"caller":"klog.go:84","func":"Infof","level":"debug","msg":"Loading configuration from /etc/prometheus-sql-exporter/prometheus-sql-exporter.yaml","ts":"2023-04-13T10:16:45.034Z"}
{"caller":"klog.go:143","func":"Fatalf","level":"error","msg":"Error creating exporter: unknown collector \"collector_a\" referenced in target","ts":"2023-04-13T10:16:45.034Z"}

Workaround

Replace [collector_a, collector_b] by [collector_*]. The bug only seems to be triggered when targets.collectors contains more than one element.

Suspected root cause

I am unfortunately not at all familiar with Go, but maybe the problem could be close to here? To me it seems like this implementation returns an error immediately after any of the collector keys k does not match the current cref, when instead it should be checking all the collectors first.

[burningalchemist]

@mkaindl Perfect, thanks for the info, that's all I need. I'll reproduce the bug and make sure it's fixed. 👍 Stay tuned, and sorry for the inconvenience. :)

[mkaindl]

I just stumbled upon PR #208 which looks like it addressed exactly this issue!
So there is probably nothing more to do and it will be fixed with the next release 🙂

[hhromic]

Hello all, I'm really sorry for the inconvenience caused.
I'm the author of the globbing support PR which introduced this issue. As mentioned, PR 208 should resolve the oversight in my implementation. Apologies! :(

[burningalchemist]

@woutersmit @mkaindl The issue has been fixed, I'm going to create a patch release today, and it would great to get your feedback. 🙂👍

[burningalchemist]

The v0.10.1 release is here, please check it out. 👍

[mkaindl]

@hhromic no worries, thank you for your contribution! I just saw that you added tests to catch such issues earlier next time, that's great.

@burningalchemist thanks a lot for the quick patch release! I can verify that v0.10.1 works fine in my setup.