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

[docs] Add a doc for scraping receivers #6358

Merged
merged 1 commit into from
Nov 15, 2022

Conversation

dmitryax
Copy link
Member

This document adds some definitions, stability requirements and guidelines on how to update emitted metrics for scraping receivers.

@codecov
Copy link

codecov bot commented Oct 19, 2022

Codecov Report

Base: 91.32% // Head: 91.32% // No change to project coverage 👍

Coverage data is based on head (6a67539) compared to base (b3c8744).
Patch has no changes to coverable lines.

❗ Current head 6a67539 differs from pull request most recent head ac51477. Consider uploading reports for the commit ac51477 to get more accurate results

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           
Impacted Files Coverage Δ
featuregate/gates.go 100.00% <0.00%> (ø)
featuregate/stage.go

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.
📢 Do you have feedback about the report comment? Let us know in this issue.

@dmitryax dmitryax added the Skip Changelog PRs that do not require a CHANGELOG.md entry label Oct 19, 2022
@dmitryax
Copy link
Member Author

@open-telemetry/collector-contrib-approvers PTAL

Copy link
Contributor

@codeboten codeboten left a 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

docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved

There are two main categories of the metrics emitted by scraping receivers:

- **Default metrics**: emitted by default, but can be disabled in user settings.
Copy link
Contributor

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

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Contributor

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.

docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
Copy link
Member

@djaglowski djaglowski 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 writing this up. We definitely need to pin these details down.

docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved

There are two main categories of the metrics emitted by scraping receivers:

- **Default metrics**: emitted by default, but can be disabled in user settings.
Copy link
Contributor

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.

Copy link
Member

@TylerHelmuth TylerHelmuth left a 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?

@dmitryax
Copy link
Member Author

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?

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

@dgoscn
Copy link

dgoscn commented Oct 24, 2022

I am facing this right this moment. If someone advances with this topic, it would be amazing

@dmitryax
Copy link
Member Author

dmitryax commented Nov 1, 2022

@djaglowski @codeboten @evan-bradley thanks for your feedback. I believe everything is addressed now. Please take another look

Copy link
Member

@djaglowski djaglowski left a 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.

Copy link
Member

@andrzej-stencel andrzej-stencel left a 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.

Copy link
Contributor

@evan-bradley evan-bradley 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 writing this up.

I left a few wordsmithing suggestions, but overall it looks good to me.

docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved
docs/scraping-receivers.md Outdated Show resolved Hide resolved

### Other changes

Other breaking changes SHOULD follow similar strategies inspecting presence of `enabled` field in user settings. For
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
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

Copy link
Member Author

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

@dmitryax
Copy link
Member Author

@evan-bradley thanks for the review! I applied all the corrections except for the last one

@bogdandrutu bogdandrutu merged commit dae4ebd into open-telemetry:main Nov 15, 2022
@dmitryax dmitryax deleted the add-doc-for-scrapers branch November 16, 2022 04:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Skip Changelog PRs that do not require a CHANGELOG.md entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants