Use Telegraf Without the Prometheus Complexity

Every system needs observability. You need to know what your CPU, memory, disk, and network are doing, and maybe keep an eye on database query latency or Redis connection counts.

But setting that up isn’t always simple.

You start with a couple of shell scripts. Then come exporters. Then Prometheus. Before long, you’re managing scrape configs, tuning retention, and watching dashboards fail under load after two days of data.

This post walks through a simpler approach: using Telegraf, a lightweight, plugin-based metrics agent. It can collect system and application metrics and push them directly to your backend, whether that’s Prometheus, InfluxDB, Last9, or something custom.

And if you want a setup that just works, we’ll show how to wire Telegraf straight to Last9 in a few minutes, no scraping, no federation, no extra YAML.

What Telegraf Solves

Telegraf is a lightweight agent that collects, processes, and forwards metrics, all through a single binary. It simplifies telemetry collection by handling multiple sources and destinations without requiring exporters, scraping logic, or custom glue code.

It works in three stages:

• Inputs – Telegraf supports 300+ input plugins. You can pull in:
  • System metrics like cpu, mem, disk, and net
  • App metrics from MySQL, Redis, Kafka, NGINX, Docker, and more
• Processors – You can transform and filter metrics before sending them:
  • Convert counters to rates
  • Drop unused fields
  • Rename measurements or tags
• Outputs – Telegraf can push metrics to a variety of backends, including:
  • Time-series databases like InfluxDB and TimescaleDB
  • Message queues like Kafka
  • Prometheus-compatible endpoints using remote write
  • HTTP APIs like Last9's ingestion endpoint

What makes Telegraf easy to work with is how little setup it needs. Install the binary, enable the plugins you want, and it starts collecting right away.

The Standard Approach vs. The Simplified Path

Here’s a side-by-side comparison of traditional metric collection workflows versus using Telegraf with Last9:

If you're already using Prometheus, Telegraf can send data using the remote_write output. But if you're starting from scratch or want to avoid the overhead of managing scrape configs, service discovery, or time-series storage, Telegraf + Last9 is a simpler path.

Last9 is an OTel-native telemetry platform that handles high-cardinality metrics at scale, with long-term storage and fast queries. It accepts metrics in Prometheus and OpenTelemetry formats. Telegraf can send data to Last9 using either push or pull methods, depending on your setup.

Common Integration Challenges (and How Telegraf Solves Them)

Telegraf solves operational problems that teams face when dealing with telemetry pipelines. Here’s how:

Problem: Metrics are exposed in too many formats

Different systems emit metrics in different protocols, JSON, Graphite, Prometheus, Influx line protocol, etc.

Telegraf standardizes this. It collects metrics from 300+ input sources and converts them into a uniform internal structure. From there, it can output in nearly any format your backend supports.

Problem: Switching backends is high-friction

Most agents are tied closely to their backend, making migrations painful.

Telegraf is backend-agnostic. Changing your destination is a config update, not a code change. For example:

[[outputs.influxdb_v2]]
  url = "https://cloud.influxdata.com"
  token = "your_token"
  bucket = "default"

Switching to a Prometheus-compatible system?

[[outputs.prometheus_remote_write]]
  url = "https://cortex.example.com/api/v1/write"

Problem: Exporters add operational overhead

Managing exporters for every service adds complexity and failure points.

Telegraf handles this with native input plugins. For example:

[[inputs.mysql]]
  servers = ["user:pass@tcp(localhost:3306)/"]

No need to install mysqld_exporter or run sidecar processes. Telegraf pulls directly from the source.

Use Cases

Remote write to Prometheus backends (Cortex, Mimir, VictoriaMetrics)

Telegraf can push metrics directly via remote_write. This bypasses the need for Prometheus scraping altogether.

[[outputs.prometheus_remote_write]]
  url = "https://your-prometheus-remote/api/v1/write"

Use this when you’re running a remote-compatible backend and want to reduce the complexity of scrape configs.

Exposing an /metrics endpoint for local Prometheus

If you already have Prometheus in place, Telegraf can expose its collected metrics for scraping.

[[outputs.prometheus_client]]
  listen = ":9273"

This integrates seamlessly with existing job configs in Prometheus.

