Google Stackdriver Debug, Trace, Logging und Logpoints verwenden

In dieser Anleitung wird Google Stackdriver vorgestellt. Damit können Sie mit Ihren Google Cloud Platform-Anwendungen Folgendes tun:

  • Sie erstellen einen Snapshot zur Fehlerbehebung, während die Anwendung in App Engine, Compute Engine und Kubernetes Engine ausgeführt wird.
  • Sie rufen Anwendungslogs auf.
  • Richten Sie Messwerte ein, überwachen Sie sie und erhalten Sie Benachrichtigungen.
  • Sie verfolgen Ihre API-Aufrufe und erhalten eine detaillierte Aufschlüsselung der Antwortzeiten und potenziellen Engpässe in Ihrem Code.
  • Fügen Sie einer laufenden Anwendung Logpoints hinzu, ohne die App bereitstellen zu müssen. Das ist eine wirklich einzigartige (und hoffentlich nützliche) Funktion.

In dieser Anleitung gehen wir so vor:

  1. Google Cloud Platform-Projekt erstellen (speziell App Engine)
  2. Google Cloud Platform-Projekt-Quellcode-Repository einrichten
  3. Den Standardquellcode der Python-Gästebuchanwendung von GitHub verwenden
  4. Code bereitstellen
  5. Debug-Snapshots der ausgeführten Anwendung erstellen
  6. Logs und Anwendungsaufruf-Traces ansehen
  7. Logpoints zur aktuell ausgeführten Anwendung hinzufügen Diese Funktion wurde ursprünglich in diesem Blogpost behandelt : Add Application Logs to an application with no restarts

Legen wir los!

Dieser Inhalt wurde ursprünglich von Romin Irani erstellt und hier gepostet.

Einrichtung der Umgebung im eigenen Tempo

Wenn Sie noch kein Google-Konto (Gmail oder Google Apps) haben, müssen Sie eins erstellen. Melden Sie sich in der Google Cloud Platform Console (console.cloud.google.com) an und erstellen Sie ein neues Projekt:

Screenshot vom 10.02.2016, 12:45:26.png

Notieren Sie sich die Projekt-ID, also den projektübergreifend nur einmal vorkommenden Namen eines Google Cloud-Projekts. Der oben angegebene Name ist bereits vergeben und kann leider nicht mehr verwendet werden. Sie wird in diesem Codelab später als PROJECT_ID bezeichnet.

Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Google Cloud-Ressourcen verwenden zu können.

Dieses Codelab sollte Sie nicht mehr als ein paar Dollar kosten, aber es könnte mehr sein, wenn Sie sich für mehr Ressourcen entscheiden oder wenn Sie sie laufen lassen (siehe Abschnitt „Bereinigen“ am Ende dieses Dokuments).

Neuen Nutzern der Google Cloud Platform steht eine kostenlose Testversion mit einem Guthaben von 300$ zur Verfügung.

Google Cloud Shell

In diesem Codelab verwenden wir Google Cloud Shell, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Auf dieser Debian-basierten virtuellen Maschine sind alle erforderlichen Entwicklungstools installiert. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf der Google Cloud, wodurch Netzwerkleistung und Authentifizierung deutlich verbessert werden. Für dieses Codelab benötigen Sie also nur einen Browser (es funktioniert auch auf einem Chromebook).

Klicken Sie zum Aktivieren von Google Cloud Shell einfach rechts oben in der Entwicklerkonsole auf die Schaltfläche. Das Bereitstellen und Herstellen einer Verbindung zur Umgebung dauert nur wenige Augenblicke:

activateCloudShell.png

Akzeptieren Sie dann die Nutzungsbedingungen und klicken Sie auf den Link „Cloud Shell starten“:

x.png

Screen Shot 2017-06-14 at 10.13.43 PM.png

Sobald Sie mit der Cloud Shell verbunden sind, sollten Sie sehen, dass Sie bereits authentifiziert sind und das Projekt bereits auf Ihre PROJECT_ID eingestellt ist :

gcloud auth list

Befehlsausgabe

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)
gcloud config list project

Befehlsausgabe

[core]
project = <PROJECT_ID>

Wenn das Projekt aus irgendeinem Grund nicht festgelegt ist, geben Sie einfach den folgenden Befehl ein :

gcloud config set project <PROJECT_ID>

Suchst du nach deinem PROJECT_ID? Prüfen Sie, welche ID Sie in den Einrichtungsschritten verwendet haben, oder suchen Sie sie im Konsolen-Dashboard:

Project_ID.png

WICHTIG: Legen Sie abschließend die Standardzone und die Projektkonfiguration fest:

