Konzepte

Auf dieser Seite werden die Clientrollen und das Datenmodell der Stackdriver Debugger-API sowie die von dieser unterstützten Vorgänge beschrieben.

Clientrollen

Die API definiert zwei Clientrollen, Agents und Debugger-Clients.

Agents

Ein Agent ist ein Programm, das auf demselben System wie die Anwendung der zu debuggenden Komponente ausgeführt wird. Der Agent sendet Statusdaten – wie die Werte von Programmvariablen und den Aufrufstapel – an Stackdriver Debugger, wenn der Code an einem Haltepunkt ausgeführt wird.

Für jede zu debuggende Komponente können mehrere Agents eingerichtet werden. Sie können beispielsweise eine Anwendung haben, die sich aus mehreren ausführbaren Aufgaben zusammensetzt. Dann wird für jede Aufgabe ein Agent eingerichtet, aber alle zusammen bilden die zu debuggende Komponente. Wenn Sie hingegen mehrere Versionen einer Anwendung ausführen, gilt jede von diesen als separate zu debuggende Komponente, deren Fehler auch separat behoben werden.

Agents können zum Beispiel die von Google bereitgestellten Debugger-Agents sein. Diese können Sie für Anwendungen nutzen, die in Java oder Go geschrieben sind und in Google Compute Engine ausgeführt werden.

Debugger-Clients

Ein Debugger-Client ist eine Anwendung, mit der Nutzer Haltepunkte einstellen und entfernen sowie Statusdaten abrufen können, die an diesen Haltepunkten erfasst werden (auch Snapshot genannt). Ein Debugger-Client ist zum Beispiel das Tool Stackdriver Debugger, das in der Google Cloud Platform Console ausgeführt wird. Ein weiteres Beispiel ist eine IDE, in der Sie eine Debugger-Funktion hinzufügen können.

Datenmodell

Das API-Datenmodell liefert die Entitäten für zu debuggende Komponenten und Haltepunkte sowie die Arten von Statusdaten, die ein Agent erfassen kann, wenn der Code an einem Haltepunkt ausgeführt wird.

Zu debuggende Komponenten

Eine zu debuggende Komponente ist eine Anwendung, an der ein Nutzer Fehler beheben möchte. Wie oben bereits erwähnt, gelten alle Aufgaben, die eine Anwendung enthält, als die gleiche zu debuggende Komponente mit derselben ID. Unterschiedliche Versionen ein und derselben Anwendung hingegen gelten als separate zu debuggende Komponenten. Zu debuggende Komponenten werden in der API mit der Entität Debuggee (REST oder RPC) repräsentiert.

Haltepunkte

Ein Haltepunkt ist eine Entität, die dem Agent mitteilt, wo und wann er Statusdaten einer Anwendung erfassen soll. Außerdem speichert der Haltepunkt die Daten bei ihrer Erfassung auch selbst.

Ein Haltepunkt legt Folgendes fest:

  • Die zu prüfende Stelle im Quellcode der zu debuggenden Komponente
  • Einen bedingungsabhängigen Ausdruck, den der Agent verwendet, um zu bestimmen, wann die Statusdaten erfasst werden
  • Die nach der Datenerfassung auszuwertenden Ausdrücke

Die von einer zu debuggenden Komponente erfassten Daten können folgende sein:

  • Werte von Variablen des Programms
  • Aufrufstapel
  • Werte von Ausdrücken, die ausgewertet wurden

Haltepunkte werden durch die Entität Breakpoint (RPC oder REST) repräsentiert.

Quellorte

Ein Quellort definiert eine bestimmte Stelle in der Zielanwendung anhand ihres Dateipfads und ihrer Zeilennummer. Quellorte werden durch die Entität SourceLocation (RPC oder REST) repräsentiert.

Variablen

Eine Variable umfasst den Inhalt eines Programmobjekts (benannt oder unbenannt) zu dem Zeitpunkt, zu dem die Statusdaten von einem Agent erfasst wurden. Beispielsweise kann sie den Wert einer lokalen Variablen vom Typ integer oder eine beliebige Anzahl von Mitgliedern enthalten, die ihrerseits auch Variablen sind. Variablen werden durch die Entität Variable (RPC oder REST) repräsentiert.

Statusmeldungen

