Telegraf: OPC UA Events based plugin

Created on 4 Sep 2020  路  3Comments  路  Source: influxdata/telegraf

Feature Request

Recently merged inputs.opcua plugin currently polls on a certain interval to gather metrics, it does not respond immediately to events. Therefore any event collected would be delayed based on the interval setting.

  • will have to be a separate plugin from existing polling plugin - maybe a opcua_events plugin (like snmp vs snmp_trap plugins)
  • subscription based plugin that responds to OPC UA events
  • supports arrays
  • look into using service input for building enhancement. For initial opcua plugin, attempted to implement both input and service input interfaces in the same plugin but it failed and only functioned as an input.

Use case:

OPC UA is subscription based, will be expected by a lot of users

areopcua enhancement

Most helpful comment

Yes, I also agree with @gavioto , usually polling and subscription are implemented as a OPC UA client configuration layer. I also want to draw your attention to the fact that in addition to improved performance, the subscription mechanism solves two very important problems:

  1. Prevents data loss during connection failure with the OPC UA server by buffering data on the OPC UA server side.
  2. Allows you to get values that change sporadically. I.e., values that change an arbitrary number of times over an arbitrary time interval. An example is the popular IEC 60870-5-104 in the power industry.

It seems to me that the plugin should be designed to solve these tasks as well.

All 3 comments

Hello,

As for the manufacturer of the opc ua server, this is an interesting topic.

I would like to note that in opc ua, events mean a special system (https://reference.opcfoundation.org/v104/Core/docs/Part3/4.6.1/), so I would suggest a different plugin name, such as opcua_subscription.

I think that "subscription" mode should be a feature of the actual plugin.
In fact, traditionally in OPC the subscription, or polling is only a configuration layer, at the end you want to receive updates and you don't mind how these updates are sent. Take into account that using subscription transparently (something that all OPC servers should support) have better performance, as the system only updates with changes, and also you can set a maximin frequency for updates.

Every other configuration option like tags or items, nodes, types, will be the same in both plugins. I think it makes no sense to have duplicated plugins.

On the other hand, having a plugin to get "OPC UA Events" like @dalekseev-monokot commented probably makes sense on it's own.

Yes, I also agree with @gavioto , usually polling and subscription are implemented as a OPC UA client configuration layer. I also want to draw your attention to the fact that in addition to improved performance, the subscription mechanism solves two very important problems:

  1. Prevents data loss during connection failure with the OPC UA server by buffering data on the OPC UA server side.
  2. Allows you to get values that change sporadically. I.e., values that change an arbitrary number of times over an arbitrary time interval. An example is the popular IEC 60870-5-104 in the power industry.

It seems to me that the plugin should be designed to solve these tasks as well.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Xiol picture Xiol  路  3Comments

efficks picture efficks  路  3Comments

yn1v picture yn1v  路  3Comments

nsteinmetz picture nsteinmetz  路  3Comments

fahimeh2010 picture fahimeh2010  路  3Comments