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.

• Observability

  -   [Native Observability zeigt keine Daten an](#observability-no-data)
  -   [Agent-Metriken fehlen, wenn der Agent sich über einen HTTP-Proxy verbindet](#metrics-proxy)
  -   [Datadog-Agent startet nach Docker-Installation nicht](#datadog-docker)
  

  • System- und Betriebssystemprobleme

    • Apache-Serverfehler: Kein installiertes ConfigArgs
    • Apache/Tomcat: APPARENT DEADLOCK
    • Apache stürzt unter gleichzeitiger Last unerwartet ab
    • 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 startet nach Abmeldung mit Authentifizierungsfehlern nicht neu

  • Listening Service

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

  • Protokollierung

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

Diagnoseschritte

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

Agent-Status überprüfen

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

Agent-Protokolldateien überprüfen

Die Agent-Protokolldateien sind die primäre Quelle für Diagnoseinformationen. Überprüfe 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 findest du 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 sowie zu Apache- und Tomcat-Services.
• service-status: Zeigt den Laufzustand aller Agent-Services an (Apache, Tomcat, PostgreSQL, PgBouncer, VerboseLogShipper).
• generate-report: Erstellt einen diagnostischen HTML-Bericht und eine ZIP-Datei mit allen Agent-Protokolldateien. Dies ist hilfreich beim Eskalieren zum Jitterbit-Support. Bei Linux-Agenten enthält der Bericht derzeit keine PostgreSQL-Daten; Windows-Agenten sind nicht betroffen.

So greifen Sie auf die Tools zu:

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

• Lösung:

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

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

    Falls der Service nicht startet, überprüfen Sie folgende 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.

  • Falls die Services ausgeführt werden, aber die Harmony Cloud nicht erreichen können, überprüfen Sie folgende Punkte:

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

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

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

    • Ein Netzwerkgerät (Firewall, NAT-Gateway oder Cloud-VM-Idle-Timeout) kann die ausgehende Verbindung des Agents zwischen den Heartbeats schließen. Versuchen Sie, das Heartbeat-Intervall des Agents (agent.heart.beat.interval) zu reduzieren. Für Cloud-gehostete Agenten siehe Azure VM: Verlorene Verbindungen und WebSocket-/E-A-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.
    • Falls 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 Privat 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 Agents wurde möglicherweise auf Infrastrukturebene dupliziert (z. B. ein VM-Klon, ein Disk-Image, eine Maschinenvorlage oder ein Snapshot, der nach der Installation und Registrierung des Agents erstellt wurde). Der duplizierte Host trägt die gleichen Agent-credentials.txt, sodass sich beide Hosts bei Harmony als derselbe Agent authentifizieren und parallel ausgeführt werden, was zu Kollisionen führt. Zwei Agents können nicht gleichzeitig unter denselben Anmeldedaten ausgeführt werden.
• Lösung:
  1. Bestätigen Sie, dass ein Duplikat ausgeführt wird. Beenden Sie den Agent auf dem Host, den Sie behalten möchten, warten Sie 10 Minuten, und aktualisieren Sie dann die Registerkarte Privat der Seite Agents der Management Console. Wenn der Agent von Beendet zurück zu Wird ausgeführt wechselt, meldet sich ein anderer Host unter derselben Identität an.
  2. Identifizieren und fahren Sie den doppelten Host herunter.
  3. Wenn der duplizierte 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 neu, den Sie behalten möchten.
  4. Überprüfen Sie, ob der neue Agent auf der Registerkarte Privat der Seite Agents der Management Console als Wird ausgeführt aufgelistet ist.
  5. Löschen Sie den alten Agent-Eintrag mit Actions > Remove.

Agent zeigt „Unbekannt" oder „Beendet" an, nachdem eine Agent-Gruppe über Betriebssysteme hinweg wiederverwendet wurde

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

Agent-Synchronisierungsfehler: Projektänderungen werden nicht angewendet

• Symptom: Nach der Bereitstellung 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.
  • Während der Synchronisierung ist ein Netzwerk-Timeout oder ein Autorisierungsfehler aufgetreten.
  • Wenig Speicherplatz auf dem Agent-Host hat verhindert, dass die synchronisierten Projektdateien geschrieben werden.

• Lösung:

  • Stellen Sie das vollständige Projekt erneut bereit: Verwenden Sie in Studio Deploy, das alle Operationen des Projekts bereitstellt, anstatt ein Configurable Deploy nur ausgewählter Workflows oder Operationen durchzuführen.
  • Starten Sie die Agent-Services neu, um eine Neusynchronisierung aller bereitgestellten Projekte zu erzwingen.
  • Überprüfen Sie die Agent-Protokolle auf synchronisierungsbezogene Netzwerk-Timeouts oder Autorisierungsfehler.
  • Überprüfen Sie den verfügbaren Speicherplatz auf dem Agent-Host. Ein voller oder fast voller Datenträger kann verhindern, dass der Agent synchronisierte Projektdateien schreibt. 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 entsteht kurzzeitig ein 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, durchsuchen Sie jitterbit-agent.log nach environment-deploy. Jeder Logeintrag 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. Informationen zum Reduzieren von Synchronisierungszeiten finden Sie unter Leistungsoptimierung der Umgebungssynchronisierung.
  3. Wenn Synchronisierungsdauern konsistent übermäßig lang sind (mehr als einige Minuten), wenden Sie sich an den Jitterbit-Support.

Agent wird als nicht leistungsfähig angezeigt

• Symptom: An die Agent-Gruppe übermittelte Operationen 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 im Process Engine des Agents sind bereits in Verwendung, 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 Leistungsmetrik ist aktiviert und hat ihren Schwellenwert erreicht. CPU-Auslastung, Speicherauslastung und Apache-Thread-Auslastung können jeweils zum Leistungsstatus 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-Agents erfasst, daher trägt sie nicht zum Leistungsstatus 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 Agents in der Gruppe untätig sind oder unterausgelastet sind.

• Lösung: Überprüfen Sie ProcessEngine.log auf lange Sequenzen von Leistungsstatusänderungen, um zu bestätigen, dass der Agent zwischen leistungsfähigen und nicht leistungsfähigen Zuständen wechselt, und 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 ihn daher konservativ fest.
  • Bestimmen Sie, welche Leistungsmetriken im Abschnitt [AgentCapability] aktiviert sind. Wenn keine aktiviert sind, sind CPU- und Speicherlast nicht das, was den Leistungsstatus des Agents geändert hat, 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 einer dieser Werte seinen Schwellenwert überschreitet, wird der Agent unabhängig von der Thread-Verfügbarkeit nicht leistungsfähig. 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 Metriken 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 Agents enthält, überprüfen Sie ProcessEngine.log auf allen Agents in der Gruppe, um zu bestimmen, ob alle Agents gleichzeitig nicht leistungsfähig waren, als die Operation fehlgeschlagen ist. Wenn nur ein Agent nicht leistungsfähig war, sollte die Operation an einen leistungsfähigen Agent weitergeleitet werden. Überprüfen Sie, ob der Lastenausgleich für die Gruppe korrekt konfiguriert ist.
  • Wenn Ressourcenlimits konsistent erreicht werden, fügen Sie Agents zur Gruppe hinzu, um die Last zu verteilen.
  • Wenn Speicherdruck der Auslöser ist, siehe Java heap space: OutOfMemoryError.

Transformation schlägt fehl: „Datei im lokalen Dateispeicher nicht gefunden"

• Symptom: Ein Vorgang schlägt während einer Transformation mit einer Fehlermeldung fehl, die angibt, 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 von der Harmony Cloud zum Agenten synchronisiert, sodass der Agent die Datei zur Laufzeit nicht finden kann. 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 Agenten höchstens einmal auf, und der Agent stellt die fehlenden Metadaten bei der nächsten Umgebungssynchronisierung wieder her (nächster Vorgangslauf 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 Agenten weiterhin fehlschlägt, liegt wahrscheinlich ein tieferes Problem vor, z. B. eine Umgebung, die ihre Bereitstellungsdatensatzgrenze erreicht hat, oder eine versionsspezifische Regression. Kontaktieren Sie den Jitterbit-Support mit dem Namen des fehlgeschlagenen Vorgangs und der TransformID sowie der File_ID aus der Fehlermeldung.

Installations- und Upgrade-Fehler

Fehler 1720 oder 1722 bei Windows-Installation

• Symptom: Die Installation des privaten Windows-Agenten schlägt teilweise fehl 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 im Installer enthaltene PostgreSQL-Datenbank sowie der Windows-Dienst jitterbitpostgres werden möglicherweise nicht vollständig erstellt. Die Meldung kann stattdessen eine andere Aktion benennen, z. B. InstallVerboseLogShipper.

• Mögliche Ursachen:

  • Ein fehlendes oder in Konflikt stehendes Microsoft Visual C++ Redistributable (das im Installer enthaltene PostgreSQL benötigt es).
  • Unzulässige Zeichen im PostgreSQL-Passwort.
  • Bei einer Neuinstallation verbleibende PostgreSQL-Komponenten von einem vorherigen Agenten. 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 Agenten. 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.
  • Bei einem Upgrade von einer vorherigen erweiterten Installation, bei der PostgreSQL für die Ausführung unter einem Windows-Dienstkonto konfiguriert wurde, das nicht jitterbitpostgres ist (z. B. NT AUTHORITY\NetworkService), könnte das Upgrade bei Agent-Versionen vor 12.10 mit Fehler 1720 fehlschlagen.

• 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 verbotene 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 das verbleibende PostgreSQL vollständig: Folgen Sie Deinstallieren eines privaten Windows-Agents, und bestätigen Sie dann, dass der Windows-Benutzer jitterbitpostgres, das PostgreSQL-Programm und die Datenverzeichnisse sowie die PostgreSQL-Registrierungsschlüssel entfernt sind.

  • Wenn die Fehlermeldung 1722 die Aktion InstallVerboseLogShipper nennt, entfernen Sie den verbleibenden Verbose-Log-Shipper-Dienst und seine Dateien vom vorherigen Agent, deinstallieren Sie den Agent erneut und installieren Sie ihn neu.

  • Wenn die vorherige Installation eine erweiterte Installation mit PostgreSQL ist, das unter einem anderen Dienstkonto als jitterbitpostgres ausgeführt wird, führen Sie ein Upgrade auf Agent-Version 12.10 oder später durch, was dieses Problem behebt. Bei einer früheren Agent-Version konfigurieren Sie den vorhandenen PostgreSQL-Dienst so um, dass er unter dem Windows-Dienstkonto jitterbitpostgres ausgeführt wird, bevor Sie das Upgrade durchführen.

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

PostgreSQL-Dienst nach fehlgeschlagenem Upgrade unter Windows entfernt

• Symptom: Nach einem fehlgeschlagenen Upgrade eines privaten Agents 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ückgerollt 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 Dienstkonto-Passwö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 privaten Windows-Agents von einem 11.x-Agent zu einem 12.x-Agent vor Version 12.10 wird erfolgreich abgeschlossen, aber die Jitterbit-Agent-Dienste können beim nächsten Neustart des Host-Systems nicht gestartet werden.

• Mögliche Ursache: Das Upgrade hinterlässt den vorherigen PostgreSQL-Windows-Dienst (postgresql-x64-<VERSION>, wobei <VERSION> die vom vorherigen Agent installierte Version ist) mit dem Starttyp Automatisch. Beim Neustart startet dieser ältere Dienst vor dem PostgreSQL-Dienst, der durch das Upgrade installiert wurde, und belegt denselben Port, was verhindert, dass der neue PostgreSQL-Dienst und damit der Agent gestartet werden.

• Lösung:

  • Upgrade auf Agent-Version 12.10 oder später durchführen, die den vorherigen PostgreSQL-Dienst während des Upgrades entfernt.
  • Bei einer früheren Agent-Version nach dem Upgrade Windows-Dienste öffnen, den älteren postgresql-x64-<VERSION>-Dienst identifizieren (denjenigen, der dem Upgrade vorausgeht), seinen Starttyp auf Manuell oder Deaktiviert setzen oder ihn deinstallieren, bevor das Hostsystem neu gestartet wird. Um zu überprüfen, welche Version derzeit mit dem Agent gebündelt ist, führen Sie den Befehl in Same version as bundled aus.

TFA verhindert die Installation des 64-Bit-Windows-Agents

• Symptom: Die Installation eines privaten 64-Bit-Windows-Agents schlägt fehl, wenn die Zwei-Faktor-Authentifizierung (TFA) für die Organisation aktiviert ist.
• Lösung: TFA vorübergehend deaktivieren, den Agent installieren und dann TFA erneut aktivieren. 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.

Eine fehlgeschlagene Windows-Installation wiederherstellen

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

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 verfügt über sudo-Berechtigungen. Ein Systemadministrator muss den Benutzer zur Gruppe wheel hinzufügen. Um die aktuelle Gruppenmitgliedschaft zu überprüfen, führen Sie groups aus.

  • Wenn Sie als Benutzer jitterbit 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 bei RHEL 9.7 und später. Siehe RHEL 9.7 und später zeigen einen OpenSSL-Fehler bei der Installation des privaten Agents ohne Root-Berechtigung in den bekannten Problemen des privaten Agents für eine Problemumgehung.

JDBC-Treiber: „Kein geeigneter Treiber gefunden"

• Symptom: Eine Datenbankverbindung schlägt fehl, weil der erforderliche JDBC-Treiber nicht auf dem Agent installiert ist, mit einem Fehler wie 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: Den erforderlichen Treiber manuell installieren: ihn in JdbcDrivers.conf registrieren und die Treiber-.jar-Datei in JITTERBIT_HOME/tomcat/drivers/lib/ kopieren, dann den Agent neu starten. Die vollständigen Schritte finden Sie unter JDBC-Treiber installieren.

Connector nicht auf den Agent heruntergeladen

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

  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 in der Management Console, wählen Sie die Agent-Gruppe aus und wählen Sie Action > Update connectors. Dies erzwingt ein Connector-Update in der Gruppe 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 oder nicht erreichbar.

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

• Symptom: Eine 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 Proxy-Authentifizierung, einschließlich einer NTLM-Domäne. Siehe Proxy-Server für private Jitterbit-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 dabei die Proxy-Anmeldedaten (und die NTLM-Domäne, falls der Proxy diese erfordert) an. Siehe Proxy während der Agent-Einrichtung konfigurieren.
  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-Informationen 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 fehl mit:

  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 memory, 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 den Heap für die Workload richtig zu dimensionieren.

Speicherplatz und Log-Ansammlung

• Symptom: Der Host des privaten Agenten läuft aus Speicherplatz 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 Speicherplatz 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 files 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 sich wiederholt (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 den Speicher des Agenten verbrauchen, siehe JVM mini-dump files fill the agent's disk.

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 flattert, ist dies ein Konnektivitätsproblem und keine Absturzschleife. Siehe Agent offline or unreachable.

• Mögliche Ursachen:

  • Ein verwaister Jitterbit-Prozess aus einem vorherigen Lauf (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.
  • Der Host läuft aus 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 Speicherplatz, 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-Protokolle 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.
  • Beenden Sie den Agent und alle verbleibenden Jitterbit-Prozesse, bevor Sie ihn neu starten. Wenn der Agent beendet 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 Protokolle 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-Speicher: 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 Protokolle zeigen, dass die Process Engine bei einem bestimmten Vorgang abstürzt, kontaktieren Sie den Jitterbit-Support mit den Vorgangsdetails und den Agent-Protokollen.
  • 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 von 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 Laufzeit für Vorgänge 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 genug 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-Speicher: 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 benötigt wird, entfernen Sie # und stellen Sie erneut bereit. Das Entfernen von # ordnet nur das erste Element zu, daher wenden Sie dies nur an, wenn eine Iteration ü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 wirkt sich auf Windows-Private-Agenten in Versionen vor 11.49 aus.

• Mögliche Ursachen:

  • Der AgentStats-Festplattenstatistik-Collector des Agenten stürzt die JVM ab, während Festplattenmetriken erfasst werden. Dies wirkt sich auf Agenten in Versionen vor 11.49 aus.
  • 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, was beide Ursachen behebt.

  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 es 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-Agent 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 ausschö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 führt nicht zum Wechsel. PgBouncer muss auch mit dem SCRAM-Verifier-Hash neu konfiguriert werden, sonst startet der Agent nicht.

• 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, daher ist der Wechsel 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: Schnelles Herunterfahren durch Administrator

• 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 startet.
  • Überprüfen Sie CPU und Speicher des Agent-Hosts. 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-Versionen 11.x und 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 die ausstellende CA nicht im cacerts-Truststore 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-Truststore der Agent-JRE. Verwenden Sie keytool -import im cacerts 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 Truststore lösen, sowohl auf Cloud- als auch auf Private Agents. Siehe SQL Server: Verbindung schlägt mit PKIX-Zertifikatpfad-Fehler 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-Truststore 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 teilen.

• Ursache: Der TLS-Handshake enthält nicht die SNI-Erweiterung, daher gibt der Server ein Standardzertifikat zurück, anstatt das für den angeforderten Host. 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 der erste das richtige Zertifikat zurückgibt und der zweite das nicht übereinstimmende, 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. Falls 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 den Host möglicherweise nicht in seinen Subject Alternative Names auf. Fügen Sie für Salesforce die Sandbox-MyDomain-URL zum Salesforce-Zertifikat hinzu, oder siehe Certificate Subject Alternative Name (SAN) mismatch.

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 mit der Netzwerk- oder Firewall-Konfiguration nicht 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 nach einem Agent-Upgrade oder -Neustart mit einem Fehler für eine leere private Schlüsseldatei fehl. 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 der Fall), 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 sind (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 gleichen Agent (mit dem gleichen 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, Key-Exchange- oder Host-Key-Algorithmen, die die cURL-Bibliothek in älteren Agent-Versionen nicht unterstützt. Server, die die älteren Algorithmen noch akzeptieren, funktionieren weiterhin, weshalb der gleiche 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, Key-Exchange- und Host-Key-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 die Basis-Authentifizierung während HTTPS-Proxy-Tunneling standardmäßig. 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 in der Lage sein, das Gateway zu erreichen (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. Dies ist der 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 ausfü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-Hilfsdienst 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 dann 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.

Fehler im Operationsprotokoll:

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 im Agenten-Protokoll:

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

Agenten mit Drain Stop beenden

Drain Stop des Agenten vor der Aktualisierung von Timeout-Einstellungen durchführen. Falls sich mehr als ein Agent in der betroffenen Gruppe befindet, führen Sie Drain Stop für alle durch.

Agenten-Ressourcen 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 Element der IP 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 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.
  • Vor Agent-Version 12.10 wurde beim Upgrade eines Windows Private Agent, dessen PgBouncer-Port bereits 6434 war (siehe PgBouncer-Ports), die Verbindung des Metrik-Service nicht aktualisiert, sodass sie auf dem alten Port 6432 blieb und die PgBouncer-Metrik möglicherweise falsch gemeldet wurde.
  • Vor Agent-Version 12.9 wurde beim Installieren 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 zeigen 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.
  • Für einen Agent, der von der Port-Nichtübereinstimmung betroffen ist, führen Sie ein Upgrade auf Agent-Version 12.10 oder später durch, das den PgBouncer-Verbindungsport des Metrik-Service automatisch korrigiert. Wenn die Nichtübereinstimmung nach dem Upgrade bestehen bleibt, wenden Sie sich an den Jitterbit-Support, um den Port zu überprüfen.
  • Für einen neuen Nicht-Root-Linux Private Agent verwenden Sie 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 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 weiterhin 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-Protokoll enthält:

  ThreadPoolAsynchronousRunner: APPARENT DEADLOCK
  

  Das Protokoll kann auch An existing connection was forcibly closed by the remote host für die PostgreSQL-Datenbank des Agents anzeigen. Ein Neustart des Agents 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 Agents (im Protokoll als c3p0 angezeigt) kann sich nach einem kurzzeitigen Datenbankverbindungsverlust nicht wiederherstellen, beispielsweise während einer vorübergehenden Netzwerkunterbrechung, obwohl PostgreSQL selbst mit Standard-Timeouts fehlerfrei und responsiv bleibt.
  • Veraltete Jitterbit-Prozesse halten Threads und Datenbankverbindungen. Dies kann auftreten, wenn ein Agent aktualisiert wird, während noch Operationen 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 burstable Cloud-Instanz (z. B. ein AWS t3-Typ) ihre CPU, sobald ihre Burst-Credits 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 den Deadlock zu beheben.
  • Falls der Deadlock im Java-Verbindungspool (c3p0) auftritt 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 ab Version 12.5 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 konstanter (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.

Apache stürzt unter gleichzeitiger Last unerwartet ab

• Symptom: Unter gleichzeitiger Last stürzt der Apache-Prozess des Agents unerwartet ab und wird neu gestartet. Der Agent kann in der Management Console kurzzeitig als stoppend oder neu startend angezeigt werden. Operationen, die zu diesem Zeitpunkt ausgeführt wurden, können fehlschlagen oder in einem unvollständigen Zustand verbleiben.
• Mögliche Ursachen:
  • Ein Skript verwendet verschachtelte RunOperation-Aufrufe, um eine untergeordnete Operation synchron (Standard) von einer übergeordneten Operation aus auszuführen, und beide Operationen lesen oder schreiben gleichzeitig auf dieselbe globale Variable.
  • Eine Transformation ist mit Chunking und mehreren Threads konfiguriert, und ein Thread wird beendet, bevor ein anderer Thread, der zur gleichen Zeit gestartet wurde, beendet wird.
  • Mehrere Operationen mit aktivierter Datengenerierung für Komponenteneingabe und -ausgabe werden gleichzeitig ausgeführt.
• Lösung: Den Private Agent auf Version 12.10 oder später aktualisieren, was diese Probleme behebt. Auf früheren Versionen gibt es keine Problemumgehung.

Der 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 Cleanup-Dienst-Protokoll 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) hält eine Sperre auf Dateien im Protokollverzeichnis des Agents.

• Lösung:

  • CleanupRules.xml bearbeiten, um die Aufbewahrung (FileAge) für die betroffenen Protokollverzeichnisse zu verkürzen, damit Dateien umgehend 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 weiterhin wachsen, obwohl gültige Cleanup-Regeln vorhanden sind, den Jitterbit-Support kontaktieren.

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

• Symptom: Nach dem Neustart eines Linux-Private-Agent-Hosts starten die Agent-Services nicht. Das Ausführen von sudo jitterbit status zeigt, dass der Scheduler und andere Services nicht ausgeführt werden, und die Agent-Logs (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 gebündelten PostgreSQL-Datenverzeichnis sind zu permissiv. PostgreSQL erfordert, dass das Datenverzeichnis 700 (nur Eigentümer) ist. Wenn 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 Sie, dass /opt/jitterbit und seine Unterverzeichnisse dem Benutzer und der Gruppe jitterbit gehören:

     sudo chown -R jitterbit:jitterbit /opt/jitterbit
     

  2. Setzen Sie das PostgreSQL-Datenverzeichnis auf 700:

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

  3. 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 Linux-Private-Agents auf einen neuen Host (oder nach einer Neuinstallation) starten die Agent-Services nicht. Das postgresql.log zeigt:

  [FATAL] password authentication failed for user "jitterbit"
  

  Das Agent-Log zeigt, dass es sich nicht mit der Datenbank verbinden kann. Der Fehler bleibt über eine vollständige Deinstallation und Neuinstallation hinweg 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.

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

• Symptom: Ein Security-Scan einer Private-Agent-Installation kennzeichnet Dateien wie log4j-over-slf4j-1.7.21.jar als End-of-Life-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 Agents umleitet. Die Datei enthält nicht den anfälligen Log4j-1.x-Code. Ihre Anwesenheit ist die Risikominderung des Agents gegen Log4j-1.x-Exposition, nicht eine Instanz der Sicherheitslücke.

Docker

Allgemein

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

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

• Das Ausführen von Private-Agents 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 die weitere Entwicklung bereitgestellt.

Agent kann nach Deregistrierung nicht neu gestartet werden – Authentifizierungsfehler

• 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 aus Harmony deregistriert, aber die nun ungültige Datei credentials.txt 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 deregistriert 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 Datei credentials.txt 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-Service

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

• Symptom: Operationen, die den Listening-Service 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 Agenten in der Agent-Gruppe werden ausgeführt und sind dem Cluster beigetreten. Bei einer Gruppe von \(N\) Agenten, unabhängig davon, ob jeder Agent ausgeführt wird, müssen \((N / 2) + 1\) Agenten (abgerundet) ausgeführt werden und Teil des Clusters sein.
  • Ein oder mehrere Agenten haben ihre Verbindung zum Cluster verloren und konnten nicht erneut beitreten, wodurch die Anzahl der ausgeführten, beigetretenen Agenten 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 Agenten zwei Cluster mit je 2 Agenten 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 Agenten in der Gruppe ausgeführt werden und Teil des Clusters sind, wobei \(N\) die Anzahl der in der Agent-Gruppe registrierten Agenten ist, unabhängig davon, ob jeder ausgeführt wird. Beispielsweise erfordert eine Gruppe von 4 Agenten 3, und eine Gruppe von 5 Agenten erfordert ebenfalls 3. Um zu sehen, welche Agenten beigetreten sind, verwenden Sie die Listening-Service-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 Persistierung unverarbeitet bleiben, stellen Sie den Cluster manuell wieder her. Siehe Cluster-Wiederherstellung nach Agent-Fehler.

  Hinweis

  Eine ungerade Anzahl von Agenten 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-Service-Meldungen nicht zugestellt

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

Protokollierung

Benutzerdefinierte API-Operationsprotokolle werden nicht angezeigt

• Symptom: Eine Operation, die durch eine benutzerdefinierte API ausgelöst wird, läuft ohne Fehler ab, aber es wird kein Protokolleintrag in Studio oder auf der Seite Runtime der Management Console angezeigt.
• Ursache: Wenn eine benutzerdefinierte API eine Operation auslöst, werden Operationsprotokolle nur generiert, wenn die Operation fehlschlägt. Erfolgreiche benutzerdefinierte API-Operationen erzeugen standardmäßig keinen Protokolleintrag.
• Lösung: Um Protokolle für erfolgreiche benutzerdefinierte API-Operationen zu erfassen, aktiviere Operation Debug Logging für die Operation. Beachte, dass API Manager eine eigene separate Protokollansicht für API-Anfragen hat.

Operation Debug Logging stoppt vor dem ausgewählten Enddatum

• Symptom: Operation Debug Logging wurde mit einem zukünftigen Enddatum aktiviert, aber die Protokollgenerierung stoppt vor diesem Datum.
• Ursache: Bei Cloud-Agent-Gruppen ist das Enddatum der Operation Debug Logging-Einstellung unzuverlässig. Die Protokollgenerierung kann vor dem konfigurierten Zeitraum beendet werden.
• Lösung: Aktiviere Operation Debug Logging nach Bedarf erneut.

Operation Debug Log-Dateien fehlen .input- oder .output-Daten

• Symptom: Bei einem privaten Agent ist für eine Operation Operation Debug Logging mit aktivierten Komponenteneingabe- und -ausgabedaten aktiviert. 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.

• Mögliche Ursachen:

  • Der Cleanup-Service des Agents löscht .input- und .output-Dateien, bevor sie überprüft werden können.
  • Der Agent wurde neu gestartet, während die Operation noch lief, sodass die Dateien nie vollständig geschrieben wurden. Siehe Komponenteneingabe-/Ausgabedaten nicht generiert für dieses Szenario.

• Lösung:

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

  2. Suche die Cleanup-Regel für das Verzeichnis DataInterchange/Temp/Debug und erhöhe 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. Starte die Agent-Services neu.

Komponenteneingabe-/Ausgabedaten nicht generiert

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

• Lösung: Überprüfe das Verbose Log Shipper-Serviceprotokoll auf dem Agent:

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

  Wenn das Protokoll Fehler anzeigt, starte 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 werden beim Neustart aller Jitterbit-Agent-Dienste auch die Verbose Log Shipper-Dienste neu gestartet.