-
Notifications
You must be signed in to change notification settings - Fork 16
feat: [SVLS-5992] support DD_URL and DD_DD_URL for metrics intake #517
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
feat: [SVLS-5992] support DD_URL and DD_DD_URL for metrics intake #517
Conversation
bottlecap/src/bin/bottlecap/main.rs
Outdated
| config.https_proxy.clone(), | ||
| Duration::from_secs(config.flush_timeout), | ||
| ); | ||
| let metrics_intake_url_prefix = MetricsIntakeUrlPrefix::new( |
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.
this feels like it should really be part of the config but that doesn't play well with our config parsing process. still, maybe we should be computing this stuff and handling sites and overrides and such in the calling function?
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.
is this an opportunity to split the config_for_parsing from the config_for_using structs? c.c. @duncanista @alexgallotta
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, we maybe don't want to do this here, but in config
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.
yep, let's keep it all close in the config/mod.rs
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.
At this stage, the code should have a validated and working immutable config struct, ready to be used around/
The only exception would be for config that changes dynamically, but that must be address with a prod/consumer or other async stuff
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.
well, i've pushed it up into main(). will followup on a thread there.
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.
(this one: #517 (comment) )
| otlp_config_receiver_protocols_grpc_endpoint: Option<String>, | ||
| // intake urls | ||
| url: Option<String>, | ||
| dd_url: Option<String>, |
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.
is this the right way to move configs from fallback into a fully supported state?
| // Intake URLs | ||
| // These two are for metrics intake. The official config is `DD_DD_URL` but `DD_URL` can also | ||
| // be used for backwards compatibility. `DD_DD_URL` takes precedence. | ||
| pub url: Option<String>, |
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 next-gen extension is already a breaking change, can we just drop this and add it to a breaking change note in the readme?
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.
@astuyve what about customers using old configuration? we just fallback? what's the politics behind this on how we manage a different 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.
If it's somehow ok to remove that deprecated config, I would say to go for it.
Worst case, the few who will complain will have a quick fix
b85f047 to
ccba5c7
Compare
| async fn main() -> Result<()> { | ||
| let (aws_config, config) = load_configs(); | ||
|
|
||
| let site = Site::new(config.site.clone()).map_err(|e| { |
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.
@duncanista, @alexgallotta : how would y'all want me to handle this config parsing block? should i push it into load_configs() and change that to return aws_config, config, and metrics_intake_url_prefix? or something else?
|
Closing in favor of #585 |
No description provided.