Fehlerbehebung beim privaten Jitterbit-Agenten

Einführung

Auf dieser Seite finden Sie Tipps zur Fehlerbehebung bei verschiedenen Problemen, die beim Ausführen eines privaten Agenten auftreten können. Kontaktieren Sie den Jitterbit-Support für hier nicht aufgeführte Probleme.

Der private Jitterbit-Agent läuft nicht oder ist angehalten oder nicht erreichbar

Die Fehlermeldung „Agent wird nicht ausgeführt oder ist nicht erreichbar“ kann folgende Ursachen haben:

• Sie verwenden eine ältere Version des Agenten.

  • Lösung: Aktualisieren Sie auf die neueste Version des Agenten.

• Die Jitterbit-Dienste laufen nicht.

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

  

  

  • Lösung: Im Installationsverzeichnis finden Sie ein StartServices.bat Script, das die entsprechenden Dienste startet; ODER

  

  • Lösung: Unter Windows finden Sie im Startmenü eine Option zum Starten von Jitterbit Services.

  

  • Wenn ein Dienst nicht gestartet wird, tritt normalerweise beim Neustart ein Fehler auf.

    • 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 prüfen Sie das Ereignisprotokoll auf Fehlermeldungen.

    • Für Linux: Suchen Sie nach einem Fehler in /opt/jitterbit/log.

    Notiz

    Ersetzen Sie BENUTZERNAME durch Ihren aktuellen Benutzernamen.

    Berechtigungen: Das Konto, unter dem die Jitterbit-Dienste ausgeführt werden, muss ein lokaler Administrator auf dem Computer sein und Vollzugriff auf den Jitterbit-Ordner haben.

• Dienste werden ausgeführt, können aber nicht mit Jitterbit Cloud kommunizieren.

  • Lösung: Prüfen:

    • Wenn das Internet funktioniert.

    • Die Protokolldatei, um zu sehen, ob eine offensichtliche Fehlermeldung vorliegt:

      • 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 auch die Fehlermeldung „Agent läuft nicht“ oder „Nicht erreichbar“ verursachen. Die Fehlerbehebung ist etwas schwieriger, da es so viele verschiedene Netzwerkkonfigurationen gibt.

  • Lösung: Während der Installation müssen Sie möglicherweise „Negotiate Ntlm Proxy“ aktivieren oder deaktivieren. Dies hängt davon ab, welchen Proxy Sie haben. Es ist auch sehr hilfreich, das Denied Log vom Proxy-Server anzuzeigen.

Privater Jitterbit-Agent zeigt unterschiedliche Versionen oder IPs an

Ausgabe

Die Agenten-Seite in der Management Console werden möglicherweise unterschiedliche Versionen und/oder IPs für einen privaten Agenten angezeigt. Nach dem Neustart der Agentendienste zeigt die Agentenseite möglicherweise zunächst die „richtige“ Version/IP an und wechselt dann kontinuierlich hin und her.

Ursache des Problems

Der Agent-Server wurde wahrscheinlich geklont. Der geklonte Server läuft parallel und kollidiert mit dem Haupt-Agent-Server. Sie können nicht mehrere Server mit denselben Agent-Anmeldeinformationen ausführen.

Schritte zur fehlerbehebung und Lösung

1. Schalten Sie den Hauptserver mit der offiziellen Version aus, warten Sie 10 Minuten und aktualisieren Sie dann die Seite Agenten der Management Console. Wenn der Status des Agenten von „Angehalten“ auf „Wird ausgeführt“ wechselt, bedeutet dies, dass eine weitere Instanz des Agenten ausgeführt wird. Die Agenten arbeiten entweder abwechselnd oder gleichzeitig.

2. Um das Problem zu beheben, müssen Sie die Instanz finden, die unter der alten Version ausgeführt wird, und diesen Server ausschalten.

3. Wenn dies nicht möglich ist, deinstallieren Sie den offiziellen Agenten, erstellen Sie einen neuen Agenten mit einem anderen Namen und installieren Sie ihn auf dem offiziellen Server.