gcloud config set compute/zone us-central1-f

Sie können verschiedene Zonen auswählen. Weitere Informationen finden Sie in der Dokumentation zu Regionen und Zonen.

Aktivierte Stackdriver APIs ansehen

Sehen wir uns die APIs an, die für Ihr Projekt aktiviert wurden. Verwenden Sie die Suchleiste, um das API-Dashboard zu finden (siehe unten).

Sehen Sie sich die spezifischen APIs an, die für Ihr Projekt aktiviert wurden :

Jedes Google Cloud Platform-Projekt bietet privates Git-Hosting. Zuerst müssen wir jedoch ein Standard-Repository erstellen, mit dem wir arbeiten können. Rufen Sie Source Repositories über das Suchfeld der Konsole auf :

Klicken Sie auf „REPOSITORY ERSTELLEN“, um ein neues Code-Repository mit dem Namen „default“ zu erstellen:

Mit Cloud Shell klonen wir dieses Verzeichnis jetzt in unsere Google Cloud Shell-Instanz. Dazu erstellen wir zuerst ein Verzeichnis in unserer Google Cloud Shell-Instanz und wechseln zu diesem, wie unten gezeigt (Beispielausgabe):

mkdir stackdriver-demo
cd stackdriver-demo/

Jetzt können wir das Standard-Repository hier über den gcloud-Befehl klonen, wie unten gezeigt:

gcloud source repos clone default

Die Ausgabe der Konsole sollte so aussehen :

Cloning into '/home/gcp123_student/default'...
warning: You appear to have cloned an empty repository.
Project [qwiklabs-gcp-1234abc1234] repository [default] was cloned to [/home/gcp123_student/default].

Sehr gut! Sehen wir uns die eingerichteten Git-Remotes genauer an. Das ist nicht unbedingt der Fall, aber es soll Ihnen helfen, besser zu verstehen, was im Hintergrund passiert ist.

Wechseln Sie in das erstellte Standardverzeichnis und führen Sie den Befehl git remote -v wie unten gezeigt aus.

cd default
git remote -v

Die Ausgabe der Konsole sollte so aussehen:

origin https://source.developers.google.com/p/qwiklabs-gcp-1234abc1234/r/default (fetch)
origin https://source.developers.google.com/p/qwiklabs-gcp-1234abc1234/r/default (push)

Wie Sie sehen, wird hier korrekt auf das Git-Repository verwiesen, das mit unserem GCP-Projekt verknüpft ist.

Gästebuchanwendung von GitHub abrufen

Die Anwendung, die wir verwenden werden, ist eine Standard-App Engine-Anwendung mit dem Namen „Guestbook“, die im offiziellen Google Cloud Platform-GitHub-Repository verfügbar ist. Diese Anwendung ist auch Teil der offiziellen Dokumentation für den Einstieg. Das GitHub-Projekt ist unter https://github.com/GoogleCloudPlatform/appengine-guestbook-python verfügbar.

Wir rufen diesen Code jetzt in unserer Cloud Shell-Instanz ab. Der Befehl und seine Ausgabe werden hier gezeigt :

git pull https://github.com/GoogleCloudPlatform/appengine-guestbook-python

Die Ausgabe der Konsole sollte so aussehen :

remote: Counting objects: 485, done.
remote: Total 485 (delta 0), reused 0 (delta 0), pack-reused 485
Receiving objects: 100% (485/485), 436.42 KiB | 163.00 KiB/s, done.
Resolving deltas: 100% (195/195), done.
From https://github.com/GoogleCloudPlatform/appengine-guestbook-python
* branch HEAD -> FETCH_HEAD

Der gesamte Code ist jetzt lokal in unserer Google Cloud Shell-Instanz vorhanden. Sie sehen die verschiedenen Dateien, die aus dem GitHub-Projekt abgerufen wurden.

Aktuellen Code mit Cloud Shell in das Git-Repository des Projekts übertragen

Jetzt übertragen wir diesen Code in das Git-Repository des GCP-Projekts, damit wir Breakpoints, Logpoints und mehr für unseren Code festlegen können. Dieser Schritt ist nicht zwingend erforderlich, da Sie Ihren Quellcode auch direkt über GitHub, Ihren lokalen Computer oder auf andere Weise verknüpfen können.

Für unsere Zwecke hier übertragen wir diesen Code jedoch per Push in das Git-Repository des GCP-Projekts. Dies erfolgt über den Standardbefehl „git push“, wie unten gezeigt:

git push origin master

Die Ausgabe der Konsole sollte so aussehen :

