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 Debugging-Tool ist einfach zu verwenden. Sie starten eine Debugging-Sitzung, führen dann einen API-Aufruf an Apigee aus und sehen sich die Anfrage- und Antwortdaten in der Benutzeroberfläche an.

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

Apigee Cloud Console

Debug v2 (neu)

So erstellen Sie eine Fehlerbehebungssitzung:

  1. Rufen Sie in der Google Cloud Console die Seite 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 Fehlerbehebungssitzung 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 des Bildes klicken neue Debug-Sitzung

Die Debugging-Sitzung zeichnet Anfragen zehn Minuten lang auf oder bis 15 Anfragen erfasst wurden. Sie können das 10‑Minuten-Limit anpassen, wenn Sie die Fehlerbehebungssitzung 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 des Bildes 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.

Debug v1

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

  1. Melden Sie sich in der Google Cloud Console an.

  2. Wählen Sie Proxy-Entwicklung > API-Proxys aus.

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

  4. Klicken Sie oben links im Fenster auf den Tab Debugging.
  5. 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 lang auf oder bis 15 Anfragen erfasst wurden. Sie können das 10‑Minuten-Limit anpassen, wenn Sie die Fehlerbehebungssitzung 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 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.

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

Klassische UI

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

      In der Apigee-Benutzeroberfläche werden jetzt im Bereich Details zur Fehlerbehebung Details zur aktuellen Fehlerbehebungssitzung einschließlich ihrer ID angezeigt.

      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 Debugging-Daten der aktiven Sitzung herunter, die Sie dann offline ansehen können.
      Zurück-Symbol Zurück 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 Debugging-Sitzung, die Sie in der Benutzeroberfläche starten, gilt ein standardmäßiges Zeitlimit von 10 Minuten. Für eine mit der API gestartete Sitzung gilt ein anderes Zeitlimit.

      Sobald Sie auf Debugging-Sitzung starten klicken, wird die Uhr gestartet. Sie können also bis nach dem nächsten Schritt warten, bevor Sie auf Debugging-Sitzung 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 in 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.

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

Proxy-URL kopieren

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

Apigee Cloud Console

Debug v2 (neu)

So finden und kopieren Sie die Proxy-URL:

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

    1. Rufen Sie in der Google Cloud Console die Seite 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 dann auf Aktualisieren.
  3. Wenn keine Fehlerbehebungssitzung 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.

Debug v1

So finden und kopieren Sie die Proxy-URL:

  1. Rufen Sie in der Google Cloud Console Verwaltung > Umgebungen > Umgebungsgruppen auf.
  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 bearbeiten Sie die Proxy-URL:

  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.

Klassische UI

So finden und kopieren Sie die Endpunkt-URL:

  1. Wechseln Sie in der Apigee-Benutzeroberfläche zu Administrator > Umgebungen > Gruppen. Sie werden zur Google Cloud Console weitergeleitet, auf die Seite Verwaltung > Umgebungen > 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 bearbeiten Sie die Ziel-URL:

  1. Suchen Sie die Endpunkt-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.

Apigee Cloud Console

Während einer aktiven Fehlerbehebungssitzung 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 „Fehlerbehebungssitzung starten“ zurückkehren

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

Klassische UI

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 in einer einzelnen 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:

  • Eine 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.
  • Eine abgeschlossene Sitzung ist eine Debugging-Sitzung, bei der entweder das Zeitlimit erreicht oder die Anzahl überschritten wurde. Bei einer abgeschlossenen Sitzung werden keine Daten zu neuen Anfragen mehr erfasst und die zugehörigen Daten werden innerhalb von 24 Stunden nach dem Ende der Sitzung gelöscht.

Debugging-Sitzung lesen

In diesem Abschnitt erhalten Sie einen Überblick über eine Debugging-Sitzung.

Siehe auch:

Apigee Cloud Console

Debug v2 (neu)

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

  • Im Transaktionsbereich werden Symbole verwendet, 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.
  • 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 beliebiges Symbol, um die Phasendetails für diesen Schritt aufzurufen.

Debug v1

In dieser Version des Debugging-Tools wird ein Gantt-Diagramm verwendet, um die Schritte in der Anfrage und Antwort darzustellen.

Klassische UI

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.

Transaktionsbereich

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

Apigee Cloud Console

Debug v2 (neu)

Hier ist ein Beispiel für den Transaktionsbereich des Fehlerbehebungs-Tools mit Labels für die wichtigsten Proxy-Verarbeitungssegmente:

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-Clients

