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

Wenn Sie eine Debugging-Sitzung erstellen, können Sie die Anfrage- und Antwortdaten in der UI ansehen – für Anfragen, die in der UI, in der API oder in einer anderen externen Quelle erstellt wurden.

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

Neuer Proxy-Editor

So erstellen Sie eine Debugging-Sitzung im neuen Proxy-Editor:

  1. Wenn Sie die Apigee-UI in der Cloud Console verwenden: Wählen Sie Proxy-Entwicklung > API-Proxys aus.

    Wenn Sie das klassische Apigee-Benutzeroberfläche nutzen: Auswählen Entwickeln > API-Proxys und in der Proxys-Bereich wählen Sie die Umgebung für den Proxy aus, den Sie debuggen möchten.

  2. Wählen Sie den API-Proxy aus, den Sie debuggen möchten. Dadurch wird die Ansicht Übersicht des Proxy-Editors angezeigt.

  3. Klicken Sie oben links im Fenster auf den Tab Debugging.
  4. Klicken Sie oben rechts im Bereich Debugging auf Debugging-Sitzung starten. Dadurch wird das Dialogfeld Debugging-Sitzung starten angezeigt.

    Starten Sie das Dialogfeld zur Debugging-Sitzung.

    Über das Dialogfeld:

    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 die Ansicht Debugging-Sitzung in Bearbeitung angezeigt.

Debugging in Bearbeitung

Die Debugging-Sitzung zeichnet Anfragen zehn Minuten nach dem Erstellen der Sitzung auf. 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 ausführen. Umgebung für die Debugging-Sitzung.

Nachdem Sie die Anfrage gesendet haben, wird sie unten im linken Bereich angezeigt.

Starten Sie das Dialogfeld zur Debugging-Sitzung.

Während einer aktiven Debugging-Sitzung können Sie eine weitere Sitzung in der Apigee-UI starten. Klicken Sie dazu einfach noch einmal auf Debugging-Sitzung starten.

Gantt-Diagramm für eine Transaktion ansehen

Klicken Sie wie in der Abbildung oben auf die Zeile für die Transaktion, wenn Sie die Details einer Transaktion (Anfrage und Antwort) in der Debugging-Ansicht ansehen möchten.

Daraufhin wird im rechten Bereich ein Gantt-Diagramm angezeigt, das die Schritte in der Anfrage und Antwort anzeigt.

Gantt-Diagramm der Transaktionsschritte im rechten Bereich.

Die horizontale Achse des Diagramms gibt die Zeit in Millisekunden an, zu der jeder Schritt aufgetreten ist. Jeder Schritt wird durch ein Rechteck dargestellt, das von der Startzeit bis zur Endzeit des Schritts reicht.

Sie können eine Debugging-Sitzung mit den Schaltflächen Zurück und Weiter rechts unten im Debugging-Bereich durchgehen. Klicken Sie auf:

  • Zurück, um die ausgewählte Zeile in den vorherigen Schritt im Diagramm zu verschieben
  • Weiter, um die ausgewählte Zeile in den nächsten Schritt im Diagramm zu verschieben.

Im obigen Beispiel werden im Diagramm zwei Richtlinien angezeigt, die in der Antwort ausgeführt werden:

  • ResponsePayload
  • CORS hinzufügen

Sie können auf einen der folgenden Schritte klicken, um die zugehörigen Details aufzurufen. Wenn Sie beispielsweise auf die Richtlinie CORS hinzufügen geklickt haben, werden neben dem Gantt-Diagramm Details wie die folgenden angezeigt:

CORS-Richtliniendetails hinzufügen

Wenn Sie dann etwas in der Richtlinienkonfiguration ändern, können Sie auf Entwickeln klicken, um zur Ansicht Entwickeln zu wechseln, in der Sie dieselben zwei Richtlinien im Response PostFlow sehen würden.

Tab "Develop" in Bezug auf eine Debugging-Sitzung ansehen

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.

Debugging-Sitzung herunterladen

Nach Abschluss einer Debugging-Sitzung können Sie sie herunterladen, um sie später im Offline-Debugging-Tool zu analysieren. Klicken Sie dazu im linken Bereich auf Sitzung herunterladen.

Laden Sie eine Debugging-Sitzung herunter.

