Provide warning when $ is used in config for env var expansion

[bryan-aguilar]

From Collector SIG Discussion 12/20/2023

Use of the $ in collector configurations for environment variable substitution will be deprecated in the future in favor of ${} or ${env:foo}. It would be nice if we started giving users warnings during collector startup if $ is used for env variable expansion to ease the transition pain.

[crobert-1]

+1 on the warning message. It should also include the recommended syntax for expansion so users know exactly how to fix it as soon as they're aware the current method is being deprecated.

[tomasmota]

I can make a pr on this

[mx-psi]

@tomasmota assigned to you :)

[tomasmota]

thanks @mx-psi , maybe you can give me a hint here. It seems like the only point at which we "know" we are dealing with a $ENV is inside this function we pass to os.Expand (https://github.com/open-telemetry/opentelemetry-collector/blob/main/confmap/converter/expandconverter/expand.go#L52). The thing is that it can be ran several times and we probably only want to print the warning once, so I suppose the solution would be setting some sort of flag from inside it? Not really sure how to approach it.

[mx-psi]

Hey @tomasmota, sorry for the delay.

It seems like the only point at which we "know" we are dealing with a $ENV is inside this function we pass to os.Expand

I would do this in the body of expandEnv (the function that calls os.Expand). Note that we want to log a warning if somebody is using the $ENV syntax, but not if they are using ${ENV}. os.Expand doesn't tell you this, so you probably want to use some sort of regex.

The thing is that it can be ran several times and we probably only want to print the warning once, so I suppose the solution would be setting some sort of flag from inside it? Not really sure how to approach it.

If you want to log once per environment variable, I think your best option is to keep a set of the environment variables for which you have already logged. You can add a new field to the converter struct of type map[string]struct{} and keep track of which variables you have already logged for.

One more thing here is that you don't really have a logger today. You can start with using a noop logger while I and other work on passing a logger to the expandconverter

[mx-psi]

I just merged #9547 that adds the logging, we now need to actually pass a logger to close this!

[tomasmota]

As far as I can see, so far no loggers are created before the service actually starts, any errors seem to just use fmt.Errorf, so I'm wondering what the best place is to create this logger. I was considering taking the LoggingOptions from CollectorSettings and creating a logger here, but afaik we don't have access to a LogsConfig, which is inside the service configuration itself which we can't access from there..

Could definitely use some pointers here :)

[mx-psi]

@tomasmota There is a draft PR (#9908) by @ankitpatel96 on this, we were discussing how to do this also with @evan-bradley. If you have an opinion on how to approach this, could you leave a review on #9908 or create an alternative PR?