Debug v1

Wenn Sie die Details einer Transaktion (Anfrage und Antwort) in der Debugging-Ansicht ansehen möchten, klicken Sie auf die Zeile für die Transaktion. Im rechten Bereich wird dann ein Gantt-Diagramm angezeigt, das die Schritte in der Anfrage und Antwort enthält.

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

Klassische UI

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-Clients

Legende für den Transaktionsbereich

Im Folgenden werden die Symbole im Transaktionsbereich beschrieben:

Apigee Cloud Console

Debug v2 (neu)

In diesem Abschnitt werden die Symbole im Transaktionsbereich beschrieben:

Richtliniensymbole

Jeder Richtlinientyp hat ein eindeutiges Symbol. 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.

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 von den Standardrichtlinien bereitgestellt werden.

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

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 Richtlinienname zu sortieren.
  • Geben Sie einen Suchbegriff ein, um nach einem Richtliniennamen zu suchen.

Richtlinientyp

Richtlinienkategorie

Symbol Name Typ Kategorie
manage_search ParseDialogflowRequest-Richtlinie Erweiterbar Dialogablauf
chat_add_on SetDialogflowResponse-Richtlinie Erweiterbar Dialogablauf
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 die JavaCallout-Richtlinie JavaCallout-Richtlinie Erweiterbar Erweiterung
Symbol für die JavaScript-Richtlinie JavaScript-Richtlinie Erweiterbar Erweiterung
add_notes MessageLogging-Richtlinie Erweiterbar Erweiterung
chat_paste_go PublishMessage-Richtlinie Standard Erweiterung
Symbol für die 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
Bericht 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
Verriegeln AccessControl-Richtlinie Standard Sicherheit
sicherheit BasicAuthentication-Richtlinie Erweiterbar Sicherheit
connect_without_contact CORS-Richtlinie Standard Sicherheit
Verriegeln DecodeJWS-Richtlinie Erweiterbar Sicherheit
Verriegeln DecodeJWT-Richtlinie Standard Sicherheit
Passkey DeleteOAuthV2Info-Richtlinie Erweiterbar Sicherheit
Verriegeln GenerateSamlAssertion-Richtlinie Erweiterbar Sicherheit
Verriegeln GenerateJWS-Richtlinie Erweiterbar Sicherheit
Verriegeln GenerateJWT-Richtlinie Erweiterbar Sicherheit
Passkey GetOAuthV2Info-Richtlinie Erweiterbar Sicherheit
Verriegeln 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
Verriegeln ValidateSamlAssertion-Richtlinie Erweiterbar Sicherheit
key VerifyAPIKey-Richtlinie Erweiterbar Sicherheit
Passkey VerifyIAM-Richtlinie Erweiterbar Sicherheit
Verriegeln VerifyJWS-Richtlinie Erweiterbar Sicherheit
Verriegeln VerifyJWT-Richtlinie Standard Sicherheit
sicherheit XMLThreatProtection-Richtlinie Erweiterbar Sicherheit
im Cache InvalidateCache-Richtlinie Erweiterbar Trafficverwaltung
im Cache LookupCache-Richtlinie Erweiterbar Trafficverwaltung
im Cache PopulateCache-Richtlinie Erweiterbar Trafficverwaltung
bar_chart_4_bars Kontingentrichtlinie Erweiterbar Trafficverwaltung
repartition ResetQuota-Richtlinie Erweiterbar Trafficverwaltung
im Cache ResponseCache-Richtlinie Erweiterbar Trafficverwaltung
emergency_home SpikeArrest-Richtlinie Standard Trafficverwaltung

Andere Symbole

In der folgenden Tabelle wird der Zweck der anderen Symbole beschrieben, die im Transaktionsbereich angezeigt werden. Diese Symbole markieren jeden der wichtigsten Verarbeitungsschritte während des Proxyablauf.

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 Clientanwendung, die eine Anfrage an den ProxyEndpoint des API-Proxy sendet.
circle Übergangsendpunkt Standardtransaktion Der Kreis kennzeichnet Ü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.
stat_0 Ablaufsegment Standardtransaktion

Die Raute kennzeichnet 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 Bedingte Abläufe.

