Monitoring with Telegraf

Use Telegraf, the open-source metrics agent, to collect from systems NetCrunch does not poll directly and push the results into NetCrunch as ordinary counters and statuses.

Telegraf is an open-source metrics collection agent with a large library of input plugins — web servers, databases, message brokers, cloud platforms, operating systems. NetCrunch does not replace it, and does not compete with it. It receives from it.

The agent runs next to the thing being measured, collects on its own schedule, and posts the results to a Telemetry Node endpoint in NetCrunch. From that point the values are ordinary NetCrunch data: they appear as counters and statuses on the node, they go on dashboards and into reports, and you set alerts on them exactly as you would on anything polled.

When Telegraf Is the Right Route

Native NetCrunch monitoring is the better choice when NetCrunch can reach the target and a monitor or sensor already exists for it — you get discovery, credentials management and monitoring packs for free.

Telegraf earns its place when one of these is true:

The system is behind NAT or a firewall and NetCrunch cannot open a connection to it
You would rather not hand out credentials for the monitored system at all — the agent authenticates locally and only pushes results outward
A Telegraf input plugin already exists for something NetCrunch has no native monitor for
The workload is containerised or short-lived, and there is nothing stable to point a poller at

How It Fits Together

Telegraf collects using one of its input plugins, running on or near the monitored system.
Telegraf posts the results to a Telemetry Node endpoint over HTTP.
NetCrunch stores what arrives as counters and status objects on that node.
You alert and report on those values like any other NetCrunch data.

The Telemetry Node is the piece that makes this work — it represents a data endpoint rather than a machine, needs no IP address, and is not discovered. See Telemetry Node.

Telegraf is one of three ways data can be pushed into NetCrunch rather than polled. The other two are the REST API directly, and the OpenTelemetry gateway for OTLP-compatible agents and exporters. See Telemetry in NetCrunch for how they compare.

telegraf-endpoint

The Endpoint

Every Telegraf example uses the same thing: an [[outputs.http]] block posting JSON to a Telemetry Node. Only the URL changes.

Posting to the NetCrunch cloud gateway:

[[outputs.http]]
  url = "https://gw.netcrunch.io/tm/v1/<serverId>@<sensorId>@<nodeId>/update"
  method = "POST"
  data_format = "json"
  [outputs.http.headers]
    Content-Type = "application/json"

Posting to your own server instead:

[[outputs.http]]
  url = "https://<nc-server>/api/rest/1/sensors/<sensorId>@<nodeId>/update"
  method = "POST"
  data_format = "json"

The three identifiers come from the Telemetry Node itself. nodeId and sensorId are assigned when you create the node — the sensor is created with it and cannot be removed. serverId identifies your NetCrunch server to the cloud gateway and is only needed for the gw.netcrunch.io form. See Telemetry Node.

Treat the URL as a Secret

The post carries no API key. The identifiers embedded in the URL are what authorizes it, which means anyone holding that URL can write data into your atlas. It is not the management API key described in the REST API chapter, and it does not inherit a user's access rights.

Give each Telegraf host its own Telemetry Node rather than sharing one URL across an estate. A shared URL cannot be revoked for one host without breaking every host, and the data all lands on one node.

A single Telegraf agent can post to several NetCrunch servers at once — repeat the [[outputs.http]] block, once per destination.

Worked Examples

NGINX Monitoring via Telegraf in NetCrunch: Collecting NGINX metrics with the Telegraf NGINX plugin — an example telegraf.conf, the metrics collected, and how to handle multiple instances and HTTPS.
Linux Sysctl Filesystem Monitoring via Telegraf in NetCrunch: Linux kernel filesystem limits from /proc/sys/fs — file descriptors, inodes, the dentry cache and asynchronous IO. The input plugin needs no configuration at all.
SQL Server Monitoring via Telegraf in NetCrunch: Microsoft SQL Server through its Dynamic Management Views, including Azure SQL Database, Managed Instance and Elastic Pool — the monitoring login to create, and the connection strings.
Azure Resource Monitoring using Telegraf in NetCrunch: Any Azure resource that publishes to Azure Monitor, by resource, resource group or whole subscription — no VPN or inbound access from NetCrunch to Azure required.
MQTT Telemetry via Telegraf in NetCrunch: Subscribing to MQTT topics and forwarding what publishers send — for IoT, edge devices and anything that would rather publish than expose an endpoint.

agentinfluxdatainput pluginintegrationmetricsnginxpluginpushtelegraftelemetrytelemetry node