Jitterbit Private Agent Fehlersuche

Einführung

Diese Seite bietet Fehlersuche für verschiedene Probleme, die beim Ausführen eines privaten Agents auftreten können. Kontaktieren Sie Jitterbit Support für Probleme, die hier nicht aufgeführt sind.

Jitterbit Private Agent läuft nicht oder ist gestoppt oder nicht erreichbar

Die Fehlermeldung Agent Not Running or Unreachable kann durch folgende Faktoren verursacht werden:

Sie verwenden eine ältere Version des Agents.

Lösung: Aktualisieren Sie auf die neueste Version des Agents.
Die Jitterbit-Dienste laufen nicht.

Lösung: Dienste können in %windir%\system32\services.msc gestartet werden; ODER

Lösung: Im Installationsverzeichnis finden Sie ein StartServices.bat-Skript, das die relevanten Dienste startet; ODER

Lösung: Für Windows finden Sie im Startmenü eine Option zum Starten der Jitterbit-Dienste.

In der Regel finden Sie einen Fehler beim Neustart, wenn ein Dienst nicht startet.
- Für Windows: Suchen Sie nach einem Fehler in C:\Program Files (x86)\Jitterbit Agent\log. Stellen Sie sicher, dass sie als Lokales System ausgeführt werden, und überprüfen Sie das Ereignisprotokoll auf Fehlermeldungen.
- Für Linux: Suchen Sie nach einem Fehler in /opt/jitterbit/log.
Hinweis

Ersetzen Sie USERNAME durch Ihren aktuellen Benutzernamen.

Berechtigungen: Das Konto, unter dem die Jitterbit-Dienste ausgeführt werden, muss ein lokaler Administrator auf dem Computer sein und vollen Zugriff auf den Jitterbit-Ordner haben.
Dienste laufen, können jedoch nicht mit Jitterbit Cloud kommunizieren.

Lösung: Überprüfen Sie:
- Ob das Internet funktioniert.
- Die Protokolldatei, um zu sehen, ob es eine offensichtliche Fehlermeldung gibt:
  - Für Windows: C:\Program Files (x86)\Jitterbit Agent\log\jitterbit-agent.log.
  - Für Linux: /opt/jitterbit/log/jitterbit-agent.log.
Proxy-Probleme können ebenfalls die Fehlermeldung "Agent nicht ausgeführt" oder "Nicht erreichbar" verursachen. Die Fehlersuche ist etwas schwieriger, da es so viele verschiedene Netzwerk-Konfigurationen gibt.

Lösung: Während der Installation müssen Sie möglicherweise das Kontrollkästchen für den Negotiate Ntlm Proxy aktivieren oder deaktivieren. Dies hängt davon ab, welchen Proxy Sie verwenden. Es ist auch sehr hilfreich, das Protokoll der abgelehnten Anfragen vom Proxy-Server zu sehen.

Jitterbit privater Agent zeigt unterschiedliche Versionen oder IPs an

Problem

Die Agenten Seite in der Management-Konsole kann unterschiedliche Versionen und/oder IPs für einen privaten Agenten anzeigen. Nach dem Neustart der Agentendienste kann die Agenten-Seite zunächst die "korrekte" Version/IP anzeigen und dann wieder ständig hin und her wechseln.

Ursache des Problems

Der Agenten-Server wurde wahrscheinlich geklont. Der geklonte Server läuft parallel und kollidiert mit dem Haupt-Agenten-Server. Sie können nicht mehrere Server unter denselben Agenten-Anmeldeinformationen betreiben.

Schritte zur Fehlersuche und -behebung

