Telegraf

Telegraf is the data collection workhorse of the open-source IIoT world. While message brokers like Mosquitto move data and databases like InfluxDB store it, Telegraf is what actually gathers the data from the factory floor and gets it where it needs to go. It is an agent, not a server, which means it runs on edge devices, gateways, or servers and continuously collects data from configured sources.

Created by InfluxData and written in Go, Telegraf ships as a single binary with no runtime dependencies. It has become the default collector in the MING stack (Mosquitto + InfluxDB + Node-RED + Grafana) and is deployed in hundreds of thousands of installations, from Raspberry Pi edge gateways to cloud infrastructure monitoring.

Key features

• 300+ plugins covering input (data sources), output (destinations), processors (transformations), and aggregators. Input plugins include OPC-UA, Modbus TCP/RTU, MQTT, S7 (Siemens), SNMP, Kafka, and HTTP endpoints.
• Single binary deployment with no dependencies. The official Docker image is 50MB. Runs on Linux, Windows, macOS, and ARM devices including Raspberry Pi.
• TOML configuration in a single file. No complex UI or API to learn. Define what to collect, how often, and where to send it.
• Built-in data processing including filtering, renaming, parsing (JSON, CSV, logfmt), and aggregation (mean, min, max, count) before writing to outputs.
• Multiple output destinations simultaneously. Write the same data to InfluxDB, Kafka, MQTT, and cloud monitoring services in parallel.
• Buffering and retry logic for unreliable networks. If the output destination is down, Telegraf buffers data in memory and retries.

What Telegraf does

Telegraf operates on a simple model: input plugins collect data at configured intervals, processor and aggregator plugins transform it, and output plugins write it to destinations. A typical manufacturing flow looks like: Telegraf's Modbus plugin reads registers from a Siemens PLC every second, the data passes through a processor that adds metadata tags (line number, machine ID), and the output plugin writes to InfluxDB via Line Protocol.

The agent runs as a service (systemd on Linux, Windows Service, or Docker container). Configuration is hot-reloadable in most cases, so you can add new inputs without restarting. Each input runs independently, so a slow or failing source does not block others.

Telegraf is not just for industrial protocols. It collects system metrics (CPU, memory, disk, network), application metrics (MySQL, PostgreSQL, Redis, Docker), and cloud service metrics (AWS CloudWatch, Azure Monitor). This makes it useful for monitoring the infrastructure that runs your factory systems, not just the PLCs and sensors.

Why choose Telegraf

Industrial protocol coverage out of the box. The Modbus, OPC-UA, and S7 plugins are maintained by InfluxData and actively tested. You do not need to write custom code to read from most PLCs. Bosch Rexroth ships Telegraf as a ctrlX AUTOMATION app, recognizing it as the standard collector for their controllers.

Part of a proven stack. Telegraf is designed for InfluxDB, and the integration is seamless. Line Protocol (InfluxDB's wire format) is the native output. If you are building a MING stack deployment, Telegraf is the path of least resistance for data collection.

Flexible enough for complex pipelines. The processor and aggregator plugins let you do significant data transformation before it hits your database. Filter out noisy sensors, calculate rolling averages, or parse custom log formats without adding another tool to the stack.

No vendor lock-in. While it integrates best with InfluxDB, Telegraf writes to 40+ outputs including Kafka, MQTT, Prometheus, TimescaleDB, and cloud services. You can migrate data destinations without changing collection logic.

Getting started

Install via package manager (apt install telegraf on Debian/Ubuntu), Docker (docker run telegraf), or download the binary. Configuration lives in /etc/telegraf/telegraf.conf (Linux) or the working directory (Windows). Enable plugins by uncommenting sections in the config file.

A minimal Modbus configuration takes about 10 lines of TOML. The Telegraf documentation includes working examples for common PLC brands. For a first project, configure one input (Modbus, OPC-UA, or MQTT) and one output (InfluxDB or just a file for testing). Once data flows, add processors and additional outputs.

Learning curve is shallow for basic collection. The complexity comes from tuning intervals, buffer sizes, and retry policies for production reliability. The InfluxData community forum and GitHub issues are active resources.

Technical specs

• Language: Go (single static binary)
• Configuration: TOML file format
• Protocols supported: OPC-UA, Modbus TCP/RTU, MQTT, S7 (Siemens), SNMP, HTTP, Kafka, AMQP, and 100+ more
• Output formats: InfluxDB Line Protocol, Prometheus exposition format, JSON, CSV, and 40+ direct integrations
• Minimum hardware: 128 MB RAM, runs on Raspberry Pi Zero and up
• OS support: Linux, Windows, macOS, FreeBSD, ARM (32-bit and 64-bit)

Limitations

• No visual configuration interface. Everything is done through TOML config files. For teams that prefer GUIs, this can be a barrier. Third-party tools exist but are not officially supported.

• Single-node architecture. Each Telegraf instance operates independently. There is no clustering or central management for large fleets. For managing hundreds of edge collectors, you need configuration management (Ansible, Puppet) or a platform like FlowFuse.

• Memory buffering has limits. When outputs are down, Telegraf buffers in memory. If the outage exceeds the configured buffer size, data is dropped. For critical data, you need disk-based buffering (available but slower) or an external message queue.

• Plugin quality varies. While core plugins (Modbus, OPC-UA, MQTT) are well-maintained, community plugins can be stale or poorly documented. Check the plugin's GitHub activity before depending on it in production.

• No built-in high availability. A single Telegraf instance is a single point of failure for its configured inputs. For HA, you need redundant instances with overlapping collection, which introduces duplicate data challenges.