Resourcedetection fails on hostnames with period (".")

[alexvanboxel]

Describe the bug
Resourcedetection fails to start pipeline on a system with hostnames with period (".") with failed getting FQDN. Yes it's allowed: Host names may contain only alphanumeric characters, minus signs ("-"), and periods (".")( from:
https://man7.org/linux/man-pages/man5/hosts.5.html )

Steps to reproduce
Set the hostname of a system to something that includes a ..
Add a processor to the config:

processors:
  batch:
  resourcedetection:
    detectors: [ "system" ]

Start the collector

What did you expect to see?
A pipeline that starts and add the host resource

What did you see instead?

Error: cannot setup pipelines: cannot start processors: failed getting FQDN: fqdn hostname not found: lookup alex.vanboxel-MBP: no such host
2021/01/20 11:49:09 application run finished with error: cannot setup pipelines: cannot start processors: failed getting FQDN: fqdn hostname not found: lookup alex.vanboxel-MBP: no such host

What version did you use?
Version: 0.18.0

What config did you use?

processors:
  batch:
  resourcedetection:
    detectors: [ "system" ]

Environment
MacOS X Catalina 10.15.7

Additional context
Add any other context about the problem here.

[mx-psi]

It might be a different thing but I suspect this is related to this known issue: https://github.com/Showmax/go-fqdn#known-issues from the package that we use for getting the FQDN. If it is indeed this issue, since the OpenTelemetry Collector does not allow for the use of cgo I think the only alternatives are either

1. disabling the FQDN on macOS or
2. finding an alternative package for getting the FQDN.

[alexvanboxel]

Thanks, I didn't realize it was a Mac problem only. So with your remark, I stepped through the code and I found a workaround to make it not crash (adding the name to the hostnames file), not perfect but that's why it's called a workaround. I'll see that I can add it to the README.

[jrcamp]

We fallback to using the plain hostname if fqdn lookup fails as of #3099. Closing since it's not a fatal error now and we rely on go-fqdn to do the fqdn magic.