Connect OPC UA to Telegraf / InfluxDB

Before you start

• A Telegraf installation on a host with a network path to each OPC UA server, and a decision about whether one agent serves many machines or one agent per machine. One per machine fails independently and is usually worth the extra instances.
• An output configured and tested first, so that when the OPC UA side works you see data immediately rather than debugging two layers at once.
• A reviewed node list, with namespace URIs and identifiers, rather than an intention to browse at runtime. Telegraf collects what you configure; it does not discover.
• A place to keep the agent's client certificate and key, and the ability to get that certificate into each server's trusted store.

Setting it up

1. Start with an unsecured read to prove the pathConfigure an inputs.opcua section with the endpoint and no security, one node group and one node, and run the agent in test mode so it prints the metric to stdout instead of writing it. This confirms endpoint, namespace and identifier in one step.
2. Configure node groups by namespace and rateGroup nodes by namespace and by the interval they need. Each group carries the namespace, the identifier type and the node list, so a group per machine subsystem keeps the configuration readable and lets you change one rate without touching the rest.
3. Switch to the listener plugin for anything event-likeUse inputs.opcua_listener with a subscription interval where you need change-driven data, particularly state variables and counters. Polling a state at a fixed interval loses transitions between polls, and a lost transition is a lost downtime event.
4. Enable security and complete the trust exchangeSet the security policy and mode to what the server offers, point the plugin at the agent's certificate and private key, and configure the identity token. Then connect once, let it fail, and move the agent's certificate from the server's rejected store to its trusted store. Trust the server's certificate on the agent side as configured by your chosen policy.
5. Fix the metric naming and tags before you write historySet the measurement name and add tags identifying machine, line and site, plus the namespace URI and identifier as metadata. Renaming a series after six months of history is far more expensive than thinking about it once now.
6. Decide which timestamp the metric carriesBy default a collector timestamps at collection. Check whether your Telegraf version can carry the OPC UA source timestamp into the metric time, and if it can, use it and confirm the option name against the plugin's own current documentation. If it cannot, record that fact where the analytics team will read it.
7. Watch the agent's own metricsEnable the internal input and alert on gather errors and write failures. A Telegraf agent that quietly cannot reach a PLC produces a gap that looks like a stopped machine, which is the single most damaging failure mode in machine-data collection.

What the address space looks like

Telegraf flattens the address space into metrics. Each collected node becomes a field on a measurement, with tags for whatever dimensions you configured, and everything else the server knew, type definitions, engineering units, browse hierarchy, is left behind unless you encoded it in names and tags. There is no model on the InfluxDB side either: a series is a name and a set of tags. The consequence is that the OPC UA namespace URI and identifier should be carried as tags or as a separate mapping table kept in version control, so that a number in a dashboard can always be traced back to the node it came from. Without that, the mapping exists only in a configuration file on one host.

The traps

• Getting the agent's certificate into each server's trusted store is the biggest deployment hurdle at fleet scale, and it is per machine. Decide on a procedure or a PKI before the first rollout, and expect the first attempt against each server to fail with a trust error by design.
• Namespace indexes in configuration break after a PLC program download. Configure by namespace URI where the plugin supports it, and treat any literal index as a known liability with a documented owner.
• Polling a state variable is not the same as subscribing to it. If availability matters, use the listener plugin, because a stop shorter than your poll interval is invisible and unrecoverable.
• The collector's own timestamp is not the machine's. If the metric time is collection time, every downtime duration inherits your polling jitter, and nobody downstream can tell.
• Counters written raw need a difference or non-negative-difference function at query time. Averaging a counter produces a convincing and meaningless series, and resets or rollovers need explicit handling.
• There is no store-and-forward for the OPC UA side. If the agent host is down, that period is a gap, and a gap is indistinguishable from a stopped machine unless you also collect a heartbeat or a connection-health metric.
• One agent collecting many machines concentrates risk: a configuration error or a restart interrupts every line at once.
• Sampling and publishing intervals you request may be revised by the server. Confirm what the server actually delivers rather than trusting the configured number.

Getting OEE data out of it

Telegraf can deliver the three inputs OEE needs, with a clear boundary. State: subscribe with the listener plugin to a state or mode variable and store every transition, so availability is computed from durations rather than from samples. Counts: read PLC counters as values and compute deltas at query time, handling resets explicitly; do not ask the collector to count edges. Reasons: OPC UA alarms and conditions are not what this collector is for, so a reason code variable is the realistic path, and event-based reasons need a different tool. Beyond that, be explicit that the collector's timestamp discipline sets the accuracy ceiling for every duration you report, and that planned production time, shift calendars and standard cycle times are not in the machine and have to arrive as separate reference data with an owner.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.