Debugging verwenden

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

In diesem Abschnitt wird beschrieben, wie Sie Fehlerbehebungssitzungen erstellen und verwalten sowie Anfrage- und Antwortdaten über die Apigee-UI und die API abrufen.

Mit Offline Debug können Sie zuvor heruntergeladene Fehlerbehebungssitzungen ansehen und analysieren.

Fehlerbehebungssitzung erstellen

Das Debug-Tool ist einfach zu verwenden. Sie starten eine Debugging-Sitzung, führen einen API-Aufruf an Apigee aus und rufen dann die Anfrage- und Antwortdaten in der UI auf.

Erstellen Sie mithilfe der Apigee-Benutzeroberfläche oder der API eine Fehlerbehebungssitzung, wie in den folgenden Abschnitten beschrieben.

Apigee-Benutzeroberfläche

So erstellen Sie eine Debugging-Sitzung:

  1. Rufen Sie in der Google Cloud Console die Seite Apigee > Proxy-Entwicklung > API-Proxys auf.

    Zu „API-Proxys“

  2. Wählen Sie den API-Proxy aus, den Sie debuggen möchten. Dadurch wird der Bereich Übersicht des Proxy-Editors angezeigt.
  3. Klicken Sie auf den Tab Debugging.
  4. Klicken Sie auf Debugging-Sitzung starten. Dadurch wird der Bereich Debugging-Sitzung starten angezeigt.

  5. Im Bereich Debugging-Sitzung starten:

    1. Wählen Sie die Umgebung aus, in der Sie die Debugging-Sitzung ausführen möchten.

    2. (Optional) Wählen Sie in der Drop-down-Liste Filter einen Filter aus, der auf alle Transaktionen in der von Ihnen erstellten Fehlerbehebungssitzung angewendet werden soll. Der Standardwert ist None (All transactions), der alle Transaktionen in den Debugging-Daten einschließt.

      Weitere Informationen zur Verwendung von Filtern finden Sie unter Filter in einer Fehlerbehebungssitzung verwenden. Informationen zu den integrierten Filtern finden Sie unter Vordefinierte Filter verwenden.

    3. Klicken Sie auf Start.

In der Apigee-Benutzeroberfläche wird jetzt der Bereich Debugging-Sitzung in Bearbeitung angezeigt.

Zum Vergrößern klicken neue Debug-Sitzung

Die Debugging-Sitzung zeichnet Anfragen zehn Minuten lang oder bis 15 Anfragen erfasst wurden auf. Sie können das 10-Minuten-Limit anpassen, wenn Sie die Debugging-Sitzung mit der API erstellen. Das Feld Endet innerhalb zeigt die verbleibende Zeit in der Sitzung an.

Im Debug-Fenster werden keine Informationen angezeigt, bis Sie eine Anfrage an den Proxy senden, für den Sie das Debugging in der ausgewählten Umgebung für die Debugging-Sitzung ausführen.

Nachdem Sie die Anfrage gesendet haben, wird sie im Bereich Transaktionen angezeigt. Die Liste Transaktionen wird alle fünf Sekunden aktualisiert.

Zum Vergrößern klicken Anfrage in der Transaktionsliste

So rufen Sie die Transaktionsausgabe auf oder kopieren sie:

  1. Klicken Sie in der Liste Transaktionen auf Transaktionsausgabe ansehen. Der Bereich Transaktionsausgabe wird angezeigt.
  2. Klicken Sie auf eine einzelne Transaktion oder auf Alle Transaktionen.
  3. Klicken Sie auf Kopieren, um die Transaktionsausgabe in die Zwischenablage zu kopieren.
  4. Klicken Sie auf Schließen.

API

Wenn Sie eine Fehlerbehebungssitzung mit der API erstellen möchten, senden Sie eine POST-Anfrage an die folgende Ressource: 

https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/apis/$API/revisions/$REV/debugsessions

Sie können auch Folgendes tun:

Im folgenden Beispiel wird gezeigt, wie eine Fehlerbehebungssitzung mit der API erstellt wird.

curl "https://apigee.googleapis.com/v1/organizations/ORG/environments/ENV/apis/PROXY/revisions/REV/debugsessions" \
      -X POST \
      -H "Authorization: Bearer $TOKEN"

Dabei ist $TOKEN auf Ihr OAuth 2.0-Zugriffstoken festgelegt. Weitere Informationen hierzu finden Sie unter OAuth 2.0-Zugriffstoken abrufen. Informationen zu den in diesem Beispiel verwendeten curl-Optionen finden Sie unter curl verwenden. Eine Beschreibung der Umgebungsvariablen, die Sie verwenden können, finden Sie unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

Im Folgenden finden Sie ein Beispiel für die Antwort:

{
      "name":"56382416-c4ed-4242-6381-591bbf2788cf",
      "validity":300,
      "count":10,
      "tracesize":5120,
      "timeout":"600"
    }

Nachfolgende Anfragen an Ihren API-Proxy (bis die Sitzungsdauer oder die maximale Anzahl von Anfragen erreicht ist) werden ausgewertet und möglicherweise in den Debug-Sitzungsdaten gespeichert.

Weitere Informationen finden Sie unter Create debug session API erstellen.

Länge einer Fehlerbehebungssitzung mithilfe der API festlegen

Wenn Sie die Länge einer Fehlerbehebungssitzung mithilfe der API festlegen möchten, fügen Sie Folgendes als Nutzlast in Ihre Anfrage zur Erstellung einer Fehlerbehebungssitzung ein:

{
      "timeout":"debug_session_length_in_seconds"
    }

Im folgenden Beispiel wird eine Sitzung zur Fehlerbehebung erstellt, die 42 Sekunden lang ist:

curl https://apigee.googleapis.com/v1/organizations/ORG/environments/ENV/apis/PROXY/revisions/REV/debugsessions"
      -X "POST" \
      -H "Authorization: Bearer $TOKEN" \
      -d ' {
        "timeout":"42"
      } '

Sie können die timeout einer Sitzung nur in Anfragen zum Erstellen von Debugging-Sitzungen festlegen. Sie können die Dauer einer Sitzung nach dem Erstellen nicht mehr ändern.

Der Standardwert von timeout ist 300 (5 Minuten). Der Höchstwert beträgt 600 Sekunden (10 Minuten).

Kopieren Sie die Proxy-URL.

Die Proxy-URL wird verwendet, um Anfragen an Ihren API-Proxy zu senden.

So finden und kopieren Sie die Proxy-URL:

  1. Klicken Sie im Bereich Debugging-Sitzung im Feld URL auf Kopieren.
  2. Wenn keine Debug-Sitzung geöffnet ist:

    1. Rufen Sie in der Google Cloud Console die Seite Apigee > Verwaltung > Umgebungen > Umgebungsgruppen auf.

      Zu „Umgebungsgruppen“

    2. Die URL ist der Hostname für die Umgebung, in der Sie die Sitzung zur Fehlerbehebung ausführen möchten. Wählen Sie sie aus und kopieren Sie sie.

