-
Notifications
You must be signed in to change notification settings - Fork 70
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
Change Metrics Collection Interval to time.Duration #282
base: master
Are you sure you want to change the base?
Conversation
Adds new field wildcard_refresh_interval to the logging files receiver in the ops-agent config.
Use a different strategy for the validator that is more scalable than the original `whole_time_denomination` implementation; take a time.Duration and see if it is a multiple of some other duration.
ae2815f
to
1f10ccd
Compare
@@ -13,7 +13,7 @@ metrics: | |||
receivers: | |||
hostmetrics: | |||
type: hostmetrics | |||
collection_interval: 60s | |||
collection_interval: 1m0s |
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.
Bleh. Is there no way we can force this to be serialized as seconds? These are user-visible sample configs, so it is not a great idea to change them…
Looks like the goccy/go-yaml library does not support this, but maybe a custom marshaler?
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.
ISTR last I looked into this it was not possible to implement a custom marshaler (hence why I had to fix it upstream in the first place). I think we just have to live with this; this is the canonical serialization of a time.Duration(60000000000)
in Go.
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 recall a GitHub issue in the golang/go repo where custom time.Duration
string formatting was discussed, and it was denied because of backwards compatibility. I'm going to keep looking for the issue, I wish I'd saved it. But the outcome of that was that we'll have to have some custom function to format this as 60s
if we want it that way.
The last intrusive way I can think to do that would be to keep the CollectionIntervalString
function, check if the value is 60 seconds, and deliberately output 60s
in that scenario, otherwise just return the string formatted duration.
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 think we just need to live with it; this is the canonical serialization of 60s.
if m.CollectionInterval != "" { | ||
return m.CollectionInterval | ||
} | ||
return "60s" |
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.
Did we just remove the 60s
default? Does it matter?
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.
+1 (to Igor's comment, that is, not the removal of the code)
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 put 60 seconds as a value any time it looked like we relied on the default result of CollectionIntervalString
, did I miss any?
I will change to using a constant instead of putting 60 seconds everywhere.
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, a constant would be preferable, thanks!
@@ -344,7 +344,7 @@ processors: | |||
- gce | |||
receivers: | |||
hostmetrics/default__pipeline_hostmetrics: | |||
collection_interval: 60s | |||
collection_interval: 1m0s |
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.
[Optional] This one is not ideal either, but less annoying than the user-visible sample config change.
cannot unmarshal uint64 into Go struct field UnifiedConfig.Metrics of type time.Duration |
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.
[Optional] Sigh. This is a net negative for usability, but there's precedent for messages like this, so we can probably kick that can down the road and address all of those in one fell swoop at some point…
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, fixing this generically for all fields would be a great separate PR.
apps/builtinconf.go
Outdated
@@ -39,7 +43,7 @@ var ( | |||
Receivers: map[string]cg.MetricsReceiver{ | |||
"hostmetrics": &MetricsReceiverHostmetrics{ | |||
ConfigComponent: cg.ConfigComponent{Type: "hostmetrics"}, | |||
MetricsReceiverShared: cg.MetricsReceiverShared{CollectionInterval: "60s"}, | |||
MetricsReceiverShared: cg.MetricsReceiverShared{CollectionInterval: time.Second * 60}, |
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.
Nit: It reads better if the number comes first.
MetricsReceiverShared: cg.MetricsReceiverShared{CollectionInterval: time.Second * 60}, | |
MetricsReceiverShared: cg.MetricsReceiverShared{CollectionInterval: 60 * time.Second}, |
if m.CollectionInterval != "" { | ||
return m.CollectionInterval | ||
} | ||
return "60s" |
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.
+1 (to Igor's comment, that is, not the removal of the code)
6857f5c
to
f4750bd
Compare
#276 updated the goccy/go-yaml library to a version that parses
time.Duration
directly, and the new time field used that. UpdateMetricsReceiverShared.CollectionInterval
to be atime.Duration
for consistency (also resolves this TODO).