feat(outputs.quix): Add plugin

[tomas-quix]

Summary

Checklist

• No AI generated code was used in this PR

Related issues

[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

[tomas-quix]

!signed-cla

[stereosky]

!signed-cla

[srebhan]

Thank you for your contribution @tomas-quix! I do have some comments in the code. Furthermore, I want to encourage you to implement some unit-tests for this plugin, e.g. by mocking the config server and using a quix docker container or at least using a kafka instance mocking the replies...

[srebhan]

@tomas-quix I've pushed some cleanups and also added some unit-tests. What is currently missing is an integration test (see commented code in the test file) with a Kafka container configured to use SASL-SCRAM256 which you enforce. Could you take a look please!?!?

Furthermore, I do have the following questions:

1. The sasl.mechanism parameter of the fetched config is not used at all but the code enforces SASL-SCRAM256. Is this intentional? What should the plugin do if the mechanism says something else?
2. The security.protocol parameter of the fetched config is not used at all. Is this intentional? If so, why do we pass that around?
3. Wouldn't it be better to simply define the timestamp_units of the serialized metrics to nanoseconds? This would avoid a potential misconfiguration between the pipeline and Telegraf and the value can be converted to seconds easily on the Quix side, can't it?

[tomas-quix]

I have fixed points 1 and 2. I do not understand point 3 however, what do you mean by that? Do you mean to just hardcode nanoseconds as a unit?

[srebhan]

I do not understand point 3 however, what do you mean by that? Do you mean to just hardcode nanoseconds as a unit?

@tomas-quix exactly. Why not send the data with the available precision? My problem is that with an option your pipeline needs to know what was configured in Telegraf and vice versa which usually is a source of trouble if both are not maintained by the same person (which is likely)... If you hard-code it, the Quix side can expect the precision/format...

[telegraf-tiger]

Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip.
Downloads for additional architectures and packages are available below.

⚠️ This pull request increases the Telegraf binary size by 2.23 % for linux amd64 (new size: 262.4 MB, nightly size 256.7 MB)

📦 Click here to get additional PR build artifacts

Artifact URLs

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

[SteveRosam]

Hey guys, any idea why this doesn't show up in the plugin directory?

[srebhan]

@SteveRosam the problem is that we still need to update and sync the plugin list manually from the actual code. I'm working on fixing this but it might take a while...