4. Überprüfen Sie, ob der neue Agent ausgeführt wird (siehe Liste auf der Seite „Agenten“ in der Management Console).

5. Löschen Sie den alten Agenten von der Seite „Agenten“ mithilfe der Dropdown-Liste Aktion > Entfernen.

Verbindungs-, WebSocket- und E/A-Fehler bei privaten Jitterbit-Agenten, die Azure-VMs verwenden

Übersicht

Auf dieser Seite finden Sie Anweisungen zur Fehlerbehebung bei einem privaten Agenten Linux oder Windows, installiert auf einer virtuellen Maschine (VM) von Microsoft Azure. (Siehe Private Agent-Leistungsoptimierung für allgemeine Informationen zur Leistungsoptimierung.)

Fehlerbehebung bei verlorenen Verbindungen

Wenn Sie einen privaten Agenten verwenden, der auf einer Microsoft Azure-VM installiert ist, kann es zu Verbindungsabbrüchen kommen. Azure setzt das WebSocket-Leerlauftimeout auf 4 Minuten, während der private Agent zum Pingen von Harmony standardmäßig auf 5 Minuten eingestellt ist. Um dieses Problem zu beheben, reduzieren Sie das Intervall für den Agent-Heartbeat:

1. Öffnen Sie das jitterbit-agent-config.properties Datei in einem Texteditor. Diese Datei befindet sich in diesen Verzeichnissen:

   • Linux: <JITTERBIT_HOME>/Resources/

   • Windows: C:\Program Files\Jitterbit Agent\Resources

2. Finden Sie die agent.heart.beat.interval Einstellung:

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

3. Ändern Sie die Einstellung auf agent.heart.beat.interval=3.

4. Speichern Sie die Änderungen und starten Sie den Agenten neu.

Beheben von WebSocket- und E/A-Fehlern

Fehler im Zusammenhang mit WebSocket und I/O können durch Aktualisierungen der mit der VM verbundenen IP-Leerlauftimeouts, TCP-Leerlauftimeouts des Network Address Translation (NAT)-Gateways und VNET-Flow-Timeout-Einstellungen behoben werden.

Die Werte für IP-Leerlauftimeout, TCP-Leerlauftimeout des NAT-Gateways und VNET-Flow-Timeout müssen alle auf 15 Minuten eingestellt werden.

Identifizieren relevanter Fehler

WebSocket- und E/A-Fehler können durch Bezugnahme auf die Operation identifiziert werden und die jitterbit-agent.log Datei. 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.

Vorgangsprotokollfehler

Falls vorhanden, kann jede der folgenden Meldungen in den Operation für einen Operation mit dem Status Fehler auf einen WebSocket- oder E/A-Fehler hinweisen:

The operation "Example Operation" completed successfully.

No message found while removing message in cache for: Message Info: AgentId: 000001 AgentGroupId: 000001 MessageId: XXX Message Version (Agent): XXXX Message Version (Harmony): XXX Counter (Harmony): 1 Submitted Timestamp (Harmony):2024-01-20 11:55:00.700, message will be retried later OperationInstanceGUID: XXX

Run message could not reach the agent.

Fehler in der Agent Protokolldatei

Falls vorhanden, wird eine der folgenden Meldungen im jitterbit-agent.log Datei kann auf einen WebSocket- oder E/A-Fehler hinweisen:

2024-01-20 12:00:00 request handler thread #10642  INFO org.jitterbit.integration.server.api.util.AgentRetryExecutor:53 - Agent Message Receipt (OperationInstanceGUID: XXX) failed. Retrying....
2024-01-20 12:00:00 request handler thread #10642 ERROR org.jitterbit.integration.server.api.util.AgentRetryExecutor:55 - org.springframework.web.client.ResourceAccessException: I/O error on PUT request for "https://na-east.jitterbit.com/jitterbit-cloud-restful-service/agent/ackmsgreceipt": Read timed out; nested exception is java.net.SocketTimeoutException: Read timed out

