PDF

Telemetria MQTT za pośrednictwem Telegraf w NetCrunch

Ten temat wyjaśnia, jak zbierać metryki systemowe publikowane za pośrednictwem MQTT, przetwarzać je przy użyciu Telegraf oraz przekazywać do punktu końcowego NetCrunch Telemetry Node jako dane telemetryczne w formacie JSON.

Omówienie

MQTT to lekki protokół komunikacyjny oparty na modelu publikowanie/subskrypcja, powszechnie używany w rozwiązaniach IoT i systemach rozproszonych. Telegraf może subskrybować tematy MQTT, analizować przychodzące komunikaty JSON i przekazywać je do NetCrunch Telemetry Node za pośrednictwem wtyczki wyjściowej HTTP.

Obsługa telemetrii MQTT przez NetCrunch

NetCrunch odbiera telemetrię opartą na MQTT za pośrednictwem Telemetry Nodes, które akceptują dane w formacie JSON i rejestrują przychodzące metryki lub wartości stanu. Telemetry Nodes nie wymagają wykrywania sieci i mogą odbierać dane z systemów rozproszonych lub odizolowanych.

Punkt końcowy, jego format adresu URL oraz sposób autoryzacji opisano w Monitoring with Telegraf. Wszystkie poniższe informacje zakładają, że Telemetry Node już istnieje — zobacz Węzeł telemetryczny.

Przepływ danych

  1. Generowanie metryk - Systemy generują metryki za pomocą skryptów, aplikacji lub agentów monitorowania.
  2. Publikowanie MQTT - Metryki są publikowane jako komunikaty JSON w tematach brokera MQTT.
  3. Subskrypcja Telegraf - Telegraf subskrybuje wyznaczone tematy MQTT.
  4. Przekazywanie danych - Telegraf wysyła odebrane komunikaty do punktu końcowego NetCrunch Telemetry Node.
  5. Przetwarzanie przez NetCrunch - Przychodzące dane są przechowywane jako liczniki lub stany alertów.

Konfiguracja Telegraf

Główny plik konfiguracyjny zwykle znajduje się w lokalizacji:

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

Podstawowa konfiguracja

Komunikaty MQTT muszą być poprawnymi obiektami JSON, aby Telegraf mógł je prawidłowo analizować.


[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"

Parametry konfiguracji

Sekcja Agent

  • interval - Częstotliwość zbierania danych
  • flush_interval - Częstotliwość przekazywania danych
  • debug - Włącza szczegółowe informacje debugowania
  • quiet - Pomija dane wyjściowe inne niż błędy

Dane wejściowe MQTT Consumer

  • servers - Adres brokera MQTT
  • topics - Subskrybowane tematy MQTT
  • data_format - Oczekiwany format (json)
  • json_name_key - Pole JSON używane jako nazwa pomiaru
  • tag_keys - Pola wyodrębniane jako tagi

Dane wyjściowe HTTP

  • url - Punkt końcowy NetCrunch Telemetry Node
  • method - Musi mieć wartość POST
  • data_format - Format danych wejściowych JSON
  • headers - Nagłówki HTTP

Format komunikatów MQTT

Komunikaty publikowane w tematach MQTT muszą być obiektami JSON zawierającymi odpowiednie metadane i pola metryk.

Wymagane pola

  • timestamp - Sygnatura czasowa ISO 8601
  • hostname - Identyfikator systemu
  • Metric fields- Wartości liczbowe lub tekstowe reprezentujące liczniki lub stany

Przykładowe komunikaty

Błędy jądra


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

Użycie deskryptorów plików


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

Stan pakietów


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

Poziom entropii systemu


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

Niedziałające jednostki Systemd


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

Przypadki użycia

Monitorowanie urządzeń IoT

Urządzenia publikują dane telemetryczne w brokerze MQTT. Telegraf odbiera komunikaty i wysyła je do NetCrunch w celu wizualizacji oraz generowania alertów.

Metryki systemów rozproszonych

Systemy w zdalnych sieciach publikują metryki w scentralizowanych brokerach MQTT. NetCrunch odbiera telemetrię bez konieczności bezpośredniej łączności.

Telemetria niestandardowych aplikacji

Aplikacje publikują ustrukturyzowane metryki w tematach MQTT, eliminując konieczność implementowania punktów końcowych HTTP.

Przetwarzanie brzegowe

Urządzenia brzegowe publikują dane telemetryczne lokalnie w brokerze MQTT. Telegraf agreguje je i przekazuje do NetCrunch.

Monitorowanie wielu dzierżawców

Struktury tematów i wyodrębnianie tagów umożliwiają kierowanie metryk do oddzielnych Telemetry Nodes na podstawie dzierżawcy lub podsystemu.

Podsumowanie

Użycie MQTT wraz z Telegraf i NetCrunch zapewnia skalowalny i elastyczny potok telemetryczny. Wydawcy wysyłają metryki JSON do brokera MQTT, Telegraf subskrybuje odpowiednie tematy, a telemetria jest przekazywana do NetCrunch za pomocą punktów końcowych REST. Ten model obsługuje rozwiązania IoT, architektury rozproszone i niestandardowe scenariusze monitorowania bez konieczności używania SNMP lub WMI.

brokeredgeiotjsonmqttmqtt_consumerpublish subscribepushtelegraftelemetry node