-
Notifications
You must be signed in to change notification settings - Fork 2.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
[receiver/prometheusreceiver] Do not add host.name
to metrics from localhost/unspecified targets
#6476
Merged
jpkrohling
merged 6 commits into
open-telemetry:main
from
mx-psi:mx-psi/prometheus-0.0.0.0
Dec 6, 2021
Merged
[receiver/prometheusreceiver] Do not add host.name
to metrics from localhost/unspecified targets
#6476
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
019c3fe
[receiver/prometheusreceiver] Set host.name to 127.0.0.1 for 0.0.0.0 …
mx-psi ecb320e
[receiver/prometheusreceiver] Do not include localhost-like or unspec…
mx-psi 0c4a905
Fix unit tests; add localhost unit test
mx-psi f4da92f
Rename to `isDiscernibleHost`
mx-psi 832eeab
Fix unit test panicking
mx-psi d2c73c1
Address review comments
mx-psi File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Wouldn't it be better to remove the host name Attribute when its value is
0.0.0.0
,localhost
,127.0.0.1
or::1
(or any variation of this) and let the resourcedetection processor do the job or setting this attribute properly (with the actual host name of the system).Because eventually, the metric is going to be stored somewhere else, where localhost will be either meaningless or misleading.
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 certainly would prefer that (e.g. the way we as a vendor use
host.name
makes it solocalhost
and similar attributes are practically useless), but I was assuming these attributes were necessary for something Prometheus-related.Maybe @dashpole can comment on this?
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.
If you are using the resource detection processor, it overrides the existing values by default anyways. I double-checked, and host.name isn't used for anything prometheus-related
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.
There are valid use cases where you don't want the
resourcedetectionprocessor
to override the hostname (e.g. chaining multiple Collectors), or maybe you can't/don't want to use it at all (e.g. your Collector distro doesn't support it or you don't want the performance hit).Personally I would prefer removing it then, if everyone is on board with this. I agree with @bertysentry that having a localhost-like value for
host.name
is, while spec-compliant, not very useful in practice.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.
Removing it only when its a localhost equivalent? Or removing it entirely?
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.
resourcedetectionprocessor has an
override
option that can be set tofalse
to prevent it from overwriting attributes that are already set.Removing the
host.name
attributes in prometheusreceiver when its value islocalhost
(or any variation of localhost, incl.0.0.0.0
) will then work very well in combination with resourcedetectionprocessor (andoverride: false
).Typical example: the internal otelcol Prometheus exporter, whose metrics are currently attached to
0.0.0.0
, which are not usable once these metrics from several collectors are aggregated into a Prometheus server.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.
Only when localhost or equivalent, yes