2 Pasywne i aktywne kontrole agenta

Przegląd

Ta sekcja zawiera szczegółowe informacje na temat kontroli 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 i odpowiedziami Zabbix agent oraz Zabbix agent 2 jest wyrażana przez wartość znacznika „variant”.

Sprawdzanie pasywne

Sprawdzanie pasywne to proste żądanie danych. Serwer Zabbix lub proxy żąda określonych danych (na przykład obciążenia procesora), a agent Zabbix odsyła wynik do serwera.

Sprawdzanie pasywne jest wykonywane asynchronicznie — nie trzeba otrzymać odpowiedzi na jedno żądanie przed rozpoczęciem innych sprawdzeń. Rozpoznawanie DNS również odbywa się asynchronicznie.

Proces odpytywania agenta spróbuje połączyć się ze wszystkimi adresami zwróconymi przez wyszukiwanie DNS. Gwarantuje to, że jeśli jeden adres IP jest nieosiągalny, proces odpytywania spróbuje użyć 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 liczba jednoczesnych sprawdzeń asynchronicznych wynosi 1000 (zdefiniowana przez parametr MaxConcurrentChecksPerPoller).

Liczbę asynchronicznych procesów odpytywania agentów definiuje parametr StartAgentPollers.

Żądanie serwera

Informacje na temat definicji nagłówka i długości danych można znaleźć w sekcji szczegóły 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 tym 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 i zmienia stan pozycji na nieobsługiwaną, używając określonego komunikatu o błędzie
5. Połączenie TCP zostaje zamknięte

Przełączanie awaryjne na stary protokół

Aby zapewnić możliwość współpracy serwera Zabbix lub proxy z agentami w wersjach wcześniejszych niż 7.0, które używają protokołu tekstowego, zaimplementowano przełączanie awaryjne na stary protokół.

Po ponownym uruchomieniu lub zmianie konfiguracji interfejsu kontrole pasywne są wykonywane przy użyciu protokołu JSON (wersja 7.0 i nowsze). 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 Zabbix/proxy ponownie spróbuje użyć nowego protokołu dla wszystkich interfejsów, a w razie potrzeby przełączy się 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.

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

Pobieranie listy pozycji

Żądanie agenta

Żądanie aktywnych kontroli służy do pobrania aktywnych kontroli, które mają być przetwarzane przez agenta. To żądanie jest wysyłane przez agenta podczas uruchamiania, a następnie w odstępach określonych przez 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ź dotycząca 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ć komunikatem o powodzeniu.

Na przykład:

1. Agent otwiera połączenie TCP
2. Agent żąda listy 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 wersji agenta Zabbix 7.0)

Wysyłanie zebranych danych

Wysyłanie przez agent

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

{
  "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 rosnącym licznikiem, unikatowym w ramach jednej sesji danych (identyfikowanej przez token sesji). Identyfikator ten służy do odrzucania zduplikowanych wartości, które mogą być wysyłane w środowiskach o słabej łączności.

Odpowiedź serwera

Odpowiedź dotycząca 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"
}

Na przykład:

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

Komunikat heartbeat

Agent wysyła

Komunikat heartbeat jest wysyłany przez aktywnego agenta do serwera/proxy Zabbix co HeartbeatFrequency sekund (konfigurowane 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": "7.0.0",
  "variant": 2
}

Odpowiedź przekierowania

Gdy host został ponownie przypisany, serwer może nakazać agentowi przekierowanie komunikatów heartbeat (oraz kolejnych aktywnych kontroli) do innego proxy lub wystąpienia serwera.

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

Starszy protokół XML