**Description:**
Follows
https://github.com/open-telemetry/opentelemetry-collector/pull/9443,
relates to
https://github.com/open-telemetry/opentelemetry-collector/pull/9513.
This builds on
https://github.com/open-telemetry/opentelemetry-collector/pull/9228 to
demonstrate the concept.
This shows one way of extending the otelcol APIs to allow passing
converters and providers from the builder with the new settings structs
for each type.
I think this approach has a few advantages:
1. This follows our pattern of passing in "factory" functions instead of
instances to the object that actually uses the instances.
2. Makes the API more declarative: the settings specify which modules to
instantiate and which settings to instantiate them with, but don't
require the caller to actually do this.
3. Compared to the current state, this allows us to update the config at
different layers. A distribution's `main.go` file can specify the
providers/converters it wants and leave the settings to be created by
`otelcol.Collector`.
The primary drawbacks I see here are:
1. This is a little more opinionated since you don't have access to the
converter/provider instances or control how they are instantiated. I
think this is acceptable and provides good encapsulation.
2. The scheme->provider map can now only be specified by the providers'
schemes, which is how it is currently done by default. I would want to
hear what use cases we see for more complex control here that
necessitates using schemes not specified by the providers.
cc @mx-psi
---------
Co-authored-by: Evan Bradley <evan-bradley@users.noreply.github.com>
**Description:**
For both #5615 and #9162 we need to be able to log during the confmap
resolution.
My proposed solution is to pass a `*zap.Logger` to converters and
providers during initialization. These components can then use this to
log any warnings they need. This PR does the first step: being able to
pass anything to converters and providers during initialization.
The obvious alternative to this is to change the interface of
`confmap.Provider` and `confmap.Converter` to pass any warnings in an
explicit struct. I think the `*zap.Logger` alternative is more natural
for developers of providers and converters: you just use a logger like
everywhere else in the Collector.
One problem for the Collector usage of `confmap` is: How does one pass a
`*zap.Logger` before knowing how a `*zap.Logger` should be configured? I
think we can work around this by:
1. Passing a special 'deferred' Logger that just stores the warnings
without actually logging them (we can use something like
`zaptest/observer` for this)
2. Resolving configuration
3. Building a `*zap.Logger` with said configuration
4. Logging the entries stored in (1) with the logger from (3) (using
`zaptest/observer` we can do that by taking the `zapcore.Core` out of
the logger and manually writing)
**We don't actually need ProviderSettings today, just ConverterSettings,
but I think it can still be useful.**
**Link to tracking Issue:** Relates to #5615 and #9162
---------
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
* [chore] use license shortform
To remain consistent w/ contrib repo, see https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/22052
Signed-off-by: Alex Boten <aboten@lightstep.com>
* make goporto
Signed-off-by: Alex Boten <aboten@lightstep.com>
---------
Signed-off-by: Alex Boten <aboten@lightstep.com>
Antoine Toulme
Tyler Helmuth
Evan Bradley
Pablo Baeyens
Alex Boten
Bogdan Drutu