Beachten Sie, dass eine Debugging-Sitzung innerhalb von 24 Stunden nach Abschluss abgeschlossen wird. Wenn Sie sich die Debugging-Sitzung nach dieser Zeit ansehen möchten, sollten Sie sie vor diesem Zeitpunkt herunterladen.

Wenn Sie eine Debugging-Sitzung herunterladen, hat der Name der Download-Datei das Format "debug-{session ID}.json", wobei {session id} die ID der Debugging-Sitzung ist. Sie können die Datei jedoch bei Bedarf umbenennen.

Klassischer Proxy-Editor

So erstellen Sie eine Debugging-Sitzung im klassischen Proxy-Editor:

  1. Melden Sie sich bei der Apigee-UI an.
  2. Wählen Sie in der Hauptansicht API-Proxys aus.

  3. Wählen Sie den API-Proxy aus, den Sie debuggen möchten.

    Der Tab Übersicht wird angezeigt.

  4. Klicken Sie rechts oben auf der Seite auf den Tab Debug:

    Tabs

    Die Ansicht Debug wird angezeigt:

    Debug-Ansicht mit den Bereichen "Fehlerbehebungssitzung starten", "Letzte Fehlerbehebungssitzungen" und "Anfragen" senden

  5. Im Bereich Fehlerbehebungssitzung starten:
    1. Wählen Sie in der Drop-down-Liste Umgebung die Umgebung und die Überarbeitungsnummer des API-Proxys aus, den Sie debuggen möchten.

      2. Das folgende Beispiel zeigt den Bereich Fehlerbehebungssitzung starten:

      Bereich "Fehlerbehebungssitzung starten"

    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, der alle Transaktionen in den Fehlerbehebungsdaten 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 Fehlerbehebungssitzung starten.

      Die Apigee-Benutzeroberfläche zeigt jetzt Details zur aktuellen Fehlerbehebungssitzung einschließlich ihrer ID im Bereich Details zur Fehlerbehebung an.

      Auch wenn die Fehlerbehebungssitzung in der UI erstellt wurde, müssen Sie zuerst die Anfrage senden, um Daten zu erfassen.

      Im Bereich Fehlerbehebungsdetails können Sie Folgendes tun:

      Symbol Funktion Beschreibung
      Download-Symbol Herunterladen Laden Sie die Fehlerbehebungsdaten der aktiven Sitzung herunter, die Sie dann offline ansehen können.
      Zurück-Symbol Zurücksenden Kehren Sie zum vorherigen Bereich zurück, in dem Sie eine weitere Fehlerbehebungssitzung starten können. Die aktuelle Fehlerbehebungssitzung wird fortgesetzt, bis das Zeitlimit oder die Anzahl der Transaktionen erreicht ist.
      Symbol "Löschen" Löschen Löschen Sie die Daten der aktuell ausgewählten Fehlerbehebungssitzung. Die Sitzungsdaten werden gelöscht, die Sitzungen aber nicht beendet.

      Für eine Fehlerbehebungssitzung, die Sie in der Benutzeroberfläche starten, gilt ein standardmäßiges Zeitlimit von zehn Minuten (unterscheidet sich von einer Sitzung, die mit der API gestartet wurde).

      Sobald Sie auf Fehlerbehebungssitzung starten klicken, wird läuft die Uhr. Sie können also bis nach dem nächsten Schritt warten, bevor Sie auf Fehlerbehebungssitzung starten klicken, um die erhobene Datenmenge zu maximieren.

  6. Im Bereich Anfragen senden:
    1. Geben Sie im Feld URL den Endpunkt ein, an den Sie eine Anfrage senden möchten. Hängen Sie optional Abfragestringparameter an die URL an. Sie können nur GET-Anfragen senden.
      So ermitteln Sie die Endpunkt-URL
      1. Gehen Sie zu Admin > Umgebungen > Groups.
      2. Die URL ist der Hostname für die Umgebung, in der Sie die Sitzung zur Fehlerbehebung ausführen möchten.

      2. Im Bereich Anfragen senden werden nur die Daten für UI-basierte Anfragen angezeigt. Die Fehlerbehebung erfasst aber auch Daten für Anfragen, die nicht von der UI initiiert wurden.

    2. Klicken Sie auf Senden.

      Apigee sendet eine Anfrage an die angegebene URL. Jedes Mal, wenn Sie auf Senden klicken, protokolliert die Apigee-UI die Anfrage im Bereich Fehlerbehebungsdetails.

      Das folgende Beispiel zeigt mehrere erfolgreiche Anfragen (die zu einem HTTP-Statuscode von 200 führen):

      Erfasste Fehlerbehebungsanfragen

      Klicken Sie auf Kopieren, um die Fehlerbehebungs-ID für zukünftige Referenzen oder Abfragen zu kopieren.

      Außerdem werden inuf der Benutzeroberfläche Fehlerbehebungsdaten in den Abschnitten "Transaktionskarte" und "Phasendetails" des Felds Anfragen senden angezeigt. Außerdem werden die Bereiche "Proxy-Endpunkt", "Anfrage-Header", "Anfrageinhalt" und "Attribute" gefüllt. Beispiel:

      Erfasste Fehlerbehebungsanfragen

      Weitere Informationen zu den Phasen, der Transaktionskarte und anderen Abschnitten der Ansicht Anfragen senden finden Sie unter Fehlerbehebung lesen.

    Die Fehlerbehebungssitzung ist jetzt aktiv und erfasst Daten zu allen Anfragen, sofern sie nicht herausgefiltert werden. Die Sitzung bleibt aktiv, bis das Zeitlimit erreicht wird oder die Anzahl der in der Sitzung aufgezeichneten Anfragen überschritten wird.

  7. Sie können in der Benutzeroberfläche eine beliebige Anzahl von Sitzungen zur Fehlerbehebung erstellen. Weitere Informationen finden Sie unter Weitere Fehlerbehebungssitzung starten.

