Fehlerbehebung für Jitterbit Private Agent

Diese Seite bietet Anleitungen zur Fehlerbehebung für häufige Probleme bei der Installation, Ausführung oder Verwaltung eines Jitterbit Private Agent. Beginnen Sie mit den Diagnoseschritten unten und suchen Sie dann nach Ihrem spezifischen Fehler im relevanten Abschnitt. Kontaktieren Sie den Jitterbit-Support für Probleme, die hier nicht aufgeführt sind.

Eine einheitliche Referenz, die Integrations-, Automatisierungs-, API-Management-, EDI- und App-Entwicklungsprobleme an einem Ort abdeckt, finden Sie im Harmony-Fehlerbehebungsleitfaden.

• System- und Betriebssystemprobleme

  • Apache-Serverfehler: Kein installiertes ConfigArgs
  • Apache/Tomcat: APPARENT DEADLOCK
  • Cleanup-Service kann gesperrte Protokolldateien unter Windows nicht entfernen
  • Linux: Agent-Services starten nach einem Neustart nicht ("postmaster.pid existiert nicht")
  • Linux: Antivirus entfernt PgBouncer, Agent kann sich nicht bei der gebündelten Datenbank authentifizieren
  • Sicherheitsscans kennzeichnen log4j-over-slf4j.jar als Log4j 1.x-Sicherheitslücke

• Docker

  • Allgemein
  • Agent kann nach der Abmeldung nicht mit Authentifizierungsfehlern neu gestartet werden

• Listening Service

  • "Cluster hat die erforderliche Mindestgröße nicht erreicht"
  • Listening Service-Meldungen nicht zugestellt

• Protokollierung

  • Benutzerdefinierte API-Operationsprotokolle werden nicht angezeigt
  • Operationsdebug-Protokollierung stoppt vor dem ausgewählten Enddatum
  • Operationsdebug-Protokolldateien fehlen .input- oder .output-Daten
  • Komponenteneingabe-/Ausgabedaten werden nicht generiert

Diagnoseschritte

Diese Schritte sind der empfohlene Ausgangspunkt für die meisten Probleme mit privaten Agenten.

Agent-Status überprüfen

Überprüfen Sie den aktuellen Status des Agenten in der Management Console unter Agents > Private und verwenden Sie ihn, um das Problem einzugrenzen. Die vollständigen Statusdefinitionen und deren Übergänge finden Sie unter Agent-Status.

Agent-Protokolldateien überprüfen

Die Agent-Protokolldateien sind die primäre Quelle für Diagnoseinformationen. Überprüfen Sie die folgende Datei auf Fehler im Zusammenhang mit Konnektivität, Service-Integrität und Operationsfehlern:

• Windows: C:\Program Files\Jitterbit Agent\log\jitterbit-agent.log
• Linux: /opt/jitterbit/log/jitterbit-agent.log

Eine vollständige Liste der verfügbaren Protokolldateien finden Sie unter Agent-Protokolle.

Agent Support Tools verwenden

Die Agent Support Tools bieten Diagnosebefehle, die direkt auf dem Agent-Host ausgeführt werden:

• connection-check: Überprüft die Konnektivität vom Agent zur Harmony Cloud, Apache und Tomcat Services.
• service-status: Zeigt den Laufzustand aller Agent-Services (Apache, Tomcat, PostgreSQL, PgBouncer, VerboseLogShipper).
• generate-report: Erstellt einen diagnostischen HTML-Bericht und eine ZIP-Datei aller Agent-Protokolldateien, nützlich bei der Eskalation an den Jitterbit-Support. Bei Linux-Agenten fehlen dem Bericht derzeit PostgreSQL-Daten; Windows-Agenten sind nicht betroffen.

Um auf die Tools zuzugreifen:

cd /opt/jitterbit/AgentSupportTools
./run.sh

cd "C:\Program Files\Jitterbit Agent\AgentSupportTools"
.\run.bat

Agent neu starten

Viele vorübergehende Probleme (veraltete Routing-Caches, Pool-Erschöpfung, Sperrbedingungen) lassen sich durch einen Service-Neustart beheben:

• Windows: Agent starten oder neu starten
• Linux: Agent starten oder neu starten

Agent-Status und Konnektivität

Agent offline oder nicht erreichbar

• Symptom: Die Registerkarte Private der Seite Agents der Management Console zeigt den Agent als Unknown oder Stopped an, oder Studio zeigt einen Agent Not Running or Unreachable-Fehler an.

• Mögliche Ursachen:

  • Die Jitterbit-Services werden nicht ausgeführt.
  • Die Services werden ausgeführt, aber der Agent-Host kann die Harmony-Cloud nicht erreichen.
  • Ein Unternehmens-Proxy verhindert die Verbindung des Agenten.

• Lösung:

  • Wenn die Jitterbit-Services nicht ausgeführt werden, starten Sie diese:

    • Windows: Siehe Windows-Agent starten.
    • Linux: Siehe Linux-Agent starten.

    Wenn der Service nicht startet, überprüfen Sie die folgenden Speicherorte auf Fehlermeldungen:

    • Windows: C:\Program Files (x86)\Jitterbit Agent\log und das Windows-Protokoll Event Viewer Application.
    • Linux: /opt/jitterbit/log.

    Das Konto, das Jitterbit-Services ausführt, benötigt lokale Administratorrechte unter Windows und vollständigen Zugriff auf das Jitterbit-Installationsverzeichnis.

  • Wenn die Services ausgeführt werden, aber die Harmony-Cloud nicht erreichen können, überprüfen Sie Folgendes:

    • Die Internetverbindung vom Agent-Host funktioniert.
    • Das Agent-Protokoll (jitterbit-agent.log) enthält keine Fehlermeldungen zur Cloud-Konnektivität.
    • Der Agent kann das Harmony-Portal auf Port 443 erreichen.

  • Wenn der Agent sich über einen Unternehmens-Proxy verbindet, überprüfen Sie, ob der Proxy korrekt für den Agent konfiguriert ist, einschließlich der NTLM-Domäne, wenn der Proxy NTLM-Authentifizierung verwendet. Siehe Proxy-Server für private Jitterbit-Agenten. Das Ablehnungsprotokoll des Proxy-Servers ist hilfreich bei der Diagnose, was der Proxy blockiert.

  • Wenn die Services des Agenten auf dem Host fehlerfrei sind (jitterbit status zeigt alle Services als ausgeführt an), aber der Agent wiederholt zu Unknown wechselt oder zwischen Running, Unknown und Stopped wechselt, wird die Verbindung oder der Prozess des Agenten wahrscheinlich zwischen den Heartbeats unterbrochen. Überprüfen Sie die folgenden möglichen Ursachen:

    • Ein Netzwerkgerät (Firewall, NAT-Gateway oder Cloud-VM-Idle-Timeout) kann die ausgehende Verbindung des Agenten zwischen den Heartbeats schließen. Versuchen Sie, das Heartbeat-Intervall des Agenten zu reduzieren (agent.heart.beat.interval). Für Cloud-gehostete Agenten siehe Azure VM: Verlorene Verbindungen und WebSocket/I/O-Fehler, was auch für andere eingeschränkte Netzwerke wie AWS gilt.
    • Der Agent kann unter Speicherdruck abgestürzt sein. Überprüfen Sie auf OutOfMemoryError oder hs_err_pid-Crash-Dump-Dateien. Siehe Java-Heap-Speicher: OutOfMemoryError.
    • Wenn die Agenten kürzlich zu einem neuen Betriebssystem migriert wurden und dabei eine Agent-Gruppe wiederverwendet wurde, die zuvor Agenten auf dem alten Betriebssystem gehostet hat, kann die wiederverwendete Gruppe die Ursache sein. Siehe Agent zeigt Unknown oder Stopped nach Wiederverwendung einer Agent-Gruppe über Betriebssysteme hinweg.

Agent zeigt unterschiedliche Versionen oder IP-Adressen an

• Symptom: Die Registerkarte Private der Seite Agents der Management Console zeigt unterschiedliche Versionen oder IP-Adressen für einen privaten Agent an, oder die Werte wechseln nach dem Neustart der Services hin und her.
• Mögliche Ursache: Die Host-Maschine des Agenten wurde möglicherweise auf Infrastrukturebene dupliziert (z. B. ein VM-Klon, Disk-Image, Machine-Template oder Snapshot, der nach der Installation und Registrierung des Agenten erstellt wurde). Der duplizierte Host trägt die gleichen Agent-credentials.txt, daher authentifizieren sich beide Hosts bei Harmony als derselbe Agent und laufen parallel, was zu Kollisionen führt. Zwei Agenten können nicht gleichzeitig unter den gleichen Anmeldedaten ausgeführt werden.
• Lösung:
  1. Bestätigen Sie, dass ein Duplikat ausgeführt wird. Stoppen Sie den Agent auf dem Host, den Sie behalten möchten, warten Sie 10 Minuten, und aktualisieren Sie dann die Registerkarte Private der Seite Agents der Management Console. Wenn der Agent von Stopped zurück zu Running wechselt, meldet sich ein anderer Host unter der gleichen Identität.
  2. Identifizieren und fahren Sie den doppelten Host herunter.
  3. Wenn der doppelte Host nicht heruntergefahren werden kann, deinstallieren Sie den Agent, erstellen Sie einen neuen Agent mit einem anderen Namen, und installieren Sie ihn auf dem Host, den Sie behalten möchten.
  4. Überprüfen Sie, dass der neue Agent auf der Registerkarte Private der Seite Agents der Management Console als Running aufgeführt ist.
  5. Löschen Sie den alten Agent-Eintrag mit Actions > Remove.

Agent zeigt Unknown oder Stopped an, nachdem eine Agent-Gruppe über Betriebssysteme hinweg wiederverwendet wird

• Symptom: Nach der Migration von privaten Agents auf ein anderes Betriebssystem (z. B. Windows zu Linux) bei Wiederverwendung derselben Agent-Gruppe zeigen die migrierten Agents auf der Registerkarte Private der Seite Agents der Management Console intermittierend als Unknown oder Stopped an, obwohl jitterbit status zeigt, dass die Services laufen und Operationen normal ausgeführt werden.
• Mögliche Ursache: Die Wiederverwendung einer Agent-Gruppe aus dem vorherigen Betriebssystem kann Metadaten hinterlassen, die die Statusmeldung für die neuen Agents beeinträchtigen. Der Effekt ist typischerweise kosmetisch: Services und Operationen laufen weiterhin normal.
• Lösung: Erstelle stattdessen eine neue, saubere Agent-Gruppe für die migrierten Agents, anstatt die Gruppe aus dem vorherigen Betriebssystem wiederzuverwenden, und registriere die Agents dort.

Agent-Synchronisierungsfehler: Projektänderungen werden nicht angewendet

• Symptom: Nach dem Bereitstellen von Änderungen in Studio führt der Agent weiterhin die vorherige Version des Projekts aus, oder eine Operation schlägt fehl, weil eine neu hinzugefügte Verbindung auf dem Agent nicht gefunden wird.

• Mögliche Ursachen:

  • Die Bereitstellung verwendete Configurable Deploy, das nur die ausgewählten Workflows und Operationen bereitstellt. Alle Teile des Projekts außerhalb dieser Auswahl bleiben in ihrer zuvor bereitgestellten Version auf dem Agent.
  • Die Komponente wird nicht im logischen Ablauf eines bereitgestellten Workflows verwendet. Nicht verwendete Komponenten werden nicht bereitgestellt, daher wird eine Verbindung, auf die keine bereitgestellte Operation verweist, nicht an den Agent gesendet.
  • Ein Netzwerk-Timeout oder Autorisierungsfehler ist während der Synchronisierung aufgetreten.
  • Unzureichender Speicherplatz auf dem Agent-Host hat verhindert, dass die synchronisierten Projektdateien geschrieben werden.

• Lösung:

  • Stelle das vollständige Projekt erneut bereit: Verwende in Studio Deploy, das alle Operationen des Projekts bereitstellt, anstatt ein Configurable Deploy nur ausgewählter Workflows oder Operationen.
  • Starte die Agent-Services neu, um eine Neusynchronisierung aller bereitgestellten Projekte zu erzwingen.
  • Überprüfe die Agent-Protokolle auf synchronisierungsbezogene Netzwerk-Timeouts oder Autorisierungsfehler.
  • Überprüfe den verfügbaren Speicherplatz auf dem Agent-Host. Ein voller oder fast voller Speicher kann den Agent daran hindern, synchronisierte Projektdateien zu schreiben. Siehe Speicherplatz und Protokollakkumulation.

