Change ENV configuration options

[SuperQ]

Problem

The current DATA_SORUCE_NAME is a single ENV var that controls the connection string.

Advantages

• Single ENV var for config.

Disadvantages

• We have to parse and modify the connect string to add extra connection param.
• Having to template connection and auth in the same ENV is cumbersome.
• We would have to do a lot more code to validate input params.
• It's harder to include defaults, like the connection params separate from the auth.
• ENV var duplicates the my.cnf style configuration that is more commonly used in MySQL.

Proposal

Deprecate the ENV var configuration in favor of my.cnf style only.

Related

• ? in the password causes parsing errors
• The upstream DSN documentation

[SuperQ]

/cc @Mattias-

[brian-brazil]

In line with the rest of the project and general security principles, we shouldn't be passing in information via the environment at all. I'd suggest that this be made to come only from a file. This also gives us one source of truth.

[SuperQ]

I thought passing in credentials from an ENV was the correct security practice. We do this for several parts of the Prometheus config.

[SuperQ]

For sure, we can move the connection option to a command line param, that would probably be better.

[brian-brazil]

No part of the Prometheus configuration comes from the environment, it's all from flags and the config file, however some libraries we use happen to read the environment themselves (e.g. AWS libs) and our security model warns about this. Secrets should not go in the environment, as it was never designed with security in mind and it is common practice for example to dump the full environment as part of collecting debug logs. See http://movingfast.io/articles/environment-variables-considered-harmful/

For sure, we can move the connection option to a command line param, that would probably be better.

You could do that, but not for the password as it'd be exposed to everyone on the same machine.

Given this exporter already reads connection information my.cnf, I'd suggest standardising on pulling connection information only from there (we usually use YAML for config files, but my.cnf seems a reasonable exception here).

You could do it all via flags too, with a flag pointing to a file for the password. Given it's best if config only comes from one place, I'm not personally sure this is worth losing my.cnf support for though.

I can't think of anything offhand beyond flags+password file or my.cnf.

[SuperQ]

So after thinking about this, I've updated the proposal to change the exporter to configuration file only.

This simplifies the configuration options and eliminates the bugs in the ENV var parsing.

The only open quesiton is, should we also include flag options for non-auth related configuration.