2 Pasywne i aktywne kontrole agenta

Przegląd

Ta sekcja zawiera szczegółowe informacje o kontrolach pasywnych i aktywnych wykonywanych przez Zabbix agent i Zabbix agent 2.

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

Protokoły Zabbix agent i Zabbix agent 2 zostały ujednolicone od wersji Zabbix 7.0. Różnica między żądaniami/odpowiedziami Zabbix agent i Zabbix agent 2 jest wyrażona przez wartość znacznika „variant”.

Pasywne sprawdzenia

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

Pasywne sprawdzenia są wykonywane asynchronicznie - nie jest wymagane otrzymanie odpowiedzi na jedno żądanie przed rozpoczęciem innych sprawdzeń. Rozwiązywanie DNS również odbywa się asynchronicznie.

Poller agenta spróbuje połączyć się ze wszystkimi adresami zwróconymi przez wyszukiwanie DNS. Zapewnia to, że jeśli jeden adres IP jest niedostępny, poller spróbuje następnego dostępnego adresu, zwiększając prawdopodobieństwo pomyślnego połączenia. To ulepszenie dotyczy zarówno serwera Zabbix, jak i proxy.

Maksymalna współbieżność asynchronicznych sprawdzeń wynosi 1000 (zdefiniowana przez MaxConcurrentChecksPerPoller).

Liczba asynchronicznych pollerów agenta jest definiowana przez parametr StartAgentPollers.

Żądanie serwera

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

{
  "request": "passive checks",
  "data": [
    {
      "key": "agent.version",
      "timeout": 3
    }
  ]
}

Odpowiedź agenta

{
  "version": "8.0.0",
  "variant": 2,
  "data": [
    {
      "value": "8.0.0"
    }
  ]
}

Na przykład, dla obsługiwanych pozycji:

1. Serwer otwiera połączenie TCP
2. Serwer wysyła <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"agent.ping","timeout":3}]}
3. Agent odczytuje żądanie i odpowiada <HEADER><DATALEN>{"version":"8.0.0","variant":2,"data":[{"value":1}]}
4. Serwer przetwarza dane, aby uzyskać wartość, w naszym przypadku '1'
5. Połączenie TCP zostaje zamknięte

Dla nieobsługiwanych pozycji:

1. Serwer otwiera połączenie TCP
2. Serwer wysyła <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"vfs.fs.size[/nono]","timeout":3}]}
3. Agent odczytuje żądanie i odpowiada <HEADER><DATALEN>{"version":"8.0.0","variant":2,"data":[{"error":"Unsupported item key."}]}
4. Serwer przetwarza dane, zmienia stan pozycji na nieobsługiwany z określonym komunikatem o błędzie
5. Połączenie TCP zostaje zamknięte

Przełączenie awaryjne na stary protokół

Aby upewnić się, że serwer lub proxy Zabbix mogą współpracować z agentami z wersji wcześniejszych niż 7.2, które używają protokołu tekstowego, zaimplementowano przełączenie awaryjne na stary protokół.

Pasywne kontrole są wykonywane z użyciem protokołu JSON (7.0 i nowsze) po restarcie lub po zmianie konfiguracji interfejsu. Jeśli w odpowiedzi nie zostanie odebrany prawidłowy JSON (agent wysłał „ZBX_NOTSUPPORTED”), Zabbix zapisze interfejs w pamięci podręcznej jako używający starego protokołu i ponowi kontrolę, wysyłając tylko klucz pozycji.

Należy pamiętać, że co godzinę serwer/proxy Zabbix ponownie spróbuje pracować z nowym protokołem na wszystkich interfejsach, w razie potrzeby przełączając się z powrotem na stary protokół.

Aktywne sprawdzenia

Aktywne sprawdzenia wymagają bardziej złożonego przetwarzania. Agent musi najpierw pobrać z serwera/proxy listę pozycji i/lub zdalnych poleceń do niezależnego przetwarzania.

Serwery/proxy, z których mają być pobierane aktywne sprawdzenia, są wymienione w parametrze 'ServerActive' w pliku konfiguracyjnym agenta. Częstotliwość odpytywania o te sprawdzenia jest ustawiana przez parametr 'RefreshActiveChecks' w tym samym pliku konfiguracyjnym. Jeśli jednak odświeżanie aktywnych sprawdzeń się nie powiedzie, ponowna próba następuje po zakodowanych na stałe 60 sekundach.