Weitere Fehlerbehebungssitzung in der Benutzeroberfläche starten

Während einer aktiven Fehlerbehebungssitzung können Sie eine weitere Sitzung in der Apigee-UI starten. Klicken Sie dazu im Bereich Fehlerbehebungsdetails auf den Zurückpfeil ():

Zurückpfeil, mit dem Sie zum Bereich „Fehlerbehebungssitzung 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 zur 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 pro Sitzung pro Message Processor aufgezeichnet werden. Da die Anzahl der Message Processors in den meisten Clustern unterschiedlich ist, können die Auswirkungen der Anzahl nicht vorhersehbar sein. Apigee empfiehlt, diese Einstellung nicht 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:

  • aktive Sitzung ist eine Fehlerbehebungssitzung, bei der das Zeitlimit noch nicht erreicht bzw. die Anzahl noch nicht überschritten wurde. Eine aktive Sitzung zeichnet weiterhin Anfragedaten für Anfragen auf, die nicht herausgefiltert werden.
  • Abgeschlossene Sitzung ist eine Fehlerbehebungssitzung, bei der entweder das Zeitlimit erreicht oder die Anzahl überschritten wurde. Eine abgeschlossene Sitzung erfasst keine Daten zu neuen Anfragen mehr und die zugehörigen Daten werden innerhalb von 24 Stunden nach dem Ende der Sitzung gelöscht.

Fehlerbehebung lesen

Das Fehlerbehebungs-Tool besteht aus zwei Hauptteilen: der Transaktionskarte und den Phasendetails:

  • Die Transaktionskarte verwendet Symbole, um jeden wichtigen Schritt zu markieren, der während einer API-Proxy-Transaktion auftritt, einschließlich Richtlinienausführung, bedingte Schritte und Übergänge. Bewegen Sie den Mauszeiger auf ein beliebiges Symbol, um eine Zusammenfassung der Informationen zu sehen. Die Schritte des Anfrageflusses werden im oberen Bereich der Transaktionszuordnung und der Schritte des Antwortflusses unten angezeigt.
  • Der Abschnitt Phasendetails des Tools enthält Informationen zur internen Verarbeitung des Proxys, einschließlich Variablen, die festgelegt oder gelesen wurden, Anfrage- und Antwortheader und vieles mehr. Klicken Sie auf ein beliebiges Symbol, um die Phasendetails für diesen Schritt aufzurufen.

Hier ist ein Beispiel einer Fehlerbehebungs-Tool-Zuordnung mit Labels für die wichtigsten Proxy-Verarbeitungssegmente:

Transaktionskarte des Fehlerbehebungs-Tools

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 für die Transaktionskarte

In der folgenden Tabelle wird der Intent der Symbole beschrieben, die in der Transaktionszuordnung angezeigt werden. Diese Symbole markieren jeden der wichtigsten Verarbeitungsschritte während des Proxyablauf.

Symbol für Transaktionskarte