Schalten Sie die Hauptserver-Maschine, die die offizielle Version ausführt, aus, warten Sie 10 Minuten und aktualisieren Sie dann die Agenten-Seite in der Management-Konsole. Wenn der Status des Agenten von gestoppt auf laufend wechselt, bedeutet dies, dass eine andere Instanz des Agenten läuft. Die Agenten arbeiten entweder abwechselnd oder gleichzeitig.
Um das Problem zu beheben, ist es notwendig, die Instanz zu finden, die unter der alten Version läuft, und diesen Server auszuschalten.
Wenn Sie das nicht tun können, deinstallieren Sie den offiziellen Agenten, erstellen Sie einen neuen Agenten mit einem anderen Namen und installieren Sie ihn auf dem offiziellen Server.
Überprüfen Sie, ob der neue Agent läuft, wie auf der Agenten-Seite in der Management-Konsole aufgeführt.
Löschen Sie den alten Agenten von der Agenten-Seite über das Dropdown-Menü Aktion > Entfernen.

Verbindungs-, Websocket- und I/O-Fehler bei Jitterbit privaten Agenten, die Azure-VMs verwenden

Übersicht

Diese Seite bietet Anweisungen zur Fehlersuche bei einem auf einer Microsoft Azure-virtuellen Maschine (VM) installierten privaten Agenten. (Siehe Leistungsoptimierung des privaten Agenten für allgemeine Informationen zur Leistungsoptimierung.)

Fehlersuche bei verlorenen Verbindungen

Bei der Verwendung eines auf einer Microsoft Azure-VM installierten privaten Agenten können verlorene Verbindungen auftreten. Azure setzt die WebSocket-Leerlaufzeit auf 4 Minuten, während der Standardwert des privaten Agenten für das Pingen von Harmony auf 5 Minuten eingestellt ist. Um dieses Problem zu lösen, reduzieren Sie das Intervall für den Agenten-Herzschlag:

Öffnen Sie die Datei jitterbit-agent-config.properties in einem Texteditor. Diese Datei befindet sich in den folgenden Verzeichnissen:
- Linux: <JITTERBIT_HOME>/Resources/
- Windows: C:\Program Files\Jitterbit Agent\Resources

Suchen Sie die Einstellung agent.heart.beat.interval:

#Agent heart beat interval (IN MINUTES)
agent.heart.beat.interval=5

Ändern Sie die Einstellung in agent.heart.beat.interval=3.
Speichern Sie die Änderungen und starten Sie den Agenten neu.

Fehlersuche bei Websocket- und I/O-Fehlern

Wichtig

Planen Sie, dass die folgenden Schritte über 30 Minuten in Anspruch nehmen.

Fehler im Zusammenhang mit WebSocket und I/O können durch Aktualisierungen der Leerlaufzeit des zugehörigen IPs der VM, der TCP-Leerlaufzeit des NAT-Gateways und der Timeout-Einstellungen für den virtuellen Netzwerkfluss (VNET) behoben werden.

Die Werte für die IP-Leerlaufzeit, die TCP-Leerlaufzeit des NAT-Gateways und die VNET-Flusszeit müssen alle auf 15 Minuten eingestellt werden.

Relevante Fehler identifizieren

WebSocket- und I/O-Fehler können durch Verweis auf die Betriebsprotokolle und die Datei jitterbit-agent.log identifiziert werden. Diese Protokolldatei befindet sich an einem der folgenden Standorte:

Für Windows: C:\Program Files (x86)\Jitterbit Agent\log\jitterbit-agent.log.
Für Linux: /opt/jitterbit/log/jitterbit-agent.log.

Fehler im Betriebsprotokoll

Falls vorhanden, können folgende Nachrichten im Betriebsprotokoll für einen Vorgang mit dem Status Fehler auf einen WebSocket- oder I/O-Fehler hinweisen:

Der Vorgang "Beispielvorgang" wurde erfolgreich abgeschlossen.

Keine Nachricht gefunden beim Entfernen der Nachricht aus dem Cache für: Nachrichteninfo: AgentId: 000001 AgentGroupId: 000001 MessageId: XXX Nachrichtenversion (Agent): XXXX Nachrichtenversion (Harmony): XXX Zähler (Harmony): 1 Eingereichtes Zeitstempel (Harmony):2024-01-20 11:55:00.700 , Nachricht wird später erneut versucht OperationInstanceGUID: XXX