InfluxDB (v2)

Telegraf natively supports Influx line protocol and is optimized for InfluxDB Cloud and OSS setups.

[[outputs.influxdb_v2]]
  urls = ["https://cloud.influxdata.com"]
  token = "your_token"
  organization = "your_org"
  bucket = "default"

Telegraf handles batching, compression, and retries out of the box.

Kafka

For internal event pipelines, Telegraf can produce structured metrics to Kafka in JSON or Influx format.

[[outputs.kafka]]
  brokers = ["kafka:9092"]
  topic = "metrics"
  data_format = "json"

Supports batching, TLS, and compression — making it suitable for high-throughput environments.

Graphite

Supports legacy stacks using Graphite’s plain-text line protocol.

[[outputs.graphite]]
  servers = ["graphite:2003"]
  prefix = "telegraf."

A practical option for teams running older dashboards or custom tooling.

Custom HTTP Endpoints

Telegraf can send metrics to any HTTP API using configurable headers and formats.

[[outputs.http]]
  url = "https://metrics.my-infra.local/ingest"
  method = "POST"
  data_format = "json"
  [outputs.http.headers]
    Authorization = "Bearer ${API_TOKEN}"

This is especially useful for integrating with SaaS platforms or internal observability systems.

So, Why Last9?

It's not just that Telegraf can push metrics to Last9, it's about what you no longer have to build or maintain.

With Last9, you get:

• Ingestion control at the edge: Use the Control Plane to filter, remap, drop, or aggregate metrics, without code changes or redeploys.
• Unified observability: Logs, metrics, traces, and events in a single UI. Alerts powered by PromQL and pattern-based logic.
• Tooling built for scale:
  • Cardinality Explorer to track exploding label sets
  • Physical Indexes to isolate high-volume queries
  • Built-in macros, alert history, and anomaly detection
• Fast onboarding: Connect Telegraf and stream metrics in minutes.
• Zero infrastructure overhead: No Prometheus servers, TSDB tuning, or dashboard sprawl. Storage, retention, and performance are managed for you.

The result: production-grade observability without the operational burden.

Get Started with Last9 in 5 minutes

Telegraf supports multiple ways to push metrics into Last9. Pick the method that fits your existing setup. Below are three supported integration methods, along with example configurations and practical considerations.

Method 1: Direct HTTP Push (Recommended for Most Setups)

This is the simplest and most direct way to get metrics into Last9. Telegraf pushes metrics using the outputs.http plugin, formatted in Prometheus remote_write wire format. No intermediary agents, no scrapers, no service discovery.

[[inputs.cpu]]
  percpu = true
  totalcpu = true

[[inputs.mem]]

[[inputs.disk]]

[[outputs.http]]
  url = "https://your-cluster.last9.io/api/v1/receive"
  method = "POST"
  data_format = "prometheusremotewrite"

  [outputs.http.headers]
    Authorization = "Bearer YOUR_TOKEN"
    Content-Type = "application/x-protobuf"
    Content-Encoding = "snappy"

How it works:

• Telegraf collects metrics from configured input plugins (cpu, mem, disk)
• These are encoded using the Prometheus remote_write protobuf format
• The payload is compressed with snappy and sent over HTTPS to Last9’s ingestion endpoint

When to use this:

• You want to avoid maintaining Prometheus servers or scrapers
• You're deploying Telegraf on VMs, containers, or edge nodes
• You want a minimal setup that sends metrics directly to Last9

Operational details:

• Supports retries and backoff if Last9 is temporarily unreachable
• Works in air-gapped networks with egress access via HTTPS
• Requires a valid cluster endpoint and ingestion token from your Last9 account

