6.0 Metricbeat dashboards switched name key? #5276
Labels
Comments
|
We've discussed this in our team meeting and decided to go back to using |
tsg
added a commit
to tsg/beats
that referenced
this issue
Oct 5, 2017
* Use `beat.name` instead of `beat.hostname` in visualizations. See elastic#5276 for the motivation * Add a "tip" widget that tells user how they can select another host. * Automatically set a search pattern of the form `beat.name: "HOSTNAME"` where HOSTNAME is the Beat name (hostname) that uploads the dashboards. The way the last point works is that I saved the dashbaord using this filter: `beat.name:"CHANGEME_HOSTNAME"`. The kibana loader code does a string replacement and replaces `CHANGEME_HOSTNAME` with the actual hostname. The disadvantage of this approach (vs doing JSON parsing) is that we must remember to always save that dashboard with the `CHANGEME_HOSTNAME` wildcard in place. I have added a unit test to the system module that checks for that, so it should be relatively hard for us to forget. Closes elastic#5276.
ruflin
pushed a commit
that referenced
this issue
Oct 6, 2017
* Use `beat.name` instead of `beat.hostname` in visualizations. See #5276 for the motivation * Add a "tip" widget that tells user how they can select another host. * Automatically set a search pattern of the form `beat.name: "HOSTNAME"` where HOSTNAME is the Beat name (hostname) that uploads the dashboards. The way the last point works is that I saved the dashbaord using this filter: `beat.name:"CHANGEME_HOSTNAME"`. The kibana loader code does a string replacement and replaces `CHANGEME_HOSTNAME` with the actual hostname. The disadvantage of this approach (vs doing JSON parsing) is that we must remember to always save that dashboard with the `CHANGEME_HOSTNAME` wildcard in place. I have added a unit test to the system module that checks for that, so it should be relatively hard for us to forget. Closes #5276.
tsg
added a commit
to tsg/beats
that referenced
this issue
Oct 6, 2017
* Use `beat.name` instead of `beat.hostname` in visualizations. See elastic#5276 for the motivation * Add a "tip" widget that tells user how they can select another host. * Automatically set a search pattern of the form `beat.name: "HOSTNAME"` where HOSTNAME is the Beat name (hostname) that uploads the dashboards. The way the last point works is that I saved the dashbaord using this filter: `beat.name:"CHANGEME_HOSTNAME"`. The kibana loader code does a string replacement and replaces `CHANGEME_HOSTNAME` with the actual hostname. The disadvantage of this approach (vs doing JSON parsing) is that we must remember to always save that dashboard with the `CHANGEME_HOSTNAME` wildcard in place. I have added a unit test to the system module that checks for that, so it should be relatively hard for us to forget. Closes elastic#5276. (cherry picked from commit 4778c51)
ruflin
pushed a commit
that referenced
this issue
Oct 9, 2017
* Use `beat.name` instead of `beat.hostname` in visualizations. See #5276 for the motivation * Add a "tip" widget that tells user how they can select another host. * Automatically set a search pattern of the form `beat.name: "HOSTNAME"` where HOSTNAME is the Beat name (hostname) that uploads the dashboards. The way the last point works is that I saved the dashbaord using this filter: `beat.name:"CHANGEME_HOSTNAME"`. The kibana loader code does a string replacement and replaces `CHANGEME_HOSTNAME` with the actual hostname. The disadvantage of this approach (vs doing JSON parsing) is that we must remember to always save that dashboard with the `CHANGEME_HOSTNAME` wildcard in place. I have added a unit test to the system module that checks for that, so it should be relatively hard for us to forget. Closes #5276. (cherry picked from commit 4778c51)
leweafan
pushed a commit
to leweafan/beats
that referenced
this issue
Apr 28, 2023
…lastic#5351) * Use `beat.name` instead of `beat.hostname` in visualizations. See elastic#5276 for the motivation * Add a "tip" widget that tells user how they can select another host. * Automatically set a search pattern of the form `beat.name: "HOSTNAME"` where HOSTNAME is the Beat name (hostname) that uploads the dashboards. The way the last point works is that I saved the dashbaord using this filter: `beat.name:"CHANGEME_HOSTNAME"`. The kibana loader code does a string replacement and replaces `CHANGEME_HOSTNAME` with the actual hostname. The disadvantage of this approach (vs doing JSON parsing) is that we must remember to always save that dashboard with the `CHANGEME_HOSTNAME` wildcard in place. I have added a unit test to the system module that checks for that, so it should be relatively hard for us to forget. Closes elastic#5276. (cherry picked from commit 8b6191e)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am trying out the 6.0 metricbeat and kibana dashboards, in preparation for getting some screenshots for the new scheme, and I ran in to an issue.
In the 5.x versions of the metricbeat dashboards, the host stuff was keyed on
beat.name(which defaults to the hostname, but can be overridden by setting the name in the config, https://www.elastic.co/guide/en/beats/metricbeat/5.6/configuration-general.html#_name)With the 6.0 the visualizations are keyed on beat.hostname - which cannot be overridden. Was this a choice that was made? Or perhaps someone simply picked the wrong field for all of the visualizations?
I was told the change was intentional, but I am looking for a discussion before GA.
I think the
beat.namemakes a lot more sense - customers can either accept the hostname, or override the beat name and use that. I see a lot of value in overriding - host names might be something generated, likeus-east-dc-1-rack-3, but when they were keyed off of the overridablename, it could show up aswebserver1. they can always go back to look at the source data to find out the hostname webserver1 - because that is in the data.@monicasarbu @tsg @simianhacker
The text was updated successfully, but these errors were encountered: