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 pyta 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": "7.0.0",
  "variant": 2,
  "data": [
    {
      "value": "7.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":"7.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":"7.0.0","variant":2,"data":[{"error":"Unsupported item key."}]}
4. Serwer przetwarza dane, zmienia stan pozycji na nieobsługiwany z określonym komunikatem błędu
5. Połączenie TCP zostaje zamknięte

Przełączenie awaryjne na stary protokół

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

Sprawdzenia pasywne są wykonywane przy użyciu protokołu JSON (7.0 i nowsze) po ponownym uruchomieniu lub po zmianie konfiguracji interfejsu.
Jeśli w odpowiedzi nie zostanie odebrany prawidłowy JSON (agent wysłał "ZBX_NOTSUPPORTED"), Zabbix zapisze interfejs jako używający starego protokołu i ponowi sprawdzenie, wysyłając tylko klucz pozycji.

Należy pamiętać, że co godzinę serwer/proxy Zabbix ponownie spróbuje używać nowego protokołu ze wszystkimi interfejsami, w razie potrzeby przechodząc z powrotem na stary protokół.

Aktywne kontrole

Aktywne kontrole 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, od których mają być pobierane aktywne kontrole, są wymienione w parametrze 'ServerActive' w pliku konfiguracyjnym agenta. Częstotliwość odpytywania o te kontrole jest ustawiana przez parametr 'RefreshActiveChecks' w tym samym pliku konfiguracyjnym. Jeśli jednak odświeżanie aktywnych kontroli zakończy się niepowodzeniem, ponowna próba następuje po na sztywno ustawionych 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 agenta

Żądanie aktywnych kontroli służy do pobrania aktywnych kontroli, które mają zostać przetworzone przez agent.
To żądanie jest wysyłane przez agenta po 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": "7.0.0",
  "variant": 2,
  "config_revision": 1,
  "session": "e3dcbd9ace2c9694e1d7bbd030eeef6e"
}

Odpowiedź serwera

Odpowiedź aktywnych kontroli jest wysyłana przez serwer z powrotem do agenta 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

Agent wysyła

Żądanie danych agenta zawiera zebrane wartości pozycji oraz wartości 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": "7.0.0",
  "variant": 2
}

Każdej wartości przypisywany jest wirtualny identyfikator. Identyfikator wartości jest prostym licznikiem rosnącym, unikalnym w obrębie jednej sesji danych (identyfikowanej przez token sesji). Ten identyfikator służy do odrzucania zduplikowanych wartości, które mogą być wysyłane w środowiskach o słabej łączności.

Odpowiedź serwera

Odpowiedź na dane 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"
}

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 serwera/proxy Zabbix co HeartbeatFrequency sekund (zgodnie z plikiem 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": "7.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 serwera.

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

Starszy protokół XML