Skip to content
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

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

braydonk
Copy link
Contributor

@braydonk braydonk commented Dec 2, 2021

#276 updated the goccy/go-yaml library to a version that parses time.Duration directly, and the new time field used that. Update MetricsReceiverShared.CollectionInterval to be a time.Duration for consistency (also resolves this TODO).

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.
@braydonk braydonk force-pushed the braydonk-collection-interval-duration branch from ae2815f to 1f10ccd Compare December 2, 2021 15:00
@@ -13,7 +13,7 @@ metrics:
receivers:
hostmetrics:
type: hostmetrics
collection_interval: 60s
collection_interval: 1m0s
Copy link
Member

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?

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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"
Copy link
Member

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?

Copy link
Member

@quentinmit quentinmit Dec 3, 2021

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)

Copy link
Contributor Author

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.

Copy link
Member

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
Copy link
Member

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
Copy link
Member

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…

Copy link
Member

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.

@@ -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},
Copy link
Member

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.

Suggested change
MetricsReceiverShared: cg.MetricsReceiverShared{CollectionInterval: time.Second * 60},
MetricsReceiverShared: cg.MetricsReceiverShared{CollectionInterval: 60 * time.Second},

if m.CollectionInterval != "" {
return m.CollectionInterval
}
return "60s"
Copy link
Member

@quentinmit quentinmit Dec 3, 2021

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)

@braydonk braydonk changed the base branch from braydonk-refresh-interval to master December 21, 2021 13:33
@braydonk braydonk force-pushed the braydonk-collection-interval-duration branch from 6857f5c to f4750bd Compare December 21, 2021 13:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants