2 Pasywne i aktywne kontrole agenta

Przegląd

W tej sekcji przedstawiono szczegółowe informacje na temat kontroli pasywnych i aktywnych wykonywanych przez Zabbix agent oraz 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 wartością 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.

Moduł odpytujący 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, moduł odpytujący 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).

Liczba asynchronicznych modułów odpytujących agenta jest definiowana przez parametr StartAgentPollers.

Żądanie serwera

Informacje na temat definicji długości nagłówka i danych znajdują się w sekcji szczegóły protokołu.

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

Odpowiedź agenta

{
  "version": "7.4.0",
  "variant": 2,
  "data": [
    {
      "value": "7.4.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 za pomocą <HEADER><DATALEN>{"version":"7.4.0","variant":2,"data":[{"value":1}]}
4. Serwer przetwarza dane, aby uzyskać wartość — w tym przypadku „1”
5. Połączenie TCP zostaje zamknięte

W przypadku 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 za pomocą <HEADER><DATALEN>{"version":"7.4.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ć serwerowi Zabbix lub proxy możliwość współpracy z agentami w wersjach starszych niż 7.2, 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, przełączając się na stary protokół, jeśli będzie to wymagane.

Kontrole aktywne

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

serwery/proxy, z których pobierane są kontrole aktywne, są wymienione w parametrze „ServerActive” w pliku konfiguracyjnym agenta. Częstotliwość żądania tych kontroli określa parametr „RefreshActiveChecks” w tym samym pliku konfiguracyjnym. Jeśli jednak odświeżenie kontroli aktywnych zakończy się niepowodzeniem, zostanie ponowione po zakodowanym na stałe czasie 60 sekund.

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. Agent wysyła to żądanie 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.4.0",
  "variant": 2,
  "config_revision": 1,
  "session": "e3dcbd9ace2c9694e1d7bbd030eeef6e"
}

Odpowiedź serwera

Odpowiedź dotycząca aktywnych kontroli jest wysyłana przez serwer 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 Zabbix agent 7.0)

Wysyłanie zebranych danych

Agent wysyła

Żą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.4.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

Wysyłany przez agenta

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.4.0",
  "variant": 2
}

Odpowiedź przekierowania

Gdy host został ponownie przypisany, serwer może nakazać agentowi przekierowanie jego 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