CBG-1424 - Show network interface stats when configured API listen adresses use hostnames instead of IPs

[bbrks]

• Lookup non-IP host to resolve addresses in discoverInterfaceName, prior to searching for a matching network interface.
  • Note: This resolves hostnames at each stat collection - which can be advantageous for dynamic addressing, and is not expected to be detremental given DNS caching on both the local resolver, and upstream DNS servers.
• Simplify networkInterfaceStatsForHostnamePort:
  • Remove intermediate allInterfaces bool in favour of single perNic
  • Remove special case for localhost->127.0.0.1 (let the resolver deal with that, along with others like localhost4, localhost6, and proper hostnames like admin.sgw.example.com)

Manual testing:

1. Add localhost alias to /etc/hosts for resolver to see.

$ cat /etc/hosts | grep localhost
# localhost is used to configure the loopback interface
127.0.0.1	localhost
::1             localhost
127.0.0.1 speciallocalhost

2. Bind admin interface to that alias

$ cat config.json
{
  "adminInterface": "speciallocalhost:4985",
  "unsupported": {
    "stats_log_freq_secs": 10
  },
...

3. Run SG and wait for first stat collection.
4. See expvar for working (>0) admin_net_bytes_recv stat and no warning in logs.
5. Repeat from step 2 with IP address instead of hostname for regression.

Before:

2021-05-17T21:50:58.825+01:00 [WRN] Error getting admin network interface resource stats: Unable to find interface for host: speciallocalhost -- rest.(*ServerContext).logNetworkInterfaceStats() at server_context.go:1122

After:

[coveralls]

Coverage increased (+0.02%) to 64.15% when pulling 5ba69c9 on CBG-1424 into feaed5d on master.

[adamcfraser]

Approach looks fine - question about a multiple address/multiple interface scenario.

[adamcfraser]

In the scenario where a host has multiple addresses, is it possible for those addresses to assigned to different interfaces?

[bbrks]

Yes it's possible, but the interface actually being used for the REST API depends what was first in the resolved list of addresses at the time of net.Listen() which does not support multiple addresses.

I think that means that as long as LookupHost resolves in the same order as net.Listen, you'll get correct results - but if that does not happen, you'll see stats for another interface. I don't know how likely or unlikely this is.

There's a "correct" implementation that resolves an address before starting up the HTTP servers, so we know exactly what to look for in this stat code, but I'm not sure it's worth that to cover this specific case.

[adamcfraser]

Makes sense - thanks.