Operationen verzögert oder in der Warteschlange nach Projektbereitstellung

• Symptom: Nach der Bereitstellung eines Projekts in Studio starten ausgelöste Operationen nicht sofort, oder es erscheint ein kurzer Rückstau von Operationen in der Warteschlange.
• Ursache: Die Umgebung ist gesperrt, während der Agent das bereitgestellte Projekt synchronisiert. Während dieses Zeitfensters können keine Operationen ausgeführt werden.
• Lösung:
  1. Um zu messen, wie lange Synchronisierungssperren andauern, durchsuche jitterbit-agent.log nach environment-deploy. Jeder Protokolleintrag enthält die Umgebungs-ID und die Synchronisierungsdauer in Millisekunden.
  2. Konsistent lange Synchronisierungszeiten deuten auf ein großes Projekt oder langsame Konnektivität zu Harmony hin. Um die Synchronisierungszeiten zu verkürzen, siehe Leistungsoptimierung der Umgebungssynchronisierung.
  3. Wenn die Synchronisierungsdauern konsistent übermäßig lang sind (mehr als ein paar Minuten), kontaktiere den Jitterbit-Support.

Agent zeigt sich als nicht leistungsfähig an

• Symptom: Operationen, die an die Agent-Gruppe übermittelt werden, werden wiederholt oder verzögert, anstatt sofort ausgeführt zu werden. ProcessEngine.log enthält wiederholte Meldungen wie:

  Agent (Id: ...) is incapable to process this message. Message will be auto-retried.
  

  Capability status changed from true to false
  

• Mögliche Ursachen:

  • Alle Worker-Threads in der Process Engine des Agenten sind bereits in Gebrauch, daher kann der Agent keine weitere Operation akzeptieren, bis ein Thread freigegeben wird. Die Pool-Größe wird durch MaxNumberOfWorkerThreads im Abschnitt [ProcessEngine] von jitterbit.conf festgelegt.
  • Eine optionale Capability-Metrik ist aktiviert und hat ihren Schwellenwert erreicht. CPU-Auslastung, Speicherauslastung und Apache-Thread-Auslastung können jeweils zum Capability-Status beitragen, aber alle drei sind standardmäßig deaktiviert und gelten nur, wenn sie im Abschnitt [AgentCapability] von jitterbit.conf aktiviert werden. Die Speicherauslastung wird nur auf Windows-Agenten erfasst, daher trägt sie nicht zum Capability-Status auf einem Linux-Agent bei, auch wenn die Speichereinstellungen aktiviert sind. Apache bedient nur API-Anfragen, daher ist die Apache-Thread-Auslastung nur auf einem Agent relevant, der APIs verarbeitet.
  • Ein einzelner Agent in der Gruppe verarbeitet mehr Last, als er bewältigen kann, während andere Agenten in der Gruppe untätig sind oder unterausgelastet sind.

• Lösung: Überprüfen Sie ProcessEngine.log auf lange Sequenzen von Capability-Status-Änderungen, um zu bestätigen, dass der Agent zwischen fähigen und unfähigen Zuständen wechselt. Untersuchen Sie dann Folgendes:

  • Wenn viele Operationen konsistent gleichzeitig ausgeführt werden, überprüfen Sie MaxNumberOfWorkerThreads im Abschnitt [ProcessEngine] von jitterbit.conf. Eine Erhöhung dieses Werts ermöglicht mehr gleichzeitige Operationen, erhöht aber auch die CPU- und Speicheranforderungen. Legen Sie den Wert daher konservativ fest.
  • Bestimmen Sie, welche Capability-Metriken im Abschnitt [AgentCapability] aktiviert sind. Wenn keine aktiviert sind, sind CPU- und Speicherlast nicht der Grund für die Änderung des Capability-Status des Agenten, und die Thread-Verfügbarkeit ist der wahrscheinlichere Auslöser. Wenn CPU- oder Speicherauslastung aktiviert ist, überprüfen Sie diese vor den Thread-Metriken: Wenn eine den Schwellenwert überschreitet, wird der Agent unfähig, unabhängig von der Thread-Verfügbarkeit. Auf einem Linux-Agent ist die CPU-Auslastung die einzige Systemressourcen-Metrik, die gilt.
  • Überprüfen Sie CPU- und Speicherauslastung auf dem Agent-Host zum Zeitpunkt des Problems. Wenn native Observability aktiviert ist, überprüfen Sie die Diagramme System Resource Capability, Apache Threads und Tomcat Threads auf der Registerkarte Metrics der Seite Agents der Management Console. Verwenden Sie bei der Überprüfung von Diagrammen für eine Multi-Agent-Gruppe Spitzen- oder Maximalwerte anstelle von Durchschnittswerten, da Durchschnittswerte einen einzelnen überbelasteten Agent maskieren können, während der Rest der Gruppe gesund aussieht.
  • Wenn die Agent-Gruppe mehrere Agenten enthält, überprüfen Sie ProcessEngine.log auf allen Agenten in der Gruppe, um festzustellen, ob alle Agenten gleichzeitig unfähig waren, als die Operation fehlgeschlagen ist. Wenn nur ein Agent unfähig war, sollte die Operation an einen fähigen Agent weitergeleitet werden. Überprüfen Sie, ob der Load Balancing für die Gruppe korrekt konfiguriert ist.
  • Wenn Ressourcenlimits konsistent erreicht werden, fügen Sie Agenten zur Gruppe hinzu, um die Last zu verteilen.
  • Wenn Speicherdruck der Auslöser ist, siehe Java heap space: OutOfMemoryError.

Transformation schlägt fehl: "Failed to find file in the local file store"

• Symptom: Eine Operation schlägt während einer Transformation mit einem Fehler fehl, der anzeigt, dass eine Datei im lokalen Dateispeicher des Agenten fehlt:

  Failed to find file in the local file store. Will attempt a re-sync the files in the environment the next time the operation runs.
  There is no file in the local file store. File_ID = ...
  Failed to find file in the local file store. TransformID: ..., FileID: ..., Error: There is no file in the local file store. File_ID = ... [CODE:10808]
  

• Mögliche Ursache: Die Bereitstellungsmetadaten einer Datei wurden nicht vollständig aus der Harmony Cloud mit dem Agent synchronisiert, daher kann der Agent die Datei zur Laufzeit nicht finden. Dies ist normalerweise vorübergehend (z. B. eine kurze Synchronisierungsunterbrechung), kann aber auch nach dem Exportieren und erneuten Importieren eines Projekts zwischen Umgebungen auftreten.

• Lösung:
  1. Führen Sie den Vorgang erneut aus. Bei Agent-Version 11.38 und später behebt der Agent diesen Zustand selbst: Der Fehler tritt pro Datei-ID auf einem bestimmten Agent höchstens einmal auf, und der Agent stellt die fehlenden Metadaten bei der nächsten Umgebungssynchronisierung wieder her (nächste Vorgangsausführung oder Bereitstellung). In den meisten Fällen wird das Problem durch erneutes Ausführen des Vorgangs behoben.
  2. Wenn dieselbe Datei bei mehreren Ausführungen auf einem aktuellen Agent weiterhin fehlschlägt, liegt wahrscheinlich ein tieferes Problem vor, z. B. eine Umgebung, die ihr Bereitstellungsdatensatz-Limit erreicht hat, oder eine versionsspezifische Regression. Kontaktieren Sie den Jitterbit-Support mit dem Namen des fehlgeschlagenen Vorgangs sowie TransformID und File_ID aus der Fehlermeldung.

Installations- und Upgrade-Fehler

Fehler 1720 oder 1722 bei Windows-Installation

