Idako vs. Telegraf: Two Ways to Log OPC UA Data to InfluxDB

This article was created with AI assistance.

Both can move process data from an OPC UA server into InfluxDB. They're built on very different assumptions about what else your pipeline needs to do — here's how to pick.

Telegraf is InfluxData's open-source metrics collection agent — a single Go binary with 300+ plugins covering everything from system metrics to databases, cloud APIs, message queues, and (via community-maintained plugins) OPC UA. Idako is a purpose-built OPC UA-to-database bridge: a much narrower tool that does one job — reading from OPC UA servers and getting that data into InfluxDB, SQL databases, or messaging platforms without losing samples along the way.

Neither is "better" in the abstract. Which one fits depends on what else is in your stack, who configures it, and how much you need OPC UA specifically — as opposed to metrics collection in general — to just work.

1The Short Version

2What Each Tool Actually Is

Telegraf

Telegraf is part of InfluxData's TICK stack — the same company that makes InfluxDB. It's a general-purpose, plugin-based collection agent configured with TOML files. For OPC UA specifically, it ships two separate input plugins: opcua, which polls a configured list of nodes on a fixed interval, and opcua_listener, which opens a true OPC UA subscription and streams changes as the server reports them ^[1]. Output goes through the influxdb_v2 (or influxdb for 1.x) plugin, one of roughly 100 supported outputs.

Idako

Idako (formerly ogamma Visual Logger for OPC) is built around a single job: bridge OPC UA servers to storage and messaging targets — InfluxDB, TimescaleDB, MS SQL/MySQL/PostgreSQL, Kafka/Confluent/Redpanda, MQTT, Snowflake — with native OPC UA subscriptions, millisecond (microsecond with InfluxDB) timestamp resolution, and Store & Forward buffering as a first-class, on-by-default feature rather than an add-on. Its own configuration lives in a SQL database (SQLite for single-node installs, PostgreSQL for larger or clustered deployments) rather than a flat file — so you can change it from the GUI, by editing the database directly, or programmatically through a REST API, whichever fits your ops workflow.

3Architecture, Side by Side

Both draw the same box diagram at a glance. The difference is in the boxes: Idako's collector and forwarder are one purpose-built component; Telegraf assembles the same pipeline out of two independently-maintained, general-purpose plugins that happen to be able to talk to each other.

4Head-to-Head

5Where Telegraf Genuinely Wins

If OPC UA is just one of several things you're collecting — say, host metrics from your edge servers, container stats, and API health checks alongside process data — running one Telegraf agent for all of it is simpler than running Idako plus a separate metrics agent. Telegraf's plugin ecosystem is enormous, it's free without a tag-count ceiling, and if your OPC UA tags are all simple scalar types, both its polling and subscription-based inputs work well. It's also the natural choice if your team already standardizes on InfluxData tooling (Telegraf, InfluxDB, Chronograf/Grafana) and is comfortable maintaining TOML configs as code.

6Where Idako Genuinely Wins

When OPC UA reliability is the project — not a side input among many — the gaps close in Idako's favor. Store & Forward isn't something you have to opt into and tune around known bugs; it's the default behavior. Structured/ExtensionObject tags, common on DCS systems and vendor-specific PLC blocks, are handled natively instead of erroring out. And a GUI-driven config means the OT technician who owns the PLC, not necessarily the person who knows TOML syntax, can maintain the tag list. For a plant where OPC UA-to-historian is the whole job, that focus tends to matter more than plugin count.

A few differences matter specifically once you're managing more than a handful of tags:

• Config lives in a real database, not a text file. Idako's own configuration is stored in SQLite or PostgreSQL rather than a flat TOML file, so a change can come from the GUI, a direct SQL statement, or a REST API call — useful if you want another system (a provisioning tool, an MES) to manage tags programmatically instead of hand-editing config.
• Selection logic, not a hand-built list. Instead of listing every node by hand, Idako lets you define selection rules in Python — e.g. "log every variable under this folder whose name matches this pattern" — and run that selection from the GUI to (re)populate the tag list in one step, instead of adding nodes one at a time.
• Mapping scales with templates. You can map OPC UA attributes to InfluxDB measurements and tags one variable at a time, or define a template once and apply it across hundreds of structurally similar tags — consistent naming without hand-editing each one.
• Built-in 2-node HA. Idako supports deployment as a high-availability cluster across two nodes, so a node failure or a planned upgrade doesn't create a collection gap — maintenance becomes a non-event instead of a scheduled outage window.

7Wrapping Up

Telegraf is the right tool when OPC UA is one data source among many and you want one open-source agent to rule them all. Idako is the right tool when OPC UA is the core of the job and you can't afford the pipeline to quietly drop a structured tag or lose an hour of data during a network blip. Most plants end up choosing based on which failure mode they're more worried about: missing a plugin, or missing data.