E:2024-01-20 12:00:00 request handler thread #884 ERROR org.jitterbit.integration.server.messaging.agent.listener.AgentMessageListener:231 - No message found while removing message in cache for: Message Info: AgentId: 000001 AgentGroupId: 000001 MessageId: XXX Message Version (Agent): XXXX Message Version (Harmony): XXX Counter (Harmony): 1 Submitted Timestamp (Harmony):2024-01-20 11:55:00.700, message will be retried later OperationInstanceGUID: XXX

Abflussstopp das Mittel

Ablaufstopp 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.

Agentressourcen isolieren

Es wird empfohlen, die VM des Agenten und die zugehörigen Ressourcen in Azure in eine eigene Ressourcengruppe aufzuteilen. Dazu gehören VNET, IP, NAT-Gateway, Netzwerkschnittstelle (NIC) und Netzwerksicherheitsgruppe (NSG), sofern vorhanden.

Aktualisieren Sie das Leerlauf-Timeout der IP

1. Navigieren Sie im Azure-Portal zu der Ressourcengruppe, die der VM des Agenten zugeordnet ist.

2. Identifizieren Sie das mit der VM verknüpfte IP-Element und klicken Sie darauf:

   

3. Klicken Sie auf Konfiguration und ändern Sie den Wert Leerlauf-Timeout (Minuten) auf 15 Minuten:

   

Aktualisieren Sie das TCP-Leerlaufzeitlimit des NAT-Gateways.

1. Navigieren Sie im Azure-Portal zu der Ressourcengruppe, die der VM des Agenten zugeordnet ist.

2. Identifizieren Sie das mit der VM und IP verknüpfte NAT-Gateway-Element und klicken Sie darauf, falls vorhanden. Ein verknüpftes NAT-Gateway wird auch in der Übersicht des IP-Elements neben dem Feld Verknüpft mit aufgeführt.

3. Klicken Sie auf Konfiguration und ändern Sie den Wert TCP-Leerlauftimeout (Minuten) auf 15 Minuten.

Aktualisieren des VNET-Flow-Timeouts

1. Navigieren Sie im Azure-Portal zu der Ressourcengruppe, die der VM des Agenten zugeordnet ist.

2. Identifizieren Sie das mit der VM verknüpfte VNET-Element und klicken Sie darauf:

   

3. Klicken Sie in der Übersicht neben Flow-Timeout auf Konfigurieren:

   

4. Aktivieren Sie im Bereich Flow-Timeout die Einstellung Flow-Timeout aktivieren und ändern Sie den Wert Flow-Timeout (Minuten) auf 15 Minuten:

   

5. Klicken Sie auf Speichern.

Starten Sie den Agenten neu

1. Starten Sie die VM des Agenten im Azure-Portal neu.

2. Starten Sie den gestoppten Agenten neu. Siehe entweder Windows-Agenten neu starten oder Einen Linux Agenten neu starten für detaillierte Informationen.

Fehler 1722 mit privaten Windows Jitterbit-Agenten

Ausgabe

Die Installation des privaten Windows-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 Microsoft Visual C++ Redistributable oder unzulässige Zeichen im PostgreSQL -Passwort.

Microsoft Visual C++ Redistributable

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

Private Agenten erfordern Microsoft Visual C++ Redistributable für Visual Studio 2015, 2017, 2019, die vor der Installation eines privaten Agenten installiert werden muss. Microsoft enthält dieselben weiterverteilbaren Dateien für Visual Studio C++ 2015, 2017 und 2019. Installieren Sie die 64-Bit Windows-Version mit vc_redist.x64.exe.

Unzulässige PostgreSQL Passwortzeichen

Ein PostgreSQL Passwort, das unzulässige Zeichen enthält, kann den Fehler 1722 verursachen.

Um dieses Problem zu beheben, 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 zu verwenden (wie é) oder eines dieser Zeichen im PostgreSQL -Passwort: + @ $ % & [] {} (), ; ? ^ = £.

IPv6-Problem bei privaten Windows-Jitterbit-Agenten

Übersicht

Einige Kunden hatten Probleme, wenn Internet Protocol Version 6 (IPv6) aktiviert war. In diesen Fällen empfehlen wir, IPv6 und IP Helper zu deaktivieren.