Symbol der Clientanwendung Die Clientanwendung, die eine Anfrage an den ProxyEndpoint des API-Proxys sendet.
Symbol für Übergangsendpunkt Die Kreise kennzeichnen Übergangsendpunkte im Proxy-Ablauf. Sie werden angezeigt, wenn eine Anfrage vom Client eingeht, wenn die Anfrage beim Ziel eingeht, wenn die Antwort vom Ziel eingeht und wenn die Antwort an den Client zurückgegeben wird.
Symbol für Ablaufsegment

Die hohen Balken kennzeichnen den Beginn eines Ablaufsegments im API-Proxy-Ablauf. Ablaufsegmente: ProxyEndpoint-Anfrage, TargetEndpoint-Anfrage, TargetEndpoint-Antwort und ProxyEndpoint-Antwort. Ein Segment enthält den PreFlow, ConditionalFlows und PostFlow.

Weitere Informationen finden Sie unter Abläufe konfigurieren.

Symbol für Analyse

Gibt an, dass Analytics-Aktionen im Hintergrund ausgeführt wurden.

Symbol für erfüllte Bedingung

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

Beachten Sie, dass einige Bedingungen von Apigee generiert werden. Folgendes ist beispielsweise ein Ausdruck, mit dem Apigee prüft, ob im ProxyEndpoint ein Fehler aufgetreten ist:

((error.state equals PROXY_REQ_FLOW) or (error.state equals PROXY_RESP_FLOW))
Symbol für nicht erfüllte Bedingung

Ein bedingter Ablauf, der mit „false“ ausgewertet wird Eine Einführung zu bedingten Abläufen finden Sie unter Abläufe konfigurieren.

Beachten Sie, dass einige Bedingungen von Apigee generiert werden. Folgendes ist beispielsweise ein 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 XML zu JSON

Symbol für Kontingent

Richtlinien Jeder Richtlinientyp hat ein eindeutiges Symbol. Dieses ist für die Richtlinie „AssignMessage“. Mit diesen Symbolen können Sie nachvollziehen, wo Richtlinien in der richtigen Reihenfolge ausgeführt werden und ob sie erfolgreich sind. Sie können auf ein Richtliniensymbol klicken, um die Ergebnisse der Ausführung aufzurufen und zu sehen, ob sie erwartet werden oder nicht. Sie können beispielsweise sehen, ob die Nachricht richtig umgewandelt wurde oder ob sie im Cache gespeichert wird.

Ordnungsgemäß ausgeführte Richtlinien sind klar an den Häkchen zu erkennen. Bei Fehlern wird ein rotes Ausrufezeichen auf dem Symbol angezeigt.
Symbol für Server Das vom API-Proxy aufgerufene Backend-Ziel.
Symbol für Millisekunden Die Zeitangabe gibt an, wie lange die Verarbeitungszeit in Millisekunden dauert. Durch den Vergleich der verstrichenen Zeitsegmente können Sie die Richtlinien ermitteln, deren Ausführung am längsten dauert und die API-Aufrufe verlangsamen.
Symbol für Epsilon Das Epsilon ist ein Zeitraum, der kleiner als eine Millisekunde ist.
Symbol für „Deaktiviert“

Deaktiviert. Erscheint bei einem Richtliniensymbol, wenn eine Richtlinie deaktiviert ist. Richtlinien können mit der öffentlichen API deaktiviert werden. Siehe API-Proxy-Konfigurationsreferenz.
Fehlersymbol Fehler. Erscheint bei einem Richtliniensymbol, wenn die Bedingung des Richtlinienschritts als falsch ausgewertet wird (siehe Ablaufvariablen und -bedingungen) oder das BoostFault-Richtliniensymbol, wenn eine BoostFault-Richtlinie ausgeführt wird.
Symbol für „Übersprungen“ Übersprungen. Erscheint in einem Richtliniensymbol, wenn die Richtlinie nicht ausgeführt wurde, da die Schrittbedingung als „false“ ausgewertet wurde. Weitere Informationen finden Sie unter Ablaufvariablen und Bedingungen.

Phasendetails verstehen

Der Teil Phasendetails des Tools teilt Ihnen mit jedem Verarbeitungsschritt viel über den Status Ihres Proxys mit. Im Folgenden finden Sie einige Details, die in den Phasendetails angegeben werden. Klicken Sie auf ein beliebiges Symbol im Fehlerbehebungs-Tool, um Details für den ausgewählten Schritt anzuzeigen. Mit den Schaltflächen Weiter und Zurück können Sie von einem Schritt zu einem anderen wechseln.