Method 2: Send to vmagent (If You're Already Using Prometheus Tooling)

If you already have vmagent deployed as part of your Prometheus pipeline, you can use Telegraf’s influxdb output format. vmagent will handle parsing and forwarding to a Prometheus remote_write backend — including Last9.

[[outputs.influxdb]]
  urls = ["http://vmagent:8429"]

How it works:

• Telegraf sends metrics in Influx line protocol format
• vmagent receives the data, rewrites it into Prometheus remote_write, and pushes it to Last9

When to use this:

• You're already using vmagent to aggregate metrics across sources
• You prefer centralized control of retries, buffering, and backpressure handling
• You want to integrate Telegraf without changing your existing pipeline

Operational details:

• This adds a hop in the data path, but gives you better control over flow, retries, and batching
• Useful in Kubernetes, multi-tenant, or regulated environments where egress is controlled centrally

Method 3: Expose a Prometheus-Compatible /metrics Endpoint

For hybrid environments where Prometheus is already scraping workloads, you can use Telegraf’s prometheus_client output to expose metrics in Prometheus text format at a local port.

[[outputs.prometheus_client]]
  listen = ":9273"

How it works:

• Telegraf exposes a /metrics endpoint on localhost:9273
• You configure Last9’s collection agents or Prometheus to scrape this endpoint like any other job

When to use this:

• You're already using Prometheus or a compatible agent to scrape metrics
• You want to gradually migrate from exporters to Telegraf
• You’re running on systems where outbound HTTP push is restricted

Operational details:

• Metrics are served in plaintext on the configured port
• Add this endpoint to your Prometheus scrape config or Last9’s agent config
• Ensure firewall rules allow access to localhost:9273 if running in containers or separate namespaces

A Quick Recap

Each method is production-ready and supports secure delivery, retries, and metric transformation via Telegraf’s processor and aggregator plugins. You can also combine methods in the same deployment if you need both push and pull semantics across environments.

Verify It's Working

Before sending metrics to any backend, it’s a good idea to confirm that Telegraf is collecting data as expected.

1. Test your configuration locally

Run Telegraf in test mode. This executes all configured input plugins once and prints the collected metrics to stdout — nothing is sent to your backend.

telegraf --test --config telegraf.conf

You should see output like:

> cpu,host=laptop usage_idle=95.2,usage_user=3.1,usage_system=1.2 1627656000000000000
> mem,host=laptop used=738197504,free=2147483648 ...

If this step fails, it’s likely a misconfigured plugin or syntax error in your config file.

2. Check for runtime errors in logs

If Telegraf is running as a service:

journalctl -u telegraf -f

Or if you’re running it directly:

telegraf --config telegraf.conf

Look for plugin load errors, failed HTTP responses, or retry loops.

3. Validate backend delivery

Once metrics are flowing, verify that your backend is receiving them:

• For Prometheus: scrape the exposed /metrics endpoint
• For HTTP targets: check API response codes or ingestion logs
• For Last9: query your metric in the UI or use the Control Plane to validate ingestion.

Collect Application, Database, and Edge Metrics with Telegraf

Here’s how you can use it in production:

Database Monitoring

Telegraf includes input plugins for MySQL, PostgreSQL, MongoDB, and more. For example, the MySQL plugin collects metrics on query throughput, connection usage, cache efficiency, and replication status:

[[inputs.mysql]]
  servers = ["user:pass@tcp(localhost:3306)/"]

With Last9, these metrics are automatically ingested and available in the UI. You get prebuilt dashboards and panels that surface key database health signals — like query latency, slow query counts, thread stats, and replica lag.

Multi-Region Metric Ingestion

In distributed setups, Telegraf agents can run in each region or availability zone and push metrics to a centralized backend.

Last9 supports globally available ingestion endpoints, so you don’t need to set up:

• Prometheus federation
• Reverse proxies
• VPN tunnels between regions

Metrics flow over secure HTTP with compression, and ingestion latency stays low, even across regions.

Edge Device Monitoring

Telegraf runs reliably on lightweight environments, including:

• ARM64 boards like Raspberry Pi
• Industrial IoT gateways
• Constrained Linux-based VMs

When paired with Last9, edge devices can stream metrics continuously without needing to manage local storage or retention windows. Metrics are ingested as-is and retained long-term, with centralized controls to drop, remap, or filter data using Last9’s Control Plane. This helps reduce noise and control storage growth, without losing fidelity at the source.

Final Thoughts

Telegraf is the agent you should reach for when:

• You want low-friction metric collection
• You're not tied to any particular backend
• You want something that just works across dev, prod, and edge

Whether you're using InfluxDB, Prometheus, or something more specialized, Telegraf gets your data there. And if you want to skip the busywork and just get insights fast, Last9 gives you a straight path to production-quality observability.