Tipps zur Fehlerbehebung beim Nachrichtenverarbeiter

In diesem Thema werden Schritte erläutert, mit denen Sie Probleme mit dem Message Processor beheben können. Der Message Processor ist Teil der apigee-runtime-Komponente. Weitere Informationen finden Sie unter Laufzeitdienst-Konfiguration – Übersicht.

Bereitschaftsprüfung schlägt mit dem HTTP-Statuscode 500 fehl

Symptom

Mindestens ein apigee-runtime-Pod ist nicht bereit.

Fehlermeldung

Wenn Sie kubectl zur Beschreibung eines fehlgeschlagenen apigee-runtime-Pods verwenden, wird folgender Fehler angezeigt:

Readiness probe failed: HTTP probe failed with statuscode: 500

Beispiele:

kubectl describe pod -n hybrid \
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

...
apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7  Readiness probe failed: HTTP probe
failed with statuscode: 500
...

Mögliche Ursachen

Der Fehler bedeutet, dass kein aktiver Vertrag für den Nachrichtenprozessor verfügbar ist, um Traffic zu verarbeiten. In diesem Status kann der Nachrichtenprozessor sich nicht als "bereit" deklarieren.

Ursache Beschreibung
Verbindungsproblem zwischen Synchronizer und Verwaltungsebene Der Synchronizer kann keine Verbindung zur Verwaltungsebene herstellen. Dieses Problem tritt normalerweise auf, wenn Sie die contractProvider-URL überschreiben und ihr ein falsches Dienstkonto zuweisen. Beispiel: Sie konfigurieren ein Dienstkonto für eine Staging-Bereitstellung mit einer contractProvider-URL, die auf den Produktionsserver verweist.
Problem mit dem Nachrichtenprozessor zum Verbindungsaufbau mit Synchronizer Startet ein neuer MP im Rahmen einer automatischen Skalierung oder eines Pod-Neustarts, wird dieser Fehler möglicherweise angezeigt. Dieses Problem tritt im Allgemeinen auf, wenn der Synchronizer nicht verfügbar ist und der MP seinen Vertrag nicht laden konnte.

Diagnose: Verbindungsproblem zwischen Synchronizer und Verwaltungsebene

So diagnostizieren Sie ein Verbindungsproblem zwischen Synchronizer und Verwaltungsebene:

  1. Lassen Sie die im Cluster enthaltenen Pods auflisten:
    kubectl get pods -n namespace
  2. Öffnen Sie eine Shell in einem apigee-synchronizer-Pod:
    kubectl exec -it -n namespace synchronizer-pod-name bash

    Beispiele:

    kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x bash
  3. Wechseln Sie zum folgenden Verzeichnis: 
    cd /application/opt/apigee/var/log/apigee-synchronizer
ls

  dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  drwxr-sr-x 2 apigee apigee  4096 Sep 12 16:52 cachedFiles
  -rw-r--r-- 1 apigee apigee 22295 Sep 12 16:52 config.log
  -rw-r--r-- 1 apigee apigee    76 Sep 12 16:52 versions.properties
  4. Prüfen Sie die aktive Version in version.properties. Beispiele: 
    cat versions.properties

  #active repository version
  #Sat Dec 14 19:45:00 GMT 2019
  active.version=749
  5. Achten Sie darauf, dass der Wert von active.version mit dem Namen des Vertragsordners übereinstimmt. Im obigen Beispiel ist der Ordnername 750. Die Elemente stimmen nicht überein: 
    dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750
  6. Beenden Sie die Pod-Shell.

Lösung

Wenn version.properties fehlt oder wie oben beschrieben eine Version nicht übereinstimmt, prüfen Sie die Synchronizer-Logs, um festzustellen, warum die neuesten Verträge nicht heruntergeladen werden. Beispiele:

kubectl logs -f -n namespace synchronizer-pod-name

Informationen zum Interpretieren der Synchronizer-Logs finden Sie unter Synchronizer-Logs. Wenn der Synchronizer ausgefallen ist, starten Sie ihn mit apigeectl neu. Beispiele: 

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

Diagnose: Verbindungsproblem zwischen Nachrichtenprozessor und Synchronizer