So wählen Sie eine andere Proxy-URL aus:

  1. Klicken Sie im Bereich Debugging-Sitzung im Feld URL auf Bearbeiten.
  2. Nehmen Sie die gewünschten Änderungen vor und klicken Sie auf Aktualisieren.
  3. Wenn keine Debug-Sitzung geöffnet ist:
    1. Suchen Sie die Proxy-URL.
    2. Klicken Sie auf Mehr und dann auf Bearbeiten.
    3. Nehmen Sie die gewünschten Änderungen vor und klicken Sie dann auf Aktualisieren.

Weitere Fehlerbehebungssitzung in der Benutzeroberfläche starten

Sie können in der Benutzeroberfläche eine beliebige Anzahl von Sitzungen zur Fehlerbehebung erstellen.

Während einer aktiven Debugging-Sitzung können Sie eine weitere Sitzung in der Apigee-UI starten. Klicken Sie dazu im Bereich Debugging-Sitzung auf Schließen:

Zum Vergrößern des Bildes klicken Schließen und zum Bereich „Debugging-Sitzung starten“ zurückkehren

Die Benutzeroberfläche kehrt zum Bereich Fehlerbehebungssitzung starten zurück, in dem Sie eine neue Fehlerbehebungssitzung starten können.

Wann endet eine Fehlerbehebungssitzung?

Eine aktive Fehlerbehebungssitzung lässt sich nicht einfach beenden. Sie können jedoch die Daten einer aktiven Sitzung löschen, wie unter Daten der Fehlerbehebungssitzung löschen beschrieben.

Beim Erstellen einer Fehlerbehebungssitzung bestimmen zwei Attribute, wann die Sitzung endet:

  • timeout: Die Dauer, für die während einer Sitzung Daten erfasst werden. Die Standardlänge hängt davon ab, wie Sie die Sitzung gestartet haben (über die Benutzeroberfläche oder API). Der Höchstwert beträgt 600 Sekunden (oder 10 Minuten).
  • count: Die maximale Anzahl von Anfragen, die in einer einzelnen Sitzung pro Message Processor aufgezeichnet werden. Da die Anzahl der Message Processor in den meisten Clustern variabel ist, können die Auswirkungen der Anzahl unvorhersehbar sein. Apigee empfiehlt nicht, diese Einstellung anzupassen.

Wenn das Zeitlimit erreicht oder die Anzahl erreicht ist, endet die Fehlerbehebungssitzung für diesen Message Processor.

Mit den folgenden Begriffen wird der Status einer Fehlerbehebungssitzung beschrieben:

  • Eine aktive Sitzung ist eine Debugging-Sitzung, die noch nicht das Zeitlimit erreicht oder die Anzahl überschritten hat. In einer aktiven Sitzung werden weiterhin Anfragedaten für Anfragen aufgezeichnet, die nicht herausgefiltert werden.
  • Eine abgeschlossene Sitzung ist eine Debug-Sitzung, die entweder ihr Zeitlimit erreicht oder ihre Anzahl überschritten hat. In einer abgeschlossenen Sitzung werden keine Daten zu neuen Anfragen mehr aufgezeichnet und die Daten werden innerhalb von 24 Stunden nach dem Ende der Sitzung gelöscht.

Fehlerbehebungssitzung lesen

In diesem Abschnitt erhalten Sie einen Überblick über eine Fehlerbehebungssitzung.

Siehe auch:

Das Debug-Tool besteht aus zwei Hauptteilen: dem Transaktionsbereich und den Phasendetails:

  • Im Transaktionsbereich werden Symbole verwendet, um jeden wichtigen Schritt zu kennzeichnen, der während einer API-Proxy-Transaktion auftritt, einschließlich Richtlinienausführung, bedingter Schritte und Übergänge. Bewegen Sie den Mauszeiger auf ein beliebiges Symbol, um eine Zusammenfassung zu sehen. Die Schritte des Anfrageablaufs werden oben in der Transaktionskarte und die Schritte des Antwortablaufs unten angezeigt.
  • Im Bereich Phasendetails werden Informationen zur internen Verarbeitung des Proxys aufgeführt, einschließlich Variablen, die festgelegt oder gelesen wurden, Anfrage- und Antwortheader und vieles mehr. Klicken Sie auf ein Symbol, um die Phasendetails für diesen Schritt aufzurufen.

Transaktionsbereich

Im Transaktionsbereich werden die Schritte in der Anfrage und Antwort angezeigt.

Hier sehen Sie ein Beispiel für den Transaktionsbereich des Debugging-Tools mit den wichtigsten Proxy-Verarbeitungssegmenten:

Zum Vergrößern des Bildes klicken Fehlerbehebungs-Diagramm, das folgende Abläufe veranschaulicht: Starten der Proxy-Anfrage, Starten der Zielanfrage, Starten der Zielantwort, Starten der Proxy-Antwort und Starten des Proxy-Post-Client-Ablaufs

Legende des Transaktionsbereichs

Im Folgenden werden die Symbole im Transaktionsbereich beschrieben:

In diesem Abschnitt werden die Symbole im Transaktionsbereich beschrieben:

Richtliniensymbole

Jeder Richtlinientyp hat ein eindeutiges Symbol. Anhand dieser Symbole können Sie sehen, wo Richtlinien in der richtigen Reihenfolge ausgeführt werden und ob sie erfolgreich sind oder nicht. Sie können auf ein Richtliniensymbol klicken, um die Ergebnisse der Ausführung zu sehen und zu prüfen, ob sie den Erwartungen entsprechen. Sie können beispielsweise sehen, ob die Nachricht richtig transformiert wurde oder ob sie im Cache gespeichert wird.

Standardrichtlinien erweitern Ihre APIs, um Traffic zu steuern, die Leistung zu verbessern, die Sicherheit zu erzwingen und den Nutzen Ihrer APIs zu erhöhen, ohne dass Sie Code schreiben oder Backend-Dienste ändern müssen.

Mit erweiterbaren Richtlinien können Sie Ihren API-Proxys benutzerdefinierte Logik hinzufügen. Mit diesen Richtlinien können Sie Funktionen hinzufügen, die nicht in den Standardrichtlinien enthalten sind.

Weitere Informationen zu Richtlinien und Kategorien finden Sie unter Übersicht über die Richtlinien.

So filtern Sie die Tabelle:

  • Wählen Sie einen Richtlinientyp und/oder eine Richtlinienkategorie aus.
  • Klicken Sie auf die Spaltenüberschrift Name, um die Tabelle nach Richtliniennamen zu sortieren.
  • Geben Sie einen Suchbegriff ein, um nach einem Richtliniennamen zu suchen.

Richtlinientyp

Richtlinienkategorie

