PDF

MQTT-Telemetrie über Telegraf in NetCrunch

In diesem Thema wird erläutert, wie über MQTT veröffentlichte Systemmetriken erfasst, mit Telegraf verarbeitet und mithilfe von JSON-basierter Telemetrie an einen NetCrunch Telemetry Node-Endpunkt weitergeleitet werden.

Übersicht

MQTT ist ein leichtgewichtiges Publish-/Subscribe-Nachrichtenprotokoll, das häufig in IoT- und verteilten Systemen verwendet wird. Telegraf kann MQTT-Themen abonnieren, eingehende JSON-Nachrichten analysieren und sie über das HTTP output plugin an einen NetCrunch Telemetry Node weiterleiten.

Unterstützung von MQTT-Telemetrie durch NetCrunch

NetCrunch empfängt MQTT-basierte Telemetriedaten über Telemetry Nodes. Diese akzeptieren Daten im JSON-Format und ordnen eingehende Metriken oder Statuswerte zu. Für Telemetry Nodes ist keine Netzwerkerkennung erforderlich, und sie können Daten aus verteilten oder isolierten Systemen empfangen.

Der Endpunkt, sein URL-Aufbau und die Art seiner Autorisierung werden einmalig unter Monitoring with Telegraf beschrieben. Im Folgenden wird vorausgesetzt, dass bereits ein Telemetry Node vorhanden ist – siehe Telemetrieknoten.

Datenfluss

  1. Metrikgenerierung - Systeme generieren Metriken mithilfe von Skripten, Anwendungen oder Monitoring-Agents.
  2. MQTT-Veröffentlichung - Metriken werden als JSON-Nachrichten in MQTT-Broker-Themen veröffentlicht.
  3. Telegraf-Abonnement - Telegraf abonniert festgelegte MQTT-Themen.
  4. Datenweiterleitung - Telegraf sendet empfangene Nachrichten an den Endpunkt des NetCrunch Telemetry Node.
  5. Verarbeitung durch NetCrunch - Eingehende Daten werden als Counter oder Alarmstatus gespeichert.

Telegraf-Konfiguration

Die primäre Konfigurationsdatei befindet sich in der Regel unter:

  • Linux: /etc/telegraf/telegraf.conf
  • Windows: C:\Program Files\Telegraf\telegraf.conf

Grundlegende Konfiguration

MQTT-Nachrichten müssen gültiges JSON enthalten, damit Telegraf sie korrekt analysieren kann.


[agent]
  interval = "30s"
  flush_interval = "30s"
  debug = false
  quiet = true


[[inputs.mqtt_consumer]]
  servers = ["tcp://localhost:1883"]
  topics = [
    "linux/kernel/errors",
    "linux/fd/usage",
    "linux/systemd/failed",
    "linux/packages/health",
    "linux/security/entropy"
  ]
  data_format = "json"
  json_name_key = "measurement_name"
  tag_keys = ["hostname"]


[[outputs.http]]
  url = "https://gw.netcrunch.io/tm/v1/SRV-001@sensor01@node100/update"
  method = "POST"
  data_format = "json"
  content_encoding = "identity"
  [outputs.http.headers]
    Content-Type = "application/json"

Konfigurationsparameter

Agent-Abschnitt

  • interval - Gibt an, wie häufig Daten erfasst werden
  • flush_interval - Gibt an, wie häufig Daten weitergeleitet werden
  • debug - Aktiviert ausführliche Debugging-Informationen
  • quiet - Unterdrückt Ausgaben, die keine Fehler betreffen

MQTT Consumer Input

  • servers - Adresse des MQTT-Brokers
  • topics - Abonnierte MQTT-Themen
  • data_format - Erwartetes Format (json)
  • json_name_key - JSON-Feld, das als Metrikname verwendet wird
  • tag_keys - Als Tags extrahierte Felder

HTTP Output

  • url - Endpunkt des NetCrunch Telemetry Node
  • method - Muss POST sein
  • data_format - Format der JSON-Nutzdaten
  • headers - HTTP-Header

MQTT-Nachrichtenformat

In MQTT-Themen veröffentlichte Nachrichten müssen JSON-Objekte sein, die relevante Metadaten und Metrikfelder enthalten.

Erforderliche Felder

  • timestamp - Zeitstempel im ISO-8601-Format
  • hostname - Systemkennung
  • Metrikfelder- Numerische oder Zeichenfolgenwerte, die Counter oder Statuswerte darstellen

Beispielnachrichten

Kernel-Fehler


{
  "timestamp": "2025-10-29T15:09:08+01:00",
  "hostname": "server01.example.com",
  "kernel_errors_5min": 0
}

Dateideskriptor-Nutzung


{
  "timestamp": "2025-10-29T15:05:12+01:00",
  "hostname": "server01.example.com",
  "total_fd_count": 1471
}

Paketstatus


{
  "timestamp": "2025-10-29T15:07:54+01:00",
  "hostname": "server01.example.com",
  "upgradable_packages": 1,
  "broken_packages": 0
}

System-Entropiestufe


{
  "timestamp": "2025-10-29T15:09:08+01:00",
  "hostname": "server01.example.com",
  "entropy_available": 256
}

Fehlgeschlagene Systemd-Einheiten


{
  "timestamp": "2025-10-29T15:06:41+01:00",
  "hostname": "server01.example.com",
  "failed_units_count": 0
}

Anwendungsfälle

Überwachung von IoT-Geräten

Geräte veröffentlichen Telemetriedaten in einem MQTT-Broker. Telegraf verarbeitet die Nachrichten und sendet sie zur Visualisierung und Alarmierung an NetCrunch.

Metriken verteilter Systeme

Systeme in entfernten Netzwerken veröffentlichen Metriken in zentralisierten MQTT-Brokern. NetCrunch empfängt Telemetriedaten, ohne dass eine direkte Verbindung erforderlich ist.

Telemetrie benutzerdefinierter Anwendungen

Anwendungen veröffentlichen strukturierte Metriken in MQTT-Themen, sodass keine HTTP-Endpunkte implementiert werden müssen.

Edge Computing

Edge-Geräte veröffentlichen Telemetriedaten lokal in einem MQTT-Broker. Telegraf aggregiert die Daten und leitet sie an NetCrunch weiter.

Mandantenfähige Überwachung

Themenstrukturen und die Extraktion von Tags ermöglichen das Weiterleiten von Metriken an separate Telemetry Nodes auf Grundlage des Mandanten oder Subsystems.

Zusammenfassung

Die Verwendung von MQTT mit Telegraf und NetCrunch stellt eine skalierbare und flexible Telemetrie-Pipeline bereit. Publisher senden JSON-Metriken an einen MQTT-Broker, Telegraf abonniert relevante Themen, und die Telemetriedaten werden mithilfe von REST-Endpunkten an NetCrunch weitergeleitet. Dieses Modell unterstützt IoT, verteilte Architekturen und benutzerdefinierte Überwachungsszenarien, ohne SNMP oder WMI zu erfordern.

brokeredgeiotjsonmqttmqtt_consumerpublish subscribepushtelegraftelemetry node