-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Use default/hardcoded configuration #1273
Conversation
@tigrannajaryan could you please review? |
958ddd1
to
828f9b3
Compare
Codecov Report
@@ Coverage Diff @@
## master #1273 +/- ##
==========================================
- Coverage 91.96% 91.94% -0.03%
==========================================
Files 254 256 +2
Lines 17286 17314 +28
==========================================
+ Hits 15897 15919 +22
- Misses 990 993 +3
- Partials 399 402 +3
Continue to review full report at Codecov.
|
Windows test failed it does not seem related to this PR. |
@tigrannajaryan could you please have a look? |
@pavolloffay apologies for the delay, this slipped off my radar. A couple questions: How does overriding of existing keys in maps and arrays work? For example if I specify a single attributes processor in my config file will it be the only processor enabled or the batch processor will be also enabled because it is in the default. Similarly, if I specify a pipeline "traces" in my config file does it completely override everything in the default? For example if I have this in the config file: pipelines:
receivers: [opencensus] What's by effective config? Is it this? pipelines:
receivers: [opencensus]
processors: [batch, queued_retry] Or the "processors" will not be included in the effective config?
I think we can enable health check by default. Anything that prevents it? |
Nevermind, I can see how it works in the tests. |
@pavolloffay please add this change to the Unreleased section of CHANGELOG.md. This changes the default behavior of the Collector so we want to make sure users are aware of it. |
service/defaultconfig/config.go
Outdated
queuedRetry := factories.Processors["queued_retry"].CreateDefaultConfig() | ||
return &configmodels.Config{ | ||
Receivers: configmodels.Receivers{otlpRec.Name(): otlpRec}, | ||
Processors: configmodels.Processors{batch.Name(): batch, queuedRetry.Name(): queuedRetry}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We intend to declare "queue_retry" obsolete, since the exporters now are supposed to have separate queues. I think we don't need "queue_retry" in the default config anymore.
cc @bogdandrutu
e1ac469
to
f48be5f
Compare
@tigrannajaryan I have updated the PR: qretry is removed from the default config and I have added the PR to the changelog. |
@pavolloffay please fix lint/test errors. |
It should be good now |
There is an issue with the load test, I am looking into it. |
func CreateDefaultConfig(factories component.Factories, forConfig *configmodels.Config) *configmodels.Config { | ||
// the default config cannot be installed to the missing pipeline | ||
// because the service will fail to start as there is no default exporter. | ||
if forConfig == nil || forConfig.Service.Pipelines["traces"] == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to add forConfig
param for the reason described ^^ e.g. the service would fail to start if there was defined only metrics pipeline.
I am not sure if I like this API now. Maybe we should not return the default config but instead modify the supplied one by installing missing components. Now is the challenge what we should do with the receivers, processors array from the pipeline. Shall we not touch it if the user defined it (this allows disabling default components)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this is unfortunate. I agree with you. Also the behavior is hard to explain to the users and can be a source of confusion. We may actually make it worse by trying to make the user's life easier.
The more I think about it the less appealing I find the initially idea of the degault config. I am inclined to give up on the notion of the default config unless we can come up with a clear and intuitive behavior. I have a hard time suggesting a good approach myself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was more talking here from the internal API perspective. I still see benefits in the default config. Users shouldn't be required to always configure batching, memory limiter, the minimal user interaction the better.
For the end-user the rationale should be:
- the default config should not cause start failure, any failures
- the default config should be overridable
- user should know the final configuration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I agree that the concept of the default config is generally useful. But I don't like how our particular implementation of it works from the user's perspective.
The workaround you have on line 27 is not going to work if the traces pipeline has a different name (which we allow). Even if it worked, how do we rationalize that default config only applies when there is a traces pipeline but not when there is a metrics pipeline only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The workaround you have on line 27 is not going to work if the traces pipeline has a different name (which we allow)
We could make it work by checking the pipeline type and properly injecting the configuration. But I agree that it might be cryptic.
6ab3ec5
to
2b5a7d9
Compare
Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
2b5a7d9
to
2a561e5
Compare
Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
@pavolloffay Sorry, I haven't been able to come up with better suggestions. Absent any new proposal on how to handle this better I think we should give up on the idea, close this PR and go with what I suggest in this comment: include a default config in the distribution. |
Agree, closing this. |
Signed-off-by: Pavol Loffay [email protected]
Description: <Describe what has changed.
This patch enabled default/hardcoded configuration. By default OTEL collector will use
batch
andqueued_retry
processors. User-defined processors take precedence over default configuration.Merging configuration is done via https://github.com/imdario/mergo. Viper does not support merging of go structs. Alternatively, we could use https://godoc.org/github.com/spf13/viper#MergeConfig, but the default configuration would have to be specified as a string. Also the Mergo library is nicely configurable.
Link to tracking Issue:
Partially implements #886. Missing is
memory_limiter
and health check.Testing: < Describe what testing was performed and which tests were added.>
Documentation: < Describe the documentation added.>