-
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
[docs] Add a doc for scraping receivers #6358
[docs] Add a doc for scraping receivers #6358
Conversation
33f749d
to
122bc08
Compare
Codecov ReportBase: 91.32% // Head: 91.32% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@
## main #6358 +/- ##
=======================================
Coverage 91.32% 91.32%
=======================================
Files 241 240 -1
Lines 13878 13878
=======================================
Hits 12674 12674
Misses 959 959
Partials 245 245
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
122bc08
to
d5a64c1
Compare
@open-telemetry/collector-contrib-approvers PTAL |
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.
Thank you for documenting this, just a few comments/questions
|
||
There are two main categories of the metrics emitted by scraping receivers: | ||
|
||
- **Default metrics**: emitted by default, but can be disabled in user settings. |
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.
Any thoughts around naming these Enabled
and Disabled
metrics? The behaviour between these two is opposite, but the word default doesn't imply it's the opposite of optional
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'm not sure. For me, it feels like Default/Optional are more intuitive even if Default doesn't imply it's the opposite of Optional. But I'm good with Enabled/Disabled as well. The only concern is that Enabled is the same name the settings option which may be ok.
Let's keep it for now, I can rename them if there is no other feedback from @open-telemetry/collector-contrib-approvers
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.
Another suggestion: DefaultOn
/ DefaultOff
. It's more verbose but it makes clear that we are describing the default state only.
Enabled
is problematic because then when the user disables the metric you have a "disabled Enabled metric"?
Optional
is also problematic because all metrics are optional.
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 agree that "default" and "optional" are a little more intuitive. I think DefaultOn
and DefaultOff
would be alright as well. Another idea is that we could call non-default metrics "additional" or "extra" to highlight that they aren't emitted out-of-the-box. I think that could also hint toward the purpose behind why a metric is enabled or disabled by default.
d5a64c1
to
f3bd9f0
Compare
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.
Thanks for writing this up. We definitely need to pin these details down.
|
||
There are two main categories of the metrics emitted by scraping receivers: | ||
|
||
- **Default metrics**: emitted by default, but can be disabled in user settings. |
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 agree that "default" and "optional" are a little more intuitive. I think DefaultOn
and DefaultOff
would be alright as well. Another idea is that we could call non-default metrics "additional" or "extra" to highlight that they aren't emitted out-of-the-box. I think that could also hint toward the purpose behind why a metric is enabled or disabled by default.
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.
Thanks so much for writing this up. Tangential to this PR, we should also update https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/cmd/mdatagen/README.md to be more accurate. Maybe linking to this doc would be enough?
9f83d43
to
251aa81
Compare
I believe https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/cmd/mdatagen/README.md should describe technical aspects of using the mdatagel tool. I'll update it once this PR is merged |
I am facing this right this moment. If someone advances with this topic, it would be amazing |
251aa81
to
e0791ab
Compare
@djaglowski @codeboten @evan-bradley thanks for your feedback. I believe everything is addressed now. Please take another look |
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.
LGTM. Thanks for considering my feedback.
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 is very educative read, thanks a lot Dmitrii.
My recent PR is a good example of applying the "Changing the emitted metrics" section. One thought related to this is that I will need to add the warning messages after this doc is accepted.
e0791ab
to
061e669
Compare
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.
Thanks for writing this up.
I left a few wordsmithing suggestions, but overall it looks good to me.
docs/scraping-receivers.md
Outdated
|
||
### Other changes | ||
|
||
Other breaking changes SHOULD follow similar strategies inspecting presence of `enabled` field in user settings. For |
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.
Other breaking changes SHOULD follow similar strategies inspecting presence of `enabled` field in user settings. For | |
Other breaking changes SHOULD follow similar strategies that modify the `enabled` field in user settings. For |
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 correction changes the statement. We don't modify enabled
field in the settings, we check if it's set only
6a67539
to
ac51477
Compare
@evan-bradley thanks for the review! I applied all the corrections except for the last one |
This document adds some definitions, stability requirements and guidelines on how to update emitted metrics for scraping receivers.