Symbol für erfüllte Bedingung Bedingter Ablauf „true“ Standardtransaktion

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

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 Bedingter Ablauf „false“ 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. 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 Ablaufinformationen Ablaufinformationen Standardtransaktion Stellt Kontextinformationen zur API-Proxy-Ausführung dar, die je nach Punkt im Ablauf variieren. Dazu gehören Details zur Proxykonfiguration, zum aktuellen Ausführungsstatus (z.B. PreFlow, PostFlow, Flow-Hooks), Details zur Richtlinienausführung und Variablen, die während der Richtlinienausführung ausgefüllt werden, um den jeweiligen Status des Proxys zu diesem Zeitpunkt anzugeben.
done_all Workflow-Ausführung Standardtransaktion Markiert den Beginn oder das Ende der Ausführung eines Ablaufs und gibt den Zeitraum eines bestimmten Ablaufsegments an, um die Ablaufgrenzen visuell abzugrenzen und die Reihenfolge der Ablaufausführung anzugeben.
commit Workflow-Verarbeitung Standardtransaktion Gibt die aktive Verarbeitung in einem Ablauf an und stellt den Zeitraum dar, in dem Richtlinien und 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 Der Backend-Dienst, der die Anfrage erhält. Das vom API-Proxy aufgerufene Backend-Ziel.
Symbol für „Deaktiviert“ Deaktiviert Schrittstatus Erscheint bei einem Richtliniensymbol, wenn eine Richtlinie deaktiviert ist. Richtlinien können mit der öffentlichen API deaktiviert werden. Weitere Informationen finden Sie in der Referenz zur API-Proxy-Konfiguration.
Fehlersymbol Fehler Schrittstatus Erscheint bei einem Richtliniensymbol, wenn die Bedingung des Richtlinienschritts als falsch ausgewertet wird (siehe Bedingungen mit Ablaufvariablen) oder das RaiseFault-Richtliniensymbol, wenn eine RaiseFault-Richtlinie ausgeführt wird.
Symbol für „Übersprungen“ Übersprungen Schrittstatus Erscheint bei einem Richtliniensymbol, wenn die Richtlinie nicht ausgeführt wurde, da die Schrittbedingung als „false“ ausgewertet wurde. Weitere Informationen finden Sie unter Bedingungen mit Ablaufvariablen.

Debug v1

In dieser Version wird ein Gantt-Diagramm verwendet, um die Schritte in der Anfrage und Antwort darzustellen. Es ist keine Legende vorhanden.

Klassische UI

In der folgenden Tabelle wird der Zweck 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 RaiseFault-Richtliniensymbol, wenn eine RaiseFault-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.

Bereich „Phasendetails“

Im Bereich „Phasendetails“ wird der Status Ihres Proxys bei jedem Verarbeitungsschritt angezeigt.

Apigee Cloud Console

Debug v2 (neu)

Im Bereich „Phasendetails“ erfahren Sie viel über den Status Ihres Proxys in den einzelnen Verarbeitungsschritten. Hier sind einige der angegebenen Details. 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.

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

Phasendetails Beschreibung
Variablen

Listet die Ablaufvariablen auf, die von einer Richtlinie gelesen und einem Wert zugewiesen wurden. Siehe auch 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 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.

Debug v1

Klicken Sie im Gantt-Diagramm auf Schritte, um die Phasendetails aufzurufen, oder verwenden Sie die Schaltflächen > Weiter oder < Zurück, um eine Debugging-Sitzung durchzugehen.

Klassische UI

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.

Zeitachse

Die Zeitachse 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.

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

Apigee Cloud Console

Debug v2 (neu)

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

Debug v1

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

Klassische UI

Zum Vergrößern des Bildes klicken Zeitachse in der klassischen Benutzeroberfläche

Gruppen maximieren und minimieren

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

Apigee Cloud Console

Debug v2 (neu)

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

In jeder Gruppe werden die relevanten Richtlinien, Bedingungen, gemeinsamen Abläufe und Ablaufinformationen deutlich angezeigt.

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

Im Transaktionsbereich sind folgende Aktionen verfügbar:

Element Name Beschreibung
Schieberegler „Alle maximieren“
<img <="" alt="collapse all slider" 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 zum Maximieren der Gruppe
Symbol zum Minimieren der Gruppe 		Maximieren
Minimieren		 Gruppe maximieren oder minimieren

Siehe auch:

Debug v1

Das Ein- und Ausblenden von Gruppen ist in dieser Version nicht möglich.

Klassische UI

Das Ein- und Ausblenden von Gruppen ist in dieser Version nicht möglich.

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

Apigee Cloud Console

Debug v2 (neu)

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