Symbol Name Typ Kategorie
Symbol für LLMTokenQuota-Richtlinie LLMTokenQuota-Richtlinie Erweiterbar AI
chat_spark PromptTokenLimit-Richtlinie Erweiterbar AI
shield_spark Richtlinie „SanitizeUserPrompt“ Erweiterbar AI
shield_spark SanitizeModelResponse-Richtlinie Erweiterbar AI
async Richtlinie „SemanticCacheLookup“ Erweiterbar AI
async Richtlinie „SemanticCachePopulate“ Erweiterbar AI
manage_search ParseDialogflowRequest-Richtlinie Erweiterbar Dialog flow
chat_add_on SetDialogflowResponse-Richtlinie Erweiterbar Dialog flow
stacked_line_chart DataCapture-Richtlinie Erweiterbar Erweiterung
display_external_input ExternalCallout-Richtlinie Standard Erweiterung
flowsheet FlowCallout-Richtlinie Erweiterbar Erweiterung
automation IntegrationCallout-Richtlinie Erweiterbar Erweiterung
Symbol für JavaCallout-Richtlinie JavaCallout-Richtlinie Erweiterbar Erweiterung
Symbol für JavaScript-Richtlinie JavaScript-Richtlinie Erweiterbar Erweiterung
add_notes MessageLogging-Richtlinie Erweiterbar Erweiterung
chat_paste_go PublishMessage-Richtlinie Standard Erweiterung
Symbol für PythonScript-Richtlinie PythonScript-Richtlinie Erweiterbar Erweiterung
integration_instructions ServiceCallout-Richtlinie Erweiterbar Erweiterung
automation SetIntegrationRequest-Richtlinie Erweiterbar Erweiterung
waterfall_chart TraceCapture-Richtlinie Erweiterbar Erweiterung
cloud_done AccessEntity-Richtlinie Erweiterbar Mediation
account_tree AssertCondition-Richtlinie Standard Mediation
edit_square AssignMessage-Richtlinie Erweiterbar Mediation
login ExtractVariables-Richtlinie Erweiterbar Mediation
Symbol für GraphQL-Richtlinie GraphQL-Richtlinie Standard Mediation
sync_alt HTTPModifier-Richtlinie Standard Mediation
sync_alt JSONtoXML-Richtlinie Standard Mediation
account_tree KeyValueMapOperations-Richtlinie Erweiterbar Mediation
sync_alt MonetizationLimitsCheck-Richtlinie Erweiterbar Mediation
cloud_done OASValidation-Richtlinie Standard Mediation
report RaiseFault-Richtlinie Standard Mediation
sync_alt ReadPropertySet-Richtlinie Standard Mediation
cloud_done SOAPMessageValidation-Richtlinie Standard Mediation
sync_alt XMLtoJSON-Richtlinie Standard Mediation
cloud_done XSLTransform-Richtlinie Erweiterbar Mediation
lock AccessControl-Richtlinie Standard Sicherheit
sicherheit BasicAuthentication-Richtlinie Erweiterbar Sicherheit
connect_without_contact CORS-Richtlinie Standard Sicherheit
lock DecodeJWS-Richtlinie Erweiterbar Sicherheit
lock DecodeJWT-Richtlinie Standard Sicherheit
Passkey DeleteOAuthV2Info-Richtlinie Erweiterbar Sicherheit
lock GenerateSamlAssertion-Richtlinie Erweiterbar Sicherheit
lock GenerateJWS-Richtlinie Erweiterbar Sicherheit
lock GenerateJWT-Richtlinie Erweiterbar Sicherheit
Passkey GetOAuthV2Info-Richtlinie Erweiterbar Sicherheit
lock HMAC-Richtlinie Standard Sicherheit
sicherheit JSONThreatProtection-Richtlinie Erweiterbar Sicherheit
Passkey OAuthV2-Richtlinie Erweiterbar Sicherheit
sicherheit RegularExpressionProtection-Richtlinie Erweiterbar Sicherheit
Passkey RevokeOAuthV2-Richtlinie Erweiterbar Sicherheit
Passkey SetOAuthV2Info-Richtlinie Erweiterbar Sicherheit
lock ValidateSamlAssertion-Richtlinie Erweiterbar Sicherheit
key VerifyAPIKey-Richtlinie Erweiterbar Sicherheit
Passkey VerifyIAM-Richtlinie Erweiterbar Sicherheit
lock VerifyJWS-Richtlinie Erweiterbar Sicherheit
lock VerifyJWT-Richtlinie Standard Sicherheit
sicherheit XMLThreatProtection-Richtlinie Erweiterbar Sicherheit
cached InvalidateCache-Richtlinie Erweiterbar Traffic-Verwaltung
cached LookupCache-Richtlinie Erweiterbar Traffic-Verwaltung
cached PopulateCache-Richtlinie Erweiterbar Traffic-Verwaltung
Symbol für Kontingentrichtlinie Kontingentrichtlinie Erweiterbar Traffic-Verwaltung
repartition ResetQuota-Richtlinie Erweiterbar Traffic-Verwaltung
cached ResponseCache-Richtlinie Erweiterbar Traffic-Verwaltung
emergency_home SpikeArrest-Richtlinie Standard Traffic-Verwaltung

Andere Symbole

In der folgenden Tabelle wird die Bedeutung der anderen Symbole beschrieben, die im Transaktionsbereich angezeigt werden. Diese Symbole kennzeichnen die einzelnen wichtigen Verarbeitungsschritte im Proxy-Ablauf.

So filtern Sie die Tabelle:

  • Wählen Sie einen Symboltyp aus.
  • Klicken Sie auf die Spaltenüberschrift Name, um die Tabelle nach Symbolnamen zu sortieren.
  • Geben Sie einen Suchbegriff ein, um nach einem Symbolnamen zu suchen.

Symboltyp

Symbol Name Typ Beschreibung
monitor Client-App Standardtransaktion Die Client-App, die eine Anfrage an den ProxyEndpoint des API-Proxy sendet.
circle Übergangsendpunkt Standardtransaktion Der Kreis markiert Übergangsendpunkte im Proxy-Ablauf. Sie sind vorhanden, wenn eine Anfrage vom Client eingeht, wenn die Anfrage an das Ziel gesendet wird, wenn die Antwort vom Ziel zurückkommt und wenn die Antwort an den Client zurückgesendet wird.
stat_0 Ablaufsegment Standardtransaktion

Die Raute gibt den Beginn eines Ablaufsegments im API-Proxy-Ablauf an. Die Flusssegmente sind: ProxyEndpoint-Anfrage, TargetEndpoint-Anfrage, TargetEndpoint-Antwort und ProxyEndpoint-Antwort. Ein Segment umfasst den PreFlow, bedingte Abläufe und den PostFlow.

Weitere Informationen finden Sie unter Bedingte Abläufe.

Symbol für Bedingung erfüllt Bedingter Ablauf wahr Standardtransaktion

Ein bedingter Ablauf, der als „true“ ausgewertet wird (z. B. eine if-Anweisung, die als true ausgewertet wird). Eine Einführung in bedingte Abläufe finden Sie unter Bedingte Abläufe.