So diagnostizieren Sie ein Verbindungsproblem zwischen Nachrichtenprozessor und Synchronizer:

  1. Lassen Sie die im Cluster enthaltenen Pods auflisten:
    kubectl get pods -n namespace
  2. Prüfen Sie anhand der Laufzeitlogs, warum die Verträge nicht heruntergeladen werden:
    kubectl logs -f -n namespace pod-name

    Beispiele:

    kubectl logs -f -n apigee apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7

    Startet ein neuer MP im Rahmen eines Autoscalings oder Pod-Neustarts, so kann es sein, dass der MP die Verträge nicht lädt. Normalerweise tritt das Problem auf, wenn der Synchronizer nicht verfügbar ist. In diesem Fall kann der MP die Verträge nicht laden. Beispiele: 

    2019-09-13 16:59:24,331 podName:N/A ipAddress:N/A dpColor:N/A
HttpClient@331886186-301 DEBUG o.e.j.c.AbstractConnectionPool - AbstractConnectionPool$1.failed() :
Connection 1/64 creation failed
java.net.UnknownHostException: apigee-synchronizer-apigee-gcp-prod1-test.hybrid.svc.cluster.local
at java.net.InetAddress.getAllByName0(InetAddress.java:1281)
at java.net.InetAddress.getAllByName(InetAddress.java:1193)
at java.net.InetAddress.getAllByName(InetAddress.java:1127)
at org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:167)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
at java.lang.Thread.run(Thread.java:748)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
	at java.lang.Thread.run(Thread.java:748)

Lösung

Versuchen Sie, den Synchronizer neu zu starten. Beispiele: 

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

Die Bereitschaftsprüfung schlägt wegen einem ungültigen Verschlüsselungsschlüssel fehl

Symptom

Die apigee-runtime-Pods befinden sich nicht im Status „Bereit“.

Diagnose

Wenn Sie kubectl für die Beschreibung eines fehlgeschlagenen apigee-runtime-Pods verwenden, wird folgender Fehler angezeigt: Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed. Beispiele: 

$ kubectl describe pod -n namespace apigee-runtime-pod-name

...
Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed due to
com.apigee.probe.model.ProbeFailedException{ code = hybrid.encryption.key.InvalidEncryptionKey,
message = Invalid encryption key. Please check the length of the encryption key, associated
contexts = []}
...

Lösung

Unterstützte Längen für Verschlüsselungsschlüssel sind 16, 24 oder 32 Byte. Der Wert des Schlüssels muss base64-codiert sein. Weitere Informationen zum Erstellen eines korrekt formatierten Schlüssels finden Sie unter Datenverschlüsselung.

Logs des Nachrichtenprozessors anzeigen

Ausführliche Informationen zum Anzeigen und Interpretieren von Nachrichtenprozessor-Logs finden Sie unter Laufzeitlogs.

Einen API-Proxy aus dem Laufzeit-Pod aufrufen

In einigen Situationen hilft es bei der Fehlersuche, zu prüfen, ob ein API-Proxy-Aufruf direkt aus dem Pod apigee-runtime möglich ist. Damit wird das Ingress-Gateway umgangen.

  1. Führen Sie folgenden Befehl aus, um an Port 8443 weiterzuleiten. So können Sie die API im Pod aufrufen: 
    kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
  2. Einen bereitgestellten API-Proxy aufrufen Wenn der Proxy-Basispfad beispielsweise ilove-apis lautet: 
    curl -k -v https://0:8443//ilove-apis

    < HTTP/1.1 200 OK
    < X-Powered-By: Apigee
    < Access-Control-Allow-Origin: *
    < X-Frame-Options: ALLOW-FROM RESOURCE-URL
    < X-XSS-Protection: 1
    < X-Content-Type-Options: nosniff
    < Content-Type: text/html; charset=utf-8
    < Content-Length: 18
    < ETag: W/"12-Jb9QP1bUxNSmZkxQGt5KLQ"
    < Date: Fri, 13 Sep 2019 18:33:46 GMT
    < Via: 1.1 google
    < X-Apigee.Message-ID: 016f5f7f-c59e-404c-86e8-7b0737833f982
    < X-Apigee.dp.color: blue
    < X-Apigee.proxy: /organizations/my-org/environments/test/apiproxies/i-loveapis/revisions/1
    < X-Apigee.proxy.basepath: /ilove-apis
    < X-Apigee.target-latency: 9
    <
    * Connection #0 to host 0 left intact
    <H2>I <3 APIs