• Symptom: Die Installation des privaten Windows-Agents bricht teilweise ab und zeigt einen dieser Windows Installer-Fehler:

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

  Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run.
  

  Beide Fehler bedeuten, dass ein Schritt im Installer (eine benutzerdefinierte Aktion, die in der Fehlermeldung 1722 genannt wird) nicht abgeschlossen wurde. Meistens ist der fehlgeschlagene Schritt das im Installer enthaltene PostgreSQL-Setup. In diesem Fall kann das Installer-Protokoll auch einen KoGetDbService- oder KoInstallPostgreSQLNew-Skriptfehler oder [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified anzeigen, und die enthaltene PostgreSQL-Datenbank sowie der Windows-Dienst jitterbitpostgres werden möglicherweise nicht vollständig erstellt. Die Meldung kann stattdessen eine andere Aktion nennen, z. B. InstallVerboseLogShipper.

• Mögliche Ursachen:

  • Ein fehlendes oder in Konflikt stehendes Microsoft Visual C++ Redistributable (das enthaltene PostgreSQL benötigt es).
  • Unzulässige Zeichen im PostgreSQL-Passwort.
  • Bei einer Neuinstallation verbleibende PostgreSQL-Komponenten von einem vorherigen Agent. Das Agent-Deinstallationsprogramm entfernt PostgreSQL, den Windows-Benutzer jitterbitpostgres oder seine Registrierungseinträge absichtlich nicht, und diese Reste können verhindern, dass das neue PostgreSQL-Setup abgeschlossen wird (z. B. kann das Dienstkonto jitterbitpostgres nicht neu erstellt werden).
  • Bei einer Neuinstallation oder einem Upgrade verbleibende Komponenten des ausführlichen Log Shippers von einem vorherigen Agent. Wie bei PostgreSQL entfernt eine Standarddeinstallation den Dienst des ausführlichen Log Shippers oder seine Dateien nicht, und diese Reste können dazu führen, dass die Aktion InstallVerboseLogShipper des Installers fehlschlägt.

• Lösung:

  • Installieren Sie das 64-Bit-Microsoft Visual C++ Redistributable für Visual Studio mit vc_redist.x64.exe (deckt Visual Studio 2015, 2017 und 2019 ab), bevor Sie den Agent installieren, und halten Sie es installiert, da das Entfernen während einer Bereinigung auch die Installation beschädigt.

  • Wenn das PostgreSQL-Passwort unzulässige Zeichen enthält, ändern Sie das Passwort in ein gültiges, bevor Sie die Installation erneut versuchen.

    Hinweis

    Bei privaten Agents 12.8 und später validiert das Installationsprogramm das Passwort des PostgreSQL-Dienstkontos (jitterbitpostgres) bei der Eingabe gegen Zeichenbeschränkungen und fordert Sie auf, es zu korrigieren, bevor PostgreSQL installiert wird.

  • Wenn Sie nach einem vorherigen Agent neu installieren, entfernen Sie zunächst vollständig die verbleibenden PostgreSQL-Komponenten: Folgen Sie Deinstallieren eines privaten Windows-Agents, und bestätigen Sie dann, dass der Windows-Benutzer jitterbitpostgres, die PostgreSQL-Programm- und Datenverzeichnisse sowie die PostgreSQL-Registrierungsschlüssel gelöscht sind.

  • Wenn die Fehlermeldung 1722 die Aktion InstallVerboseLogShipper nennt, entfernen Sie den verbleibenden Dienst des ausführlichen Log Shippers und seine Dateien vom vorherigen Agent, deinstallieren Sie den Agent dann erneut und installieren Sie ihn neu.

Wenn die Installation auch nach einer gründlichen Bereinigung fehlschlägt, wenden Sie sich an den Jitterbit-Support.

PostgreSQL-Dienst nach fehlgeschlagenem Upgrade unter Windows entfernt

• Symptom: Nach einem fehlgeschlagenen Upgrade des privaten Agenten unter Windows wird der PostgreSQL-Dienst (postgresql-x64-<VERSION>) nicht mehr in den Windows-Diensten angezeigt, und die Jitterbit-Agent-Dienste können nicht gestartet werden, da eine Abhängigkeit fehlt.

• Ursache: Dies tritt bei privaten Agent-Versionen vor 11.59 / 12.3 auf, wenn während des Upgrades ein falsches Passwort eingegeben wird und das Installationsprogramm nicht ordnungsgemäß zurückgesetzt wird. Dieses Problem ist in privatem Agent 11.59 / 12.3 und später behoben, wo ein falsches Passwort das Upgrade im selben Dialog blockiert und eine erneute Eingabe oder einen Abbruch ermöglicht, ohne die vorhandene Installation zu beeinträchtigen.

• Lösung:

  1. Öffnen Sie eine Eingabeaufforderung als Administrator.

  2. Registrieren Sie den PostgreSQL-Dienst erneut:

     "C:\Program Files\PostgreSQL\<VERSION>\bin\pg_ctl.exe" register -N "postgresql-x64-<VERSION>" -D "C:\Program Files\PostgreSQL\<VERSION>\data"
     

     Ersetzen Sie <VERSION> durch Ihre PostgreSQL-Versionsnummer. Um diese zu finden, siehe PostgreSQL-Version im privaten Agent enthalten.

  3. Starten Sie die PostgreSQL- und PgBouncer-Dienste:

     net start postgresql-x64-<VERSION>
     net start JitterbitPgbouncer
     

  4. Starten Sie alle Jitterbit-Agent-Dienste:

     "C:\Program Files\Jitterbit Agent\StartServices.bat"
     

  5. Sobald der Agent ausgeführt wird, setzen Sie die PostgreSQL-Admin- und Service-Kontokennwörter zurück, bevor Sie das Upgrade erneut versuchen.

Agent-Dienste können nach dem Neustart von Windows nach einem Upgrade nicht gestartet werden

• Symptom: Ein Upgrade eines Windows-basierten privaten Agenten von einem 11.x-Agenten auf einen 12.x-Agenten vor 12.10 wird erfolgreich abgeschlossen, aber die Jitterbit-Agent-Dienste können beim nächsten Neustart des Hostsystems nicht gestartet werden.

• Mögliche Ursache: Das Upgrade belässt den vorherigen PostgreSQL-Windows-Dienst (postgresql-x64-<VERSION>, wobei <VERSION> die vom vorherigen Agenten installierte Version ist) mit dem Starttyp weiterhin auf Automatisch. Beim Neustart startet dieser ältere Dienst vor dem durch das Upgrade installierten PostgreSQL-Dienst und belegt denselben Port, wodurch der neue PostgreSQL-Dienst und damit der Agent nicht gestartet werden können.

• Lösung:

  • Führen Sie ein Upgrade auf Agent-Version 12.10 oder höher durch, wodurch der vorherige PostgreSQL-Dienst während des Upgrades entfernt wird.
  • Öffnen Sie bei einer früheren Agent-Version nach dem Upgrade die Windows-Dienste, identifizieren Sie den älteren postgresql-x64-<VERSION>-Dienst (den, der vor dem Upgrade bestand), und setzen Sie dessen Starttyp auf Manuell oder Deaktiviert, oder deinstallieren Sie ihn, bevor Sie das Hostsystem neu starten. Um zu prüfen, welche Version derzeit mit dem Agenten gebündelt ist, führen Sie den Befehl unter Gleiche Version wie gebündelt aus.

TFA verhindert Installation des 64-Bit-Windows-Agenten

• Symptom: Die Installation eines 64-Bit-Windows-Privatagenten schlägt fehl, wenn die Zwei-Faktor-Authentifizierung (TFA) für die Organisation aktiviert ist.
• Lösung: Deaktivieren Sie TFA vorübergehend, installieren Sie den Agent, und aktivieren Sie TFA dann erneut. Die Einstellung Zwei-Faktor-Authentifizierung (TFA) erforderlich befindet sich auf der Registerkarte Benutzerverwaltung der Organisationsrichtlinien, auf die über die Seite Organisationen der Management Console zugegriffen wird.

Fehlgeschlagene Windows-Installation wiederherstellen

• Symptom: Die Installation oder das Upgrade eines Windows-Privatagenten schlägt fehl oder hinterlässt den Agent in einem fehlerhaften Zustand.
• Lösung: Deinstallieren Sie den Agent vollständig und installieren Sie dann die Agent-Software neu.

Linux-Installation ohne Root-Berechtigung schlägt fehl

• Symptom: Das Installationsprogramm Linux Redhat Non-Root (x64) schlägt fehl.

• Lösung: Überprüfen Sie Folgendes:

  • Der Benutzer ohne Root-Berechtigung hat sudo-Privilegien. Ein Systemadministrator muss den Benutzer zur wheel-Gruppe hinzufügen. Um die aktuelle Gruppenmitgliedschaft zu überprüfen, führen Sie groups aus.

  • Wenn Sie als jitterbit-Benutzer angemeldet sind, ist die Umgebungsvariable JITTERBIT_HOME auf den Installationsort gesetzt:

    echo $JITTERBIT_HOME
    

    Das Ergebnis sollte /opt/jitterbit sein. Dies wird durch $HOME/.bashrc.d/jitterbit gesetzt, wenn die Installationsanweisungen befolgt werden. Um es manuell zu setzen, führen Sie aus:

    . /opt/jitterbit/scripts/set.env
    

  • Wenn das Installationsprogramm stattdessen mit einem OPENSSL_3.4.0-Fehler fehlschlägt, ist dies ein bekanntes Problem unter RHEL 9.7 und später. Siehe RHEL 9.7 und später zeigen einen OpenSSL-Fehler bei der Installation des privaten Agenten ohne Root-Berechtigung in den bekannten Problemen des privaten Agenten für eine Problemumgehung.

JDBC-Treiber: "No suitable driver found"

• Symptom: Eine Datenbankverbindung schlägt fehl, weil der erforderliche JDBC-Treiber nicht auf dem Agent installiert ist. Die Fehlermeldung lautet beispielsweise No suitable driver found for jdbc:<subprotocol>://....
• Ursache: Jitterbit wird nicht mit allen JDBC-Treibern ausgeliefert. Der erforderliche Treiber muss manuell installiert werden.
• Lösung: Installieren Sie den erforderlichen Treiber manuell: Registrieren Sie ihn in JdbcDrivers.conf und kopieren Sie die Treiber-.jar-Datei nach JITTERBIT_HOME/tomcat/drivers/lib/. Starten Sie dann den Agent neu. Die vollständigen Schritte finden Sie unter Install a JDBC driver.

Connector wurde nicht auf den Agent heruntergeladen

• Symptom: Operationen schlagen mit Fehlern fehl, die darauf hindeuten, dass ein Connector nicht verfügbar oder auf dem Agent nicht vorhanden ist. Dies tritt typischerweise nach der Veröffentlichung einer neuen Connector-Version oder nach der Bereitstellung eines Projekts auf, das einen auf dem Connector SDK basierenden Connector verwendet:

  This connector was not found on the Jitterbit Agent. Please be patient with us while the connector is downloaded across the agents. This may take up to several minutes
  

• Mögliche Ursachen:

  • Die vom Projekt erforderliche Connector-Version wurde noch nicht aus der Cloud auf den Agent heruntergeladen. Dies ist oft vorübergehend und wird innerhalb weniger Minuten behoben.
  • Bei privaten Agents: Der Agent kann die Harmony-Cloud nicht erreichen, um den Connector herunterzuladen.

• Lösung:

  • Öffnen Sie in Studio die betroffene Verbindung und klicken Sie auf Test. Dies veranlasst den Agent, die neueste Connector-Version aus der Cloud herunterzuladen.
  • Wenn der Connector immer noch nicht heruntergeladen wird, überprüfen Sie, ob die Organisationsrichtlinie Disable Auto Connector Update aktiviert ist. Wenn dies der Fall ist, lädt die Schaltfläche Test keine Connector-Versionen herunter. Siehe Agent Management.
  • Um den Connector herunterzuladen, ohne die Richtlinie zu ändern, gehen Sie zur Seite Agents der Management Console, wählen Sie die Agent-Gruppe aus und wählen Sie Action > Update connectors. Dies erzwingt ein Connector-Update über die Gruppe hinweg und wird durch die Richtlinie Disable Auto Connector Update nicht beeinflusst.
  • Überprüfen Sie bei privaten Agents, ob der Agent-Host die Harmony-Cloud erreichen kann. Siehe Agent offline or unreachable.

Agent-Installation kann sich nicht über einen Unternehmens-Proxy registrieren

• Symptom: Die Installation eines privaten Agents auf einem Host hinter einem Unternehmens-Proxy schlägt während des anfänglichen Registrierungsschritts fehl, und das Installationsprogramm meldet, dass es die Harmony-Cloud nicht erreichen konnte:

  Could not connect to Jitterbit Harmony cloud
  

• Mögliche Ursachen:

  • Der Proxy blockiert die Verbindung des Agents zur Harmony-Cloud während der Registrierung.
  • Der Proxy erfordert eine Authentifizierung, die die Proxy-Konfiguration des Agents nicht bereitstellt. Private Agents unterstützen die Proxy-Authentifizierung, einschließlich einer NTLM-Domäne. Siehe Proxy server for Jitterbit private agents.

• Lösung:

  1. Konfigurieren Sie den Proxy während der Agent-Einrichtung, damit das Installationsprogramm die Harmony-Cloud über ihn erreichen kann. Geben Sie die Proxy-Anmeldedaten an (und die NTLM-Domäne, falls der Proxy diese erfordert). Siehe Configure a proxy during agent setup.
  2. Wenn die Registrierung über den Proxy immer noch fehlschlägt, bitten Sie Ihr Netzwerk-Team, die Jitterbit-Domänen und IP-Adressen durch den Proxy zuzulassen oder den Proxy für diese zu umgehen. Die regionsspezifischen Harmony-URLs sind in Allowlist information dokumentiert.
  3. Führen Sie das Installationsprogramm erneut aus, sobald der Proxy konfiguriert ist oder der Host die Harmony-Cloud erreichen kann.

Leistungs- und Ressourcenprobleme

Java-Heap-Speicher: OutOfMemoryError

• Symptom: Operationen, die große Dateien verarbeiten oder viele Operationen gleichzeitig ausführen, schlagen mit folgendem Fehler fehl:

  java.lang.OutOfMemoryError: Java heap space
  

• Ursache: Die maximale Java-Heap-Größe (-Xmx) des privaten Agenten ist für die Workload (große Dateien oder hohe Job-Parallelität) zu klein.

• Lösung:
  1. Erhöhen Sie den maximalen Java-Heap des privaten Agenten. Siehe Tomcat-Heap-Speicher, um den -Xmx-Wert zu ändern (z. B. von -Xmx1024m zu -Xmx4096m).
  2. Starten Sie die Agent-Services nach der Änderung neu.
  3. Konfigurieren Sie für Operationen, die große Dateien verarbeiten, Chunking, um die Speichernutzung pro Job zu reduzieren. Studio wendet Streaming-Transformationen automatisch an, wo sie zutreffen.
  4. Wenn native Observability aktiviert ist, verwenden Sie das Diagramm System Resource Capability auf der Registerkarte Metrics der Seite Agents der Management Console, um die Speichernutzung im Laufe der Zeit zu überwachen und die Heap-Größe für die Workload richtig zu dimensionieren.

Festplattenspeicher und Log-Ansammlung

• Symptom: Dem Host des privaten Agenten geht der Festplattenspeicher aus, was dazu führen kann, dass PostgreSQL heruntergefahren wird oder Operationen mit Berechtigungsfehlern fehlschlagen. Log- und temporäre Dateien sammeln sich in den Agent-Verzeichnissen an, besonders auf Agenten, die hohe Volumen verarbeiten.
• Lösung:
  • Überprüfen Sie den verfügbaren Festplattenspeicher auf dem Agent-Host.
  • Identifizieren Sie große Dateien. Agent-Logs und temporäre Dateien befinden sich unter JITTERBIT_HOME/log, JITTERBIT_HOME/tomcat/logs (catalina.out) und JITTERBIT_HOME/DataInterchange/Temp. Siehe Log-Dateien für die vollständige Liste. Eine einzelne Log-Datei kann mehrere Gigabyte groß werden, wenn eine Komponente übermäßig protokolliert (z. B. ein ausführlicher Connector, der catalina.out überschwemmt) oder wenn ein Fehler wiederholt auftritt (z. B. eine fehlgeschlagene Datenbankverbindung, die sich in ProcessEngine.log wiederholt). Löschen Sie übergroße Dateien, wenn der Speicherplatz kritisch niedrig ist. Das Löschen der Datei und der Neustart des Agenten können auch den zugrunde liegenden Fehler beheben.
  • Bestätigen Sie, dass der Cleanup-Service ausgeführt wird und seine Aufbewahrung eingehalten wird. Überprüfen Sie im Abschnitt [FileCleanup] von jitterbit.conf, dass AutoStart auf true gesetzt ist, und überprüfen Sie FrequencyInHours. Die Aufbewahrung pro Verzeichnis wird in CleanupRules.xml mit NumDays oder NumOfHours festgelegt.
  • Wenn der Cleanup-Service aktive Log-Dateien nicht löschen kann (Tomcat hält seine stdout- und stderr-Logs unter Windows offen), erhöhen Sie FileAge für dieses Verzeichnis in CleanupRules.xml auf mindestens einen Tag, damit Cleanup keine Dateien anvisiert, die noch geschrieben werden.
  • Wenn große .dmp-Crash-Dump-Dateien die Festplatte des Agenten verbrauchen, siehe JVM-Mini-Dump-Dateien füllen die Festplatte des Agenten.

Agent-Service-Neustartschleife

• Symptom: Die Services des Agenten stürzen wiederholt ab und werden neu gestartet. Tomcat oder die Process Engine stoppt und startet in einer Schleife, ohne online zu bleiben, und Operationen schlagen mit Fehlern wie Tomcat service is not running fehl. Wenn jitterbit status alle Services auf dem Host als fehlerfrei anzeigt, aber der angezeigte Status nur zwischen Running, Unknown und Stopped wechselt, handelt es sich um ein Konnektivitätsproblem und nicht um eine Absturzschleife. Siehe Agent offline oder nicht erreichbar.
• Mögliche Ursachen:
  • Ein verwaister Jitterbit-Prozess aus einem vorherigen Durchlauf (ein Tomcat-, Process Engine- oder Scheduler-Prozess) hält noch den Service-Port, sodass jeder Neustart mit java.net.BindException: Address already in use fehlschlägt und der Agent zyklisch läuft.
  • Dem Host geht der Speicher aus und das Betriebssystem beendet den Prozess. Dies kann vorkommen, wenn der Host zu wenig Speicher für die Workload hat oder wenn das Speicherlimit eines Containers zu niedrig gesetzt ist.
  • Der Agent-Host hat wenig Festplattenspeicher, oder die interne PostgreSQL-Datenbank ist groß genug geworden, um beim Start fehlzuschlagen.
  • Die Process Engine stürzt unter anhaltender Last wiederholt ab.

• Lösung:
  • Bestätigen Sie, dass es sich um eine echte Crash-Schleife handelt. Überprüfen Sie die Tomcat-Logs in JITTERBIT_HOME/tomcat/logs/ und ProcessEngine.log auf die bei jedem Neustart protokollierte Ausnahme. Ein java.net.BindException: Address already in use deutet darauf hin, dass ein verwaister Prozess den Port belegt.
  • Stoppen Sie den Agent und beenden Sie alle verbleibenden Jitterbit-Prozesse, bevor Sie ihn neu starten. Wenn der Agent gestoppt ist, suchen Sie nach verwaisten Prozessen: Führen Sie unter Linux ps aux | grep -E 'tomcat|jitterbit' aus und kill alle verbleibenden Prozess-IDs; unter Windows beenden Sie alle verwaisten Jitterbit- oder Tomcat-Prozesse im Task Manager. Starten Sie den Agent neu, sobald keine mehr vorhanden sind.
  • Überprüfen Sie auf Speichererschöpfungsereignisse. Unter Windows überprüfen Sie die Logs Anwendung und System in der Ereignisanzeige; unter Linux führen Sie journalctl -u jitterbit aus oder überprüfen Sie /var/log/syslog auf OOM-Killer-Ereignisse. Wenn dem Host der Speicher ausgeht, erhöhen Sie den verfügbaren Speicher (oder das Speicherlimit des Containers). Siehe Java heap space: OutOfMemoryError.
  • Überprüfen Sie den Festplattenspeicher und die interne Datenbank. Eine volle Festplatte oder eine überladene PostgreSQL-Datenbank können dazu führen, dass die Dienste bei jedem Neustart abstürzen. Siehe Festplattenspeicher und Protokollakkumulation.
  • Wenn die Logs zeigen, dass die Process Engine bei einem bestimmten Vorgang abstürzt, kontaktieren Sie den Jitterbit-Support mit den Vorgangsdetails und den Agent-Logs.
  • Wenn die native Observability aktiviert ist, öffnen Sie die Registerkarte Metriken der Seite Agents der Management Console und überprüfen Sie die Service-Diagramme Tomcat und Process Engine, um zu ermitteln, wann die Dienste ausfallen begannen.

Vorgänge werden zeitüberschritten oder ignorieren Timeout-Einstellungen

• Symptom: Vorgänge werden unbegrenzt oder länger als erwartet ausgeführt. Bei API-gesteuerten Vorgängen scheinen die in Studio konfigurierten Timeout-Einstellungen keine Auswirkung zu haben, und Vorgänge können im Status Wird ausgeführt steckenbleiben.

• Mögliche Ursachen:

  • Standardmäßig ignorieren durch API Manager-APIs ausgelöste Vorgänge die Timeout-Einstellungen für Studio-Vorgänge. Die Einstellung EnableAPITimeout in jitterbit.conf muss explizit aktiviert werden, damit API-Vorgänge Timeout-Werte berücksichtigen.
  • Es ist keine maximale Vorgangslaufzeit festgelegt, daher werden Vorgänge ohne zeitliche Obergrenze ausgeführt.

• Lösung:

  1. Um Timeout-Einstellungen für API-gesteuerte Vorgänge zu erzwingen, setzen Sie EnableAPITimeout=true im Abschnitt [Settings] von jitterbit.conf.
  2. Um die Gesamtlaufzeit eines Vorgangs zu begrenzen, setzen Sie MaxOperationRuntimeSeconds im Abschnitt [ProcessEngine] von jitterbit.conf. Dies erfordert, dass RunOperationsInSeparateProcess auf true (Standard) gesetzt ist.
  3. Starten Sie die Agent-Dienste nach Änderungen an jitterbit.conf neu.

Agent-Durchsatz ändert sich nicht nach Erhöhung von max.concurrent.requests

• Symptom: Nach Erhöhung von max.concurrent.requests in jitterbit-agent-config.properties verbessert sich der Durchsatz des Agents nicht.

• Mögliche Ursachen:

  • Nur max.concurrent.requests wurde geändert. Der Agent-Durchsatz hängt auch von den Tomcat- und Apache-Thread-Pools sowie den HTTP-Verbindungs-Pools ab. Eine Erhöhung dieser einen Einstellung ohne gleichzeitige Skalierung der anderen bringt keinen Gewinn.
  • Der Agent-Host verfügt nicht über genügend CPU oder Speicher für die zusätzliche Parallelität, oder der Agent wechselt unter Last in einen unfähigen Zustand.

• Lösung:

  • Folgen Sie dem vollständigen Tuning-Verfahren, anstatt nur max.concurrent.requests zu ändern, und skalieren Sie die zugehörigen Thread-Pool- und Verbindungs-Pool-Einstellungen zusammen. Siehe Agent-Leistung und Tuning.
  • Bestätigen Sie, dass der Agent-Host ausreichend CPU- und Speicherreserven für die höhere Parallelität hat. Wenn der Agent unter Last abstürzt oder in einen unfähigen Zustand wechselt, siehe Agent-Dienst-Neustartschleife und Java heap space: OutOfMemoryError.

XML-Transformationen verlangsamen sich nach dem Upgrade auf Agent 11.45 oder später

• Symptom: Nach dem Upgrade eines privaten Agenten auf Version 11.45 oder später dauert eine Transformation, die über ein großes Array iteriert, länger als in Version 11.44. Die Verlangsamung tritt speziell bei Zuordnungspfaden auf, die die #-Notation verwenden, um über jedes Element eines großen Arrays zu iterieren (ungefähr mehrere hundert bis einige tausend Datensätze). Transformationen, die nicht über große Arrays iterieren, sind nicht betroffen.
• Mögliche Ursache: Die vom Agent verwendete XML-Parsing-Bibliothek wurde in Version 11.45 aktualisiert, und die aktualisierte Version analysiert große XML-Daten langsamer. Dies wirkt sich auf Transformationen aus, die über ein großes Array iterieren, da die Zuordnung die analysierten Daten wiederholt durchläuft.
• Lösung:
  • Überprüfen Sie die Zuordnungspfade der Transformation auf die #-Notation. Wenn ein Pfad # verwendet, um über ein Array zu iterieren, aber nur das erste Element erforderlich ist, entfernen Sie # und stellen Sie erneut bereit. Das Entfernen von # ordnet nur das erste Element zu, daher wenden Sie dies nur an, wenn das Iterieren über das gesamte Array nicht erforderlich ist.
  • Wenn die Zuordnung über das gesamte Array iterieren muss, verarbeiten Sie weniger Datensätze pro Durchlauf, indem Sie einen großen Datensatz in kleinere Batches aufteilen, sodass jede Transformation ein kleineres Array durchläuft.

JVM-Mini-Dump-Dateien füllen die Festplatte des Agenten

• Symptom: Der Agent generiert kontinuierlich große JVM-Crash-Dateien (.dmp- und .mdmp-Mini-Dumps sowie hs_err_pid*.log-Dateien) unter <JITTERBIT_HOME>/Tomcat/temp (oder bei älteren Builds direkt im Tomcat-Ordner) und verbraucht damit den Festplattenspeicher des Agent-Hosts. Dies betrifft Windows-Private-Agenten in Versionen vor 11.49.

• Mögliche Ursachen:

  • Der AgentStats-Festplattenstatistik-Collector des Agenten stürzt die JVM ab, während er Festplattenmetriken erfasst. Dies betrifft Agenten in Versionen vor 11.49.
  • Bei Agenten mit Version 11.47 oder 11.48 kann ein separater Crash in der Process Engine die gleichen Crash-Dateien erzeugen.

• Lösung: Aktualisieren Sie den privaten Agenten auf Version 11.49 oder später, wodurch beide Ursachen behoben werden.

  Wenn ein sofortiges Upgrade nicht möglich ist und die Crash-Dateien aus der Festplattenstatistik-Erfassung stammen, können Sie diese Erfassung als Workaround deaktivieren (das Flag DiskStatsEnabled ist ab Agent 11.44.1 verfügbar):

  1. Fügen Sie in jitterbit.conf Folgendes hinzu:

     [AgentStats]
     DiskStatsEnabled=false
     

  2. Starten Sie die Agent-Services neu. Vorhandene Crash-Dateien können dann sicher gelöscht werden, um Festplattenspeicher freizugeben.

  3. Wenn Sie Version 11.47 oder 11.48 verwenden und die Crash-Dateien weiterhin auftreten, aktualisieren Sie auf 11.49 oder kontaktieren Sie den Jitterbit-Support für einen Workaround.

Datenbankprobleme

TranDb-Verbindungsfehler

• Symptom: Operationen schlagen mit Fehlern fehl, die auf die interne PostgreSQL-Datenbank des privaten Agenten verweisen, oder interne Agent-Services können nicht gestartet werden, da das Verbindungslimit erreicht wurde. Wiederholte Fehler können auch ProcessEngine.log überfluten und auf mehrere GB anwachsen lassen:

  Failed to connect to back-end database 'TranDb'
  

  FATAL: query_wait_timeout
  

  FATAL: remaining connection slots are reserved for non-replication superuser connections
  

• Mögliche Ursachen:

  • Das Limit max_connections der internen PostgreSQL oder das Limit max_db_connections von PgBouncer ist für die Workload des Agenten zu niedrig.
  • Operationen stauen sich unter hoher Last oder aufgrund einer Netzwerk- oder Endpoint-Verlangsamung auf und halten Datenbankverbindungen, bis der PgBouncer-Pool erschöpft ist (query_wait_timeout).
  • Bei einem Windows-Agenten beeinträchtigt IP Helper die lokalen Datenbankverbindungen des Agenten.

• Lösung:
  • Aktuelle Agent-Versionen werden standardmäßig mit höheren PostgreSQL- und PgBouncer-Verbindungslimits ausgeliefert. Bestätigen Sie daher zunächst, dass der Agent eine aktuelle Version hat. Falls ein aktueller Agent sein Verbindungslimit trotzdem erschöpft, kontaktieren Sie den Jitterbit-Support, um es unter Support-Anleitung zu erhöhen. Die gebündelten PostgreSQL- und PgBouncer-Instanzen sollten nur unter Support-Anleitung geändert werden.
  • Falls die Limits bereits ausreichend sind, untersuchen Sie, was Verbindungen offen hält: Überprüfen Sie die Agent-Host-Last und mögliche Netzwerk- oder Endpoint-Verzögerungen, die Operationen aufstauen.
  • Deaktivieren Sie auf einem Windows-Agent IP Helper. Siehe IPv6-Problem unter Windows.

Gebündelte PostgreSQL unter Linux verwendet MD5 statt SCRAM-SHA-256

• Symptom: Sie möchten die Authentifizierungsmethode der gebündelten PostgreSQL auf einem privaten Linux-Agent von MD5 zu SCRAM-SHA-256 ändern, aber der Agent verwendet weiterhin MD5.

• Mögliche Ursachen:

  • MD5 ist die Standard-Passwortverschlüsselung für die gebündelte PostgreSQL auf privaten Linux-Agenten. SCRAM-SHA-256 war nur in den Versionen 12.6 und 12.7 Standard; Version 12.8 hat den Standard auf MD5 zurückgesetzt. Wenn Sie einen Linux-Agent von 12.6 oder 12.7 aktualisieren, fordert das Installationsprogramm Sie auf, die Verschlüsselung auf MD5 zurückzusetzen oder SCRAM-SHA-256 beizubehalten; siehe Linux-Agent aktualisieren.
  • Das alleinige Bearbeiten von pg_hba.conf und postgresql.conf schließt den Wechsel nicht ab. PgBouncer muss auch mit dem SCRAM-Verifier-Hash neu konfiguriert werden, sonst kann der Agent nicht gestartet werden.

• Lösung: Um einen privaten Linux-Agent zu SCRAM-SHA-256 zu wechseln, folgen Sie dem SCRAM auf PostgreSQL-Leitfaden. SCRAM-SHA-256 ist eine stärkere Authentifizierungsmethode, während MD5 performanter ist. Der Wechsel ist daher eine bewusste, mehrstufige Änderung: Der Leitfaden konfiguriert die gebündelte PostgreSQL neu, aktualisiert die Benutzerkennwörter und konfiguriert PgBouncer mit dem neuen Hash neu. Das Neukonfigurieren der gebündelten Instanz ist die unterstützte Methode, um SCRAM zu aktivieren. Ersetzen Sie die gebündelte Instanz nicht durch Ihren eigenen PostgreSQL-Server, um SCRAM zu erhalten: Agenten, die eine andere PostgreSQL-Instanz als die gebündelte verwenden, werden nicht unterstützt.

PostgreSQL: Administratives schnelles Herunterfahren

• Symptom: Alle Operationen schlagen fehl, weil die Datenbank des Agenten nicht verfügbar ist (Operationen können im Status Ausstehend steckenbleiben), und das PostgreSQL-Protokoll zeichnet ein schnelles Herunterfahren auf:

  received fast shutdown request
  

  Verbindungsoperationen können auch FATAL: terminating connection due to administrator command melden.

• Mögliche Ursachen:

  • Eine externe oder Systemoperation hat PostgreSQL gestoppt oder neu gestartet: ein Betriebssystem-Neustart, ein Windows-Update oder eine geplante Aufgabe, oder ein Überwachungs- oder Sicherungstool, das Dienste neu startet.
  • Der Agent-Host hatte wenig CPU oder Speicher, was Tomcat zum Absturz brachte und PostgreSQL mit sich zog.

• Lösung:

  • Starten Sie die PostgreSQL- und Jitterbit-Agent-Dienste neu (oder starten Sie den Agent-Host neu), um die Wiederherstellung durchzuführen. Falls Operationen nach der Wiederherstellung von PostgreSQL im Status Ausstehend oder Wird ausgeführt steckenbleiben, kontaktieren Sie den Jitterbit-Support, da der Datenbankverbindungspool des Agenten möglicherweise nicht wiederhergestellt wurde.
  • Ermitteln Sie, was PostgreSQL gestoppt hat: Überprüfen Sie das Betriebssystem-Ereignisprotokoll (unter Windows Ereignisanzeige) um den Zeitpunkt des Fehlers auf Neustarts, Updates, geplante Aufgaben, Dienstabstürze oder Sicherungs- und Überwachungstools, die Dienste neu starten. Verhindern Sie oder verschieben Sie, was es stoppt, und stellen Sie den PostgreSQL-Dienst so ein, dass er bei Fehler automatisch neu gestartet wird.
  • Überprüfen Sie Agent-Host-CPU und Speicher. Falls die Jitterbit-Dienste unter Last abstürzen, siehe Agent-Dienst-Neustartschleife und Java-Heap-Speicher: OutOfMemoryError.

Netzwerk und Konnektivität

Fehler beim Zertifikat-Handshake (TLS)

• Symptom: Operationen, die sich mit sicheren Endpunkten verbinden, schlagen während des TLS-Handshakes fehl, mit Fehlern wie:

  error:0A000152:SSL routines::unsafe legacy renegotiation disabled
  

  SSLHandshakeException: Received fatal alert: protocol_version
  

  PKIX path building failed: unable to find valid certification path to requested target
  

• Mögliche Ursachen:

  • Der Endpunkt verwendet TLS-Legacy-Renegotiation, die der Agent standardmäßig blockiert.
  • Der Agent und der Endpunkt können keine gemeinsame TLS-Version oder Cipher aushandeln. Agent-Version 11.x und Version 12.x werden mit unterschiedlichen Sicherheitsbibliotheken ausgeliefert, daher kann ein Endpunkt, der sich auf einem 11.x-Agent nicht verbindet, auf einem 12.x-Agent erfolgreich sein.
  • Das Zertifikat des Endpunkts (oder eines seiner Zwischenzertifikate) wird vom Agent nicht vertraut, da seine ausstellende CA nicht im cacerts-Vertrauensspeicher der Agent-JRE enthalten ist.

• Lösung: Führen Sie vom Agent-Host aus Folgendes aus, um zu bestätigen, welche TLS-Version der Endpunkt aushandelt und ob der Handshake auf Netzwerkebene erfolgreich ist:

  openssl s_client -connect hostname:port
  

  Wenden Sie dann die Lösung an, die dem Fehler entspricht:

  • Wenn der Fehler unsafe legacy renegotiation disabled ist, setzen Sie AllowUnsafeLegacyRenegotiation=true im Abschnitt [Settings] von jitterbit.conf und starten Sie den Agent neu. Diese Einstellung erfordert Agent-Version 11.39 oder später.
  • Wenn der Fehler PKIX path building failed: unable to find valid certification path to requested target ist, befindet sich das Zertifikat des Endpunkts (oder eines seiner Zwischenzertifikate) nicht im cacerts-Vertrauensspeicher der Agent-JRE. Verwenden Sie keytool -import im cacerts-Vertrauensspeicher der Agent-JRE (Standardpasswort changeit), um die fehlenden Zertifikate zu importieren, und starten Sie dann die Agent-Services neu. Für eine SQL Server-Datenbank, auf die über eine Database-Verbindung zugegriffen wird, können Sie dies auch in den Treibereinstellungen der Verbindung statt im Vertrauensspeicher lösen, sowohl auf Cloud- als auch auf privaten Agents. Siehe SQL Server: Verbindung schlägt mit PKIX-Zertifikatpfadfehler fehl.
  • Wenn ein TLS-Aushandlungs- oder Handshake-Fehler bestehen bleibt, besonders auf einem 11.x-Agent, führen Sie ein Upgrade auf einen aktuellen 12.x-Agent durch, der aktualisierte Sicherheitsbibliotheken und einen aktualisierten Zertifikat-Vertrauensspeicher enthält.

Salesforce-Sandbox-Verbindung schlägt mit Zertifikat-Nichtübereinstimmung fehl

• Symptom: Eine Private-Agent-Verbindung zu einem Endpunkt, der Server Name Indication (SNI) erfordert, schlägt mit einer Zertifikat-Nichtübereinstimmung fehl, während die gleiche Verbindung von einer Cloud-Agent-Gruppe oder von einem direkten openssl- oder curl-Test auf dem Agent-Host erfolgreich ist. Der häufigste Fall ist eine Salesforce-Sandbox-URL, die auf .sandbox.my.salesforce.com endet:

  Certificate for <your-domain.sandbox.my.salesforce.com> doesn't match any of the subject alternative names: ...
  

  Andere betroffene Endpunkte sind Hosts, die eine einzelne IP hinter Virtual Hosting gemeinsam nutzen.

• Ursache: Der TLS-Handshake enthält nicht die SNI-Erweiterung, daher gibt der Server ein Standardzertifikat statt des für den angeforderten Host zurück. Für eine Salesforce-Sandbox gibt der Load Balancer das Produktionszertifikat zurück, dessen Namen *.sandbox.my.salesforce.com nicht abdecken. SNI wird standardmäßig gesendet, daher unterdrückt oder entfernt etwas SNI, wenn es fehlt.

• Lösung:

  1. Bestätigen Sie, dass SNI die Ursache ist. Vergleichen Sie vom Agent-Host aus das zurückgegebene Zertifikat mit und ohne SNI:

     openssl s_client -connect HOST:443 -servername HOST   # Zertifikat, wenn SNI gesendet wird
     openssl s_client -connect HOST:443                    # Zertifikat, wenn SNI weggelassen wird
     

Wenn die erste das richtige Zertifikat zurückgibt und die zweite das nicht übereinstimmende zurückgibt, ist SNI die Ursache.

1. Prüfen Sie, ob SNI in den Java-Optionen des Agenten explizit deaktiviert ist, und entfernen Sie es gegebenenfalls. Öffnen Sie unter Windows den Registry Editor unter HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\Jitterbit Tomcat Server\Parameters\Java und bearbeiten Sie den Wert Options. Unter Linux prüfen Sie JAVA_OPTS in /etc/sysconfig/jitterbit. Entfernen Sie -Djsse.enableSNIExtension=false, falls vorhanden (diese Einstellung unterdrückt SNI). Starten Sie die Agent-Services neu.
2. Wenn SNI danach immer noch fehlt, entfernt ein Netzwerkgerät, ein Proxy oder ein VM-Netzwerk-Stack zwischen dem Agent und dem Endpunkt die SNI-Erweiterung. Ihr Netzwerk-Team muss die SNI-Erweiterung zulassen.

Wenn die Verbindung auch von einer Cloud-Agent-Gruppe aus fehlschlägt, ist SNI nicht die Ursache. Das Zertifikat des Servers listet möglicherweise den Host nicht in seinen Subject Alternative Names auf. Fügen Sie für Salesforce die Sandbox-MyDomain-URL zum Salesforce-Zertifikat hinzu, oder siehe Zertifikat: Nichtübereinstimmung des Subject Alternative Name (SAN).

FTP: Datenverbindung hat das Zeitlimit überschritten

• Symptom: FTP-Anmeldung erfolgreich, aber Dateiauflistung oder Dateiübertragung hängt und überschreitet das Zeitlimit.

• Mögliche Ursachen:

  • Der FTP-Verbindungsmodus (aktiv vs. passiv) ist nicht mit der Netzwerk- oder Firewall-Konfiguration kompatibel.
  • Der auf dem FTP-Server definierte passive Portbereich ist in der Unternehmens-Firewall nicht offen.

• Lösung:

  • Aktivieren oder deaktivieren Sie in den FTP-Verbindungseinstellungen das Kontrollkästchen Passiver Modus. Der passive Modus wird im Allgemeinen für Agenten hinter einer Firewall bevorzugt.
  • Bestätigen Sie mit Ihrem Netzwerk-Team, dass der auf dem FTP-Server konfigurierte passive Portbereich in der Firewall zwischen dem Agent und dem FTP-Server offen ist.
  • Um detaillierte Protokolle auf Verbindungsebene zu erfassen, aktivieren Sie das Curl-Debug-Logging, indem Sie CurlDebugDir im Abschnitt [Settings] von jitterbit.conf setzen. Siehe Curl-Protokolle.

SSH: SFTP-Verbindung schlägt aufgrund eines falschen Schlüsseldateipfads fehl

• Symptom: SFTP-Operationen schlagen auf einem Windows-Agent fehl, obwohl die SSH-Schlüsseldateien korrekt installiert sind.
• Ursache: Die Pfadwerte PrivateKeyFile und PublicKeyFile im Abschnitt [SSH] von jitterbit.conf verwenden Windows-Backslash-Trennzeichen (\), die nicht unterstützt werden.
• Lösung: Verwenden Sie Schrägstriche in allen SSH-Schlüsseldateipfaden in jitterbit.conf, auch unter Windows (z. B. C:/jitterbit/keys/id_rsa). Siehe [SSH].

SFTP-SSH-Einstellungen fehlen oder befinden sich im falschen jitterbit.conf-Abschnitt

• Symptom: SFTP-Operationen, die einen privaten Schlüssel zur Authentifizierung verwenden, schlagen mit einem Fehler für eine leere private Schlüsseldatei fehl, nachdem ein Agent-Upgrade oder -Neustart durchgeführt wurde. SSH-Schlüssel-Einstellungen, die zur lokalen jitterbit.conf hinzugefügt wurden, funktionieren möglicherweise auch nach dem Neustart des Agenten nicht mehr.

  CURL_DEBUG_TEXT: Using SSH private key file ''
  CURL_DEBUG_TEXT: SSH public key authentication failed: Unable to extract public key from private key file
  

• Mögliche Ursachen:

  • Die Remote-Agent-Konfiguration ist aktiviert (standardmäßig aktiviert), daher haben Einstellungen, die über die Registerkarte Jitterbit Configuration der Management Console verwaltet werden, Vorrang. SSH-Schlüssel-Einstellungen, die nur zur lokalen jitterbit.conf hinzugefügt wurden, funktionieren möglicherweise nicht oder werden nach dem Neustart des Agenten nicht beibehalten.
  • Die SSH-Schlüssel-Einstellungen (PrivateKeyFile, PrivateKeyPassphrase, PublicKeyFile) befinden sich im falschen Abschnitt. Neuere Agent-Versionen analysieren streng und ignorieren SSH-Einstellungen, die außerhalb des Abschnitts [SSH] platziert werden (z. B. unter [SSL]).

• Lösung:

  1. Wenn die Remote-Konfiguration aktiviert ist, fügen Sie die SSH-Schlüssel-Einstellungen dort hinzu: Öffnen Sie die Schublade Agent group details für die Agent-Gruppe, wählen Sie die Registerkarte Jitterbit Configuration aus, und fügen Sie sie unter dem Abschnitt SSH hinzu. Siehe Jitterbit configuration.
  2. Wenn die lokale jitterbit.conf die Konfigurationsquelle ist, bestätigen Sie, dass die SSH-Schlüssel-Einstellungen unter [SSH] platziert sind (nicht [SSL]).
  3. Starten Sie die Agent-Services neu.
  4. Weitere Informationen zur Fehlerbehebung bei SFTP-Schlüsselauthentifizierung (Passwortfelder, Passphrase, Schlüsselformat) finden Sie unter SFTP "Login denied. Authentication failure." when using SSH keys.

SFTP-Authentifizierungsfehler bei einem bestimmten Server (cURL-Cipher-Nichtübereinstimmung)

• Symptom: Eine SFTP-Verbindung mit SSH-Schlüsselauthentifizierung schlägt auf einem privaten Agent mit Login denied. Authentication failure. fehl, aber andere SFTP-Verbindungen vom selben Agent (mit demselben Schlüssel) sind erfolgreich, und die Verbindung zum fehlgeschlagenen Server über die Befehlszeile des Betriebssystems ist ebenfalls erfolgreich.

  Failed to get ftp directory list for url sftp://... Login denied. Authentication failure.
  

• Ursache: Der SFTP-Server erfordert neuere SSH-Cipher, Schlüsselaustausch- oder Host-Schlüssel-Algorithmen, die die cURL-Bibliothek in älteren Agent-Versionen nicht unterstützt. Server, die die älteren Algorithmen noch akzeptieren, funktionieren weiterhin, weshalb derselbe Schlüssel bei anderen Hosts und über die Befehlszeile des Betriebssystems erfolgreich ist.

• Lösung: Aktualisieren Sie den privaten Agent auf Version 11.37 oder später, die eine aktualisierte cURL-Bibliothek mit Unterstützung für aktuelle SSH-Cipher, Schlüsselaustausch- und Host-Schlüssel-Algorithmen enthält.

HTTPS-Proxy: Basis-Authentifizierung durch Proxy-Tunnel schlägt fehl

• Symptom: Wenn der Agent sich über einen HTTPS-Proxy verbindet, der Basis-Authentifizierung erfordert, schlagen Verbindungen durch den Proxy-Tunnel mit einem Authentifizierungsfehler fehl.
• Ursache: Moderne JDK-Versionen deaktivieren standardmäßig die Basis-Authentifizierung während des HTTPS-Proxy-Tunneling. Die JVM-Eigenschaft jdk.http.auth.tunneling.disabledSchemes blockiert die Basis-Authentifizierung, sofern sie nicht explizit gelöscht wird.
• Lösung: Fügen Sie -Djdk.http.auth.tunneling.disabledSchemes="" zu CATALINA_OPTS hinzu, bevor Sie Tomcat starten. Schritt-für-Schritt-Anweisungen für Windows, Linux und Docker finden Sie unter Allow basic authentication during HTTPS proxy tunneling.

Private Agents in eingeschränkten Netzwerken: Nur ausgehende Konnektivität

• Symptom: Bei der Bereitstellung privater Agents hinter einer strikten Unternehmens-Firewall oder in einer eingeschränkten Umgebung (z. B. OpenShift) zusammen mit einem privaten API-Gateway fragen Netzwerk-Teams manchmal, welche eingehenden Ports auf dem Agent für Harmony oder das Gateway geöffnet werden müssen, um es zu erreichen.

• Ursache: Private Agents erfordern keine geöffneten eingehenden Ports, da die Agent-Konnektivität wie folgt funktioniert:

  • Private Agents akzeptieren keine eingehenden Verbindungen von Harmony oder von einem privaten API-Gateway. Der Agent stellt eine ausgehende WebSocket-Verbindung zu Harmony über HTTPS (Port 443) her. Der gesamte Datenverkehr von Harmony und vom Gateway zum Agent wird über diese vorher etablierte Verbindung zurückgeleitet.
  • Ein privates API-Gateway sendet API-Anfragen an Harmony, und Harmony leitet die Anfrage über die vorhandene ausgehende WebSocket zum entsprechenden Agent weiter. Der Agent leitet die API-Antwort-Nutzlast zurück an das private API-Gateway, daher muss der Agent auch das Gateway erreichen können (direkt oder über seinen Load Balancer in einer Multi-Gateway-Bereitstellung).

• Lösung:

  • Öffnen Sie ausgehende HTTPS (Port 443) vom Agent-Host zu den Harmony-Region-URLs. Die Verbindung wird auf WSS (sicheres WebSocket) für die laufende bidirektionale Kommunikation aktualisiert. Auf dem Agent-Host müssen keine eingehenden Ports für Harmony oder das Gateway geöffnet werden.
  • Konfigurieren Sie beim Einrichten der Firewall die regionsspezifischen Jitterbit-Services, die unter Ausgehende Kommunikation aufgelistet sind, auf die Allowlist. Verwenden Sie den Abschnitt, der für einen privaten Agent hinter einer Firewall gilt.
  • Falls der Agent für die Verwendung von nicht standardmäßigen (benutzerdefinierten) Ports konfiguriert wurde, lassen Sie diese auch durch die Unternehmens-Firewall zu. Siehe Netzwerk-Ports.
  • Falls ein privates API-Gateway bereitgestellt wird, lassen Sie auch ausgehende Konnektivität von jedem Agent-Host zum Gateway zu (direkt oder über seinen Load Balancer bei einer Multi-Gateway-Bereitstellung). Der Agent verbindet sich mit dem Gateway, um die API-Antwort-Payload zurückzugeben. Den vollständigen Request-Flow finden Sie unter Systemarchitektur des privaten API-Gateways.

Benutzerdefinierte API gibt 504 zurück, aber das Operationsprotokoll zeigt Erfolg

• Symptom: Eine benutzerdefinierte API gibt einen 504-Gateway-Timeout zurück, aber das Operationsprotokoll auf der Seite Runtime der Management Console zeigt, dass die Operation erfolgreich abgeschlossen wurde.
• Ursache: Wenn eine Request- oder Response-Payload (Header plus Body, komprimiert) etwa 1 KB überschreitet, speichert das Jitterbit-Cloud-API-Gateway die Payload, und der private Agent stellt eine ausgehende Verbindung zum jitterbitsysservice-Host seiner Region her, um die Request-Payload herunterzuladen (oder die Response-Payload hochzuladen), bevor der Vorgang abgeschlossen wird. Falls der Agent-Host diesen Host nicht erreichen kann, tritt bei der Übertragung ein Timeout auf und die API gibt einen 504 zurück, obwohl der Vorgang selbst ausgeführt wurde. Die standardmäßige Agent-Verbindungsprüfung überprüft nicht die Konnektivität zum jitterbitsysservice-Host, daher kann der Agent vollständig verbunden erscheinen, während dieser Host blockiert bleibt.
• Lösung:
  1. Fügen Sie den jitterbitsysservice-Host für Ihre Region (z. B. jitterbitsysservice.jitterbit.net) und seine statischen IP-Adressen zur ausgehenden Allowlist in der Firewall des Agent-Hosts hinzu. Siehe Jitterbit-Allowlist-Informationen für die regionsspezifischen URLs und IPs.
  2. Überprüfen Sie die Konnektivität, indem Sie einen HTTP-Test vom Agent-Host zur jitterbitsysservice-URL Ihrer Region durchführen, und bestätigen Sie dann, dass die API nicht mehr das Timeout überschreitet.

IPv6-Problem unter Windows

• Symptom: Einige Agents treten auf Konnektivitätsprobleme auf, wenn IPv6 auf dem Windows-Host aktiviert ist. Dies kann sich beispielsweise als Operationen manifestieren, die im Status Ausstehend stecken bleiben, mit einem schnell wachsenden ProcessEngine.log, wenn der IP-Helper-Service abstürzt und der Agent seine Verbindung zur internen Datenbank verliert.

• Lösung: Deaktivieren Sie sowohl IPv6 als auch IP Helper auf dem Windows-Host.

  Deaktivieren Sie IPv6 wie folgt:

  1. Öffnen Sie Systemsteuerung > Netzwerk und Internet > Netzwerkverbindungen.
  2. Öffnen Sie die Eigenschaften der Netzwerkverbindung.

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

     

  Deaktivieren Sie IP Helper wie folgt:

  1. Öffnen Sie Dienste.
  2. Suchen Sie IP Helper, klicken Sie mit der rechten Maustaste darauf, und wählen Sie Eigenschaften.
  3. Klicken Sie auf Beenden, und setzen Sie Starttyp auf Deaktiviert:

Azure VM: Verlorene Verbindungen und WebSocket-/I/O-Fehler

Dieser Abschnitt behandelt die Fehlerbehebung für private Agenten, die auf virtuellen Microsoft Azure-Maschinen (VMs) installiert sind. Informationen zur allgemeinen Leistungsoptimierung finden Sie unter Leistungsoptimierung für private Agenten.

Verlorene Verbindungen

Azure setzt das WebSocket-Leerlauf-Timeout auf 4 Minuten, während das Standard-Heartbeat-Intervall des privaten Agenten 5 Minuten beträgt. Um verlorene Verbindungen zu beheben, reduzieren Sie das Heartbeat-Intervall:

1. Öffnen Sie jitterbit-agent-config.properties in einem Text-Editor:

   • Linux: <JITTERBIT_HOME>/Resources/
   • Windows: C:\Program Files\Jitterbit Agent\Resources

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

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

3. Ändern Sie den Wert auf agent.heart.beat.interval=3.

4. Speichern Sie die Datei und starten Sie den Agenten neu.

WebSocket- und I/O-Fehler

WebSocket- und I/O-Fehler lassen sich beheben, indem man das IP-Leerlauf-Timeout der Azure VM, das NAT-Gateway-TCP-Leerlauf-Timeout und das Virtual Network (VNET)-Flow-Timeout jeweils auf 15 Minuten einstellt. Dies wird in den folgenden Schritten behandelt.

Relevante Fehler identifizieren

Überprüfen Sie die Operationsprotokolle und jitterbit-agent.log auf die folgenden Meldungen.

Operationsprotokollfehler:

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.

Agentprotokollfehler:

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

Agent mit Drain Stop beenden

Drain Stop des Agenten durchführen, bevor Sie Timeout-Einstellungen aktualisieren. Wenn sich mehr als ein Agent in der betroffenen Gruppe befindet, führen Sie Drain Stop für alle durch.

Agentressourcen isolieren

Es wird empfohlen, die VM des Agenten und die zugehörigen Ressourcen (VNET, IP, NAT-Gateway, NIC und NSG) in ihre eigene Ressourcengruppe in Azure zu trennen.

IP-Leerlauf-Timeout aktualisieren

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

2. Klicken Sie auf das IP-Element, das der VM zugeordnet ist:

   

3. Klicken Sie auf Konfiguration und setzen Sie Leerlauf-Timeout (Minuten) auf 15:

   

NAT-Gateway-TCP-Leerlauf-Timeout aktualisieren

1. Navigieren Sie im Azure-Portal zur Ressourcengruppe, die dem Agent-VM zugeordnet ist.

2. Klicken Sie auf das NAT-Gateway-Element, das dem VM und der IP zugeordnet ist. Das zugeordnete NAT-Gateway wird auch im IP-Element unter Übersicht neben Zugeordnet zu aufgelistet.

3. Klicken Sie auf Konfiguration und setzen Sie TCP-Leerlauftimeout (Minuten) auf 15.

VNET-Flusszeitüberschreitung aktualisieren

1. Navigieren Sie im Azure-Portal zur Ressourcengruppe, die dem Agent-VM zugeordnet ist.

2. Klicken Sie auf das VNET-Element, das dem VM zugeordnet ist:

   

3. Klicken Sie in Übersicht neben Flusszeitüberschreitung auf Konfigurieren:

   

4. Aktivieren Sie Flusszeitüberschreitung aktivieren und setzen Sie Flusszeitüberschreitung (Minuten) auf 15:

   

5. Klicken Sie auf Speichern.

Agent neu starten

1. Starten Sie den Agent-VM im Azure-Portal neu.

2. Starten Sie den gestoppten Agent (Windows | Linux).

Observability

Native Observability zeigt keine Daten an

• Symptom: Nach dem Aktivieren von Native Observability zeigt die Registerkarte Metriken der Seite Agents der Management Console keine Daten an, zeigt unvollständige Daten an, oder die Diagramme bleiben nach mehreren Minuten leer.

• Mögliche Ursachen:

  • Der Abschnitt [AgentMetrics] in jitterbit.conf hat nicht Enabled=true, was verhindert, dass der Metrik-Service ausgeführt wird.
  • Nicht alle erforderlichen Einstellungen im Abschnitt [AgentCapability] sind auf true gesetzt.
  • Die Agent-Services wurden nach Konfigurationsänderungen nicht neu gestartet.
  • Der Agent-Host kann die Harmony-Cloud nicht erreichen, was verhindert, dass Metriken eingereicht werden.
  • Der Metrik-Service ist so konfiguriert, dass er sich mit der gebündelten PgBouncer-Instanz des Private Agent auf einem anderen Port verbindet als PgBouncer tatsächlich verwendet, sodass der Metrik-Service keine Verbindung herstellen kann und Metriken nur teilweise erfasst werden. Diese Port-Nichtübereinstimmung kann nach bestimmten Agent-Installationen oder -Upgrades auftreten.
  • Vor Agent-Version 12.9 wurde bei der Installation eines Private Agent als Nicht-Root-Benutzer unter Linux PgBouncer nicht bereitgestellt, sodass der Service nie gestartet wurde und sein Status immer als fehlerhaft angezeigt wird.

• Lösung:

  • Überprüfen Sie, dass jitterbit.conf alle erforderlichen Einstellungen aus den Abschnitten [AgentMetrics] und [AgentCapability] enthält. Siehe das vollständige Konfigurationsbeispiel in Native Observability-Setup.
  • Überprüfen Sie metrics.log und metrics_service.log im Agent-Protokollverzeichnis auf Fehler. Diese Protokolle zeichnen den Status des Metrik-Service auf und geben an, ob Metriken erfasst und eingereicht werden.
  • Starten Sie die Agent-Services neu, wenn Konfigurationsänderungen vorgenommen wurden.
  • Überprüfen Sie, dass der Agent-Host die Harmony-Cloud erreichen kann. Siehe Agent offline oder nicht erreichbar. Wenn der Agent über einen Proxy verbunden ist, siehe Agent-Metriken fehlen, wenn der Agent über einen HTTP-Proxy verbunden ist.
  • Wenn Metriken nur teilweise erfasst werden und die obigen Schritte das Problem nicht beheben, wenden Sie sich an den Jitterbit-Support, um zu überprüfen, dass der Verbindungsport des Metrik-Service für PgBouncer mit dem konfigurierten Port von PgBouncer übereinstimmt.
  • Verwenden Sie für einen neuen Nicht-Root-Linux-Private-Agent Version 12.9 oder später, bei der PgBouncer während der Installation korrekt bereitgestellt wird. Das Upgrade eines vorhandenen Nicht-Root-Linux-Agent auf 12.9 oder später stellt PgBouncer nicht rückwirkend bereit; der Agent muss neu installiert werden.

Agent-Metriken fehlen, wenn der Agent über einen HTTP-Proxy verbunden ist

• Symptom: Der private Agent verbindet sich erfolgreich mit Harmony über einen konfigurierten HTTP-Proxy, aber die Registerkarte Metrics der Seite Agents der Management Console zeigt keine Daten an. Die Datei metrics.log kann Einträge wie Client.Timeout exceeded while awaiting headers enthalten.
• Ursache: Der Agent sendet Metriken über HTTPS mit einer separaten Verbindung, die die Proxy-Konfiguration des Agents nicht übernimmt. Wenn der Proxy nur HTTP unterstützt oder nicht für den Metrics-Traffic des Agents konfiguriert ist, können die Metriken Harmony nicht erreichen, obwohl sich der Agent selbst erfolgreich verbindet.
• Lösung:
  1. Bestätigen Sie, dass der Proxy HTTPS unterstützt. Agent-Metriken werden über HTTPS übermittelt, daher blockiert ein Proxy, der nur HTTP-Traffic verarbeitet, diese. Das Aktivieren von HTTPS auf dem Proxy behebt das Problem.
  2. Wenn Sie HTTPS auf dem Proxy nicht aktivieren können oder Metriken nach dem Aktivieren immer noch fehlen, benötigt der Metrics-Traffic des Agents eine eigene Proxy-Konfiguration, getrennt von der des Agents. Kontaktieren Sie den Jitterbit-Support, um dies einzurichten.

Datadog-Agent startet nach Docker-Installation nicht

• Symptom: Nach der Installation des Datadog-Agenten in einem Docker-Container als Teil des Datadog-Observability-Setups startet der Datadog-Agent nicht.
• Ursache: Ein bekanntes Datadog-Problem führt dazu, dass der Agent beim Start fehlschlägt, wenn die Konfigurationsdatei des Security-Agenten nicht vorhanden ist.

• Lösung: Kopieren Sie die Beispielkonfigurationsdatei des Security-Agenten:

  cp /etc/datadog-agent/security-agent.yaml.example /etc/datadog-agent/security-agent.yaml
  

  Starten Sie dann den Datadog-Agent. Beachten Sie, dass der Datadog-Agent auf Docker nicht automatisch mit dem Container startet und nach jedem Container-Start manuell gestartet werden muss:

  sudo datadog-agent run
  

System- und Betriebssystemprobleme

Apache-Serverfehler: Keine installierten ConfigArgs

• Symptom: Der Agent gibt folgende Meldung zurück:

  No Installed ConfigArgs for the Service "Jitterbit Apache Server"
  

• Ursache: Das Konto, das den Jitterbit Apache-Server ausführt, hat keinen vollständigen Zugriff auf das Jitterbit-Installationsverzeichnis.

• Lösung: Gewähren Sie dem Dienstkonto vollständigen Zugriff auf den Jitterbit-Installationsordner und starten Sie die Dienste neu.

Apache/Tomcat: APPARENT DEADLOCK

• Symptom: Unter anhaltender Last stoppt der Agent die Verarbeitung von Operationen und kann in der Management Console als stoppend angezeigt werden. Das Agent-Log enthält:

  ThreadPoolAsynchronousRunner: APPARENT DEADLOCK
  

  Das Log kann auch An existing connection was forcibly closed by the remote host für die PostgreSQL-Datenbank des Agents anzeigen. Ein Neustart des Agenten stellt den normalen Betrieb vorübergehend wieder her, woraufhin der Deadlock unter Last erneut auftritt.

• Mögliche Ursachen:

  • Der Connection-Pool der Agent-Datenbank verursacht einen Deadlock, wenn die interne PostgreSQL-Datenbank unter hoher Last keine verfügbaren Verbindungen mehr hat.
  • Der Java-Datenbankverbindungs-Pool des Agenten (im Log als c3p0 angezeigt) kann sich nach einem kurzzeitigen Datenbankverbindungsverlust nicht wiederherstellen, beispielsweise während einer vorübergehenden Netzwerkunterbrechung, obwohl PostgreSQL selbst mit Standard-Timeouts gesund und reaktionsfähig bleibt.
  • Veraltete Jitterbit-Prozesse halten Threads und Datenbankverbindungen. Dies kann auftreten, wenn ein Agent aktualisiert wird, während Operationen noch ausgeführt werden, oder wenn die Dienste beendet werden, ohne dass alle Jitterbit-Prozesse sauber beendet werden.
  • Der Agent-Host ist durch Spitzenaktivität überlastet oder seine CPU wird gedrosselt. Beispielsweise drosselt eine burstfähige Cloud-Instanz (wie ein AWS t3-Typ) ihre CPU, sobald ihre Burst-Guthaben aufgebraucht sind, was die interne PostgreSQL unter Last aushungern kann.

• Lösung:

  • Alle Jitterbit-Dienste beenden, alle noch laufenden Jitterbit-Prozesse beenden und dann die Dienste neu starten, um das Deadlock zu beheben.
  • Falls das Deadlock im Java-Verbindungspool (c3p0) liegt und PostgreSQL selbst funktioniert einwandfrei, den Agent auf seinen internen C++-Verbindungspool umschalten, indem man UseInternalPooling=true im Abschnitt [DbInfo] von jitterbit.conf setzt, und dann den Agent neu starten. Der interne Pool erholt sich zuverlässiger von unterbrochenen oder veralteten Verbindungen. Bei Neuinstallationen von Windows Private Agents Version 12.5 und später ist dies bereits standardmäßig aktiviert.
  • Die Last auf dem Agent reduzieren: Operationen planen, um Spitzenlastspitzen zu vermeiden, Agents zur Agent-Gruppe hinzufügen, um die Last zu verteilen, und bestätigen, dass der Host die Systemanforderungen erfüllt. Für Cloud-Hosts eine Instanzart mit dauerhafter (nicht burstfähiger) CPU-Leistung verwenden.
  • Vor dem Upgrade eines Agents diesen drain stop durchführen und laufende Operationen beenden lassen, damit während des Upgrades keine Prozesse Datenbankverbindungen halten. In ausgelasteten Umgebungen zusätzliche Zeit für den Abschluss des Drain Stop einplanen.

Cleanup-Dienst kann gesperrte Protokolldateien unter Windows nicht entfernen

• Symptom: Protokolldateien auf einem Windows Private Agent wachsen unbegrenzt, und der Cleanup-Dienst entfernt sie nicht. Das Protokoll des Cleanup-Diensts meldet einen Fehler wie:

  Failed to remove file, retries (10) exhausted: '...\jitterbit tomcat server-stdout.<date>.log'. Reason: The process cannot access the file because it is being used by another process.
  

• Mögliche Ursachen:

  • Ein Agent-Prozess hält die Datei offen. Unter Windows kann der Cleanup-Dienst eine Datei, die in Gebrauch ist, nicht entfernen, und Tomcat hält seine stdout- und stderr-Protokolldateien während der Ausführung offen.
  • Software von Drittanbietern (Antivirus oder ein Überwachungs-Agent) sperrt Dateien im Protokollverzeichnis des Agents.

• Lösung:

  • CleanupRules.xml bearbeiten, um die Aufbewahrung (FileAge) für die betroffenen Protokollverzeichnisse zu verkürzen, damit Dateien schnell entfernt werden, sobald sie nicht mehr in Gebrauch sind. Den Agent nach dem Bearbeiten der Datei neu starten.
  • Die kontinuierlich geschriebenen Tomcat-stdout- und stderr-Protokolle aus den Cleanup-Regeln ausschließen, damit der Dienst nicht wiederholt Dateien erneut versucht, die während der Agent-Ausführung gesperrt bleiben.
  • Falls Software von Drittanbietern beteiligt ist, das Jitterbit-Installationsverzeichnis und die Protokollverzeichnisse zur Ausschlussliste hinzufügen.
  • Falls Protokolle auch mit gültigen Cleanup-Regeln weiter wachsen, den Jitterbit-Support kontaktieren.

Linux: Agent-Dienste starten nach einem Neustart nicht („postmaster.pid existiert nicht")

• Symptom: Nach dem Neustart eines Linux Private Agent-Hosts starten die Agent-Dienste nicht. Das Ausführen von sudo jitterbit status zeigt, dass der Scheduler und andere Dienste nicht laufen, und die Agent-Protokolle (oder die Konsole) enthalten Fehler wie:

  postmaster.pid does not exist
  

  reindexdb: could not connect to database template1: could not connect to server: No such file or directory
  

• Ursache: Die Dateiberechtigungen im Verzeichnis der gebündelten PostgreSQL-Daten sind zu permissiv. PostgreSQL erfordert, dass das Datenverzeichnis 700 (nur Eigentümer) ist. Falls die Berechtigungen lockerer sind (z. B. 755 oder 777), weigert sich PostgreSQL zu starten, was verhindert, dass der Rest des Agents startet.

• Lösung:

  1. Bestätigen, dass /opt/jitterbit und seine Unterverzeichnisse dem Benutzer und der Gruppe jitterbit gehören:

     sudo chown -R jitterbit:jitterbit /opt/jitterbit
     

• Setzen Sie das PostgreSQL-Datenverzeichnis auf 700:

  ```sh
  sudo chmod 700 /opt/jitterbit/DataInterchange/pgsql/data
  ```
  

  1. Starten Sie die Agent-Services:

     sudo /etc/init.d/jitterbit start
     

Linux: Antivirus entfernt PgBouncer, Agent kann sich nicht bei der gebündelten Datenbank authentifizieren

• Symptom: Nach der Migration eines privaten Linux-Agenten auf einen neuen Host (oder nach einer Neuinstallation) können die Agent-Services nicht gestartet werden. Das postgresql.log zeigt:

  [FATAL] password authentication failed for user "jitterbit"
  

  Das Agent-Protokoll zeigt, dass es keine Verbindung zur Datenbank herstellen kann. Der Fehler bleibt auch nach vollständiger Deinstallation und Neuinstallation bestehen.

• Ursache: Ein hostbasiertes Antivirus- oder Endpoint-Protection-Produkt erkennt die gebündelte PgBouncer-Binärdatei als verdächtig und entfernt oder isoliert sie. Ohne PgBouncer kann sich der Agent nicht bei seiner internen PostgreSQL-Datenbank authentifizieren.

• Lösung:

  1. Deaktivieren Sie das Antivirus- oder Endpoint-Protection-Produkt auf dem Agent-Host vorübergehend.
  2. Fügen Sie das Jitterbit-Installationsverzeichnis (normalerweise /opt/jitterbit) zur Ausschlussliste des Antivirus hinzu.

  3. Installieren Sie den Agent neu. Auf RHEL/CentOS:

     sudo dnf reinstall jitterbit-agent
     

  4. Starten Sie die Agent-Services und bestätigen Sie den normalen Betrieb. Aktivieren Sie dann das Antivirus mit der Ausschlussliste erneut.

Sicherheitsscans kennzeichnen log4j-over-slf4j.jar als Log4j-1.x-Sicherheitslücke

• Symptom: Ein Sicherheitsscan einer privaten Agent-Installation kennzeichnet Dateien wie log4j-over-slf4j-1.7.21.jar als veraltete Log4j-1.x-Sicherheitslücke.
• Lösung: Es ist keine Maßnahme erforderlich. log4j-over-slf4j.jar ist nicht Log4j 1.x. Es ist Teil des SLF4J-Logging-Frameworks und fungiert als Bridge, die Aufrufe von Drittanbieter-Bibliotheken, die gegen die Log4j-1.x-API geschrieben wurden, zum aktuellen, unterstützten Logging-Framework des Agenten umleitet. Die Datei enthält nicht den anfälligen Log4j-1.x-Code. Ihre Anwesenheit ist die Risikominderung des Agenten gegen Log4j-1.x-Exposition, nicht eine Instanz der Sicherheitslücke.

Docker

Allgemein

Die folgenden Punkte gelten für Docker-bezogene Probleme:

• Ein privater Docker-Agent wird nicht gestartet, wenn das conf-Verzeichnis sowohl eine credentials.txt-Datei als auch eine register.json-Datei enthält.

• Das Ausführen privater Agenten auf Kubernetes ist nicht offiziell von Jitterbit zertifiziert, und Jitterbit hat keine produktionsreife Kubernetes-Konfiguration validiert. Das Helm-Chart und die Kubernetes-Schritte werden nur als Ausgangspunkt zum Testen oder für weitere Entwicklung bereitgestellt.

Agent kann nach der Abmeldung nicht mit Authentifizierungsfehlern neu gestartet werden

• Symptom: Ein Agent, der mit deregisterAgentOnDrainstop=true (oder der Umgebungsvariable AUTO_REGISTER_DEREGISTER_ON_DRAINSTOP) konfiguriert ist, kann nach dem Stoppen nicht neu gestartet werden. Dies gilt für Docker-Agenten, die ein persistentes Volume für /opt/jitterbit/Resources verwenden, und für nicht containerisierte Linux-Agenten.

• Ursache: Wenn der Agent mit deregisterAgentOnDrainstop=true stoppt, wird er von Harmony abgemeldet, aber die nun ungültige credentials.txt-Datei bleibt auf der Festplatte. Beim Neustart versucht der Agent, die veralteten Anmeldedaten zu verwenden, und kann sich nicht authentifizieren.

  Hinweis

  Ab Docker-Agent-Version 12.4 wird beim Neustart des Containers mit aktiviertem deregisterAgentOnDrainstop=true der vorhandene Agent automatisch abgemeldet und ein neuer registriert. Die folgenden Schritte gelten für Docker-Agenten in früheren Versionen und für Linux-Agenten in jeder Version.

• Lösung: Entfernen Sie die veraltete credentials.txt-Datei, und starten Sie den Agent neu, um eine neue Registrierung auszulösen.

  Auf einem nicht containerisierten Linux-Agent entfernen Sie die Datei direkt:

  rm /opt/jitterbit/Resources/credentials.txt
  

  Auf einem Docker-Agent entfernen Sie die Datei aus dem bereitgestellten Volume:

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

  Ersetzen Sie VOLUME_NAME durch den Namen des Docker-Volumes, unter dem /opt/jitterbit/Resources bereitgestellt wird.

Listening-Dienst

„Cluster hat die erforderliche Mindestgröße nicht erreicht"

• Symptom: Operationen, die den Listening-Dienst verwenden, schlagen mit folgendem Fehler fehl:

  Failed to enable events for operation. Cluster has not met the minimum required size.
  

• Mögliche Ursachen:

  • Zu wenige Agents in der Agent-Gruppe werden ausgeführt und sind dem Cluster beigetreten. Bei einer Gruppe von \(N\) Agents, unabhängig davon, ob jeder Agent ausgeführt wird, müssen \((N / 2) + 1\) Agents (abgerundet) ausgeführt werden und Teil des Clusters sein.
  • Ein oder mehrere Agents haben ihre Verbindung zum Cluster verloren und konnten nicht erneut beitreten, wodurch die Anzahl der laufenden, beigetretenen Agents unter die erforderliche \((N / 2) + 1\) fiel.
  • Eine Netzwerkunterbrechung hat die Agent-Gruppe in mehrere kleinere Cluster aufgeteilt. Beispielsweise kann eine Netzwerkaufteilung in einer Gruppe von 4 Agents zwei Cluster mit je 2 Agents erzeugen; keiner erfüllt die erforderliche \((N / 2) + 1\) von 3, daher melden beide den Fehler, obwohl jeder Agent ausgeführt wird.

• Lösung:

  • Bestätigen Sie, dass \((N / 2) + 1\) der Agents in der Gruppe ausgeführt werden und Teil des Clusters sind, wobei \(N\) die Anzahl der in der Agent-Gruppe registrierten Agents ist, unabhängig davon, ob jeder ausgeführt wird. Beispielsweise erfordert eine Gruppe von 4 Agents 3, und eine Gruppe von 5 Agents erfordert ebenfalls 3. Um zu sehen, welche Agents beigetreten sind, verwenden Sie die Listening-Dienst-REST-API, um den Cluster-Status anzuzeigen.
  • Überprüfen Sie, dass die TCP-Ports 5701 und 5801 zwischen allen Agent-Hosts offen sind und nicht durch Antivirus- oder Firewall-Regeln blockiert werden.
  • Wenn der Cluster ausfällt und Nachrichten mit aktivierter Persistenz unverarbeitet bleiben, stellen Sie den Cluster manuell wieder her. Siehe Cluster-Wiederherstellung nach Agent-Fehler.

  Hinweis

  Eine ungerade Anzahl von Agents in der Agent-Gruppe wird empfohlen, ist aber nicht erforderlich. Bei einer geraden Anzahl kann eine Netzwerkunterbrechung die Gruppe in zwei Hälften aufteilen, von denen keine groß genug ist, um den Cluster am Laufen zu halten.

Listening-Dienst-Nachrichten nicht zugestellt

• Symptom: Der Wiederholungsmechanismus des Clusters verwirft unzugestellte Nachrichten nach einem konfigurierten Zeitraum stillschweigend, wodurch abhängige Operationen nicht ausgeführt werden.
• Lösung: Um das Aufbewahrungsfenster zu verlängern oder das Löschen zu verhindern, bearbeiten Sie JITTERBIT_HOME/Resources/jitterbit-agent-config.properties und setzen Sie agent.sdk_framework.retry.deleteRetryableMessageAfter auf einen höheren Wert (in Minuten). Um alle Nachrichten auf unbestimmte Zeit beizubehalten, setzen Sie den Wert auf -1. Starten Sie den Agent nach Änderungen neu.

Protokollierung

Benutzerdefinierte API-Operationsprotokolle werden nicht angezeigt

• Symptom: Eine Operation, die durch eine benutzerdefinierte API ausgelöst wird, wird ohne Fehler ausgeführt, aber es wird kein Protokolleintrag in Studio oder auf der Seite Laufzeit der Management Console angezeigt.
• Ursache: Wenn eine benutzerdefinierte API eine Operation auslöst, werden Operationsprotokolle nur generiert, wenn die Operation erfolglos ist. Erfolgreiche benutzerdefinierte API-Operationen erzeugen standardmäßig keinen Protokolleintrag.
• Lösung: Um Protokolle für erfolgreiche benutzerdefinierte API-Operationen zu erfassen, aktivieren Sie Operationsdebug-Protokollierung für die Operation. Beachten Sie, dass API Manager eine eigene separate Protokollierungsansicht für API-Anfragen hat.

Operation debug logging stops before the selected end date

• Symptom: Operation debug logging wurde mit einem zukünftigen Enddatum aktiviert, aber die Protokollgenerierung stoppt vor diesem Datum.
• Cause: Bei Cloud-Agent-Gruppen ist das Enddatum der Operation-Debug-Logging-Einstellung unzuverlässig. Die Protokollgenerierung kann vor dem konfigurierten Zeitraum enden.
• Resolution: Aktivieren Sie Operation debug logging nach Bedarf erneut.

Operation debug log files missing .input or .output data

• Symptom: Auf einem privaten Agent hat eine Operation operation debug logging aktiviert, wobei Komponenteneingabe- und Ausgabedaten aktiviert sind. Der Debug-Log-Ordner in DataInterchange/Temp/Debug enthält die .jtr-Dateien für jeden Schritt, aber die entsprechenden .input- und .output-Datendateien fehlen.

• Possible causes:

  • Der cleanup service des Agenten löscht .input- und .output-Dateien, bevor diese überprüft werden können.
  • Der Agent wurde neu gestartet, während die Operation noch ausgeführt wurde, sodass die Dateien nie vollständig geschrieben wurden. Siehe Component input/output data not generated für dieses Szenario.

• Resolution:

  1. Öffnen Sie auf dem Agent-Host CleanupRules.xml im Agent-Installationsverzeichnis.

  2. Suchen Sie die Cleanup-Regel für das Verzeichnis DataInterchange/Temp/Debug und erhöhen Sie den Wert <FileAge NumDays = "2"...> auf ein längeres Aufbewahrungsfenster (z. B. 7).

     <CleanupRule>
       <DirectoryPath SearchSubDirectory = "YES" >DataInterchange/Temp/Debug</DirectoryPath>
       <Pattern>*</Pattern>
       <FileAge NumDays = "7" Comparator = "GE"/>
       <FileSize Size = "0" Comparator = "GE"/>
     </CleanupRule>
     

  3. Starten Sie die Agent-Services neu.

Component input/output data not generated

• Symptom: Operation debug logging ist aktiviert, die Generierung von Komponenteneingabe- und Ausgabedaten ist aktiviert, aber es werden keine Eingabe-/Ausgabedatendateien für Private-Agent-Operationen angezeigt.

• Resolution: Überprüfen Sie das Verbose Log Shipper-Service-Protokoll auf dem Agent:

  <JITTERBIT_HOME>/VerboseLogShipper/verbose-log-shipper.out.log
  

  Wenn das Protokoll Fehler anzeigt, starten Sie den Verbose Log Shipper-Service neu. Unter Linux kann dies ohne einen vollständigen Agent-Neustart durchgeführt werden:

  jitterbit stop verboselogshipper
  jitterbit start verboselogshipper
  

  Unter Windows und Linux wird der Verbose Log Shipper-Service auch durch einen Neustart aller Jitterbit-Agent-Services neu gestartet.