Skip to content

Error opening config file "postgres_exporter.yml" #779

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
micheljung opened this issue Mar 24, 2023 · 11 comments · Fixed by #784
Closed

Error opening config file "postgres_exporter.yml" #779

micheljung opened this issue Mar 24, 2023 · 11 comments · Fixed by #784

Comments

@micheljung
Copy link

micheljung commented Mar 24, 2023

docker run --rm quay.io/prometheuscommunity/postgres-exporter:v0.12.0
ts=2023-03-24T18:45:04.199Z caller=main.go:86 level=error msg="Error loading config" err="Error opening config file \"postgres_exporter.yml\": open postgres_exporter.yml: no such file or directory"
ts=2023-03-24T18:45:04.199Z caller=proc.go:250 msg="Excluded databases" databases=[]
ts=2023-03-24T18:45:04.200Z caller=main.go:130 level=error msg="Failed to create PostgresCollector" err="empty dsn"
ts=2023-03-24T18:45:04.200Z caller=tls_config.go:232 level=info msg="Listening on" address=[::]:9187
ts=2023-03-24T18:45:04.200Z caller=tls_config.go:235 level=info msg="TLS is disabled." http2=false address=[::]:9187

According to the readme, this is the config that can be set via --config.file. However, there is no mention of config.file in Flags or Environment Variables.

If this is a problem, I would expect the application to exit. If it's not, as it seems, I would expect this to either be logged as warn or not logged at all.

@MatteoGioioso
Copy link

MatteoGioioso commented Mar 24, 2023

Same issue here, try to use v0.11.1

@sysadmind
Copy link
Contributor

These should be warnings. The collector can now be used as a direct exporter configured to scrape metrics from a single node as well as using the multi-target support through the /probe endpoint. The flags section of the README could also use some housekeeping. Thanks for pointing these out.

@4chEr
Copy link

4chEr commented Apr 3, 2023

docker exec <container> /bin/postgres_exporter --help

usage: postgres_exporter [<flags>]


Flags:
  -h, --[no-]help                Show context-sensitive help (also try
                                 --help-long and --help-man).
      --[no-]collector.database  Enable the database collector (default:
                                 enabled).
      --[no-]collector.bgwriter  Enable the bgwriter collector (default:
                                 enabled).
      --[no-]collector.replication_slot
                                 Enable the replication_slot collector (default:
                                 enabled).
      --config.file="postgres_exporter.yml"
                                 Postgres exporter configuration file.
      --[no-]web.systemd-socket  Use systemd socket activation listeners instead
                                 of port listeners (Linux only).
      --web.listen-address=:9187 ...
                                 Addresses on which to expose metrics and web
                                 interface. Repeatable for multiple addresses.
      --web.config.file=""       [EXPERIMENTAL] Path to configuration file that
                                 can enable TLS or authentication.
      --web.telemetry-path="/metrics"
                                 Path under which to expose metrics.
                                 ($PG_EXPORTER_WEB_TELEMETRY_PATH)
      --[no-]disable-default-metrics
                                 Do not include default metrics.
                                 ($PG_EXPORTER_DISABLE_DEFAULT_METRICS)
      --[no-]disable-settings-metrics
                                 Do not include pg_settings metrics.
                                 ($PG_EXPORTER_DISABLE_SETTINGS_METRICS)
      --[no-]auto-discover-databases
                                 Whether to discover the databases
                                 on a server dynamically.
                                 ($PG_EXPORTER_AUTO_DISCOVER_DATABASES)
      --extend.query-path=""     Path to custom queries to run.
                                 ($PG_EXPORTER_EXTEND_QUERY_PATH)
      --[no-]dumpmaps            Do not run, simply dump the maps.
      --constantLabels=""        A list of label=value separated by comma(,).
                                 ($PG_EXPORTER_CONSTANT_LABELS)
      --exclude-databases=""     A list of databases to remove when
                                 autoDiscoverDatabases is enabled
                                 ($PG_EXPORTER_EXCLUDE_DATABASES)
      --include-databases=""     A list of databases to include when
                                 autoDiscoverDatabases is enabled
                                 ($PG_EXPORTER_INCLUDE_DATABASES)
      --metric-prefix="pg"       A metric prefix can be used to have non-default
                                 (not "pg") prefixes for each of the metrics
                                 ($PG_EXPORTER_METRIC_PREFIX)
      --[no-]version             Show application version.
      --log.level=info           Only log messages with the given severity or
                                 above. One of: [debug, info, warn, error]
      --log.format=logfmt        Output format of log messages. One of: [logfmt,
                                 json]

@jsabater
Copy link

This warning is still happening in version 0.15. The binary seems to successfully load the configuration file using the following:

ARGS="--web.config.file='/etc/prometheus/postgres_exporter.yml'

Yet it's still showing the warning/error. It's like it's trying a default path or similar:

@sysadmind
Copy link
Contributor

The warning is not for the web.config.file arg. It's for the --config.file parameter. The warning is because it doesn't find the config file which is used for the multi-target support

@lethargosapatheia
Copy link

The warning also shows up in 0.16.0 and it's rather misleading. I'm not using any configuration file, I'm just using the environmental variables to connect to postgresql and that's it. I expect it to show up only if I explicitly set the --config-file directive, otherwise it can be a real red herring when debugging connectivity issues among other things.

@jsabater
Copy link

The warning also shows up in 0.16.0 and it's rather misleading.

Admittedly, it reads config file, not web config file. But I agree that it may be misleading, especially for the newcomer.

@4chEr
Copy link

4chEr commented Dec 11, 2024

Recommends to always set config-file
minimum 1 string with
auth_modules:

@lethargosapatheia
Copy link

lethargosapatheia commented Dec 11, 2024

That's not really the issue now, is it? I don't think anyone here wouldn't have known how to use a configuration file. The point is, if the application really needs one, it should simply not start, and if it doesn't, it should just not work. Half-baked solutions are not really what people look for.

@sysadmind
Copy link
Contributor

I think there are some good points here. I also think it's not as black and white as it appears on the surface. This exporter can be used as a single target exporter like most exporters where you know the system you are going to query up front. In this mode, currently there is no config file necessary although that could change in the future. In that scenario, we can just quietly ignore anything for the config file. The other way that this exporter can be used is via the multi-target support. This is where you query the /probe endpoint and pass in the remote system to query for metrics. For example, you could deploy a single instance of this exporter and configure Prometheus to get metrics for a dozen Postgres instances through this one exporter. In that scenario, the configuration file becomes relevant where you can pass in reusable options so that you don't have to pass authentication credentials over the network. Both of these strategies can also be used at the same time. There's nothing stopping someone from using the same instance of the exporter for both.

For multi-target support, the config file is relevant, but not strictly necessary. We could potentially remove the default which would allow the code to know if it was set by the user or not. I'm not sure that the config file is strictly necessary for multi-target support so that option could work, although I think the config file is strongly advised. The log line has been downgraded to a warning, which I think feels appropriate in this case.

@giovannimanzoni
Copy link

Recommends to always set config-file minimum 1 string with auth_modules:

this fix the problem level=WARN source=main.go:85 msg="Error loading config" err="Error parsing config file "/etc/postgres_exporter/postgres_exporter.yml": EOF"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants