3 Pasywne i aktywne sprawdzenia agenta

Przegląd

Ta sekcja zawiera szczegóły dotyczące pasywnych i aktywnych sprawdzeń wykonywanych przez agenta Zabbix.

Zabbix używa protokołu komunikacyjnego opartego na JSON do komunikacji z agentem Zabbix.

Zobacz także: szczegóły protokołu Zabbix agent 2.

Pasywne sprawdzenia

Pasywne sprawdzenie to proste żądanie danych. Serwer lub proxy Zabbix pyta o pewne dane (na przykład obciążenie CPU), a agent Zabbix przesyła wynik z powrotem do serwera.

Żądanie serwera

Definicje nagłówka i długości danych można znaleźć w szczegółach protokołu.

<item key>

Odpowiedź agenta

<DATA>[\0<ERROR>]

Powyżej, część w nawiasach kwadratowych jest opcjonalna i jest wysyłana tylko dla pozycji nieobsługiwanych.

Na przykład, dla obsługiwanych pozycji:

  1. Serwer otwiera połączenie TCP
  2. Serwer wysyła <HEADER><DATALEN>agent.ping
  3. Agent odczytuje żądanie i odpowiada <HEADER><DATALEN>1
  4. Serwer przetwarza dane, aby uzyskać wartość, w naszym przypadku '1'
  5. Połączenie TCP jest zamykane

Dla nieobsługiwanych pozycji:

  1. Serwer otwiera połączenie TCP
  2. Serwer wysyła <HEADER><DATALEN>vfs.fs.size[/nono]
  3. Agent odczytuje żądanie i odpowiada <HEADER><DATALEN>ZBX_NOTSUPPORTED\0Cannot obtain filesystem information: [2] No such file or directory
  4. Serwer przetwarza dane, zmienia stan pozycji na nieobsługiwaną ze wskazanym komunikatem o błędzie
  5. Połączenie TCP jest zamykane

Aktywne sprawdzenia

Aktywne sprawdzenia wymagają bardziej złożonego przetwarzania. Agent musi najpierw pobrać z serwera(ów) listę pozycji do samodzielnego przetwarzania.

Serwery, z których pobierane są aktywne sprawdzenia, są wymienione w parametrze 'ServerActive' w pliku konfiguracji agenta. Częstotliwość pobierania tych sprawdzeń jest ustawiana przez parametr 'RefreshActiveChecks' w tym samym pliku konfiguracyjnym. Jednak w przypadku niepowodzenia odświeżenia aktywnych sprawdzeń, jest ponawiane po zakodowanych na stałe 60 sekundach.

Agent następnie okresowo wysyła nowe wartości do serwera(ów).

Jeśli agent znajduje się za zaporą ogniową, warto rozważyć używanie tylko aktywnych sprawdzeń, ponieważ w takim przypadku nie trzeba modyfikować zapory, aby umożliwić początkowe połączenia przychodzące.

Pobieranie listy pozycji

Żądanie agenta

Żądanie aktywnych sprawdzeń jest używane do uzyskania aktywnych sprawdzeń przetwarzanych przez agenta. To żądanie jest wysyłane przez agenta przy uruchomieniu, a następnie z interwałami RefreshActiveChecks.

{
         "request": "active checks",
         "host": "Zabbix server",
         "host_metadata": "mysql,nginx",
         "hostinterface": "zabbix.server.lan",
         "ip": "159.168.1.1",
         "port": 12050
       }
Pole Typ Wymagane Wartość
request string tak active checks
host string tak Nazwa hosta.
host_metadata string nie Wartość metryki HostMetadata lub HostMetadataItem.
hostinterface string nie Wartość metryki HostInterface lub HostInterfaceItem.
ip string nie Pierwszy adres IP ustawiony w parametrze ListenIP, jeśli ustawiony.
port number nie Wartość parametru ListenPort, jeśli ustawiony i nie jest domyślnym portem nasłuchiwania agenta.

Odpowiedź serwera

Odpowiedź na aktywne sprawdzenia jest wysyłana przez serwer z powrotem do agenta po przetworzeniu żądania aktywnych sprawdzeń.

{
         "response": "success",
         "data": [
           {
             "key": "log[/home/zabbix/logs/zabbix_agentd.log]",
             "key_orig": "log[/home/zabbix/logs/zabbix_agentd.log]",
             "itemid": 1234,
             "delay": "30s",
             "lastlogsize": 0,
             "mtime": 0
           },
           {
             "key": "agent.version",
             "key_orig": "agent.version",
             "itemid": 5678,
             "delay": "10m",
             "lastlogsize": 0,
             "mtime": 0
           }
         ]
       }
