2 Passive and active agent checks

Übersicht

Dieser Abschnitt enthält Details zu passiven und aktiven Prüfungen, die vom Zabbix Agent und Zabbix Agent 2 durchgeführt werden.

Zabbix verwendet ein JSON-basiertes Kommunikationsprotokoll für die Kommunikation mit den Agents.

Die Protokolle von Zabbix Agent und Zabbix Agent 2 sind seit Zabbix 7.0 vereinheitlicht. Der Unterschied zwischen Anforderungen und Antworten von Zabbix Agent und Zabbix Agent 2 wird durch den Wert des Tags „variant“ ausgedrückt.

Passive Prüfungen

Eine passive Prüfung ist eine einfache Datenanforderung.
Der Zabbix-Server oder Proxy fordert Daten an (zum Beispiel die CPU-Auslastung), und der Zabbix-Agent sendet das Ergebnis an den Server zurück.

Passive Prüfungen werden asynchron ausgeführt – die Antwort auf eine Anfrage muss nicht empfangen werden, bevor andere Prüfungen gestartet werden.
Auch die DNS-Auflösung erfolgt asynchron.

Der Agent-Poller versucht, eine Verbindung zu allen von der DNS-Abfrage zurückgegebenen Adressen herzustellen.
Wenn eine IP-Adresse nicht erreichbar ist, versucht der Poller daher die nächste verfügbare Adresse. Dadurch steigt die Wahrscheinlichkeit einer erfolgreichen Verbindung.
Diese Verbesserung gilt sowohl für den Zabbix-Server als auch für den Proxy.

Die maximale Anzahl gleichzeitig ausgeführter asynchroner Prüfungen beträgt 1000 (definiert durch MaxConcurrentChecksPerPoller).

Die Anzahl der asynchronen Agent-Poller wird durch den Parameter StartAgentPollers festgelegt.

Serveranforderung

Informationen zur Definition der Header- und Datenlänge finden Sie unter Protokolldetails.

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

Agent-Antwort

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

Beispiel für unterstützte Datenpunkte:

1. Der Server öffnet eine TCP-Verbindung.
2. Der Server sendet <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"agent.ping","timeout":3}]}
3. Der Agent liest die Anfrage und antwortet mit <HEADER><DATALEN>{"version":"7.4.0","variant":2,"data":[{"value":1}]}
4. Der Server verarbeitet die Daten, um den Wert zu erhalten – in diesem Fall „1“.
5. Die TCP-Verbindung wird geschlossen.

Beispiel für nicht unterstützte Datenpunkte:

1. Der Server öffnet eine TCP-Verbindung.
2. Der Server sendet <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"vfs.fs.size[/nono]","timeout":3}]}
3. Der Agent liest die Anfrage und antwortet mit <HEADER><DATALEN>{"version":"7.4.0","variant":2,"data":[{"error":"Unsupported item key."}]}
4. Der Server verarbeitet die Daten und ändert den Status des Datenpunkts mit der angegebenen Fehlermeldung in „nicht unterstützt“.
5. Die TCP-Verbindung wird geschlossen.

Failover auf das alte Protokoll

Damit der Zabbix Server oder Proxy mit Agents aus Versionen vor 7.2 arbeiten kann, die das Klartextprotokoll verwenden, wurde ein Failover auf das alte Protokoll implementiert.

Passive Prüfungen werden nach einem Neustart oder bei einer Änderung der Schnittstellenkonfiguration mit dem JSON-Protokoll (7.0 und höher) durchgeführt.
Wenn als Antwort kein gültiges JSON empfangen wird (der Agent hat „ZBX_NOTSUPPORTED“ gesendet), speichert Zabbix die Schnittstelle als Schnittstelle mit altem Protokoll und wiederholt die Prüfung, indem nur der Datenpunktschlüssel gesendet wird.

Beachten Sie, dass der Zabbix Server/Proxy jede Stunde erneut versucht, mit allen Schnittstellen das neue Protokoll zu verwenden, und bei Bedarf auf das alte Protokoll zurückfällt.

