feat(inputs.opcua_listener): OPC UA Event subscriptions

[LarsStegman]

Required for all PRs

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

resolves #8083

Refactored the opc ua plugin to use a more generic structure. This allows easy injection of either the read client or a subscription client.

I extracted the logic for an opc ua client into an /internal/opcua package, as the same client logic could be reused for creating an opcua client output plugin.

It has become quite a big pull request, so please be thorough with your reviews.

There should be no breaking changes, as by default the request service is used. This PR is purely additive.

[Hipska]

Not yet reviewed all files, but already some minor comments..

[srebhan]

First of all thanks @LarsStegman for the huge undertaking to clean this up. Much appreciated! Before going into a more detailed review I have some more general questions:

1. Can you please more internal/opcua to plugins/common/opcua as this is where we should keep plugin related things.
2. Is it possible to mimick the behavior of the HTTP common part (in plugins/common/http) with a shared config and a defined way to create a client from it? This client would then provide the interface functions you define.
3. Does it make sense to split the opcu plugin into one actively querying part (named opcu) and a listening part named opcua_listener or opcua_consumer? This way, you don't need to deal with partially overlapping config options and stuff but rather move common things to the common part and keep distictive code in the corresponding plugin.

Looking forward to hearing your opinion!

[srebhan]

I guess both State and Client don't need to be exported, do they? Furthermore, you probably want to generate the client from a given config (similar to http's common part) and do not need to store it internaly...

[LarsStegman]

Client and State need to be exported, because the OpcUAClient is now in the common package and SubscribeClient and ReadClient need access to it.

I do not entirely understand what you mean with generating the Client from a config and not needing to store it internally. We need the client in memory, because we need to maintain a connection to the server.

[srebhan]

Why do we need this state-tracking? Isn't the state encoded in the existence of the client?

[LarsStegman]

This was already in the original code.

There was some discussion on it here, so I'm hesitant to remove it.

[LarsStegman]

1. Can you please more internal/opcua to plugins/common/opcua as this is where we should keep plugin related things.

Yes, I will do this.

2. Is it possible to mimick the behavior of the HTTP common part (in plugins/common/http) with a shared config and a defined way to create a client from it? This client would then provide the interface functions you define.

I think this should be possible. I will look into it. I wasn't very happy with how the client creation was done anyway, but I hadn't found a better solution.

3. Does it make sense to split the opcu plugin into one actively querying part (named opcu) and a listening part named opcua_listener or opcua_consumer? This way, you don't need to deal with partially overlapping config options and stuff but rather move common things to the common part and keep distictive code in the corresponding plugin.

This might be a good idea. This will be much easier now that the new configuration loading structure has been adopted everywhere. When I implemented this, that wasn't the case yet, so loading the configuration would have been much more of a hassle. I am a bit worried about having to maintain two example configs, but I think this is not that big of a problem.

[LarsStegman]

I will fix the build failing tomorrow

[LarsStegman]

@Hipska any idea what is triggering the CI? I can't find it.

[powersj]

Thanks for driving this!

[telegraf-tiger]

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

☺️ This pull request doesn't significantly change the Telegraf binary size (less than 1%)

📦 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_i386.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz
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
		static_linux_amd64.tar.gz

[LarsStegman]

🎉