[receiver/hostmetrics] Add documentation for mute_*_error configuration fields

[bsponge]

Description:
Added documentation for mute_*_error configuration fields and updated comments in the code.

Link to tracking Issue:
Resolves #30779

Testing: not applicable

Documentation: Added missing documentation of mute_*_error configuration in hostmetricsreceiver

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: bsponge / name: Jakub Skiba (ec6d6dc, 62af24f, c5573d6, b9c2f85, 34cfa98, 4b64b71, 6ef98e9, f760a8e)

[braydonk]

Hi @bsponge, thanks for opening a PR for this!

Unfortunately, the documentation can't be added where you have it here; note at the top of that file that it mentions it is autogenerated and thus shouldn't be edited.

What I'd suggest instead is adding it to the README.md in the root hostmetricsreceiver folder. In there, you'll see a section that shows the configuration options for every scraper. This can definitely be improved, but for now if you could add those descriptions directly below the yaml example that would be good for now.

The rest of the PR looks good to me.

[braydonk]

Thanks, looks good to me! Will still need approval from dmitryax before merge.

[crobert-1]

Thanks for your PR, always appreciate documentation enhancements!

[crobert-1]

Hope you don't mind, I updated your PR description to automatically close the linked issue 👍

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[braydonk]

unstale

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[rogercoll]

Could we reopen this PR? This is still important documentation we should have in the process scrapper.

[crobert-1]

Added ready to merge as it's been approved by an approver and code owner.

[braydonk]

@crobert-1 Maybe you'll know the answer to this. I'm not sure if as a codeowner in .github/CODEOWNERS my approval is supposed to count for codeowner approval according to GitHub (still has the grey checkmark here and in other PRs). This has been the case for a while but I wasn't sure if it was intentional or not, if I mixed something up with adding myself as a codeowner I can try to fix it.

[crobert-1]

@crobert-1 Maybe you'll know the answer to this. I'm not sure if as a codeowner in .github/CODEOWNERS my approval is supposed to count for codeowner approval according to GitHub (still has the grey checkmark here and in other PRs). This has been the case for a while but I wasn't sure if it was intentional or not, if I mixed something up with adding myself as a codeowner I can try to fix it.

It's nothing wrong on your side, the green check mark is reserved for approvers and maintainers of the project, unrelated to code owners. Code owners are automatically added as reviewers on PRs, and we can also manually check the .github/CODEOWNERS file to see if someone is a code owner for a given component. (For reference, here's a recent PR where code owner approved and they also don't have a green check mark, just to confirm it's not you.)

I see you also requested a review from @dmitryax, but given this is only a documentation change, I assume we're good to merge. Is that accurate, or would you still prefer a review?

[braydonk]

Thanks for the clarification; I was used to other repos where approvals from CODEOWNERS were green check so I wasn't sure.

I thought merging would be blocked by Dmitrii's review; if it wouldn't be, then I imagine this is fine to merge.

[crobert-1]

I thought merging would be blocked by Dmitrii's review; if it wouldn't be, then I imagine this is fine to merge.

One code owner approval is just fine by default, especially for something simple like this that's only documentation. That being said, if you're ever unsure about a change or want specific feedback from another code owner we can definitely block and ask for more input 👍