Beachten Sie, dass einige Bedingungen von Apigee generiert werden. Der folgende Ausdruck wird beispielsweise von Apigee verwendet, um zu prüfen, ob im ProxyEndpoint ein Fehler aufgetreten ist:

((error.state equals PROXY_REQ_FLOW) or (error.state equals PROXY_RESP_FLOW))

Symbol für Bedingung „Falsch“ Bedingter Ablauf falsch Standardtransaktion

Ein bedingter Ablauf, der mit „false“ ausgewertet wird Eine Einführung in bedingte Abläufe finden Sie unter Bedingte Abläufe.

Beachten Sie, dass einige Bedingungen von Apigee generiert werden. Im Folgenden finden Sie beispielsweise einen Ausdruck, mit dem Apigee prüft, ob im TargetEndpoint ein Fehler aufgetreten ist:

(((error.state equals TARGET_REQ_FLOW) or (error.state equals TARGET_RESP_FLOW)) or ((error.state equals REQ_SENT) or (error.state equals RESP_START)))

Symbol für Ablaufinformationen Ablaufinformationen Standardtransaktion Stellt Kontextinformationen zur API-Proxy-Ausführung dar, die je nach Punkt im Ablauf variieren. Dazu gehören Details zur Proxy-Konfiguration, zum aktuellen Ausführungsstatus (z.B. PreFlow, PostFlow, Flow-Hooks), zur Richtlinienausführung und zu Variablen, die während der Richtlinienausführung ausgefüllt wurden, um den spezifischen Status des Proxys zu diesem Zeitpunkt anzugeben.
done_all Ablaufausführung Standardtransaktion Markiert den Beginn oder das Ende der Ausführung eines Ablaufs und gibt den Zeitraum eines bestimmten Ablaufsegments an, um die Grenzen des Ablaufs visuell abzugrenzen und die Reihenfolge der Ausführung des Ablaufs anzugeben.
commit Ablaufverarbeitung Standardtransaktion Gibt die aktive Verarbeitung innerhalb eines Ablaufs an und stellt den Zeitraum dar, in dem Richtlinien und die Ablauflogik ausgeführt werden.
bar_chart Von Apigee Analytics erfasste Daten Standardtransaktion Gibt an, dass Analytics-Aktionen im Hintergrund ausgeführt wurden.
location_on Backend-Dienst Standardtransaktion Backend-Dienst, der die Anfrage empfängt. Das vom API-Proxy aufgerufene Backend-Ziel.
Symbol für „Deaktiviert“ Deaktiviert Schrittstatus Erscheint bei einem Richtliniensymbol, wenn eine Richtlinie deaktiviert ist. Eine Richtlinie kann mit der öffentlichen API deaktiviert werden. Weitere Informationen finden Sie in der Referenz zur API-Proxy-Konfiguration.
Fehlersymbol Fehler Schrittstatus Wird auf einem Richtliniensymbol angezeigt, wenn die Schrittbedingung des Richtlinienschritts „false“ ergibt (siehe Bedingungen mit Ablaufvariablen), oder auf dem RaiseFault-Richtliniensymbol, wenn eine RaiseFault-Richtlinie ausgeführt wird.
Symbol für „Übersprungen“ Übersprungen Schrittstatus Wird auf einem Richtliniensymbol angezeigt, wenn die Richtlinie nicht ausgeführt wurde, weil die Schrittbedingung als „false“ ausgewertet wurde. Weitere Informationen finden Sie unter Bedingungen mit Ablaufvariablen.

Bereich „Phasendetails“

Im Detailbereich der Phase finden Sie Informationen zum Status Ihres Proxys bei jedem Verarbeitungsschritt.

Im Detailbereich der Phase finden Sie viele Informationen zum Status Ihres Proxys bei jedem Verarbeitungsschritt. Hier sind einige der angegebenen Details. Klicken Sie auf ein beliebiges Symbol im Debugging-Tool, um Details zum ausgewählten Schritt aufzurufen, oder verwenden Sie die Buttons > Weiter oder < Zurück, um von einem Schritt zum nächsten zu wechseln.

In der folgenden Tabelle werden die Details im Bereich „Phasendetails“ beschrieben.

Phasendetails Beschreibung
Variablen

Listet die Ablaufvariablen auf, die von einer Richtlinie gelesen und denen ein Wert zugewiesen wurde. Weitere Informationen finden Sie unter Ablaufvariablen verwenden.

Anfrageheader Listet die HTTP-Anfrageheader auf.
Inhalt anfragen Zeigt den HTTP-Anfragetext an.
Eigenschaften Attribute stellen den internen Status des API-Proxys dar. Diese werden standardmäßig nicht angezeigt.
Zielendpunkt Gibt an, welcher TargetEndpoint für die Ausführung ausgewählt wurde.
Antwortheader Listet die HTTP-Antwortheader auf.
Antwortinhalt Zeigt den HTTP-Antworttext an.

Zeitachse

Die Zeitachse gibt an, wie lange (in Millisekunden) die Verarbeitung gedauert hat. Durch den Vergleich der verstrichenen Zeitsegmente können Sie die Richtlinien isolieren, deren Ausführung am längsten dauert und die Ihre API-Aufrufe verlangsamen.

Das Epsilon ist ein Zeitraum, der kleiner als eine Millisekunde ist.

Zum Vergrößern des Bildes klicken Zeitachse in der Debug v2-Benutzeroberfläche

Gruppen maximieren und minimieren

In diesem Abschnitt wird beschrieben, wie Sie Gruppen im Transaktionsbereich maximieren und minimieren.

Transaktionsschritte für Anfrage und Antwort werden danach gruppiert, wie sie zuvor auf dem Tab „Entwickeln“ konfiguriert wurden, und zwar nach freigegebenem Ablauf. Beispiel: pre-proxy, post-proxy, pre-target und post-target.

In jeder Gruppierung werden relevante Richtlinien, Bedingungen, freigegebene Abläufe und Ablaufinformationen deutlich angezeigt.

Freigegebene Abläufe werden standardmäßig gruppiert und minimiert.

Im Transaktionsbereich sind die folgenden Aktionen verfügbar:

Element Name Beschreibung
Schieberegler „Alle maximieren“
<img <="" alt="Schieberegler zum Minimieren aller Elemente" class="screenshot" src="/static/apigee/docs/api-platform/debug/images/collapse_all_slider.png" td="" width="" /> 		Alle maximieren
Alle minimieren		 Alle Gruppen maximieren oder minimieren.
Symbol „Gruppe maximieren“
Symbol „Gruppe minimieren“ 		Maximieren
Minimieren		 Gruppe maximieren oder minimieren

Siehe auch:

Mit der Suche können Sie ein Wort oder eine Wortgruppe in der Anfrage oder Antwort finden.

Mit der Suche können Sie ein Wort oder eine Wortgruppe in der Anfrage oder Antwort finden.

