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

feat(inputs.unbound): Collect histogram statistics #16452

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

Conversation

zeloff
Copy link

@zeloff zeloff commented Jan 30, 2025

Summary

The histogram data on unbound response times is more informative than the (already exported) mean and median values.

The bounds of the histogram's buckets are hardcoded (see util/timehist.c on the unbound source) so it is safe to assume they will remain constant. Therefore, it is sufficient to only export the lower bound of each bucket, in the field name.

Checklist

  • No AI generated code was used in this PR

Related issues

resolves #16451

@telegraf-tiger
Copy link
Contributor

Thanks so much for the pull request!
🤝 ✒️ Just a reminder that the CLA has not yet been signed, and we'll need it before merging. Please sign the CLA when you get a chance, then post a comment here saying !signed-cla

@srebhan srebhan changed the title Collect unbound histogram stats feat(inputs.unbound):Collect histogram statistics Jan 31, 2025
@srebhan srebhan changed the title feat(inputs.unbound):Collect histogram statistics feat(inputs.unbound): Collect histogram statistics Jan 31, 2025
@telegraf-tiger telegraf-tiger bot added feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin plugin/input 1. Request for new input plugins 2. Issues/PRs that are related to input plugins labels Jan 31, 2025
Copy link
Member

@srebhan srebhan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution @zeloff! I do have one suggestion in the code. Furthermore, I wonder if we should guard this feature with a configuration setting to avoid adding those fields for existing users...

Comment on lines 96 to 107
} else if strings.HasPrefix(stat, "histogram") {
statTokens := strings.Split(stat, ".")
if len(statTokens) > 1 {
lbound, err := strconv.ParseFloat(strings.Join(statTokens[1:3], "."), 64)
if err != nil {
acc.AddError(fmt.Errorf("expected a numeric value for the histogram bucket lower bound: %s", strings.Join(statTokens[1:3], ".")))
continue
}
field := fmt.Sprintf("%s_%f", statTokens[0], lbound)
fields[field] = fieldValue
}
} else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about

Suggested change
} else if strings.HasPrefix(stat, "histogram") {
statTokens := strings.Split(stat, ".")
if len(statTokens) > 1 {
lbound, err := strconv.ParseFloat(strings.Join(statTokens[1:3], "."), 64)
if err != nil {
acc.AddError(fmt.Errorf("expected a numeric value for the histogram bucket lower bound: %s", strings.Join(statTokens[1:3], ".")))
continue
}
field := fmt.Sprintf("%s_%f", statTokens[0], lbound)
fields[field] = fieldValue
}
} else {
} else if suffix, found := strings.CutPrefix(x, "histogram."); found {
statTokens := strings.Split(stat, ".")
fields["histogram_"+suffix] = fieldValue
} else {

Copy link
Author

@zeloff zeloff Jan 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was my first stab at Go, so apologies for style and efficiency issues.

Your suggestion is indeed simpler but - and this is a personal opinion - I think field names become unnecessarily large, and harder to parse and post-process (histogram_000064.000000.to.000128.000000 vs histogram_64.000000). The upper bounds of the histogram are redundant, as they'll always be the lower bound of the next bucket. So the longer field names bring no additional information, but are harder to analyze. But again, this is an opinion, I can understand if you want to keep things closer to the original data. I'll change the PR if needed.

(I also found two issues with your suggested code: x on line 96 should be stat, and line 97 can be dropped, as it raises an error about statTokens being defined but not uses, but that's a detail)

The option for collecting these stats sounds like a good idea. I'll work on that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed two additional commits adding an option for collecting histogram statistics, and documenting it. Let me know how you stand on the field names issue. I'm also considering dropping this PR, which is getting a bit messy, and make a new cleaner one, once it is all settled.

@srebhan srebhan self-assigned this Jan 31, 2025
@telegraf-tiger
Copy link
Contributor

telegraf-tiger bot commented Feb 3, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin plugin/input 1. Request for new input plugins 2. Issues/PRs that are related to input plugins
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Histogram stats aren't exported by the unbound input plugin
2 participants