Rename host.name to host.hostname and add config option for name #9943
Conversation
|
@urso Could you see this breaking something? |
| @@ -68,7 +68,7 @@ func ReportInfo(_ monitoring.Mode, V monitoring.Visitor) { | |||
| } | |||
| info := h.Info() | |||
|
|
|||
| monitoring.ReportString(V, "name", info.Hostname) | |||
| monitoring.ReportString(V, "hostname", info.Hostname) | |||
There was a problem hiding this comment.
@ycombinator This affects the monitoring reporting. Will this break something?
There was a problem hiding this comment.
I checked docs in the .monitoring-beats-* indices, and this field will end up as beats_state.state.host.hostname in those docs after this PR, in place of beats_state.state.host.name today. The latter is not being used anywhere in the Stack Monitoring UI code, so this change should be safe.
We will however, want to update the mapping here: https://github.com/elastic/elasticsearch/blob/master/x-pack/plugin/core/src/main/resources/monitoring-beats.json#L52-L54.
There was a problem hiding this comment.
@ycombinator Could you tackle the update of the template?
There was a problem hiding this comment.
Currently by default the hostname of the host on which the Beat is running is fed into host.name. Based on ECS this is now changed to `host.hostname`: https://github.com/elastic/ecs#-host-fields By default `host.name` stays the hostname of the host for backward compatibility. It is not set by the processor but by the pipeline. If the config option `name` is changed in the Beat config, `host.name` will be set to this value as before. In addition a new config option was added to `add_host_metadata`: ``` processors: - add_host_metadata: name: foo ``` `name` for the host metadata processor can be set and will overwrite the current value of `host.name`. It is also possible to set both config options as below: ``` name: bar processors: - add_host_metadata: name: foo ``` The outcome event will contain the following two fields: ``` agent.name: bar host.name: foo ``` Overall if nothing is configured, the behavior stays the same as before but allows additional options.
ruflin
force-pushed
the
rename-name-to-hostname
branch
from
f170a55
to
a05ac11
Compare
There was a problem hiding this comment.
lgtm. apm-server does not support using the add_host_metadata processor. elastic/apm-server#1684 is related.
CI is green, but I still wonder about dashboards/visualizations/ml jobs/infra UI potentially using the field. This could also break links to dashboards with filters set on |
|
@urso As |
me as well :) |
This new `hostname` field is meant to be a replacement for its sibling `name` field. See elastic/beats#9943, particularly elastic/beats#9943 (comment). This PR simply adds the new field (`hostname`) to the mapping without removing the old one (`name`), because a user might be running an older-version Beat (without this field rename in it) with a newer-version Monitoring ES cluster (with this PR's change in it). AFAICT the Monitoring UI isn't currently using the `name` field so no changes are necessary there yet. If it decides to start using the `name` field, it will also want to look at the value of the `hostname` field.
This new field is meant to be a replacement for its sibling name field. See elastic/beats#9943.
Currently by default the hostname of the host on which the Beat is running is fed into host.name. Based on ECS this is now changed to
host.hostname: https://github.com/elastic/ecs#-host-fields By defaulthost.namestays the hostname of the host for backward compatibility. It is not set by the processor but by the pipeline.If the config option
nameis changed in the Beat config,host.namewill be set to this value as before. In addition a new config option was added toadd_host_metadata:namefor the host metadata processor can be set and will overwrite the current value ofhost.name.It is also possible to set both config options as below:
The outcome event will contain the following two fields:
Overall if nothing is configured, the behavior stays the same as before but allows additional options.