Die Ausführungsnachricht konnte den Agenten nicht erreichen.

Fehler in der Agentenprotokolldatei

Falls vorhanden, können folgende Nachrichten in der jitterbit-agent.log-Datei auf einen WebSocket- oder I/O-Fehler hinweisen:

2024-01-20 12:00:00 Anforderungsbehandlungs-Thread #10642  INFO org.jitterbit.integration.server.api.util.AgentRetryExecutor:53 - Empfang der Agentennachricht (OperationInstanceGUID: XXX) fehlgeschlagen. Wiederhole....
2024-01-20 12:00:00 Anforderungsbehandlungs-Thread #10642 ERROR org.jitterbit.integration.server.api.util.AgentRetryExecutor:55 - org.springframework.web.client.ResourceAccessException: I/O-Fehler bei PUT-Anforderung für "https://na-east.jitterbit.com/jitterbit-cloud-restful-service/agent/ackmsgreceipt": Lesezeitüberschreitung; geschachtelte Ausnahme ist java.net.SocketTimeoutException: Lesezeitüberschreitung

E:2024-01-20 12:00:00 Anforderungsbehandlungs-Thread #884 ERROR org.jitterbit.integration.server.messaging.agent.listener.AgentMessageListener:231 - Keine Nachricht gefunden beim Entfernen der Nachricht aus dem Cache für: Nachrichteninfo: AgentId: 000001 AgentGroupId: 000001 MessageId: XXX Nachrichtenversion (Agent): XXXX Nachrichtenversion (Harmony): XXX Zähler (Harmony): 1 Eingereichtes Zeitstempel (Harmony): 2024-01-20 11:55:00.700 , Nachricht wird später erneut versucht OperationInstanceGUID: XXX

Wichtig

Fahren Sie nur fort, wenn ein WebSocket- oder I/O-Fehler in den Betriebsprotokollen oder Agentenprotokollen basierend auf den oben genannten Kriterien identifiziert wurde.

Agenten stoppen

Drain stop den Agenten, bevor Sie irgendwelche Timeout-Einstellungen aktualisieren. Wenn Sie mehr als einen Agenten in der betroffenen Agentengruppe haben, tun Sie dasselbe für alle.

Isolieren der Agentenressourcen

Es wird empfohlen, dass die VM des Agenten und die zugehörigen Ressourcen in ihre eigene Ressourcengruppe in Azure getrennt werden. Dazu gehören das VNET, die IP, das NAT-Gateway, die Netzwerkschnittstelle (NIC) und die Netzwerksicherheitsgruppe (NSG), falls vorhanden.

Aktualisieren des Leerlauf-Timeouts der IP

Navigieren Sie im Azure-Portal zur Ressourcengruppe, die mit der VM des Agenten verbunden ist.
Identifizieren und klicken Sie auf das IP-Element, das mit der VM verbunden ist:
Klicken Sie auf Konfiguration und ändern Sie den Wert für Leerlauf-Timeout (Minuten) auf 15 Minuten:

Aktualisieren des TCP-Leerlauf-Timeouts des NAT-Gateways

Navigieren Sie im Azure-Portal zur Ressourcengruppe, die mit der VM des Agenten verbunden ist.
Identifizieren und klicken Sie auf das NAT-Gateway-Element, das mit der VM und der IP verbunden ist, falls vorhanden. Ein zugehöriges NAT-Gateway wird auch im Überblick des IP-Elements neben dem Feld Zugeordnet zu aufgeführt.
Klicken Sie auf Konfiguration und ändern Sie den Wert für TCP-Leerlauf-Timeout (Minuten) auf 15 Minuten.

Aktualisieren des Fluss-Timeouts des VNET

