[system detector] Fallback to os.Hostname when FQDN is not available

[mx-psi]

Description:

• Fall back to os.Hostname when FQDN is not available.

Link to tracking Issue: Fixes #3092

Testing: Updated unit tests

[codecov]

Codecov Report

Merging #3099 (1030b04) into main (e9f085b) will increase coverage by 0.01%.
The diff coverage is 87.50%.

@@            Coverage Diff             @@
##             main    #3099      +/-   ##
==========================================
+ Coverage   91.64%   91.65%   +0.01%     
==========================================
  Files         482      482              
  Lines       23381    23385       +4     
==========================================
+ Hits        21427    21434       +7     
+ Misses       1454     1449       -5     
- Partials      500      502       +2     

Flag	Coverage Δ
integration	63.30% <ø> (ø)
unit	90.65% <87.50%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...urcedetectionprocessor/internal/system/metadata.go	0.00% <0.00%> (ø)
...sourcedetectionprocessor/internal/system/system.go	100.00% <100.00%> (ø)
receiver/k8sclusterreceiver/watcher.go	95.29% <0.00%> (-2.36%)	⬇️
processor/groupbytraceprocessor/event.go	95.96% <0.00%> (-0.81%)	⬇️
exporter/datadogexporter/metadata/metadata.go	90.14% <0.00%> (+5.63%)	⬆️
internal/stanza/receiver.go	100.00% <0.00%> (+5.88%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e9f085b...1030b04. Read the comment docs.

[pmcollins]

This change is fine for a short-term fix IMO, but longer term, what do you think about moving away from the fqdn third party library we're using, and coding the fqdn resolution ourselves? I say this because the library is small, but it doesn't seem to have the fallback behavior we want.

[mx-psi]

what do you think about moving away from the fqdn third party library we're using, and coding the fqdn resolution ourselves? I say this because the library is small, but it doesn't seem to have the fallback behavior we want.

What is the fallback behavior we want? I think we don't want to fall back to os.Hostname when we can't get a FQDN (through the library or otherwise) on the FQDN method. The FQDN and the OS hostname are different concepts and if e.g. we introduce a host.fqdn attribute we would want to be able to distinguish between them. Maybe you are talking about a different fallback behavior?

[pmcollins]

what do you think about moving away from the fqdn third party library we're using, and coding the fqdn resolution ourselves? I say this because the library is small, but it doesn't seem to have the fallback behavior we want.

What is the fallback behavior we want? I think we don't want to fall back to os.Hostname when we can't get a FQDN (through the library or otherwise) on the FQDN method. The FQDN and the OS hostname are different concepts and if e.g. we introduce a host.fqdn attribute we would want to be able to distinguish between them. Maybe you are talking about a different fallback behavior?

Yeah, that's the fallback behavior I was thinking of. The fact that the library gets the hostname then tries to get the fqdn, and if that fails, we get the hostname seemed a little redundant. But your explanation makes sense. Thanks.

[dmitryax]

LGTM. Thanks for fixing it!