Wichtige Hinweise:

  • Bei der Suche wird die Groß- und Kleinschreibung nicht berücksichtigt.
  • Die Suche gilt für eine einzelne Transaktion, d. h., es wird nicht in allen Transaktionen der gesamten Debugging-Sitzung gesucht.
  • Bei der Suche werden minimierte Abschnitte maximiert, aber es werden keine Informationen zu Knoten angezeigt, die durch die Auswahl von Ansichtsoptionen herausgefiltert werden.

So funktioniert die Suche.

  1. Geben Sie Text in das Suchfeld ein.

  2. Drücken Sie die Eingabetaste.

    Die Suchergebnisse werden im Bereich Transaktion und im Bereich Phasendetails hervorgehoben.

  3. Klicken Sie auf keyboard_arrow_up Zurück oder keyboard_arrow_down Weiter, um zum nächsten oder vorherigen Schritt zu gelangen.
Zum Vergrößern des Bildes klicken Suchergebnisse in der Debug v2-Benutzeroberfläche

Zoom

Mit dem Zoom können Sie die Ansicht des Transaktionsbereichs steuern.

Mit dem Zoom wird die Ansicht des Transaktionsbereichs so gesteuert:

Zum Vergrößern des Bildes klicken Zoomsteuerelemente für Debug v2
Symbol Beschreibung
100 % Aktuelle Zoomstufe. Die Standardeinstellung ist 100%.
fit_screen An Bildschirm anpassen
zoom_in Heranzoomen
zoom_out Herauszoomen
youtube_searched_for Zoom zurücksetzen

Fehlerbehebung mit dem Fehlerbehebungs-Tool

Bei der Fehlerbehebung erhalten Sie viele interne Details zu einem API-Proxy. Beispiel:

  • Sie können auf einen Blick sehen, welche Richtlinien ordnungsgemäß ausgeführt werden oder fehlschlagen.
  • Angenommen, Sie haben in einem der Analytics-Dashboards festgestellt, dass die Leistung einer Ihrer APIs ungewöhnlich zurückgegangen ist. Mit Debug können Sie jetzt ermitteln, wo der Engpass auftritt. Debug gibt die Zeit in Millisekunden an, die jeder einzelne Verarbeitungsschritt benötigt. Wenn die Ausführung eines Schritts zu lange dauert, können Sie entsprechende Korrekturen vornehmen.
  • Sie können Header überprüfen, die an das Backend gesendet werden, Variablen ansehen, die von Richtlinien festgelegt wurden, usw.
  • Anhand des Basispfads können Sie prüfen, ob eine Richtlinie die Nachricht an den richtigen Server weiterleitet.

Daten in einer Fehlerbehebungssitzung filtern

Beim Erstellen einer Fehlerbehebungssitzung können Sie einen Filter zu dieser Sitzung hinzufügen, damit Apigee nur die gewünschten Daten zurückgibt. Ein Filter ist eine bedingte Anweisung, die Apigee anhand von Anfrage- und Antwortnachrichten darauf prüft, ob ihre Fehlerbehebungsdaten in der Fehlerbehebungssitzung enthalten sein sollen. Sie können beispielsweise alle Anfragen mit einem HTTP-Antwortcode filtern, der kleiner als 599 ist, oder Werte in der Anfrage mit benutzerdefinierten Variablen vergleichen.

Hinweis:

  • Anfragen, die nicht in einer Fehlerbehebungssitzung enthalten sind, da sie herausgefiltert wurden, werden nicht für die maximale Anzahl von Transaktionen in der Fehlerbehebungssitzung berücksichtigt.
  • Apigee unterstützt nicht das Hinzufügen von Filtern im Abfragestring.
  • Nachdem die Sitzung gestartet wurde, können Sie einer Fehlerbehebungssitzung keinen Filter hinzufügen. Wenn Sie einen Filter hinzufügen möchten, müssen Sie eine Fehlerbehebungssitzung erstellen.

Filter verwenden

Verwenden Sie einen Filter, um eine Fehlerbehebungssitzung mit der Apigee-UI oder der API zu erstellen. Dies wird in den folgenden Abschnitten beschrieben.

Apigee-Benutzeroberfläche

Wenn Sie eine Fehlerbehebungssitzung in der Benutzeroberfläche erstellen, können Sie in der Drop-down-Liste Filter einen vordefinierten Filter auswählen, der im Bereich Fehlerbehebungssitzung starten angewendet werden soll, oder Benutzerdefinierter Filter auswählen und mit der Filtersyntax eine eigene erstellen.

API

Um eine Fehlerbehebungssitzung mit einem Filter unter Verwendung der API zu erstellen, fügen Sie Folgendes als Nutzlast in Ihre Anfrage zur Erstellung einer Fehlerbehebungssitzung ein:

{
  "filter":"filter_body"
}

Informationen zum Erstellen von Filtern finden Sie unter Filtersyntax.

Im folgenden Beispiel wird eine Fehlerbehebungssitzung erstellt, die nur Transaktionen enthält, bei denen der Header A gleich 42 und der Header B gleich 43 oder der Fehlercode ExpectedEOF ist:

curl -H "Authorization: Bearer $TOKEN" -X "POST"
  https://apigee.googleapis.com/v1/organizations/ORG/environments/ENV/apis/PROXY/revisions/REV/debugsessions
  -d ' {
    "filter":"(request.header.A == '42' && request.header.B == '43') || fault.code == 'jsonparser.ExpectedEOF'"
  } '

Sie können einen Filter nur in Anfragen zur Erstellung von Fehlerbehebungssitzungen definieren; Sie können einen Filter nicht zu einer bestehenden Fehlerbehebungssitzung hinzufügen und Sie können einen Filter nicht aus einer aktiven Fehlerbehebungssitzung entfernen.

Filtersyntax

Filter unterstützen die gleiche Syntax, die auch von Apigee-Bedingungen verwendet wird, wie in der Referenz für Bedingungen beschrieben. Dazu zählen:

Darüber hinaus können Filter auf alle Ablaufvariablen zugreifen, die in der Referenz für Ablaufvariablen sowie in benutzerdefinierten Variablen beschrieben werden. Die folgenden Beispiele zeigen nur einige der möglichen Ablaufvariablen, die Sie in Filtern verwenden können:

# Response codes:
  response.status.code <= 599
  response.status.code >=301 && response.status.code <=420

# Requests/responses:
  request.verb == "GET"
  request.header.A == 'B' || request.queryparam.X == 'Y'

# Query parameters:
  request.queryparam.myparam == 'fish'
  (request.queryparam.param1 == 'X' || request.queryparam.param2 == 'Y') && request.queryparam.param3 == 'Z'

# Faults:
  fault.code != 'messaging.runtime.RouteFailed'
  fault.name == 'IPDeniedAccess'

Informationen zur Verwendung benutzerdefinierter Variablen finden Sie unter Verwendung benutzerdefinierter Attribute in Apigee in der Apigee-Community.