Navigieren Sie im Azure-Portal zur Ressourcengruppe, die mit der VM des Agenten verbunden ist.
Identifizieren und klicken Sie auf das VNET-Element, das mit der VM verbunden ist:
Klicken Sie im Überblick auf Konfigurieren neben Fluss-Timeout:
Aktivieren Sie im Bereich Fluss-Timeout die Einstellung Fluss-Timeout aktivieren und ändern Sie den Wert für Fluss-Timeout (Minuten) auf 15 Minuten:
Klicken Sie auf Speichern.

Agent neu starten

Starten Sie die VM des Agents im Azure-Portal neu.
Starten Sie den gestoppten Agenten neu. Siehe entweder Einen Windows-Agenten neu starten oder Einen Linux-Agenten neu starten für detaillierte Informationen.

Fehler 1722 bei Windows Jitterbit privaten Agenten

Problem

Die Installation des Windows privaten Agenten schlägt mit dieser Fehlermeldung fehl:

Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. ...

Ursache und Lösung des Problems

Es gibt mehrere Gründe, warum die Installation des privaten Agenten mit dieser Fehlermeldung fehlschlagen kann. Zwei der häufigsten Gründe sind ein Konflikt mit dem Microsoft Visual C++ Redistributable oder das Vorhandensein verbotener Zeichen im PostgreSQL-Passwort.

Microsoft Visual C++ Redistributable

Ein Konflikt mit einer vorhandenen Version des Microsoft Visual C++ Redistributable kann Fehler 1722 verursachen.

Private Agenten erfordern, dass Microsoft Visual C++ Redistributable für Visual Studio installiert ist, bevor ein privater Agent installiert wird. Microsoft enthält die gleichen redistributierbaren Dateien für Visual Studio C++ 2015, 2017 und 2019. Installieren Sie die 64-Bit-Version für Windows mit vc_redist.x64.exe.

Verbotene PostgreSQL-Passwortzeichen

Ein PostgreSQL-Passwort, das verbotene Zeichen verwendet, kann Fehler 1722 verursachen.

Um dieses Problem zu lösen, ändern Sie das Passwort in ein gültiges.

IPv6-Problem bei Windows Jitterbit privaten Agenten

Übersicht

Einige Kunden haben Probleme festgestellt, wenn das Internetprotokoll der Version 6 (IPv6) aktiviert ist. In diesen Fällen empfehlen wir, IPv6 und IP Helper zu deaktivieren.

IPv6 deaktivieren

Um IPv6 zu deaktivieren:

Öffnen Sie unter Windows die Systemsteuerung > Netzwerk und Internet > Netzwerkverbindungen.
Öffnen Sie die Eigenschaften einer Verbindung.
Deaktivieren Sie das Kontrollkästchen für Internetprotokoll Version 6 (TCP/IPv6):

IP-Helfer deaktivieren

Um den IP-Helfer zu deaktivieren:

Öffnen Sie unter Windows Dienste.
Suchen Sie IP-Helfer in der Liste der Dienste. Klicken Sie dann mit der rechten Maustaste auf IP-Helfer und wählen Sie Eigenschaften.
Klicken Sie in den Eigenschaften des IP-Helfers auf Stop, um den Dienst zu stoppen, und ändern Sie den Starttyp auf Deaktiviert:

Apache-Serverfehler bei Jitterbit-privaten Agenten

Wenn Sie diese Fehlermeldung erhalten:

No Installed ConfigArgs for the Service "Jitterbit Apache Server"

bedeutet dies, dass der Benutzer, unter dem der Jitterbit Apache-Server läuft, keinen vollständigen Zugriff auf den Jitterbit-Ordner hat.

PostgreSQL-Fehler bei Windows Jitterbit-privaten Agenten

Problem

In bestimmten Fällen, nachdem ein Windows-privater Agent deinstalliert wurde und anschließend versucht wird, den Agenten erneut zu installieren, können Benutzer einen Fehler im Zusammenhang mit der PostgreSQL-Datenbank erhalten.

Ursache des Problems

