# Telegraf: a single Go binary that collects, processes and ships metrics and logs

> Telegraf is an MIT-licensed agent from InfluxData with over 300 plugins, a TOML config and a static binary. It fits teams that need one collector for many sources, and it is a poor fit for anyone who wants a hosted service with a UI.

**influxdata/telegraf** — Agent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.

- Repository: https://github.com/influxdata/telegraf
- Website: https://influxdata.com/telegraf
- Stars: 17,841 · Forks: 5,837
- Language: Go
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/influxdata-telegraf

## What Telegraf replaces, and for whom

Most monitoring stacks accumulate one small agent per data source: something for CPU and disk, something else for Docker, another for a log file, a fourth for a Modbus device on the factory floor. Telegraf's premise is that all of these are the same job. It is an agent that collects, processes, aggregates and writes metrics, logs and other arbitrary data, and the README states it ships over 300 plugins spanning system monitoring, cloud services and message passing.

The audience is therefore infrastructure and platform engineers who already have a destination for time-series data and want the collection side standardised. The plugin list is unusually broad in two directions that rarely meet in one tool. On the IT side: CPU, memory, disk, network, SMART, Docker, Nvidia SMI, Windows Event Log, WMI and Performance Counters. On the operational-technology and network side: OPC UA, Modbus, SNMP, gNMI and Cisco TelemetryMDT. A shop that monitors both a Kubernetes cluster and a PLC rack can use the same binary and the same config format for both, which is the actual selling point here.

It is not a backend. Telegraf writes somewhere; it does not store, query or visualise. If what you want is a dashboard, this is one component of that stack, not the stack.

## How the agent moves data: inputs, processors, aggregators, outputs

The architecture is a pipeline, and the repository layout makes it explicit. The top level contains accumulator.go, aggregator.go, input.go, output.go, parser.go, processor.go, serializer.go and plugin.go, with the concrete implementations under plugins/. Data flows in one direction: an input plugin collects at each interval, optional processors transform individual metrics, optional aggregators combine them over a window, and output plugins write at each flush interval. The README describes exactly this split between collection interval and flush interval, which are configured separately and need not match.

The plugin interfaces are the extension point. The README says Telegraf enables integration of user-defined code to collect, transform and transmit data, and there is an EXTERNAL_PLUGINS.md at the repository root for plugins that live outside this tree, plus a testutil/ directory used by plugin tests. Parsers and serializers are separate from the plugins that use them, so an input that reads a file and an input that reads a socket can share the same parsing logic. The metric model itself lives in metric/ and metric.go.

Two details matter for capacity planning. First, each plugin has its own README under plugins/, and those files, not the root README, are where interval, timeout and per-plugin options are documented. Second, the binary is built from a Go module that requires Go 1.27.0, and go.mod pulls in a very large dependency set (cloud SDKs, database drivers, protocol libraries). That is the cost of the plugin breadth: a build carries far more code than any single deployment exercises.

## Installing Telegraf and running a first config

The README does not inline install commands. It points at docs/INSTALL_GUIDE.md for binary builds, Docker images, RPM and DEB packages, and at docs/QUICK_START.md for a basic walkthrough. The README also links the official image on Docker Hub as library/telegraf, and the Makefile in the repository root builds the agent with make, honouring GOOS and GOARCH when cross-compiling.

The root README gives no sample TOML, so the configuration shape has to come from docs/CONFIGURATION.md and each plugin's own README under plugins/. What the README does state is the mechanism: users define a TOML configuration with the plugins and settings they wish to use, then pass that configuration to Telegraf, and the agent collects data from inputs at each interval and sends data to outputs at each flush interval. Find the input you need in plugins/inputs, read its README for the exact table name and option keys, and do the same for the output under plugins/outputs. Then check the configuration document for the agent-level interval and flush_interval settings that apply across the pipeline. Because plugin option names are not listed in the root README, copying a block from a blog post is the most common way to end up with a config that parses but collects nothing.

## Where Telegraf is the wrong tool

The static binary and the TOML file are also the limitations. There is no server component, no central configuration store and no UI. Every host gets a config file and a service unit, and changing a collection interval across a fleet means changing files across a fleet. Teams used to pushing agent configuration from a control plane will feel this immediately.

The plugin count cuts both ways. A plugin existing in the tree does not mean it is maintained at the same depth as the core system inputs; each one has its own README, and some document their options far more thoroughly than others. The repository also carries an EXTERNAL_PLUGINS.md, which is a signal that not everything lives in-tree and that quality and support expectations vary by plugin.