Vordefinierte UI-Filter

Die Apigee-Benutzeroberfläche bietet eine Reihe von gemeinsamen Filtern, sodass Sie keine eigenen benutzerdefinierten Filter schreiben müssen. Die vordefinierten Filter sind in der folgenden Tabelle zusammengefasst.

Filtername Beschreibung
Response Time Greater Than

Prüft auf Latenzprobleme, bei denen:

  • target.duration die Ziellatenz oder die Zeit in Millisekunden ist, die eine Anfrage zum Senden und Empfangen ab dem Ziel benötigt (berechnet als die Differenz zwischen target.received.end.timestamp und target.sent.start.timestamp)
  • client.duration die Client-Latenz oder die Zeit in Millisekunden ist, die eine Anfrage zum Senden und Empfangen ab dem Client benötigt (berechnet als Differenz zwischen client.received.end.timestamp und client.sent.start.timestamp)

Beispiel:

target.duration > 420 && client.duration > 1000

Weitere Informationen finden Sie unter client und target in der Referenz zu Ablaufvariablen.
Response Code

Prüft, ob der HTTP-Antwortcode mit dem angegebenen Wert übereinstimmt. Beispiel:

response.status.code <= 599
Header

Prüft, ob der angegebene Anfrageheader mit dem angegebenen Wert übereinstimmt. Beispiel:

request.header.cache-control.1 == "16544"
Path

Prüft, ob die Anfrage mit dem angegebenen Pfad übereinstimmt. Sie können Platzhalter in Ihrem Wert verwenden. Zum Beispiel:

request.path == /myproxy/customer/4*
Query Param

Prüft, ob der angegebene Abfrageparameter der Anfrage dem angegebenen Wert entspricht. Beispiel:

request.queryparam.lang == "language:en-us"
Custom

Sie können eigene Ausdrücke einfügen. Sie können alle Objekte in der Referenz zu Ablaufvariablen und die Syntax in der Bedingungsreferenz verwenden. Darüber hinaus können Sie auch benutzerdefinierte Variablen verwenden.

Weitere Informationen zum Erstellen benutzerdefinierter Filter finden Sie unter Filtersyntax.
 

Fehlerbehebungssitzungen anzeigen

Apigee speichert Fehlerbehebungssitzungsdaten 24 Stunden lang. Sie können diesen Wert nicht konfigurieren. Nach 24 Stunden sind die Daten nicht mehr verfügbar. Bis dahin können Sie alle Fehlerbehebungssitzungen ansehen.

Sehen Sie sich aktuelle Fehlerbehebungssitzungen über die Apigee-UI oder -API an, wie in den folgenden Abschnitten beschrieben.

Apigee-Benutzeroberfläche

So rufen Sie Debugging-Sitzungen mit der Google Cloud Console auf:

  1. Rufen Sie in der Google Cloud Console die Seite Proxy-Entwicklung > API-Proxys auf.

    Zu „API-Proxys“

  2. Klicken Sie auf den Proxy, den Sie debuggen möchten.
  3. Klicken Sie auf den Tab Debugging.
  4. Unter Aktuelle Debugging-Sitzungen wird eine Liste der verfügbaren Debugging-Sitzungen angezeigt.

  5. Klicken Sie auf den Link für die Sitzung, die Sie sich ansehen möchten.

API

Mit der API können Sie:

Alle Fehlerbehebungssitzungen mit der API anzeigen

Wenn Sie alle aktuellen Fehlerbehebungssitzungen aufrufen möchten, die für eine API-Proxy-Überarbeitung in einer Umgebung definiert sind, senden Sie eine GET-Anfrage an die folgende Ressource: 

https://apigee.googleapis.com/v1/organizations/org/environments/env/apis/api/revisions/rev/debugsessions

Optional können Sie einen der folgenden Abfrageparameter angeben, um die Menge der zurückgegebenen Daten zu steuern:

  • pageSize: Maximale Anzahl der aufzulistenden Fehlerbehebungssitzungen. Die Seitengröße ist standardmäßig auf 25 festgelegt.
  • pageToken: Seitentoken, das von einem vorherigen Aufruf zurückgegeben wurde und zum Abrufen der nächsten Seite verwendet werden kann.

Im folgenden Beispiel wird dargestellt, wie die Fehlerbehebungssitzungen für Überarbeitung 1 der helloworld-API-Proxy in der test-Umgebung angezeigt werden.

curl "https://apigee.googleapis.com/v1/organizations/myorg/environments/test/apis/helloworld/revisions/1/debugsessions" \
-X GET \
-H "Authorization: Bearer $TOKEN"

Dabei ist $TOKEN auf Ihr OAuth 2.0-Zugriffstoken festgelegt. Weitere Informationen hierzu finden Sie unter OAuth 2.0-Zugriffstoken abrufen. Informationen zu den in diesem Beispiel verwendeten curl-Optionen finden Sie unter curl verwenden. Eine Beschreibung der Umgebungsvariablen, die Sie verwenden können, finden Sie unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

Die Antwort beinhaltet ein sessions-Objekt, das eine Liste der derzeit aktiven Fehlerbehebungssitzungen enthält, wie im folgenden Beispiel gezeigt:

{
"sessions": [
{
"id": "a423ac73-0902-4cfa-4242-87a353a84d87",
"timestamp_ms": 1566330186000
},
{
"id": "f1eccbbe-1fa6-2424-83e4-3d063b47728a",
"timestamp_ms": 1566330286000
}
]
}

Nur Debugging-Sitzungen, in denen die Antwort mindestens eine Transaktion enthält. Debugging-Sitzungen ohne Transaktionen sind nicht in dieser Liste enthalten.

Weitere Informationen finden Sie unter List Debug sessions API.

Alle Transaktionen für eine Fehlerbehebungssitzung mithilfe der API anzeigen

Senden Sie eine GET-Anfrage an die folgende Ressource, um eine Liste der Transaktionen für eine Fehlerbehebungssitzung aufzurufen:

https://apigee.googleapis.com/v1/organizations/org/environments/env/apis/api/revisions/rev/debugsessions/debugsession/data

Dabei ist debugsession die ID einer Fehlerbehebungssitzung, die beim Aufrufen der Fehlerbehebungssitzungen zurückgegeben wird.

Im folgenden Beispiel wird gezeigt, wie Sie die Transaktionen für eine Fehlerbehebungssitzung für Revision 1 der helloworld-API in der test-Umgebung aufrufen können.

curl "https://apigee.googleapis.com/v1/organizations/myorg/environments/test/apis/helloworld/revisions/1/debugsessions/a423ac73-0902-4cfa-4242-87a353a84d87/data" \
-X GET \
-H "Authorization: Bearer $TOKEN"

Dabei ist $TOKEN auf Ihr OAuth 2.0-Zugriffstoken festgelegt. Weitere Informationen hierzu finden Sie unter OAuth 2.0-Zugriffstoken abrufen. Informationen zu den in diesem Beispiel verwendeten curl-Optionen finden Sie unter curl verwenden. Eine Beschreibung der Umgebungsvariablen, die Sie verwenden können, finden Sie unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