Deaktivieren von IPv6

So deaktivieren Sie IPv6:

1. Öffnen Sie unter Windows die Systemsteuerung > Netzwerk und Internet > Netzwerkverbindungen.

2. Öffnen Sie die Eigenschaften einer Verbindung.

3. Deaktivieren Sie das Kontrollkästchen für Internet Protocol Version 6 (TCP/IPv6):

   

IP-Helfer deaktivieren

So deaktivieren Sie IP Helper:

1. Öffnen Sie unter Windows Dienste.

2. Suchen Sie in der Liste der Dienste nach IP Helper. Klicken Sie dann mit der rechten Maustaste auf IP Helper und wählen Sie Eigenschaften.

3. Klicken Sie in den IP Helper-Eigenschaften auf Stopp, um den Dienst zu beenden, und ändern Sie den Starttyp in Deaktiviert:

   

Apache-Serverfehler bei privaten Jitterbit-Agenten

Wenn Sie diese Fehlermeldung erhalten:

No Installed ConfigArgs for the Service "Jitterbit Apache Server"

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

PostgreSQL Fehler mit privaten Windows Jitterbit-Agenten

Ausgabe

In bestimmten Fällen erhalten Benutzer nach der Deinstallation eines privaten Windows Agenten und dem anschließenden Versuch, den Agenten erneut zu installieren, möglicherweise einen Fehler im Zusammenhang mit der PostgreSQL -Datenbank.

Ursache des Problems

Es ist bekannt, dass dieser Fehler auf Systemen auftritt, auf denen die mit dem privaten Agenten verknüpfte PostgreSQL Installation nicht vollständig entfernt wurde.

Auflösung

Um den Fehler zu beheben, sollten Benutzer die unter Deinstallieren eines privaten Windows Agenten 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 weiterhin Probleme auftreten, kontaktieren Sie bitte den Support.

64-bit Windows-Jitterbit-Privatagenten mit Zwei-Faktor-Authentifizierung (TFA) können nicht installiert werden

Ausgabe

Es ist ein Bekanntes Problem, dass private 64-Bit Windows Agenten nicht mit aktivierter Zwei-Faktor-Authentifizierung (TFA) installiert werden können. Wenn TFA aktiv ist, schlägt die Installation eines privaten 64-Bit Windows Agenten fehl und zeigt einen Fehlerdialog an.

Problemumgehung

Um dieses Problem zu umgehen, deaktivieren Sie TFA vorübergehend und installieren Sie den privaten 64-Bit Windows Agent. Aktivieren Sie TFA nach der Installation.

TFA kann in den Einstellungen einer Organisation deaktiviert und aktiviert werden, Zugriff über die Management Console Organisationen Seite.

Verbindungsslotfehler mit privaten 64-Bit-Jitterbit-Agenten Windows

Ausgabe

Dieser Fehler tritt bekanntermaßen bei privaten 64-Bit Windows Agenten auf, die vor der Version 10.14 von Harmony 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-Treiber-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;!

Auflösung

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

1. Erstellen Sie eine Sicherungskopie Ihrer postgresql.conf Datei und speichern Sie sie an einem anderen Ort. Diese Datei finden Sie im C:\Program Files\PostgreSQL\9.x\data Verzeichnis.

2. Öffnen Sie das postgresql.conf Datei in einem Texteditor.

3. Suchen Sie die max_connections Einstellung.

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

4. Ändern Sie diese Einstellung in max_connections = 400.

5. Finden Sie die checkpoint_timeout Einstellung.

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

6. Ändern Sie diese Einstellung in checkpoint_timeout = 1h und lösche den Kommentarmarker (#) der Zeilenanfang.

7. Speichern Sie Ihre Änderungen und starten Sie den Agenten neu.

Wiederherstellen einer fehlgeschlagenen privaten Agentinstallation unter Windows

Ausgabe

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

Auflösung

Aufgrund der Vielzahl möglicher Ursachen ist die einfachste Lösung die vollständige Deinstallation dann neu installieren die private Agentensoftware, wenn ein Teil des Installations- oder Upgradevorgangs fehlschlägt.