Phasendetails Beschreibung
Proxy-Endpunkt Gibt an, welcher ProxyEndpoint-Ablauf für die Ausführung ausgewählt wurde. Ein API-Proxy kann mehrere benannte Proxy-Endpunkte haben.
Variablen

Listet die Ablaufvariablen auf, die von einer Richtlinie gelesen und einem Wert zugewiesen wurden, siehe auch Ablaufvariablen verwenden.

Hinweis:

  • Ein Gleichheitszeichen (=) gibt den Wert an, der der Variable zugewiesen wurde.
  • Ein durchgestrichenes Gleichheitszeichen (≠) gibt an, dass der Variable kein Wert zugewiesen werden konnte, da sie schreibgeschützt ist oder ein Fehler bei der Richtlinienausführung aufgetreten ist.
  • Ein leeres Feld gibt an, dass der Variablenwert gelesen wurde.
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 nicht standardmäßig 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.
PostClientFlow Zeigt Informationen zum PostClientFlow an, der nach der Anfrage an die anfragende Clientanwendung ausgeführt wird. Nur MessageLogging-Richtlinien können an den PostClientFlow angehängt werden. Der PostClientFlow wird derzeit hauptsächlich zum Messen des Zeitintervalls zwischen den Start- und Endzeitstempeln für die Antwortnachricht verwendet.

Apigee API

Um eine Fehlerbehebungssitzung mit der API zu erstellen, 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

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 verwendeten Umgebungsvariablen findet sich 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 gegebenenfalls in den Daten der Fehlerbehebungssitzung gespeichert.

Weitere Informationen finden Sie unter Create debug session API erstellen.

Länge einer Fehlerbehebungssitzung mithilfe der API festlegen

Um die Länge einer Fehlerbehebungssitzung mithilfe der API festzulegen, fügen Sie Folgendes als Nutzlast in Ihre Anfrage zur 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 das timeout einer Sitzung nur in Debug-Sitzungserstellungsanfragen festlegen; Sie können die Dauer einer Sitzung nicht mehr ändern, nachdem Sie die Sitzung erstellt haben.

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

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.

Klassische Apigee-UI

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.

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

Weitere 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 für 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.

Neuer Proxy-Editor

So zeigen Sie Debugging-Sitzungen mit dem neuen Proxy-Editor an:

  1. Wenn Sie die Apigee-UI in der Cloud Console verwenden: Wählen Sie Proxy-Entwicklung > API-Proxys aus.

    Wenn Sie das klassische Apigee-Benutzeroberfläche nutzen: Auswählen Entwickeln > API-Proxys und in der Proxys-Bereich wählen Sie die Umgebung für den Proxy aus, den Sie debuggen möchten.

  2. Wählen Sie den Proxy aus, den Sie debuggen möchten.
  3. Klicken Sie auf den Tab Debugging.
  4. Die aktuellen Debugging-Sitzungen zeigt eine Liste der verfügbaren Debugging-Sitzungen an.

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

Klassischer Proxy-Editor

So zeigen Sie Debugging-Sitzungen mit dem klassischen Proxy-Editor an:

  1. Melden Sie sich bei der Apigee-UI an.
  2. Wählen Sie in der Hauptansicht API-Proxys aus.
  3. Wählen Sie den Proxy aus, den Sie debuggen möchten.
  4. Klicken Sie rechts oben in der Ansicht Bereitstellungen auf den Tab Fehlerbehebung.
  5. Im Bereich Letzte Fehlerbehebungssitzungen:
    1. Wählen Sie in der Drop-down-Liste Umgebung die Umgebung des API-Proxys aus, dessen Fehlerbehebungssitzung Sie aufrufen möchten.
    2. Wählen Sie in der Drop-down-Liste Rev die Überarbeitungsnummer des API-Proxys aus, dessen Fehlerbehebungssitzung Sie aufrufen möchten.

    In der Apigee-Benutzeroberfläche wird eine Liste der verfügbaren Fehlerbehebungssitzungen angezeigt.

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

    Die Apigee-UI lädt die Fehlerbehebungssitzung und füllt den Bereich Anfragen senden mit den Fehlerbehebungsdaten.