Die Antwort enthält ein Array mit Transaktions-IDs, wie im folgenden Beispiel gezeigt:

[
"myorg-test-ver-5qxdb-64",
"myorg-test-ver-5qxdb-65",
"myorg-test-ver-5qxdb-66",
"myorg-test-ver-5qxdb-67",
"myorg-test-ver-5qxdb-68",
"myorg-test-ver-5qxdb-69",
"myorg-test-ver-5qxdb-70",
"myorg-test-ver-5qxdb-71",
"myorg-test-ver-5qxdb-72"
]

Weitere Informationen finden Sie unter List debug session data API.

Transaktionsdaten für eine Fehlerbehebungssitzung mithilfe der API aufrufen

Wenn Sie Transaktionsdaten für eine Fehlerbehebungssitzung aufrufen möchten, senden Sie eine GET-Anfrage an die folgende Ressource: 

https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/apis/{api}/revisions/{rev}/debugsessions/{debugsession}/data/{transactionId}

Dabei ist debugsession die ID einer Fehlerbehebungssitzung, die zurückgegeben wird, wenn Sie Fehlerbehebungssitzungen aufrufen, und transactionId ist die Transaktions-ID, wenn Sie eine Liste der Transaktionen für eine Fehlerbehebungssitzung anzeigen

Die während einer Fehlerbehebungssitzung gespeicherten Transaktionsdaten sind in JSON formatiert. Sie können diese Daten im Offline-Debug-Tool laden.

Das folgende Beispiel zeigt, wie Sie die Transaktionsdaten für eine Fehlerbehebungssitzung für Revision 1 der helloworld-API in der test-Umgebung herunterladen.

curl "https://apigee.googleapis.com/v1/organizations/myorg/environments/test/apis/helloworld/revisions/1/debugsessions/a423ac73-0902-4cfa-4242-87a353a84d87/data/myorg-test-ver-5qxdb-64" \
-X GET \
-H "Authorization: Bearer $TOKEN"

Dabei ist $TOKEN auf Ihr OAuth 2.0-Zugriffstoken festgelegt. Weitere Informationen hierzu finden Sie unter OAuth 2.0-Zugriffstoken abrufen. Informationen zu den in diesem Beispiel verwendeten curl-Optionen finden Sie unter curl verwenden. Eine Beschreibung der Umgebungsvariablen, die Sie verwenden können, finden Sie unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

Die Antwort besteht aus einer JSON-Nutzlast, die die Daten für die angegebene Transaktion enthält, wie unter Datenstruktur herunterladen beschrieben.

Debug-Daten enthalten alle Informationen zur Anfrage und Antwort für jeden Teil des Ablaufs in einem proprietären JSON-Format. Sie können diese Daten speichern und später im Offline-Debugging-Tool verwenden.

Wenn vor dem Ende der Sitzung keine Anfragen hinzugefügt wurden, sieht die Antwort so aus:

[]

Weitere Informationen finden Sie unter Get debug session data API.

Ansichtsoptionen in der Benutzeroberfläche auswählen

In diesem Abschnitt wird beschrieben, wie Sie Ansichtsoptionen auswählen, um die Anzeige in der Benutzeroberfläche zu filtern.

Wählen Sie im Bereich Ansichtsoptionen die Ansichtsoptionen für die Debug-Sitzung aus oder heben Sie die Auswahl auf. Diese Ansichtsoptionen bleiben für jeden Nutzer über die Debug-Sitzung hinweg erhalten.

Zum Vergrößern klicken Optionsliste anzeigen
Option Beschreibung
Deaktivierte Richtlinien anzeigen Deaktivierte Richtlinien anzeigen Richtlinien können mit der öffentlichen API deaktiviert werden. Weitere Informationen finden Sie in der Referenz zur API-Proxy-Konfiguration.
Übersprungene Richtlinien anzeigen Übersprungene Richtlinien anzeigen. Eine übersprungene Richtlinie tritt auf, wenn die Richtlinie nicht ausgeführt wurde, weil die Schrittbedingung als „false“ ausgewertet wurde. Weitere Informationen finden Sie unter Bedingungen mit Ablaufvariablen.
Alle Ablaufinformationen anzeigen Übergänge innerhalb eines Ablaufsegments darstellen.
Alle Ablaufbedingungen anzeigen Stellen die Bedingungen dar, die für jeden Ablauf ausgewertet wurden.

Debugging-Sitzung freigeben

Sie können eine Debugging-Sitzung für andere Nutzer freigeben, die Zugriff auf Ihre Organisation und die erforderlichen Berechtigungen haben. Senden Sie dazu einfach die URL, die in Ihrem Browser angezeigt wird, wenn Sie die Debugging-Sitzung aufrufen. Der Link ist nur 24 Stunden nach dem Erstellen der Debugging-Sitzung gültig.

Sitzungsdaten zur Fehlerbehebung herunterladen

Sie können eine Datei mit unverarbeiteten Fehlerbehebungsergebnissen herunterladen und offline ansehen. Die heruntergeladene Datei enthält die vollständigen Details der Fehlerbehebungssitzung, einschließlich des Inhalts aller Header, Variablen und Richtlinien.

Daten zur Fehlerbehebung von Sitzungen können nur 24 Stunden lang in der Benutzeroberfläche heruntergeladen oder angesehen werden. Danach löscht Apigee die Sitzungsdaten.

Verwenden Sie das Offline-Debugging-Tool, um heruntergeladene Daten zur Fehlerbehebung aufzurufen.

Apigee-Benutzeroberfläche

Klicken Sie zum Herunterladen der aktuellen Debugging-Sitzung in der Google Cloud -Console in der Debugging-Ansicht auf Herunterladen.

API

Geben Sie den folgenden Befehl ein, um die IDs aller Transaktionen für die aktuelle Debugging-Sitzung mithilfe der Apigee API aufzurufen:

    curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
         https://apigee.googleapis.com/v1/organizations/ORG/environments/ENV/apis/PROXY/revisions/REV/debugsessions/SESSION_ID/data

Dabei ist SESSION_ID die ID für die Debugging-Sitzung, die Sie herunterladen möchten.

Weitere Informationen finden Sie unter Transaktions-IDs aus einer Debugging-Sitzung auflisten.

Geben Sie den folgenden Befehl ein, um die Debugging-Daten für eine Transaktion mithilfe der Apigee API abzurufen:

    curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://apigee.googleapis.com/v1/organizations/ORG/environments/ENV/apis/PROXY/revisions/REV/debugsessions/SESSION_ID/data/TRANSACTION_ID

Datenstruktur des Downloads

Die Downloadstruktur der Fehlerbehebungssitzungen unterscheidet sich für die Apigee-UI und die Apigee API.

Apigee-Benutzeroberfläche