Aktive Prüfungen

Aktive Prüfungen erfordern eine komplexere Verarbeitung.
Der Agent muss zunächst vom Server/Proxy eine Liste von Datenpunkten und/oder Remote-Befehlen zur unabhängigen Verarbeitung abrufen.

Die Server/Proxys, von denen die aktiven Prüfungen abgerufen werden, sind im Parameter „ServerActive“ der Agent-Konfigurationsdatei aufgeführt.
Die Häufigkeit, mit der diese Prüfungen abgerufen werden, wird durch den Parameter „RefreshActiveChecks“ in derselben Konfigurationsdatei festgelegt.
Wenn die Aktualisierung der aktiven Prüfungen jedoch fehlschlägt, wird sie nach fest vorgegebenen 60 Sekunden erneut versucht.

Der Agent sendet die neuen Werte anschließend regelmäßig an den bzw. die Server. Wenn der Agent Remote-Befehle zur Ausführung erhalten hat, wird auch das Ausführungsergebnis gesendet. Beachten Sie, dass die Ausführung von Remote-Befehlen auf einem aktiven Agent seit Zabbix Agent 7.0 unterstützt wird.

Liste der Datenpunkte abrufen

Agent-Anfrage

Die Anfrage für aktive Prüfungen wird verwendet, um die vom Agent zu verarbeitenden aktiven Prüfungen abzurufen. Diese Anfrage wird vom Agent beim Start und anschließend in RefreshActiveChecks-Intervallen gesendet.

{
  "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"
}

Server-Antwort

Die Antwort auf die aktiven Prüfungen wird vom Server nach der Verarbeitung der Anfrage für aktive Prüfungen an den Agent zurückgesendet.

{
  "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
    }
  ]
}

Der Server muss mit Erfolg antworten.

Beispiel:

1. Der Agent öffnet eine TCP-Verbindung
2. Der Agent fordert die Liste der Prüfungen an
3. Der Server antwortet mit einer Liste von Datenpunkten und auszuführenden Remote-Befehlen
4. Der Agent analysiert die Antwort
5. Die TCP-Verbindung wird geschlossen
6. Der Agent beginnt mit der regelmäßigen Datenerfassung und führt Remote-Befehle aus (seit Zabbix agent 7.0 unterstützt)

Senden der gesammelten Daten

Agent sendet

Die Datenanforderung des Agents enthält die erfassten Datenpunktwerte sowie die Werte der ausgeführten Remote-Befehle (falls vorhanden).

{
  "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
}

Jedem Wert wird eine virtuelle ID zugewiesen. Die Wert-ID ist ein einfacher aufsteigender Zähler, der innerhalb einer Datensitzung (identifiziert durch das Sitzungstoken) eindeutig ist. Diese ID wird verwendet, um doppelte Werte zu verwerfen, die bei schlechter Netzwerkverbindung gesendet werden könnten.

Serverantwort

Die Antwort auf die Agent-Datenanforderung wird vom Server nach der Verarbeitung der Agent-Datenanforderung an den Agent zurückgesendet.

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

Beispiel:

1. Der Agent öffnet eine TCP-Verbindung
2. Der Agent sendet eine Liste von Werten
3. Der Server verarbeitet die Daten und sendet den Status zurück
4. Die TCP-Verbindung wird geschlossen

Heartbeat-Nachricht

Agent sendet

Die Heartbeat-Nachricht wird von einem aktiven Agent alle HeartbeatFrequency Sekunden an den Zabbix Server/Proxy gesendet (konfiguriert in der Konfigurationsdatei des Zabbix Agent/Agent 2).

Sie wird verwendet, um die Verfügbarkeit aktiver Prüfungen zu überwachen.

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

Antwort zur Umleitung

Wenn ein Host neu zugewiesen wurde, kann der Server den Agent anweisen, seinen Heartbeat (und nachfolgende aktive Prüfungen) an eine andere Proxy- oder Serverinstanz umzuleiten.

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

Älteres XML-Protokoll