Pole Typ Wymagane Wartość
response string tak success | failed
info string nie Informacja o błędzie w przypadku niepowodzenia.
data array of objects nie Pozycje aktywnego sprawdzenia.
key string nie Klucz pozycji z rozwiniętymi makrami.
key_orig string nie Klucz pozycji bez rozwiniętych makr.
itemid number nie Identyfikator pozycji.
delay string nie Interwał aktualizacji pozycji.
lastlogsize number nie Ostatnia wielkość dziennika pozycji.
mtime number nie Czas modyfikacji pozycji.
refresh_unsupported number nie Interwał odświeżania nieobsługiwanej pozycji.
regexp array of objects nie Globalne wyrażenia regularne.
name string nie Nazwa globalnego wyrażenia regularnego.
expression string nie Globalne wyrażenie regularne.
expression_type number nie Typ globalnego wyrażenia regularnego.
exp_delimiter string nie Separator globalnego wyrażenia regularnego.
case_sensitive number nie Ustawienie wrażliwości na wielkość liter w globalnym wyrażeniu regularnym.

Serwer musi odpowiedzieć z parametrem success.

Na przykład:

  1. Agent otwiera połączenie TCP
  2. Agent prosi o listę sprawdzeń
  3. Serwer odpowiada listą pozycji (klucz pozycji, opóźnienie)
  4. Agent analizuje odpowiedź
  5. Połączenie TCP jest zamykane
  6. Agent rozpoczyna okresowe zbieranie danych

Zauważ, że (wrażliwe) dane konfiguracyjne mogą stać się dostępne dla osób mających dostęp do portu trappera serwera Zabbix przy użyciu aktywnego sprawdzenia. Jest to możliwe, ponieważ każdy może udawać aktywnego agenta i żądać danych konfiguracyjnych pozycji; uwierzytelnienie nie ma miejsca, chyba że użyjesz opcji szyfrowania.

Wysyłanie zebranych danych

Wysyłanie przez agenta

Żądanie danych agenta zawiera zebrane wartości pozycji.

{
         "request": "agent data",
         "data": [
           {
             "host": "Zabbix server",
             "key": "agent.version",
             "value": "2.4.0",
             "clock": 1400675595,
             "ns": 76808644
           },
           {
             "host": "Zabbix server",
             "key": "log[/home/zabbix/logs/zabbix_agentd.log]",
             "lastlogsize": 112,
             "value": " 19845:20140621:141708.521 Starting Zabbix Agent [<hostname>]. Zabbix 2.4.0 (revision 50000).",
             "clock": 1400675595,
             "ns": 77053975
           }
         ],
         "session": "1234456akdsjhfoui"
       }
Pole Typ Wymagane Wartość
request string tak agent data
session string tak Unikalny identyfikator sesji generowany za każdym razem, gdy agent jest uruchamiany.
data array of objects tak Wartości pozycji.
id number tak Identyfikator wartości (licznik przyrostowy używany do sprawdzania zduplikowanych wartości w przypadku problemów z siecią).
host string tak Nazwa hosta.
key string tak Klucz pozycji.
value string nie Wartość pozycji.
lastlogsize number nie Ostatnia wielkość logu pozycji.
mtime number nie Czas modyfikacji pozycji.
state number nie Stan pozycji.
source string nie Źródło dziennika zdarzeń wartości.
eventid number nie Eventid dziennika zdarzeń wartości.
severity number nie Poziom dziennika zdarzeń wartości.
timestamp number nie Znacznik czasu dziennika zdarzeń wartości.
clock number tak Znacznik czasu (sekundy od Epoki).
ns number tak Nanosekundy znacznika czasu.

Każy wartości przypisane jest wirtualne ID. ID wartości to prosty rosnący licznik, unikalny w obrębie jednej sesji danych (zidentyfikowanej przez token sesji). To ID jest używane do odrzucania zduplikowanych wartości, które mogą być wysłane w warunkach słabego połączenia.

Odpowiedź serwera

Odpowiedź na żądanie danych agenta jest wysyłana przez serwer z powrotem do agenta po przetworzeniu żądania danych agenta.

{
         "response": "success",
         "info": "processed: 2; failed: 0; total: 2; seconds spent: 0.003534"
       }
Pole Typ Wymagane Wartość
response string tak success | failed
info string tak Wyniki przetwarzania pozycji.

Jeśli wysłanie niektórych wartości nie powiedzie się na serwerze (na przykład, gdy host lub pozycja zostały wyłączone lub usunięte), agent nie będzie ponawiał próby wysłania tych wartości.

Na przykład:

  1. Agent otwiera połączenie TCP
  2. Agent wysyła listę wartości
  3. Serwer przetwarza dane i wysyła status z powrotem
  4. Połączenie TCP jest zamykane

Zauważ, jak w powyższym przykładzie stan nieobsługiwany dla vfs.fs.size[/nono] jest wskazany przez wartość "state" równą 1 i komunikat o błędzie w właściwości "value".

Komunikat o błędzie zostanie przycięty do 2048 symboli po stronie serwera.

Starszy protokół XML

Zabbix przyjmie maksymalnie 16 MB danych XML zakodowanych Base64, ale pojedyncza zdekodowana wartość nie powinna przekraczać 64 KB, w przeciwnym razie zostanie przycięta do 64 KB podczas dekodowania.