Przesyłanie danych do NetCruncha

Przeczytaj, jak wysyłać dane do NetCruncha i tworzyć niestandardowy monitor. W ten sposób można łatwo przekształcić dowolną aplikację lub skrypt w agenta NetCruncha.

Czujnik danych z agenta (Generic Agent Data Sensor)

Do dowolnego węzła można dodać czujnik ** Generic Agent ** Data z listy czujników. Konfiguracja tutaj jest bardzo minimalna. Wymaga podania nazwy, następnie automatycznie tworzy klucz API dla zewnętrznego agenta, który ma wysyłać dane do NetCruncha. Klucz API składa się z nazwy czujnika (bez spacji) i numeru identyfikacyjnego węzła. Na przykład kluczem API może być JMX@1034, jeśli nazwiemy naszego agenta "JMX".

Możesz dodać wiele czujników na jednym węźle dla każdej aplikacji, którą chcesz monitorować.

Czas retencji

Ponieważ NetCrunch nie wie, jak często zamierzasz wysyłać do niego dane, musisz określić "czas retencji" dla danych, po których dane wygasają i są usuwane z pamięci.

REST API

Chcieliśmy, aby API dla czujnika było bardzo proste. Najprostszym narzędziem, za pomocą którego można wysyłać zapytania do NetCruncha, jest projekt open-source cUrl, dostępny dla prawie każdej platformy. Możesz go znaleźć w curl.haxx.se

Interfejs API składa się tylko z 5 poleceń:

Update

POST /api/rest/1/sensors/<api-key>/update

Dane zapytania musi wysłać typ zawartości application/json:

Przykład

 {
    "retain": 1,
    "counters": {
        "PBX/line status.0" : 1,
        "PBX/line status.1" : 0
     },
     "statuses":  {
       "AC"  : "On",
       "Power": "On"
     }
 }

Jak widać, możesz wysyłać wiele statusów i liczników w jednym zapytaniu.

Status Objects

Oprócz prostych wartości statusu (par klucz-wartość), NetCrunch umożliwia śledzenie obiektów statusu. Obiekt statusu może być opisany przez obiekt JSON i może zawierać dodatkowe dane użytkownika.

Na przykład:

 { 
    "Disk C:" : {
                       "value" : "ok",
                       "message" : "Working fine",
                       "retain" : 5,
                       "critical": true,
                       "data" : { 
                           "type" : "SDD", 
                           "upTimeSec" : 123431  
                     }
               }
     }

Obiekt statusu może zawierać pola takie jak:

- Wartość - wartość statusu, która może być dowolnym ciągiem znaków, ale jeśli zostanie użyta jedna ze standardowych wartości, wówczas NetCrunch będzie mógł użyć wartości do warunków alertów obliczeniowych. Pole jest wymagane, aby rozpoznać obiekt statusu, w przeciwnym razie cały obiekt będzie traktowany jako ciąg tekstowy. Standardowe wartości to: ok, error, warning, disabled, unknown (ok, błąd, ostrzeżenie, wyłączone, nieznane).
Name - nazwa obiektu, nie musi być unikalna (opcjonalna)
Message - może to być tekst opisujący stan (na przykład informacja o błędzie) (opcjonalne)
Received - czas odczytania statusu (opcjonalne)
Retain - jak długo dany statu będzie traktowany jako aktualny w razie nieotrzymania nowszego statusu. Po upływie zadanego tu czasu, status zmieniany będzie na nieznany unknown
Class - klasa statusu. Czy historia statusu będzie zapisywana do bazy. Klasa pomaga zrozumieć dane powiązane ze statusem i poprawnie je wyświetlać.
Data - dane niestandardowe. Może to być dowolny obiekt JSON, chyba że klasa wskazuje jedną z dobrze znanych klas - wtedy musi być zgodna z formatem danych klasy.

Wyliczanie statusu czujnika

Gdy obiekt zawiera pole "Critical", będzie miał wpływ na cały stan czujnika, w przeciwnym razie status czujnika jest oparty na stanie alertu trwającego.

Każdy obiekt ustawiony na "critical": ** true ** ustawi status czujnika na najwyższy poziom alertu (błąd lub ostrzeżenie). Jeśli obiekt nie jest krytyczny ("critical": ** false **) to czujnik jest w stanie błędu tylko wtedy, gdy wszystkie obiekty są w stanie błędu i znajduje się w stanie ostrzeżenie, gdy którykolwiek z jego obiektów jest w stanie błąd lub w stanie ostrzeżenie.

Licznik

GET /api/rest/1/sensors/<api-key>/counter?<parameter-list>

Przykład

 <nc-server-address>/api/rest/1/sensors/<api-key>/counter?Temp=65&Wind=4&@retain=5

Counter/Inc, Counter/dec - Licznik rosnący lub malejący

Ponieważ NetCrunch przechowuje wartości liczników w pamięci, agent może go inkrementować bez zapisywania jego rzeczywistej wartości. Zapytanie zwiększy lub zmniejszy licznik o podaną wartość.

Przykład

 <nc-server-addres>/api/rest/1/sensors/<api-key>/counter/inc?Door.Opened=1

Status

GET /api/rest/1/sensors/<api-key>/status?<parameter-list>

Przykład

 <nc-server-address>/api/rest/1/sensors/<api-key>/status?Door=Opened&@retain=5

Przesyłanie danych do wielu węzłów - współdzielone adresy URL

Domyślnie URL danych wskazuje na pojedynczy czujnik w jednym węźle, ale w przypadku, gdy chcesz dostarczyć dane do wielu węzłów, możesz użyć współdzielonego adresu URL. Aby to zrobić, podczas dodawania czujnika użyj współdzielonego adresu URL.

Teraz twoje dane powinny mieć postać tablicy JSON, a każdy obiekt czujnika musi zawierać identyfikator węzła, którym jest nazwa DNS lub adres IP węzla, w zależności od określonego dla tego węzła ** Typu identyfikacji **.

Przykład

[ 
 {
    "node": "192.168.10.1"
     "statuses":  {
       "AC"  : "On",
       "Power": "On"
     }
 } ,
 {
    "node": "test.lab"
     "statuses":  {
       "AC"  : "Off",
       "Power": "Off"
     }
 }

]

Wiadomości przesylane przez internet

Możesz łatwo wysyłać wiadomości o zdarzeniach do NetCruncha za pomocą zapytania HTTP. Program akceptuje polecenia POST i GET. W powyższych przykładach pomijamy pierwszą część adresu URL, który jest adresem URL dostępu do sieci Web serwera NetCrunch. Zdecydowanie zalecamy skonfigurowanie serwera do korzystania z protokołu HTTPS.

Service URL

 http://<nc-server>/api/rest/1/event/<node-identification>

identyfikacją węzła jest jego adres IP lub nazwa DNS.

agentapigeneric agentgenericmonjsonmonitorobjectrestsensorstatus