Analytics-Daten bleiben in der Qpidd-Warteschlange für unzustellbare Nachrichten hängen

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen.
info

Symptom

In der Edge-Benutzeroberfläche fehlen Analytics-Daten, da der Qpidd-Server keine Analytics-Nachrichten an PostgreSQL überträgt. In Edge entspricht die edge-qpid-server-Komponente dem Qpidd-Server.

Qpidd verwaltet zwei Warteschlangen für jede Analysegruppe:

  • ax-q-axgroup001-consumer-group-001

    Diese Warteschlange enthält Analysenachrichten, die von den Message Processors und Routern gesendet werden. Nachrichten werden von hier von edge-qpid-server abgerufen, das Nachrichten parst und in PostgreSQL einfügt. Nachdem Nachrichten erfolgreich verarbeitet wurden, werden sie aus der Warteschlange entfernt.

  • ax-q-axgroup001-consumer-group-001-dl

    Diese Warteschlange ist die Warteschlange für unzustellbare Nachrichten. Es dient als Ziel für Nachrichten, die von edge-qpid-server nicht verarbeitet werden konnten und die daher nicht mehr empfangen möchte. Dieses Feld wird in der Regel ausgefüllt, wenn die maximale Anzahl von Zustellungen überschritten wurde oder wenn PostgreSQL das Einfügen neuer Daten aufgrund von Laufzeitfehlern abgelehnt hat.

Fehlermeldung

Die Ursache kann in verschiedenen Laufzeitfehlern der edge-qpid-server-Komponente liegen. Wenn edge-qpid-server einen Laufzeitfehler von PostgreSQL empfängt, wird die Warteschlange für unzustellbare Nachrichten erstellt, sofern sie noch nicht vorhanden ist. Anschließend wird die folgende Nachricht dorthin gesendet:

yyyy-MM-dd HH:mm:ss,SSS ax-q-axgroup001-consumer-group-001-persistpool-thread-6 WARN c.a.a.m.MessageConsumer - MessageConsumer.process() : Sending message batch to the DLQ.

Mögliche Ursachen

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
Nachrichten bleiben in der Dead-Letter-Warteschlange von qpidd hängen edge-qpid-server konnte Nachrichten, die vom Qpidd-Broker gelesen wurden, nicht verstehen oder Nachrichten nicht in PostgreSQL speichern. Edge Private Cloud-Nutzer

Allgemeine Diagnoseschritte

Führen Sie den folgenden Befehl aus, um Statistiken zur Qpidd-Warteschlange aufzurufen:

qpid-stat -q

Die Ausgabe gibt die Menge der beim Broker registrierten Warteschlangen zurück. Wenn die Warteschlange, deren Name mit „-dl“ endet, Nachrichten enthält, sind Nachrichten in der Dead-Letter-Warteschlange hängen geblieben.

Queues
  queue                                     dur  autoDel  excl  msg   msgIn  msgOut  bytes  bytesIn  bytesOut   cons  bind
  ========================================================================================================================
  ax-q-axgroup-001-consumer-group-001       Y                   0     185    185     0       13.8m   13.8m      6      2
  ax-q-axgroup-001-consumer-group-001-dl    Y                   0     70     70      0        3.9m    3.9m      0      2

Ursache: Nachrichten bleiben in der Dead-Letter-Warteschlange von qpidd hängen

Diagnose

Dieser Zustand kann in den folgenden Szenarien auftreten:

  1. In der Vergangenheit hat ein Upgrade stattgefunden, während dem PostgreSQL nicht verfügbar war.
  2. Ein vorübergehender Ausfall von PostgreSQL aufgrund von Netzwerkproblemen.
  3. Die edge-qpid-server hat versucht, eine Nachricht an PostgreSQL zu senden, aber PostgreSQL hat einen Laufzeitfehler zurückgegeben.

Auflösung

  1. Notieren Sie sich die Namen der Warteschlangen aus den allgemeinen Diagnoseschritten. Beispiel:

    • ax-q-axgroup-001-consumer-group-001
    • ax-q-axgroup-001-consumer-group-001-dl
  2. Führen Sie den Befehl qpid-tool aus, um einen interaktiven qpid-Prompt einzugeben:

    qpid-tool

    Dieser Befehl gibt Folgendes zurück:

    Management Tool for QPID
    qpid:
  3. Führen Sie list broker aus, um eine Liste der aktiven Broker abzurufen:

    list broker

    Dieser Befehl gibt Folgendes zurück:

    Object Summary:
    ID   Created   Destroyed  Index
    =======================================
    125  21:00:00  -          amqp-broker

    Dabei gibt die Spalte ID die ID des Brokers an.

  4. Notieren Sie sich die ID des Brokers. Im Beispiel ist das 125.

  5. Führen Sie den folgenden Befehl aus, um die Nachrichten aus der Warteschlange für unzustellbare Nachrichten zurück in die eigentliche Warteschlange zu verschieben:

    call 125 queueMoveMessages ax-q-axgroup-001-consumer-group-001-dl ax-q-axgroup-001-consumer-group-001 100000 {}

    Dieser Befehl gibt Folgendes zurück:

    OK (0) - {}

    Wenn keine Ausgabe erfolgt, gab es nichts zu tun, d. h. keine Nachrichten zum Verschieben. Wenn OK(0) nicht angezeigt wird, wenden Sie sich an den Apigee Edge-Support.

  6. Beenden Sie das qpid-tool-Terminal.

    quit
  7. Warte 5 Minuten und führe die Diagnoseschritte unter Allgemeine Diagnoseschritte noch einmal aus. Prüfen Sie, ob die Nachrichten in der tatsächlichen Warteschlange verarbeitet werden, und achten Sie darauf, dass die Anzahl der Nachrichten in der Warteschlange für unzustellbare Nachrichten bei 0 bleibt.

Wenn das Problem weiterhin besteht, fahre mit dem nächsten Abschnitt fort.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie bitte die folgenden Diagnoseinformationen. Wenden Sie sich mit den folgenden Informationen an den Apigee Edge-Support:

  • Qpidd-Logs: /opt/apigee/var/log/apigee-qpidd/apigee-qpidd.log
  • PostgreSQL-Logs: /opt/apigee/var/log/apigee-postgresql/apigee-postgresql.log
  • Edge-qpid-Serverlogs: /opt/apigee/var/log/edge-qpid-server/logs/system.log
  • Edge-postgres-Serverlogs:/opt/apigee/var/log/edge-postgres-server/logs/system.log
  • Qpidd-Warteschlangenstatistiken:

    qpid-stat -q
  • Analytics-Gruppe, die vom folgenden curl-Befehl zurückgegeben wird:

    curl -u sysadminEmail:password http://mgmt:8080/v1/analytics/groups/ax