fix: cloudwatch metrics collection #10027

[n2N8Z]

Required for all PRs:

• Updated associated README.md.
• Wrote appropriate unit tests.
• Pull request title or commits are in conventional commit format

resolves #10027

store pointer to metric rather than pointer to range value variable

Copied from #10123:

getDataQueries iterates over all filteredMetrics and takes the address of the metric from that list to store it in the dataQueries map. However since go seems to re-use the same object for every iteration of the loop the pointer that is taken always points to the exact same memory location. Due to this the Metric field will always contain the same pointer (and therefore value) after the for loop is done. The fix is easy and I will provide it as soon as I am done with this issue: the metric struct needs to be copied once to allocate new memory, after that the address can be taken.

[telegraf-tiger]

Thanks so much for the pull request!
🤝 ✒️ Just a reminder that the CLA has not yet been signed, and we'll need it before merging. Please sign the CLA when you get a chance, then post a comment here saying !signed-cla

[telegraf-tiger]

👍 This pull request doesn't change the Telegraf binary size

📦 Looks like new artifacts were built from this PR.

Expand this list to get them here ! 🐯

Artifact URLs

DEB	RPM	TAR GZ	ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	freebsd_amd64.tar.gz	windows_i386.zip
armel.deb	armv6hl.rpm	freebsd_armv7.tar.gz
armhf.deb	i386.rpm	freebsd_i386.tar.gz
i386.deb	ppc64le.rpm	linux_amd64.tar.gz
mips.deb	s390x.rpm	linux_arm64.tar.gz
mipsel.deb	x86_64.rpm	linux_armel.tar.gz
ppc64el.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_s390x.tar.gz
		static_linux_amd64.tar.gz

[n2N8Z]

!signed-cla

[powersj]

Thanks for the PR, I've been wanting to get back to looking at that bug so I appreciate the help! can you explain why changed what you did and how it fixes things?

[n2N8Z]

I had included "store pointer to metric rather than pointer to range value variable"
in the description, but it was hidden in a comment.

[powersj]

@n2N8Z thanks for that

Can you show some test output? I'm curious if we should take this or the fix in #10123

[n2N8Z]

@powersj I don't do much golang, so don't know whether the fix i #10123 is better than what I've proposed, but the issue being fixed is the same. Not sure why any test output is required, the bug is pretty clear. But if you insist, what do you want, the output of "--test" without and with the fix applied ?

[maxmoehl]

Hi @powersj any ETA on when this will be released?

[powersj]

This will be part of v1.21.0. We have already released 2x v1.21.0 RCs, which you can find on the releases page if you want to give it a shot to ensure it fixes the issue.

The official v1.21.0 release is scheduled for this Wednesday!

[n2N8Z]

Confirmed fixed in 1.21.2