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.
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
[RFC] Stage 0 - TSDB Dimensions #2172
[RFC] Stage 0 - TSDB Dimensions #2172
Changes from 13 commits
186813b
f60b78a
26abe0c
187dab5
2b658cc
03bba9f
d70b2f8
5ea7841
1484f3d
0988771
8c5dbe5
5980d40
eb3e67f
7d16e96
7317e8a
ed7bd3b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 reason why not to consider
host.id
? https://www.elastic.co/guide/en/ecs/current/ecs-host.html#field-host-idas mentioned in description of
host.name
:since it can be specified by user - it might be not unique.
in combination with other fields dimension should be unique I guess though
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.
The proposal as-is will be merged as Stage 0, but this concern is worth discussing in Stage 1+ and capturing. I'll make a note this item is brought up in the next stage's PR.
cc @agithomas
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.
@agithomas ?
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.
Based on my discussion with ElasticSearch team,
host.name
is preferred overhost.ip
. host.ip values change often and hence it is not a preferred dimension field.host.name
, in combination with other dimension fields provides a unique identifier of the asset / resource getting monitored.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.
Please ignore my previous comment, i mis-read it as
host.ip
.I shall go through the
host.id
, its values & cardinality and its qualification of it becoming dimension field during RFC-1 phaseThere 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.
@tetianakravchenko , @lalit-satapathy ,
It appears that
host.id
is not unique enough . ReferenceThe below scenario i could recreate and validate. I have two VMs in GCP created out of same image. Both share the same
host.id
, but they have differenthost.name
My personal belief and opinion is - When defining a dimension, we may not be concerned of meta data such as
host.name
getting changed or replaced. If such a change occur, it may be an intentional change by the infra admin - wanting the replaced asset taking the place of the original asset. I am not sure if there exist a situation where we need to bring the insight to a customer if an IT asset is replaced by another (especially in an on-prem environment). Thoughts?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.
@agithomas thanks for the investigation and bringing to my attention mentioned issue, I agree that
host.id
is not the better option andhost.name
should be used instead.in GCP there is no way to create an instance with an existing in the same project name, so it should be safe to assume that
host.name
will be unique within one project in such case