Support fully qualified domain name in host

[simitt]

Problem

ECS changed the definition of host.name and encourages to use the fully qualified domain name for the host name.

All Elastic ECS producers should populate the host.name field with the lowercased FQDN from here forward.

Solution

The Elastic Agent supports this behind a feature flag (to avoid breaking changes for users).

The APM agents need to collect the host.domain information, but only the APM server knows if the Elastic agent is configured to store the FQDN. The server needs to query this configuration from the Elastic agent policy, and if enabled, prepend the domain name to the host to yield a FQDN.

related elastic/apm#793

[trentm]

From discussion in the Agents meeting today, the system.detected_hostname (or the system.hostname for those agents that still haven't implemented system.detected_hostname) from some agents will include the domain info, and from some agents it will just be the simple hostname without domain info.

That means that creating the FQDN in apm-server will involve a heuristic to determine if the hostname info includes domain info.

[simitt]

@trentm is that described logic already the case or are different agents just going to have different implementations in the future? In case of the latter, then I'd be curious to know why you would prefer that over adding a dedicated new fieldfor the FQDN?

[trentm]

is that described logic already the case or ...

My understanding from the discussion is that it is already the case.

• Node.js APM agent: sends metadata.system.hostname (the old deprecated name) with domain info (e.g. pink.local on my macOS laptop)
• Python: same as Node.js agent
• Ruby: metadata.system.detected_hostname: "pink.local" with domain info
• .NET (from the discussion): metadata.system.detected_hostname without domain info
• Java: I don't know

[simitt]

What about configured_hostname? If that doesn't contain the FQDN, there is no way that the apm-server could add it to the hostname, when indicated so by the Elastic Agent configuration.

[trentm]

What about configured_hostname? ...

If the user sets export ELASTIC_APM_HOSTNAME=my-computer, i.e. not a FQDN, then the APM agent should send: configured_hostname: "my-computer" and detected_domain_name: "example.biz".
I suppose APM server could assume those can be joined and yield host.name: "my-computer.example.biz".

If the configured_hostname (or detected_hostname) has dots in it, then I'm not sure how smart APM server needs to get to decide if it is a FQDN. For example detected_hostname: "fred.local" is a FQDN, but "cs123.computer-department" isn't.

[axw]

If various agents are already sending an FDQN, and we want to end up with them all doing that, I wonder if it is worth the complexity of sending additional information and joining fields server-side.

What's the downside of simply updating the agents that send an unqualified hostname to send an FQDN?

[trentm]

What's the downside of simply updating the agents that send an unqualified hostname to send an FQDN?

From the APM agents weekly discussion the downside mentioned was that it would potentially be considered a breakage for users upgrading that agent. (I don't have a strong opinion either way here.)

/cc @stevejgordon @gregkalapos

[simitt]

Closing this issue according to the plans to support FQDN directly in the apm agents (see spec draft).