There is a build-side cost too. Building from source requires Go 1.27.0 and resolves a dependency graph that includes multiple cloud provider SDKs, several database drivers and protocol libraries. If you are compiling Telegraf yourself rather than using a package or image, expect a heavy build and a binary that contains far more than your deployment uses. And if your need is a single narrow metric from one source, a purpose-built exporter will be smaller and easier to reason about than a general agent with a plugin you must configure and keep current.

## Telegraf against Prometheus and the OpenTelemetry Collector

The closest alternatives differ in where the configuration lives. Prometheus scrapes targets: the server holds the target list and pulls metrics over HTTP on a schedule, so adding a host is a server-side change. Telegraf inverts that. The agent holds its own configuration and pushes, so adding a host is a host-side change and the backend needs no knowledge of it. The README lists a Prometheus input plugin, which means Telegraf can also act as a scrape target or scrape others, but the default posture is push, not pull.

The OpenTelemetry Collector is the nearer comparison in shape: also a Go binary, also a pipeline of receivers, processors and exporters, also configured as a file. The README lists an OpenTelemetry input plugin, so Telegraf can consume OTLP rather than only compete with it. The practical difference is breadth of non-application sources. OPC UA, Modbus, SNMP, gNMI, Cisco TelemetryMDT, Windows Event Log, WMI and Performance Counters are first-class inputs here, and that set is what pulls Telegraf into industrial and network environments where an application-tracing collector has little to offer.

For log collection specifically, Telegraf's File, Tail and Directory Monitor inputs overlap with dedicated log shippers. Telegraf's advantage is that the same config can also carry CPU and disk metrics, which removes one agent from the host.

## Release cadence, licence and what upgrades cost

The project is MIT licensed, which permits commercial and closed-source use and modification. That is the whole of the licence implication worth stating here; nothing in the README adds restrictions, and this is not legal advice.

Maintenance is visible in the release list: v1.40.0 on 2026-09-07, v1.39.3 on 2026-08-10, v1.39.2 on 2026-07-20, with the last push to master on 2026-09-21. That is a fast release train, roughly one minor release a month plus patch releases. The README points at docs/RELEASES.md for versioning details and at CHANGELOG.md for change history, and both are in the tree. The practical upgrade cost is therefore not the binary swap, it is reading the changelog for the plugins you actually enable. A general agent with 300 plugins will accumulate breaking changes in plugins you do not use, and those are noise; the ones that matter are the handful you have configured. Pinning a version and reading the changelog entries for your plugin names before moving is the cheap discipline here. The Makefile shows that a build without an exact git tag produces a version string suffixed with the commit, while a tagged build produces the clean version, which matters if you compile your own and want to identify what is running.

## Conclusion

Adopt Telegraf if you already run InfluxDB, Prometheus, Kafka or MQTT and want one static binary to cover system metrics, log tails and device protocols without a per-source agent. Skip it if you need a hosted backend with dashboards, or if you cannot own a TOML file and a service unit per host. Before rolling it out, verify three things: that the specific input plugin you need is documented under plugins/inputs with its own README, that your target output plugin's configuration keys match your endpoint, and that the release you pick from the releases page is the one your package repository actually serves.

## FAQ

### What is Telegraf used for?

It is an agent for collecting, processing, aggregating and writing metrics, logs and other arbitrary data. The README describes over 300 plugins covering system monitoring, cloud services and message passing, so it is typically used as the single collector that feeds a time-series backend.

### How do I install Telegraf?

The README does not list install commands itself. It directs readers to the install guide at docs/INSTALL_GUIDE.md for binary builds, Docker images, RPM and DEB packages, and to the releases documentation for versioning details.

### How does Telegraf work?

A TOML configuration defines the plugins and settings to use. The agent then collects data from inputs at each interval, passes it through any processors and aggregators, and sends it to outputs at each flush interval.

### What is the latest version of Telegraf?

The most recent release listed is v1.40.0, dated 2026-09-07. The preceding releases were v1.39.3 on 2026-08-10 and v1.39.2 on 2026-07-20.

### Can I use Telegraf with InfluxDB and Grafana?

Telegraf writes to outputs, and InfluxDB is a natural destination for a metrics pipeline; the README's plugin list is organised around collection and writing, not storage or visualisation. Grafana is not part of Telegraf, so it sits downstream of whatever database you write to.

## Sources

- [influxdata/telegraf on GitHub](https://github.com/influxdata/telegraf)
- [License: MIT](https://github.com/influxdata/telegraf/blob/master/LICENSE)
- [Project website](https://influxdata.com/telegraf)
- [README](https://github.com/influxdata/telegraf/blob/master/README.md)
- [Releases](https://github.com/influxdata/telegraf/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/influxdata-telegraf