Counting objects: 485, done.
Compressing objects: 100% (280/280), done.
Writing objects: 100% (485/485), 436.42 KiB | 0 bytes/s, done.
Total 485 (delta 195), reused 485 (delta 195)
remote: Storing objects: 100% (485/485), done.
remote: Processing commits: 100% (152/152), done.
To https://source.developers.google.com/p/qwiklabs-gcp-1234abc1234/r/default
* [new branch] master -> master

Kehren Sie nun zur GCP Console zurück und rufen Sie den Bereich „Entwicklung“ auf. Klicken Sie auf „Quellcode“. Im Standard-Repository sollten Sie alle Projektdateien sehen. Die Beispielausgabe ist unten dargestellt:

Jetzt können wir unsere App Engine-Anwendung für das Gästebuch bereitstellen. Achten Sie darauf, dass Sie sich in Google Cloud Shell und im Standardverzeichnis befinden, um die App bereitzustellen. Verwenden Sie den Befehl gcloud app deploy wie unten gezeigt:

gcloud app deploy --version 1

Wenn Sie aufgefordert werden, eine Region auszuwählen, wählen Sie [1] us-east1 aus.

Die Ausgabe der Konsole sollte so aussehen :

You are about to deploy the following services:
— qwiklabs-gcp-1234abc1234/default/1 (from [/home/gcp123-student/default/app.yaml])
Deployed URL: [https://qwiklabs-gcp-1234abc1234.appspot.com]
Do you want to continue (Y/n)? Y
Beginning deployment of service [default]...
File upload done.
Updating service [default]...done.
Deployed service [default] to https://qwiklabs-gcp-1234abc1234.appspot.com]

Beachten Sie, dass wir dem Befehl zum Bereitstellen der App einen Versionsparameter übergeben haben. Wir haben ihm den Wert "1" zugewiesen.

Da die Gästebuchanwendung Google Cloud Datastore für die Persistenz verwendet, müssen wir die Datastore-Indexe aktualisieren. Die Indexe werden in der Datei index.yaml angegeben. Wir verwenden einfach den Befehl gcloud datastore create-indexes, wie unten gezeigt:

gcloud datastore create-indexes index.yaml

Die Ausgabe der Konsole sollte so aussehen :

You are about to update the following configurations:
— qwiklabs-gcp-1234abc1234/index From: [/home/gcp123_student/default/index.yaml]
Do you want to continue (Y/n)? Y

Es kann eine Weile dauern, bis die Datastore-Indexe aktualisiert werden. Suchen Sie nach „Datenspeicherindexe“ und klicken Sie auf „Indexe“, um den Status zu prüfen. Während die Indexe erstellt werden, wird der Status „Wird indexiert“ angezeigt:

Wir können prüfen, ob unsere App mit Version 1 bereitgestellt und verfügbar ist, indem wir zu „Compute“ → „App Engine“ gehen und dann auf „Versions“ klicken, wie unten dargestellt:

Jetzt sollte alles in Ordnung sein. Sie können sich Ihr Projekt unter https://<PROJECT_ID>.appspot.com ansehen. Es kann einige Minuten dauern, bis die Datenspeicherindexe bereit sind. Wenn die Anwendung einen Fehler ausgibt (z. B. „Interner Serverfehler“), versuchen Sie es einige Minuten später noch einmal.

Melden Sie sich jetzt an und erstellen Sie einige Gästebucheinträge, wie unten dargestellt:

Sehr gut! Jetzt können wir uns die Stackdriver-Funktionen ansehen.

Sehen wir uns zuerst an, wie wir Snapshots unserer laufenden Anwendung erstellen können. Die Snapshots sind nützlich, wenn Sie einen bestimmten Codeabschnitt debuggen, die Variablen prüfen und mehr tun möchten. All dies geschieht, während Ihre Anwendung weiterhin bereitgestellt wird. Das ist sehr hilfreich, wenn Sie Berichte über ein Problem mit Ihrer Anwendung erhalten und versuchen möchten, das Problem zu beheben und zu sehen, was mit Ihrer App passiert. Sie können dann eine Reihe von Variablen untersuchen, den Snapshot bedingt aufnehmen und vieles mehr.

Das wollen wir jetzt für die Gästebuchanwendung tun. Wir werden einen Snapshot anfordern, wenn jemand die Startseite aufruft. Insbesondere möchten wir, dass die Liste der Begrüßungen abgerufen wird, die sich derzeit im Datastore befinden.

Der Code dafür ist in der Datei guestbook.py enthalten. Wir möchten uns den Code zur Laufzeit ansehen, nachdem die Liste der Begrüßungen aus dem Datenspeicher abgerufen wurde. Dies geschieht in Zeile 72. Wir können also einfach einen Haltepunkt in Zeile 74 setzen, damit wir wissen, dass Zeile 72 ausgeführt wurde.

Klicken Sie dazu entweder in der App Engine-Versionsansicht auf „Debuggen“ oder rufen Sie Stackdriver → Debug auf . Daraufhin wird der unten abgebildete Bildschirm angezeigt. Wählen Sie dazu die Datei (guestbook.py) links aus und klicken Sie dann auf die Zeilennummer, wie unten dargestellt.

Es wird eine Meldung angezeigt, die im roten Feld oben hervorgehoben ist und besagt, dass auf das Auslösen eines Schnappschusses gewartet wird. Jetzt müssen wir nur noch unsere Seite unter

https://<PROJECT_ID>.appspot.com.

Danach wird der Snapshot aktiviert und die Abschnitte „Variablen“ und „Aufrufstack“ werden wie unten dargestellt gefüllt. Sehen Sie sich an, wie die Variablen dargestellt werden. Sie können sie maximieren, um die Werte zu prüfen. Das ist sehr hilfreich.

Wenn Sie beispielsweise die Variable „Begrüßungen“ maximieren, sehen Sie die Datensätze, die der Anzahl der von Ihnen erstellten Gästebucheinträge entsprechen.

Eine sehr praktische Funktion ist, dass Sie jederzeit einen Snapshot neu aufnehmen können. Klicken Sie einfach jederzeit auf das Kamerasymbol. Das System wartet dann wieder auf den Snapshot, wie unten dargestellt:

Sie können das Feld „Ausdrücke“ wie unten dargestellt verwenden, um bestimmte Variablen zu verfolgen. Angenommen, wir haben eine Variable „greetings“ und möchten ihren Wert zum Zeitpunkt eines Snapshots untersuchen. Wir können die Variable „greetings“ wie im Screenshot unten einfügen. Wenn der Snapshot erreicht wird, werden die Werte wie dargestellt eingefügt.

Wenn der Snapshot nur unter einer bestimmten Bedingung aktiviert werden soll, können Sie das Feld „Bedingung“ verwenden, wie unten dargestellt. Hier wird festgelegt, dass der Snapshot nur erstellt werden soll, wenn die Anzahl der Begrüßungen größer als 1 ist. Sie können das gern ausprobieren.

Es ist äußerst wichtig, dass die Webanwendung die von Ihnen vorgegebenen Leistungsanforderungen erfüllt. Stackdriver Trace ist ein wichtiges Tool, mit dem Sie die Latenz in Ihren Anwendungen nachvollziehen können.

Sie ist standardmäßig für alle App Engine-Anwendungen aktiviert und liefert uns sehr nützliche Leistungsdetails für alle unsere Endpunkte sowie eine Aufschlüsselung nach verschiedenen Aufrufen.

In unserem Fall haben wir die Startseite („/“) aufgerufen und die Gästebucheinträge angesehen bzw. hinzugefügt. Das reicht aus, damit wir anhand des Traces mehr über die Latenz erfahren. Rufen Sie einfach die Stackdriver Traces-Übersicht auf. Dort sehen Sie einen Screenshot wie unten. Beachten Sie die aktuellen Traces und ihre Latenzen.

Wenn wir auf einen der Traces klicken, d.h. auf den URI-Link, wird der detaillierte Trace wie unten dargestellt angezeigt:

Hier sehen wir, wie die Latenz aufgeschlüsselt wird und welche Aufrufe am längsten dauern. In der obigen Visualisierung sehen Sie, dass die Datenspeicherabfrage Zeit in Anspruch nimmt. Eine Möglichkeit, diesen Engpass zu verringern, könnte darin bestehen, die Daten im Cache zu speichern. Auch hier hängt alles von Ihrer Anwendung ab. Diese Informationen können sehr nützlich sein, um zu ermitteln, welche Bereiche in Ihrem Aufruf-Trace möglicherweise refaktoriert werden müssen.

Sie können Ihre Anwendungslogs jederzeit aufrufen, indem Sie zu Stackdriver Logging navigieren (siehe unten). Es sind mehrere Filter verfügbar, die auf verschiedenen GCP-Diensten, Logtypen, Logebenen, Datumsangaben usw. basieren.

Der Screenshot unten zeigt die Logs für unsere App Engine-Anwendung und die Standardversion 1.

logging.png

Zum Schluss sehen wir uns noch eine Funktion an, die Ihnen die Möglichkeiten von Google Workspace näherbringen soll. Normalerweise geben wir als Entwickler unser Bestes, um Protokollausgaben in unseren Code einzufügen, den Code bereitzustellen und dann darauf zu hoffen, dass das Protokoll uns alles sagt, was wir wissen möchten.

Wir wissen aber, dass das nicht ausreicht. Erst beim Debuggen stellen wir fest, dass wir vielleicht hier und da ein paar weitere Log-Anweisungen hätten einfügen sollen. Der übliche Workflow besteht dann darin, den Code zu ändern, die zusätzliche Log-Anweisung einzufügen, die Anwendung neu bereitzustellen und die Logs zu beobachten.

Das ist in Ordnung, aber was wäre, wenn Sie diese Log-Anweisungen (wir nennen sie jetzt Logpoints) zu Ihrer laufenden Anwendung hinzufügen könnten? Das bedeutet, dass wir die Anwendung nicht beenden, den Code ändern und neu bereitstellen müssen. Stattdessen können wir unsere Liste mit Logpoints mithilfe der Logpoints-Unterstützung außerhalb unserer Anwendung verwalten.

Prüfen wir in Cloud Shell die aktuelle Liste der konfigurierten Logpoints. Sie sollte natürlich 0 sein. Dies erfolgt über den Befehl gcloud, wie unten dargestellt:

gcloud debug logpoints list

Die Ausgabe der Konsole sollte so aussehen :

Debug target not specified. Using default target: default-1
Listed 0 items.

Als Nächstes fügen wir der laufenden Anwendung einen Logpoint hinzu. So fügen Sie einen Logpoint hinzu:

  • Suchen Sie die Quellcodedatei und die Zeilennummer, an der Sie den Logpoint hinzufügen möchten.
  • Die Log-Nachricht identifizieren. Diese Log-Nachricht kann hartcodiert oder auch ein Ausdruck sein.

In unserem Fall fügen wir der Datei „guestbook.py“ in Zeile 74 einen Logpoint über den Befehl „logpoints create“ hinzu, wie unten dargestellt:

gcloud debug logpoints create guestbook.py:74 "Fetched greetings from Datastore. Count of greetings : {len(greetings)}"

Die Ausgabe der Konsole sollte so aussehen :

Debug target not specified. Using default target: default-1
— id: 53538243519d4-f9a0-bdbce
location: guestbook.py:74
logLevel: INFO
logMessageFormat: Fetched greetings from Datastore. Count of greetings : {len(greetings)}
condition: None
status: ACTIVE

Wir haben die filename:linenumber und die Log-Nachricht oben angegeben. Beachten Sie, dass unsere Log-Nachricht auch einen Ausdruck enthält, der die Anzahl der Begrüßungen ausgibt, die aus dem Datenspeicher abgerufen wurden.

Der Befehl gibt die Meldung zurück, dass der Logpoint hinzugefügt wurde. Im Folgenden sehen Sie einen Screenshot von Cloud Shell:

Wenn Sie nun den Befehl für die Logpunkte-Liste ausführen, wird die folgende Ausgabe angezeigt:

gcloud debug logpoints list

Die Ausgabe der Konsole sollte so aussehen :

Debug target not specified. Using default target: default-1
STATUS LOCATION CONDITION LOG_LEVEL LOG_MESSAGE_FORMAT ID
ACTIVE
guestbook.py:74 INFO Fetched greetings from Datastore. Count of greetings : {len(greetings)} 53538243519d4-f9a0-bdbce

Um das in Aktion zu sehen, können wir noch einmal die Startseite unter https://<PROJECT_ID>.appspot.com aufrufen. Dadurch wird der Code und damit auch unser Logpoint aufgerufen. Dies wird standardmäßig in unseren Anwendungslogs protokolliert. Wir müssen also nur noch einmal Stackdriver Logging aufrufen, wie unten dargestellt:

Klicken Sie auf die entsprechende Anfrage. In den Details sehen Sie, dass unser Logpoint ausgelöst wurde und die Logmeldung angezeigt wird.

Wir hoffen, dass Ihnen dieses Tutorial gefallen hat. In diesem Lab werden nur einige der vielen Funktionen der Stackdriver-Plattform erläutert. Es gibt noch viel mehr zu entdecken. Weitere Google Cloud-Tutorials finden Sie im Blog von Romin Irani (dem ursprünglichen Autor dieses Codelabs) unter https://rominirani.com/.

Sie können sich auch dieses andere Codelab ansehen: „Mit Stackdriver Monitoring und Logging bessere Einblicke in die Integrität Ihrer Anwendung bekommen“.

Wenn Sie Feedback geben oder Probleme mit diesem Codelab melden möchten, verwenden Sie bitte den Link „Please find a bug“ (Bitte einen Fehler finden) unten links auf dieser Seite.