Wichtige Hinweise:

  • Bei der Suche wird nicht zwischen Groß- und Kleinschreibung unterschieden.
  • Die Suche bezieht sich auf eine einzelne Transaktion. Es wird also nicht in allen Transaktionen der gesamten Debugging-Sitzung gesucht.
  • Bei der Suche werden minimierte Bereiche maximiert, es werden jedoch keine Informationen zu Knoten angezeigt, die durch die Auswahl von Ansichtsoptionen herausgefiltert wurden.

So funktioniert die Suche.

  1. Geben Sie Text in das Suchfeld ein.

  2. Drücken Sie die Eingabetaste.

    Die Suchergebnisse werden im Transaktionsbereich 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 Benutzeroberfläche von Debug v2

Debug v1

Die Suche ist in dieser Version nicht verfügbar.

Klassische UI

Die Suche ist in dieser Version nicht verfügbar.

Zoom

Mit der Zoomfunktion können Sie die Ansicht des Transaktionsbereichs anpassen.

Apigee Cloud Console

Debug v2 (neu)

Mit der Zoomfunktion wird die Ansicht des Transaktionsbereichs so gesteuert:

Zum Vergrößern des Bildes klicken Zoomsteuerelemente für Debugging 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

Debug v1

Zoom ist in dieser Version nicht verfügbar.

Klassische UI

Zoom ist in dieser Version nicht verfügbar.

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 Cloud Console

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. Sie können auch Benutzerdefinierter Filter auswählen, um einen neuen Filter mit der Filtersyntax zu erstellen.

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

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.

Apigee Cloud Console

Debug v2 (neu)

So zeigen Sie Debugging-Sitzungen mit der Google Cloud Console an:

  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. Im Bereich Letzte 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.

Debug v1

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

  1. Melden Sie sich in der Google Cloud Console an.

  2. Wählen Sie Proxy-Entwicklung > API-Proxys aus.

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

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

Klassische UI

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 Debug.
  5. Im Bereich Letzte Fehlerbehebungssitzungen:
    1. Wählen Sie in der Drop-down-Liste Umgebung die Umgebung des API-Proxy aus, dessen Fehlerbehebungssitzung Sie aufrufen möchten.
    2. Wählen Sie in der Drop-down-Liste Überarbeitung 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.

API

Mit der API haben Sie folgende Möglichkeiten:

Alle Fehlerbehebungssitzungen mit der API anzeigen

Wenn Sie alle aktuellen Fehlerbehebungssitzungen anzeigen möchten, 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 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.

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.

Ansichtsoptionen in der Benutzeroberfläche auswählen

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

Apigee Cloud Console

Wählen Sie im Bereich Ansichtsoptionen Optionen aus oder heben Sie die Auswahl auf, um die Ansichtsoptionen für die Debugging-Sitzung festzulegen. Diese Ansichtsoptionen werden für jeden Nutzer über Debug-Sitzungen hinweg beibehalten.

Zum Vergrößern des Bildes 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 Sie können alle übersprungenen Richtlinien einblenden. Eine übersprungene Richtlinie 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 Ablaufinformationen anzeigen Übergänge innerhalb eines Ablaufsegments darstellen.
Alle Ablaufbedingungen anzeigen Stellen Sie die Bedingungen dar, die für jeden Ablauf ausgewertet wurden.

Klassische UI

Wenn Sie die Ansichtsoptionen für die Debugging-Sitzung auswählen möchten, aktivieren oder deaktivieren Sie Optionen im Bereich Ansichtsoptionen:

Optionsliste anzeigen

Option Beschreibung
Deaktivierte Richtlinien einblenden. Deaktivierte Richtlinien anzeigen Richtlinien können mit der öffentlichen API deaktiviert werden. Weitere Informationen finden Sie in der Referenz zur API-Proxy-Konfiguration.
Ü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 Ablaufinformationen anzeigen Ü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.)

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 Fehlerbehebungssitzung anzusehen.

Apigee Cloud Console

Debug v2 (neu)

Wenn Sie die aktuelle Debugging-Sitzung in der Google Cloud Konsole herunterladen möchten, klicken Sie in der Debugging-Ansicht auf Download (Herunterladen).

Debug v1

Klicken Sie zum Herunterladen der aktuellen Debugging-Sitzung im linken Bereich der Debugging-Ansicht auf Sitzung herunterladen.

Laden Sie eine Debugging-Sitzung herunter.

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

Klassische UI

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.

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 Cloud Console

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

Klassische 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

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.

Apigee Cloud Console

Debug v2 (neu)

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.

Debug v1

So löschen Sie eine Debugging-Sitzung:

  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.

Klassische UI

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

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 vorher löschen, löscht Apigee die Daten.