Dieser Fehler tritt häufig auf Systemen auf, bei denen die PostgreSQL-Installation, die mit dem privaten Agenten verbunden ist, nicht vollständig entfernt wurde.

Lösung

Um den Fehler zu beheben, sollten Benutzer die in Einen Windows-privaten Agenten deinstallieren beschriebenen Schritte befolgen, um das Jitterbit PostgreSQL-Benutzerkonto vollständig zu entfernen.

Sobald dies erledigt ist, sollten Sie in der Lage sein, eine neue Agenteninstallation abzuschließen. Wenn Sie weiterhin Probleme haben, wenden Sie sich bitte an den Support.

Installation von 64-Bit-Windows-Jitterbit-privaten Agenten mit Zwei-Faktor-Authentifizierung (TFA) nicht möglich

Problem

Es ist ein bekanntes Problem, dass 64-Bit Windows private Agenten nicht installiert werden können, wenn die Zwei-Faktor-Authentifizierung (TFA) aktiviert ist. Wenn TFA aktiv ist, schlägt die Installation eines 64-Bit Windows privaten Agenten fehl und es wird ein Fehlermeldungsdialog angezeigt.

Workaround

Um dieses Problem zu umgehen, deaktivieren Sie vorübergehend die TFA und installieren Sie den 64-Bit Windows privaten Agenten. Nach der Installation aktivieren Sie die TFA erneut.

Die TFA kann in den Einstellungen der Organisation deaktiviert und aktiviert werden, die über die Seite Organisationen der Management-Konsole zugänglich ist.

Verbindungsslots-Fehler mit Windows 64-Bit Jitterbit privaten Agenten

Problem

Dieser Fehler tritt bekanntlich bei Windows 64-Bit privaten Agenten auf, die vor der Harmony 10.14-Version installiert wurden:

Failed to connect to back-end database "TranDb"
FATAL: remaining connection slots are reserved for non-replication superuser
connections
(0) SQL Error! SQLSTATE = 53300 Native err = 210 msg = FATAL: remaining connection slots are reserved for non-replication superuser connections
(1) SQL Error! SQLSTATE = IM006 Native err = 0 msg = [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed
Details:
Unable to connect to database using connection string:
UID=jitterbit;PWD=<REMOVED>;SERVER=127.0.0.1;DRIVER={PostgreSQL ODBC
Driver(UNICODE)};DATABASE=TranDb;Port=6543;!

Lösung

Um dieses Problem zu beheben, erhöhen Sie die Einstellungen max_connections und checkpoint_timeout in der Datei postgresql.conf auf dem Windows 64-Bit privaten Agenten, indem Sie die folgenden Schritte ausführen:

Erstellen Sie eine Sicherungskopie Ihrer Datei postgresql.conf und speichern Sie sie an einem anderen Ort. Diese Datei befindet sich im Verzeichnis C:\Program Files\PostgreSQL\*\data.
Öffnen Sie die Datei postgresql.conf in einem Texteditor.

Suchen Sie die Einstellung max_connections.

# - Connection Settings -

listen_addresses = '*'      # what IP address(es) to listen on;
                    # comma-separated list of addresses;
                    # defaults to 'localhost'; use '*' for all
                    # (change requires restart)
port = 6543             # (change requires restart)
max_connections = 100           # (change requires restart)
#superuser_reserved_connections = 3 # (change requires restart)
#unix_socket_directories = ''   # comma-separated list of directories

Ändern Sie diese Einstellung in max_connections = 400.

Suchen Sie die Einstellung checkpoint_timeout.

# - Checkpoints -

#checkpoint_timeout = 5min      # range 30s-1d
#max_wal_size = 1GB
#min_wal_size = 80MB

Ändern Sie diese Einstellung in checkpoint_timeout = 1h und löschen Sie das Kommentarzeichen (#) am Anfang der Zeile.
Speichern Sie Ihre Änderungen und starten Sie den Agenten neu.

Wiederherstellung einer fehlgeschlagenen Installation des privaten Agenten unter Windows

Problem

Die Installation oder das Upgrade eines privaten Agenten unter Windows schlägt fehl.

Lösung

Aufgrund der Vielzahl möglicher Ursachen ist die einfachste Lösung, die private Agentensoftware vollständig zu deinstallieren und dann neu zu installieren, wenn ein Teil des Installations- oder Upgradeprozesses fehlschlägt.

Linux-Installation ohne Root schlägt fehl

Wenn Sie Probleme bei der Installation eines privaten Agents auf Linux mit dem Linux Redhat Non-Root (x64) Installationspaket haben, überprüfen Sie, ob Folgendes zutrifft:

Der nicht-root Benutzer, der die Installation durchführt, hat sudo-Berechtigungen. Der übliche Weg, dies sicherzustellen, besteht darin, einen Systemadministrator zu bitten, den Benutzer zur wheel-Gruppe hinzuzufügen. Um zu überprüfen, in welchen Gruppen der Benutzer ist, führen Sie den Befehl groups aus.
Wenn Sie als jitterbit-Benutzer angemeldet sind, ist die Umgebungsvariable JITTERBIT_HOME auf den Installationsort gesetzt. Um dies zu überprüfen, führen Sie diesen Befehl als jitterbit aus:
```
echo $JITTERBIT_HOME
```
Das Ergebnis sollte /opt/jitterbit sein. Dies wird durch die Bash-Umgebungsdatei des jitterbit-Benutzers $HOME/.bashrc.d/jitterbit gesetzt, wenn Sie die Installationsanweisungen befolgt haben. Wenn nicht, können Sie die Umgebung schnell mit diesem Befehl setzen:
```
. /opt/jitterbit/scripts/set.env
```

Docker-Fehlerbehebung

Allgemein

Die folgenden allgemeinen Punkte können bei Docker-bezogenen Problemen hilfreich sein:

Ein Docker-privater Agent startet nicht, wenn das conf-Verzeichnis sowohl eine credentials.txt-Datei als auch eine register.json-Datei enthält.
Docker-Agents verwenden die Standardeinstellungen in der jitterbit.conf-Datei des Images. Ohne Persistenz gehen alle Änderungen, die Sie an dieser Datei innerhalb des Containers vornehmen, verloren, wenn der Container stoppt. Um Ihre eigenen Einstellungen zu verwenden, legen Sie diese in conf/jitterbit.conf ab. Diese Datei wird in den Container kopiert, wenn er startet, und überschreibt die Standarddatei.

Containerisierter Agent kann aufgrund von Authentifizierungsfehlern nicht neu gestartet werden

Wenn Ihr containerisierter Agent mit deregisterAgentOnDrainstop=true (oder der entsprechenden Umgebungsvariable AUTO_REGISTER_DEREGISTER_ON_DRAINSTOP) konfiguriert wurde und ein persistentes Volume für das Verzeichnis /opt/jitterbit/Resources des Containers verwendet, kann es sein, dass er nach dem Stoppen nicht neu gestartet werden kann.

Dies geschieht, weil der Agent beim Stoppen des Containers mit deregisterAgentOnDrainstop=true sich von Harmony abmeldet, aber die nun ungültige credentials.txt-Datei im persistenten Volume verbleibt. Beim Neustart versucht der Agent, diese veralteten Anmeldeinformationen zu verwenden, und kann sich nicht authentifizieren.

Um dies zu beheben, müssen Sie die Datei credentials.txt manuell aus dem Volume entfernen. Dies können Sie mit dem folgenden Befehl tun:

docker run -i --rm -v VOLUME_NAME:/opt/jitterbit/Resources jitterbit/agent rm -i /opt/jitterbit/Resources/credentials.txt

VOLUME_NAME: Das Docker-Volume, unter dem das persistierte Verzeichnis /opt/jitterbit/Resources gemountet wurde.

Nachdem Sie die Datei entfernt haben, starten Sie den privaten Agenten-Container neu, um eine neue Registrierung zu starten.