Eine Statusmeldung enthält Informationen über den Status von Haltepunkten und/oder Variablen. So kann zum Beispiel ein Haltepunkt, der an einem ungültigen Quellort eingerichtet wurde, eine Statusmeldung beinhalten, die einen Fehler signalisiert. Statusmeldungen werden durch die Entität StatusMessage (RPC oder REST) repräsentiert.

Formatmeldungen

Die Formatmeldung ist der in der Statusmeldung enthaltene Text. Formatmeldungen werden durch die Entität FormatMessage (RPC oder REST) repräsentiert.

Vorgänge

Die Controller- und Debugger-Oberflächen stellen eine Reihe von Vorgängen sowohl für Agents als auch für Debugger-Clients bereit.

Vorgänge des Agents

In der Controller-Oberfläche können Agents folgende Vorgänge ausführen:

Vorgang Beschreibung REST RPC
Anmelden Meldet die zu debuggende Komponente beim Controller-Dienst an. register RegisterDebuggee
Aktive Haltepunkte auflisten Gibt eine Liste aller aktiven Haltepunkte der jeweiligen zu debuggenden Komponente aus. list ListActiveBreakpoints
Aktive Haltepunkte aktualisieren Aktualisiert die Statusdaten – zum Beispiel Programmvariablen und den Aufrufstapel – der Anwendung am jeweiligen Haltepunkt. update UpdateActiveBreakpoint

Eine typische Sequenz von Vorgängen für einen Agent sieht folgendermaßen aus:

  1. Anwendungen werden vom Agent nach ihrem Start mit der Methode register oder RegisterDebugger als zu debuggende Komponenten angemeldet.

  2. In bestimmten Abständen ruft der Agent list oder ListActiveBreakpoints auf, um die aktuell eingestellten Haltepunkte zu erfassen.

  3. Sobald in der Anwendung eine Stelle im Code erreicht wird, an der ein Haltepunkt eingerichtet ist, erfasst der Agent die Statusdaten – zum Beispiel den Wert von Programmvariablen oder den Aufrufstapel – und sendet sie mit update oder UpdateActiveBreakpoint an den Controllerdienst.

Vorgänge des Debugger-Clients

Über die Debugger-Oberfläche können Debugger-Clients folgende Vorgänge ausführen:

Vorgang Beschreibung REST RPC
Zu debuggende Komponenten auflisten Listet die zu debuggenden Komponenten auf, an denen ein Nutzer des Clients Haltepunkte einrichten kann. list ListDebuggees
Haltepunkt festlegen Stellt einen Haltepunkt ein. set SetBreakpoint
Haltepunkte auflisten Gibt eine Liste der Haltepunkte aus, auf die der aktuelle Nutzer zugreifen kann. list ListBreakpoints
Haltepunkt aufrufen Liefert Informationen zum Haltepunkt, geordnet nach den IDs der zu debuggenden Komponenten und der Haltepunkte. get GetBreakpoint
Haltepunkt löschen Löscht den markierten Haltepunkt. delete DeleteBreakpoint

Eine typische Sequenz von Vorgängen für einen Debugger-Client sieht folgendermaßen aus:

  1. Wenn ein Nutzer den Debugger-Workflow startet – zum Beispiel durch das Öffnen der Debugger-Ansicht in der UI der Client-Anwendung – ruft der Client die Methode list oder ListDebugees auf, um eine Liste der Anwendungsversionen zu erhalten, die für die Fehlerbehebung verfügbar sind, sodass der Nutzer aus dieser Liste wählen kann.

  2. Wenn der Nutzer in der UI einen Haltepunkt erstellt, ruft die Client-Anwendung den Vorgang set oder SetBreakpoint auf, um den Haltepunkt einzurichten.

  3. In bestimmten Intervallen ruft die Client-Anwendung get oder GetBreakpoint auf, um zu prüfen, ob eine zu debuggende Komponente am Haltepunkt Code ausgeführt und der Agent die Statusdaten für den Haltepunkt aktualisiert hat. Ist dies der Fall, zeigt die Client-Anwendung dem Nutzer die Statusdaten an.

  4. Löscht der Nutzer den Haltepunkt in der UI, ruft der Client delete oder DeleteBreakpoint auf.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Stackdriver Debugger-Dokumentation