Agent następnie okresowo wysyła nowe wartości do serwera(ów). Jeśli agent otrzymał jakiekolwiek zdalne polecenia do wykonania, wynik ich wykonania również zostanie wysłany. Należy pamiętać, że wykonywanie zdalnych poleceń na aktywnym agencie jest obsługiwane od Zabbix agent 7.0.

Pobieranie listy pozycji

Żądanie agent

Żądanie aktywnych kontroli jest używane do pobrania aktywnych kontroli, które mają zostać przetworzone przez agent.
To żądanie jest wysyłane przez agent przy uruchomieniu, a następnie w odstępach RefreshActiveChecks.

{
  "request": "active checks",
  "host": "Zabbix server",
  "host_metadata": "mysql,nginx",
  "interface": "zabbix.server.lan",
  "ip": "159.168.1.1",
  "port": 12050,
  "version": "8.0.0",
  "variant": 2,
  "config_revision": 1,
  "session": "e3dcbd9ace2c9694e1d7bbd030eeef6e"
}

Odpowiedź serwer

Odpowiedź aktywnych kontroli jest wysyłana przez serwer z powrotem do agent po przetworzeniu żądania aktywnych kontroli.

{
  "response": "success",
  "config_revision": 2,
  "data": [
    {
      "key": "system.uptime",
      "itemid": 1234,
      "delay": "10s",
      "lastlogsize": 0,
      "mtime": 0
    },
    {
      "key": "agent.version",
      "itemid": 5678,
      "delay": "10m",
      "lastlogsize": 0,
      "mtime": 0,
      "timeout": "30s"
    }
  ],
  "commands": [
    {
      "command": "df -h --output=source,size / | awk 'NR>1 {print $2}'",
      "id": 1324,
      "wait": 1
    }
  ]
}

Serwer musi odpowiedzieć sukcesem.

Na przykład:

1. Agent otwiera połączenie TCP
2. Agent prosi o listę kontroli
3. Serwer odpowiada listą pozycji i zdalnych poleceń do wykonania
4. Agent analizuje odpowiedź
5. Połączenie TCP zostaje zamknięte
6. Agent rozpoczyna okresowe zbieranie danych i wykonuje zdalne polecenia (obsługiwane od Zabbix agent 7.0)

Wysyłanie zebranych danych

Wysyłanie przez agent

Żądanie danych agenta zawiera zebrane wartości pozycji oraz wartości dla wykonanych zdalnych poleceń (jeśli występują).

{
  "request": "agent data",
  "data": [
    {
      "id": 1,
      "itemid": 5678,
      "value": "7.0.0",
      "clock": 1712830783,
      "ns": 76808644
    },
    {
      "id": 2,
      "itemid": 1234,
      "value": "69672",
      "clock": 1712830783,
      "ns": 77053975
    }
  ],
  "commands": [
    {
      "id": 1324,
      "value": "16G"
    }
  ],
  "session": "8495cd52070e6ca52b371f29c8574165",
  "host": "Zabbix server",
  "version": "8.0.0",
  "variant": 2
}

Wirtualny identyfikator jest przypisywany do każdej wartości. Identyfikator wartości to prosty rosnący licznik, unikalny w obrębie jednej sesji danych (identyfikowanej przez token sesji). Ten identyfikator służy do odrzucania zduplikowanych wartości, które mogą zostać wysłane w środowiskach o słabej łączności.

Odpowiedź serwera

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

{
  "response": "success",
  "info": "processed: 2; failed: 0; total: 2; seconds spent: 0.003534"
}

Na przykład:

1. Agent otwiera połączenie TCP
2. Agent wysyła listę wartości
3. Serwer przetwarza dane i odsyła status
4. Połączenie TCP zostaje zamknięte

Komunikat heartbeat

Agent wysyła

Komunikat heartbeat jest wysyłany przez aktywny agent do serwer/proxy Zabbix co HeartbeatFrequency sekund (skonfigurowane w pliku konfiguracyjnym Zabbix agent/ agent 2).

Służy do monitorowania dostępności aktywnych kontroli.

{
  "request": "active check heartbeat",
  "host": "Zabbix server",
  "heartbeat_freq": 60,
  "version": "8.0.0",
  "variant": 2
}

Odpowiedź przekierowania

Gdy host został przypisany ponownie, serwer może polecić agentowi przekierowanie jego heartbeat (oraz kolejnych aktywnych kontroli) do innej instancji proxy lub serwer.

  {
    "response": "failed",
    "redirect": {
      "revision": 2,
      "address": "192.0.2.1:10055"
    }
  }

Starszy protokół XML