Update CloudWatch config to support arbitrary interface names

[hrist0stoichev]

After an update to the most recent AMI, I noticed most of our CloudWatch logs for the fck-nat namespace are gone. Following an investigation from my side, I saw that the network interfaces are no longer eth0 and eth1 but ens5 and ens6. Not sure what caused this change - maybe the AMI update to Amazon Linux 2023. This PR enables metrics for all interfaces, regardless of their name. I tested it and it works.

Relevant docs - https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-network-performance.html

interface_include— Including this section causes the agent to collect metrics from only the interfaces that have names listed in this section. If you omit this section, metrics are collected from all Ethernet interfaces that aren't listed in interface_exclude.

The default ethernet interface is eth0.

interface_exclude— If you include this section, list the Ethernet interfaces that you don't want to collect metrics from.

The ethtool plugin always ignores loopback interfaces.

[RaJiska]

Thanks for taking the time to dig into it. Indeed this could be due to the upstream fck-nat AMI which has been updated to use AL2023, or perhaps just using a different type of instance causes this.

Nevertheless, the reason why it is set to only monitor eth0 and eth1 is because Cloudwatch comes with additional costs per metric. As it may be too complex to pre-set the name of the interfaces depending of AMI/instance type, we may indeed wish to adopt a solution that works in every cases.

How about adding a parameter in the cloudwatch_agent_configuration object input variable to select the list of interfaces to monitor from, defaulting to all?

[hrist0stoichev]

If the instances are not being used for anything extra, i.e. they are only used for running fck-nat, then all is basically equivalent to eth0 + eth1 or any other names those might be given. There are no other interfaces present on the instances (only the loopback one which is ignored as stated in the documentation). That's why I think there's no reason to complicate things further and introduce a new input variable. Also, as those interface names change based on AMI or instance type, hardcoding them would be always prone to failure, e.g. it works one day but then it stops on the next one for no apparent reason.

[RaJiska]

Fair enough, it makes sense. Thank you for looking into that and making a PR @hrist0stoichev ~

[hrist0stoichev]

Thanks for merging, @RaJiska 🚀