Verwaltungs-API prüfen

Sie können die unten beschriebene API verwenden, um zu prüfen, ob die Verwaltungs-API ordnungsgemäß funktioniert.

  1. Rufen Sie die Namen der Pods in Ihrem Cluster ab: 
    kubectl get pods -n namespace
  2. Verwenden Sie die Portweiterleitung, um auf den apigee-runtime-Pod zuzugreifen. Die Syntax für die Portweiterleitung lautet wie folgt: 
    kubectl port-forward -n namespace podname 8843:8843

    Beispiele:

    kubectl port-forward -n apigee \
    apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843
  3. Verwenden Sie dann in einem anderen Terminalfenster ein Dienstprogramm wie curl, um eine Anfrage an die classification/tree-API zu senden, wie im folgenden Beispiel gezeigt: 
    curl -k https://0:8843/v1/classification/tree

    Hier sehen Sie eine Beispielantwort, in der Informationen zu den bereitgestellten Proxys in der "Testumgebung" aufgeführt werden:

    [ {
  "condition" : "(always matches)",
  "virtualHost" : {
    "env" : "test",
    "name" : "default",
    "org" : "my-organization",
    "tree" : {
      "elements" : [ {
        "application" : "myproxy",
        "basePath" : "/myproxy",
        "name" : "default",
        "revision" : "1"
      } ],
      "name" : "IdentificationTree"
    }
  }
} ]

Logging verwenden, um Probleme mit Laufzeit-Pods zu beheben

Zur Fehlerbehebung können Sie eine Logsitzung erstellen, um eine detaillierte Logausgabe für die apigee-runtime-Pods zu generieren.

Logsitzung erstellen

So erstellen Sie eine Logsitzung für einen Laufzeit-Pod:

  1. Listen Sie die Laufzeit-Pods auf. Standardmäßig befinden sie sich im Namespace apigee. Wenn Sie einen anderen Namespace ausgewählt haben, verwenden Sie stattdessen diesen: 
    kubectl get pods -n apigee
  2. Wählen Sie einen der aufgelisteten apigee-runtime-Pods zur Fehlerbehebung.
  3. Erstellen Sie mit der /logsessions API eine Logsitzung im Laufzeit-Pod, für den Sie Fehler beheben möchten. Weitere Informationen zur API finden Sie unter Informationen zur Logsessions API: 
    kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v

    Beispiele:

    kubectl exec -it apigee-runtime-hybrid-18-01232-dev-d27ca57-190rc6-3klyg-lc7h5 -n apigee \
  -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v

    Die Antwort ist eine Logsitzungs-ID. Beispiel: 9f831a7d-e533-4ead-8e58-12ec1059a622

  4. Geben Sie die Logs aus: 
    kubectl logs -f -n apigee RUNTIME_POD_NAME

Logsitzungen auflisten

So rufen Sie eine Liste aller aktiven Logsitzungen für einen Laufzeit-Pod ab:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions" -k -v

Logsitzung abrufen

So rufen Sie Logsitzungsdetails ab:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
  -- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -v

Logsitzung beenden

So beenden Sie eine Logsitzung:

kubectl exec -it RUNTIME_POD_NAME -n apigee \
    -- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -X DELETE -v

Informationen zur Logsessions API

In diesem Abschnitt werden die Abfrageparameter der Logsessions API beschrieben:

  • loggerNames: Gibt den anzuzeigenden Logausgabetyp an. Mögliche Werte sind CONTRACT_REPLICATION, DEBUG.SESSION oder ALL.
  • level: Gibt die Ebene der Logausgabe an. Zulässige Werte sind FINEST, FINER, FINE, INFO, SEVERE, ALL.
  • timeout: Gibt die Zeit an, die die Logsitzung für die angegebene Logebene ausgeführt wird. Nach Ablauf des Zeitlimits wird die Logebene auf INFO zurückgesetzt.

Bei Erfolg gibt die API eine Sitzungs-ID für die Logsitzung zurück.