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 odebranie odpowiedzi na jedno żądanie przed rozpoczęciem innych sprawdzeń. Rozwiązywanie DNS również odbywa się asynchronicznie.

Agent poller będzie próbował połączyć się ze wszystkimi adresami zwróconymi przez wyszukiwanie DNS. Zapewnia to, że jeśli jeden adres IP jest nieosiągalny, poller spróbuje użyć kolejnego 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 agent pollerów jest określana 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

Na przykład 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ługiwaną z określonym komunikatem błędu
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ół.

Kontrole aktywne

Kontrole aktywne 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 kontrole aktywne, 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żenie kontroli aktywnych się nie powiedzie, ponowna próba nastąpi 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 active checks służy do pobrania aktywnych kontroli, które mają być przetwarzane przez agent. To żądanie jest wysyłane przez agent przy uruchomieniu, 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": "8.0.0",
  "variant": 2,
  "config_revision": 1,
  "session": "e3dcbd9ace2c9694e1d7bbd030eeef6e"
}

Odpowiedź serwera

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

{
  "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 żą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 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

Wiadomość heartbeat

Agent wysyła

Wiadomość heartbeat jest wysyłana przez aktywnego agenta do serwera/proxy Zabbix co HeartbeatFrequency sekund (skonfigurowane w pliku konfiguracyjnym Zabbix agent/ agent 2).

Jest używana do monitorowania dostępności aktywnych kontroli.

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

Odpowiedź przekierowująca

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

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

Starszy protokół XML