Wenn Sie Daten über die Apigee-UI herunterladen, wird die Datenstruktur:

  • alle Transaktionen der gesamten Sitzung umfassen
  • Transaktionen in einem Messages-Array speichern
  • Metadaten zur Sitzung (als DebugSession-Objekt) enthalten

API

Mit der Apigee API können Sie die Daten einer gesamten Sitzung nicht gleichzeitig anzeigen. Sie können mit der API nur einzelne Transaktionsdaten abrufen, wie unter Fehlerbehebungssitzungen aufrufen beschrieben.

Beispiel:

{
"completed": true,
"point": [
  ...
...
}

Datenbeispiele herunterladen

Im folgenden Beispiel wird ein DebugSession-Metadatenobjekt in den heruntergeladenen Daten hervorgehoben. Auf dieses Objekt folgt das Array Messages, das die Transaktionen in der Sitzung enthält.

{
  "DebugSession": {
    "Retrieved": "2019-06-08T13:08:13.395Z",
    "Organization": "myorg",
    "Environment": "prod",
    "API": "myproxy",
    "Revision": "1",
    "SessionId": "a2a271aa-4242-4ac6-97cb-aec8dcb115a9"
  },
  "Messages": [
    {
      "completed": true,
      "point": [
        {
          "id": "Paused"
        },
        {
          "id": "Resumed"
        },
        {
          "id": "StateChange",
          "results": [
            {
              "ActionResult": "DebugInfo",
              "properties": {
                "property": [
                  {
                    "name": "To",
                    "value": "REQ_HEADERS_PARSED"
                  },
                  {
                    "name": "From",
                    "value": "REQ_START"
                  }
                ]
              },
              "timestamp": "8-6-19 13:08:37:718"
            },
            {
              "ActionResult": "RequestMessage",
              "headers": [
                {
                  "name": "accept",
                  "value": "*/*"
                },
                {
                  "name": "accept-encoding",
                  "value": "gzip,gzip,deflate,br"
                },
                {
                  "name": "content-length",
                  "value": "0"
                },
                {
                  "name": "host",
                  "value": "myorg.example.domain.net"
                },
                {
                  "name": "user-agent",
                  "value": "Google-Apigee"
                },
                {
                  "name": "x-b3-sampled",
                  "value": "0"
                },
                {
                  "name": "x-b3-spanid",
                  "value": "d4ee579206759662"
                },
                {
                  "name": "x-b3-traceid",
                  "value": "adc1e171777c237dd4ee579206759662"
                },
                {
                  "name": "x-forwarded-for",
                  "value": "66.102.8.98"
                },
                {
                  "name": "x-forwarded-proto",
                  "value": "https"
                },
                {
                  "name": "x-request-id",
                  "value": "54e05cba-4242-4490-4242-60c45c156f90"
                }
              ],
              "uRI": "/myproxy",
              "verb": "GET"
            }
          ]
        },
        {
          "id": "FlowInfo",
          "results": [
            {
              "ActionResult": "DebugInfo",
              "properties": {
                "property": [
                  {
                    "name": "environment.name",
                    "value": "prod"
                  },
                  {
                    "name": "environment.qualifiedname",
                    "value": "myorg__prod"
                  },
                  {
                    "name": "environment.orgname",
                    "value": "myorg"
                  }
                ]
              },
              "timestamp": "8-6-19 13:08:37:718"
            }
          ]
        },
        {
          "id": "FlowInfo",
          "results": [
            {
              "ActionResult": "DebugInfo",
              "properties": {
                "property": [
                  {
                    "name": "organization.name",
                    "value": "myorg"
                  }
                ]
              },
              "timestamp": "8-6-19 13:08:37:718"
            }
          ]
        },
        {
          "id": "FlowInfo",
          "results": [
            {
              "ActionResult": "DebugInfo",
              "properties": {
                "property": [
                  {
                    "name": "apiproxy.qualifiedname",
                    "value": "myproxy__1"
                  },
                  {
                    "name": "apiproxy.basepath",
                    "value": "/"
                  },
                  {
                    "name": "apiproxy.revision",
                    "value": "1"
                  },
                  {
                    "name": "apiproxy.name",
                    "value": "myproxy"
                  }
                ]
              },
              "timestamp": "8-6-19 13:08:37:718"
            }
          ]
        },
        ...
      ...
    }
  ]
}

Wenn die Debugging-Sitzung keine Anfragen enthielt, ist das Message-Array leer, wie im folgenden Beispiel gezeigt:

{
  "DebugSession": {
    "Retrieved": "2019-06-08T13:08:13.395Z",
    "Organization": "myorg",
    "Environment": "prod",
    "API": "myproxy",
    "Revision": "1",
    "SessionId": "a2a271aa-4242-4ac6-97cb-aec8dcb115a9"
  },
"Messages": []
}

Daten für eine Fehlerbehebungssitzung löschen

Löschen Sie Daten für eine Fehlerbehebungssitzung mit der Apigee-Benutzeroberfläche oder der API, wie in den folgenden Abschnitten beschrieben.

Apigee-Benutzeroberfläche

So löschen Sie eine Debugging-Sitzung in der Google Cloud Console:

  1. Klicken Sie auf dem Tab Debug auf die Zeile für die Sitzung, die Sie löschen möchten.
  2. Klicken Sie im Bereich Debugging-Sitzung auf Löschen.

API

Wenn Sie alle Fehlerbehebungssitzungsdaten mit der API löschen möchten, senden Sie eine DELETE-Anfrage an die folgende Ressource: 

https://apigee.googleapis.com/v1/organizations/org/environments/env/apis/api/revisions/rev/debugsessions/debugsession/data

Dabei ist debugsession die ID einer Fehlerbehebungssitzung, die beim Aufrufen der Fehlerbehebungssitzungen zurückgegeben wird.

Das folgende Beispiel zeigt, wie Sitzungsdaten für Revision 1 der helloworld-API in der test-Umgebung gelöscht werden.

curl "https://apigee.googleapis.com/v1/organizations/myorg/environments/test/apis/helloworld/revisions/1/debugsessions/a423ac73-0902-4cfa-4242-87a353a84d87/data" \
      -X DELETE \
      -H "Authorization: Bearer $TOKEN"

Dabei ist $TOKEN auf Ihr OAuth 2.0-Zugriffstoken festgelegt. Weitere Informationen hierzu finden Sie unter OAuth 2.0-Zugriffstoken abrufen. Informationen zu den in diesem Beispiel verwendeten curl-Optionen finden Sie unter curl verwenden. Eine Beschreibung der Umgebungsvariablen, die Sie verwenden können, finden Sie unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

Wenn der Vorgang erfolgreich ist, ist der Antworttext leer.

Daten zu einer Fehlerbehebungssitzung werden nur 24 Stunden lang gespeichert. Wenn Sie sie nicht explizit vor diesem Zeitpunkt löschen, wird sie von Apigee gelöscht.