Ansichtsoptionen in der Benutzeroberfläche auswählen

In der Apigee-Benutzeroberfläche können Sie die Ansichtsoptionen für die Fehlerbehebungssitzung auswählen.

Optionsliste anzeigen

Option Beschreibung
Deaktivierte Richtlinien einblenden. Deaktivierte Richtlinien anzeigen Richtlinien können mit der öffentlichen API deaktiviert werden. Siehe API-Proxy-Konfigurationsreferenz.
Übersprungene Phasen einblenden Sie können alle übersprungenen Phasen einblenden. Eine übersprungene Phase tritt auf, wenn die Richtlinie nicht ausgeführt wurde, da die Schrittbedingung als „false“ ausgewertet wurde. Weitere Informationen finden Sie unter Bedingungen mit Ablaufvariablen.
Alle FlowInfos einblenden Übergänge innerhalb eines Ablaufsegments darstellen.
Ausgewählte Phase automatisch vergleichen Vergleicht die ausgewählte Phase mit der vorherigen. Deaktivieren Sie diese Option, damit nur die ausgewählte Phase angezeigt wird.
Variablen anzeigen Variablen anzeigen, die gelesen und/oder denen ein Wert zugewiesen wurde.
Attribute ansehen Attribute stellen den internen Status des API-Proxys dar. (Standardmäßig ausgeblendet.)

Apigee API

Mit der API haben Sie folgende Möglichkeiten:

Alle Fehlerbehebungssitzungen mit der API anzeigen

Um alle aktuellen Fehlerbehebungssitzungen anzuzeigen, die für eine API-Proxy-Überarbeitung in einer Umgebung definiert wurden, 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 verwendeten Umgebungsvariablen 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 verwendeten Umgebungsvariablen 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 verwendeten Umgebungsvariablen 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.

Fehlerbehebungsdaten enthalten alle Informationen über die Anfrage und die Antwort für jeden Teil des Ablaufs in einem proprietären JSON-Format. Sie können diese Daten speichern und später im Offline Debug-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.

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.

Neuer Proxy-Editor

Klicken Sie zum Herunterladen der aktuellen Debugging-Sitzung im neuen Proxy-Editor im linken Bereich der Debugging-Ansicht auf Download Session (Sitzung herunterladen).

Laden Sie eine Debugging-Sitzung herunter.

Beachten Sie, dass eine Debugging-Sitzung innerhalb von 24 Stunden nach Abschluss abgeschlossen wird. Wenn Sie die Debugging-Sitzung nach dieser Zeit aufrufen möchten, müssen Sie sie vor diesem Zeitpunkt herunterladen.

Klassischer Proxy-Editor

So laden Sie die Daten der aktuellen Debugging-Sitzung über den klassischen Proxy-Editor herunter:

  • Aktive Sitzung: Klicken Sie im Bereich Fehlerbehebungsdetails auf das Downloadsymbol (Download-Symbol).
  • Vorherige Sitzung: Klicken Sie im Bereich Letzte Fehlerbehebungssitzungen auf den Namen der Sitzung, wie unter Fehlerbehebungssitzungen ansehen beschrieben. Klicken Sie dann im Bereich Fehlerbehebungsdetails auf Download-Symbol.

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

Klassische Apigee-UI

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

Apigee API

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

Beispiel:

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

Datenbeispiele herunterladen

Im folgenden Beispiel wird das Metadatenobjekt DebugSession 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 Fehlerbehebungssitzung keine Anfragen enthielt, ist das Array Message leer, wie das folgende Beispiel zeigt:

{
  "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.

Neuer Proxy-Editor

So löschen Sie eine Debugging-Sitzung im neuen Proxy-Editor:

  1. Wählen Sie die Zeile für die Sitzung aus, die Sie löschen möchten.
  2. Klicken Sie auf das Dreipunkt-Menü am Ende der Zeile und wählen Sie Löschen aus.

Klassischer Proxy-Editor

Klicken Sie im Bereich Fehlerbehebungsdetails für die Fehlerbehebungssitzung auf Symbol &quot;Löschen&quot;.

Apigee 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 verwendeten Umgebungsvariablen finden Sie unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

Bei Erfolg ist der Antworttext leer.

Daten zu einer Fehlerbehebungssitzung werden nur 24 Stunden lang gespeichert. Wenn Sie sie nicht vorher löschen, löscht Apigee die Daten.