Apparently Go does not provide the FQDN on all systems (particularly Linux, it seems) because it checks /bin/hostname rather than /bin/hostname -f.
Here's the Go test showing that they accept the shortname: https://golang.org/src/os/os_test.go#L1341
It would be great if we could fill in the actual FQDN rather than an unexpected subset, but it does mean providing an appropriate mechanism for _every_ supported system (or falling back to the subpar behavior that comes out of the box).
As a workaround, #715 will allow environment variables to fill this in, but it still requires something else in the environment to be used.
/cc @andrewkroh
+1
+1, running topbeat on my linux hosts returns FQDN, but running topbeat on windows hosts (Server 2012R2) only returns the hostname. Would like to have it normalized.
my linux systems (cent 7.2) report fqdn, but my windows report the shortname.
I would prefer the shortname (which is how my rsyslog data comes in). can we update this request to allow you to specificy the command used to aquire the hostname?
windows: %COMPUTERNAME%.%USERDNSDOMAIN% or %COMPUTERNAME%
linux: hostname -s or hostname -f
Please make this an option, I for one prefer the shortname as it keeps the field length shorter. Some windows domains have really long FQDNs.
it might be preferable to allow running a custom command to determine hostname. on some systems even hostname -f returns short name, and user might run a custom command to determine fqdn.
A good idea, too but hostname -f shows the short version only if the system is wrongly setup (or didnt have a domain)
How can i force this ? We need fqdn
@mib4fun, we replaced host field with fields_under_root, fqdn fills with ansible:
filebeat.prospectors:
- input_type: log
fields_under_root: true
fields:
host: "fqdn"
Also you can define beat.name: just set name on top level of filebeat.yml
@popstas ! Its' working !
Found this report while trying to figure out how to do the opposite...
I only want the hostname part available in a field, not the entire fqdn. I.e. what _hostname -s_ returns.
Having two fields, one with just the hostname and one with the fqdn, would be a fine solution for me.
Reasons:
1) Clutter. All machines reporting in to a single elastic cluster belong to the same domain the way I built things out. Having the extra domain information just clutters up dashboards / viz labels.
2) Mac OS X bug that occasionally reports the .local version of the hostname instead of the correct .
This is really an issue. The inconsistencies in host.name usage result in all kinds of unwanted results. As this field is used as the primary key for many stuff, this should get cleared out asap, as every query, dashboard, saved search, watch, alert or ml job will have to be revisited and updated once there is finally a consensus on using shortname or fqdn for all host.name values in all beats.
As some organizations might index events from different domains where some hosts might have the same name, imho there is no choice but to move to lowercase fqdn. (for example dc01.domain1.net and dc01.domain2.net)
To make stuff convenient for users who don't need / want fqdn, an additional field, such as host.shortname could be added?
I can understand that it takes some time to update beats host.name output and processors etc, but at least we should asap evolve to a consensus where this is going long-term, so we can make the necessary preparations and if time permits even add the domain ourselves untill Elastic provides it.
@MorrieAtElastic @andrewkroh @webmat @MikePaquette Please think about a long term plan for host.name and communicate about this.
Agreed, there's a few things we'd like to shore up with regards to host identifiers. I'll make sure fqdn vs shortname is part of the discussion.
hi there,
please fix it quickly, that is otherwise totally confused with all action.
An example of many here, because of the inconsistent handling of the host.name.
In the Metric App / Inventory i see most hosts twice "with" and "without FQDN".
Currently, with Metricbeat, Filebeat and Packetbeat, the FQDN is not sent as host.name but only the hostname (without FQDN).
However, with one exception, Winlogbeat sends the FQDN as host.name.
@webmat Any news about this?
On the ECS side we've just started a more holistic discussion around all the host identifiers, it's RFC 0006. Still very early stage, though. Should start moving in the coming weeks.
Most helpful comment
This is really an issue. The inconsistencies in
host.nameusage result in all kinds of unwanted results. As this field is used as the primary key for many stuff, this should get cleared out asap, as every query, dashboard, saved search, watch, alert or ml job will have to be revisited and updated once there is finally a consensus on using shortname or fqdn for allhost.namevalues in all beats.As some organizations might index events from different domains where some hosts might have the same name, imho there is no choice but to move to lowercase fqdn. (for example dc01.domain1.net and dc01.domain2.net)
To make stuff convenient for users who don't need / want fqdn, an additional field, such as
host.shortnamecould be added?I can understand that it takes some time to update beats host.name output and processors etc, but at least we should asap evolve to a consensus where this is going long-term, so we can make the necessary preparations and if time permits even add the domain ourselves untill Elastic provides it.
@MorrieAtElastic @andrewkroh @webmat @MikePaquette Please think about a long term plan for
host.nameand communicate about this.