Tipps zur Fehlerbehebung beim Nachrichtenverarbeiter

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Für dieses Thema gibt es keine entsprechende Apigee Edge-Dokumentation.

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

Beispiel:

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

    Beispiel:

    kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x -- bash
  3. Wechseln Sie zum folgenden Verzeichnis: 
    cd /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. Beispiel: 
    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. Beispiel:

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

$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

    Beispiel:

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

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

$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. Beispiel: 

$ 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

    Beispiel:

    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"
    }
  }
} ]

Fehlerbehebungsmodus verwenden

Zur Fehlerbehebung können Sie den Fehlerbehebungsmodus aktivieren, um ausführlichere Informationen in die Pod-Logs apigee-runtime aufzunehmen.

  1. Listen Sie die Pods in Ihrem Namespace auf: 
    kubectl get pods -n namespace
  2. Wählen Sie einen der aufgelisteten apigee-runtime-Pods zur Fehlerbehebung.
  3. Führen Sie den Portweiterleitungsbefehl für diesen Pod aus. Beispiele: 
    kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843
  4. Öffnen Sie ein anderes Terminal und rufen Sie folgende API auf, um das Debugging zu aktivieren:
    curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
  5. Führen Sie den Befehl kubectl logs aus, um das Log im Fehlerbehebungsmodus zu prüfen. Beispiel: 
    kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
  6. Sobald Sie mit der Prüfung des Fehlerbehebungsprotokolls fertig sind, setzen Sie die Protokollebene auf INFO (Standardeinstellung) zurück. Beispiele: 
    curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
  7. Führen Sie den Befehl kubectl logs aus, um zu prüfen, ob sich das Log wieder im INFO-Modus befindet.