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 den 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 läuft nicht oder ist nicht erreichbar" 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, wenn ein Dienst nicht startet, finden Sie während des Neustarts einen Fehler.
  - 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 vollständigen Zugriff auf den Jitterbit-Ordner haben.
Dienste laufen, können aber 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 hierbei 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 haben. Es ist auch sehr hilfreich, das Protokoll der abgelehnten Anfragen vom Proxy-Server zu sehen.

Jitterbit privater Agent zeigt unterschiedliche Versionen oder IPs

Problem

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

attachment

Ursache des Problems

Der Agent-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 ausführen.

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 Agents-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 lösen, 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 Agents-Seite in der Management-Konsole aufgeführt.
Löschen Sie den alten Agenten von der Seite "Agenten" über das Dropdown-Menü Aktion > Entfernen.

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

Übersicht

Diese Seite bietet Anweisungen zur Fehlersuche bei einem auf einer Microsoft Azure-virtuellen Maschine (VM) installierten Linux- oder Windows-Privatagenten. (Siehe Leistungsoptimierung für Privatagenten für allgemeine Informationen zur Leistungsoptimierung.)

Fehlersuche bei verlorenen Verbindungen

Bei der Verwendung eines auf einer Microsoft Azure-VM installierten Privatagenten können verlorene Verbindungen auftreten. Azure setzt die WebSocket-Leerlaufzeit auf 4 Minuten, während der Standardwert für den Ping an Harmony beim Privatagenten 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 Herzschlagintervall (IN MINUTEN)
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 der zugehörigen IP der VM, der TCP-Leerlaufzeit des NAT-Gateways und der Einstellungen für die Flusszeitüberschreitung des virtuellen Netzwerks (VNET) behoben werden.

Die Werte für die IP-Leerlaufzeit, die TCP-Leerlaufzeit des NAT-Gateways und die VNET-Flusszeitüberschreitung 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 Speicherorte:

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 im 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. Erneuter Versuch....
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 im 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.

Agent stoppen

Agent stoppen Sie 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.

Agentenressourcen isolieren

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 Sie das Leerlauf-Timeout der IP

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

Aktualisieren Sie das TCP-Leerlauf-Timeout des NAT-Gateways

Navigieren Sie im Azure-Portal zur Ressourcengruppe, die mit der VM des Agenten verbunden ist.
Identifizieren Sie 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 Sie das Fluss-Timeout des VNET

Navigieren Sie im Azure-Portal zur Ressourcengruppe, die mit der VM des Agenten verbunden ist.
Identifizieren Sie das VNET-Element, das mit der VM verbunden ist, und klicken Sie darauf:
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 mit 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 könnte. 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, verwenden Sie kein Pluszeichen (+) als Teil des PostgreSQL-Passworts bei der Installation eines privaten Agenten. Die Mindestanzahl von Zeichen für ein PostgreSQL-Passwort beträgt acht (8). Wir empfehlen, keine Akzentzeichen (wie é) oder eines dieser Zeichen im PostgreSQL-Passwort zu verwenden: + @ $ % & [] {} () , ; ? ^ = £ \ |.

IPv6-Probleme bei Windows Jitterbit-Privatagenten

Ü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 Helper deaktivieren

Um IP Helper zu deaktivieren:

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

Apache-Serverfehler bei Jitterbit-Privatagenten

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-Privatagenten

Problem

In bestimmten Fällen kann es nach der Deinstallation eines Windows-Privatagenten und dem anschließenden Versuch, den Agenten erneut zu installieren, zu einem Fehler im Zusammenhang mit der PostgreSQL-Datenbank kommen.

Ursache des Problems

Dieser Fehler tritt häufig auf Systemen auf, bei denen die mit dem Privatagenten verbundene PostgreSQL-Installation nicht vollständig entfernt wurde.

Lösung

Um den Fehler zu beheben, sollten die Benutzer die in Deinstallation eines Windows-Privatagenten 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.

Kann 64-Bit Windows Jitterbit private Agents mit Zwei-Faktor-Authentifizierung (TFA) nicht installieren

Problem

Es ist ein bekanntes Problem, dass 64-Bit Windows private Agents 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 private Agents fehl und es wird ein Fehlerdialog angezeigt.

Lösung

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

TFA kann in den Einstellungen der Organisation deaktiviert und aktiviert werden, die über die Management Console auf der Seite Organisationen zugänglich sind.

Verbindungsslots-Fehler mit Windows 64-Bit Jitterbit private Agents

Problem

Dieser Fehler tritt bekanntlich bei Windows 64-Bit private Agents 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 private Agent, 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\9.x\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 Agents unter Windows

Problem

Die Installation oder das Upgrade eines privaten Agents 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

Ein Docker-privater Agent startet nicht, wenn das Verzeichnis conf 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.