Bei Aliz haben wir uns auf Google Cloud Platform (GCP) Lösungen spezialisiert. Unser Team ist an der Entwicklung einer erfolgreichen Dokumentenmanagement-Plattform namens AODocs beteiligt, einer wirklich cloud-nativen Lösung. Wir möchten Ihnen zeigen, wie wir bestimmte GCP-Dienste während der Entwicklung und des Betriebs dieser Anwendung nutzen.
AODocs hat etwa 5 Millionen installierte Nutzer auf dem G Suite Marketplace, speichert 25 TB an Daten in einer NoSQL-Datenbank (ohne Indizes), speichert 500 TB an Daten in BigQuery, bedient etwa 80 Millionen Anfragen pro Tag mit 100-150 Instanzen und läuft seit mehr als 8 Jahren rund um die Uhr.
AODocs läuft auf Google App Engine, einer Platform-as-a-Service, serverlosen Lösung auf GCP, wo wir grundsätzlich WAR-Dateien in Servlet-Containern bereitstellen. Alle von uns verwendeten Dienste bieten eine skalierungsunabhängige Leistung: eine NoSQL-Datenbank, Volltextsuche, Aufgabenwarteschlangen usw.
Lassen Sie uns tic-tac-toe spielen
Um einige Daten zu den Diagrammen zu erhalten, haben wir ein einfaches anonymes Tic-Tac-Toe-Spiel erstellt, bei dem die angeschlossenen Spieler zufällig einander zugewiesen werden. Sie können auch mit sich selbst spielen, indem Sie ein anderes Browserprofil oder ein Inkognito-Fenster öffnen. Wir laden Sie ein, ein Spiel zu spielen, und Sie werden Ihr Spiel in den am Ende verlinkten Dashboards sehen. Das macht Spaß!
Stackdriver-Dashboards
Stackdriver ist der zentrale Ort, an dem Sie den Zustand Ihrer Anwendung überwachen können. Es bietet Ihnen eine breite Palette an sofort einsatzbereiten Metriken für die meisten GCP-Dienste. Sie können ganz einfach Diagramme und Warnungen für die folgenden Punkte einrichten:
Die Überprüfung einiger mit diesen Diagrammen erstellter Boards gehört zu unserer täglichen Routine. Sie lassen sich mit wenigen Klicks einrichten und sind von großem Wert, da sie es uns ermöglichen, Fehler oder seltsames Verhalten nahezu in Echtzeit zu erkennen.
Log-Analyse, Metriken, Warnungen
Wie zu erwarten, können Sie auf Ihre Anwendungsprotokolle zugreifen. Die Logs von fast allen GCP-Diensten sind auf einer zentralen Log-Überwachungsseite verfügbar, auf der Sie die benötigten Logs einfach durchsuchen können. Die Protokolle sind nach Anfragen gruppiert, so dass Sie verfolgen können, was eine einzelne Benutzeroperation protokolliert hat. Sie müssen sich nicht mit Thread-IDs oder Client-IPs herumschlagen.
Die Protokolle sind in dieser Konsole für einen bestimmten Zeitraum verfügbar. Sie zahlen für den Umfang der gespeicherten Protokolle. Normalerweise sind einige Wochen ausreichend. Sie können konfigurieren, dass alte Protokolle in den Cloud-Speicher, in BigQuery oder in Ihren eigenen Speicher über Pub/Sub verschoben werden.
Metriken und Warnungen
Log-basierte Metriken stellen eine leistungsstarke Funktion für Ihr System dar.
Nehmen wir an, Sie haben eine bedingte Verzweigung in Ihrem Code, die Sie normalerweise mit dem Kommentar "// Dies sollte nie passieren" versehen würden. An diesen Stellen können Sie stattdessen 'log.warn("Dies hätte nicht passieren dürfen")` einfügen und eine logbasierte Metrik einrichten, um zu überwachen, wie oft dies tatsächlich geschieht 🙂 .
In unserem Spielbeispiel habe ich eine Protokollzeile hinzugefügt, in der ein Spiel abgebrochen wurde, damit ich die Anzahl der Spielabbrüche im Laufe der Zeit leicht überwachen kann.
Sie können diese Metriken in Stackdriver-Dashboards grafisch darstellen und auf der Grundlage dieser Metriken benutzerdefinierte Warnmeldungen konfigurieren. In unserem Beispiel kann ich benachrichtigt werden, wenn die Zahl der Spielabbrüche zu hoch wird, was bedeuten könnte, dass ein Anwendungsfehler vorliegt, der eine korrekte Benutzerzuordnung verhindert.
Fehlerberichterstattung
Die Fehlerberichterstattung basiert ebenfalls auf Protokollen, sucht aber speziell nach Fehlermeldungen mit einem Stacktrace. Es gruppiert die Vorkommnisse automatisch auf der Grundlage des Stacktrace, als ob es automatisch eine protokollbasierte Metrik und Warnung für jede Art von Ausnahme in unserer Anwendung erstellen würde.
Die regelmäßige Überprüfung der Fehlermeldungen ist Teil der Betriebsroutine unserer Anwendung während unserer Arbeit mit GCP. Dadurch konnten wir viele Fehler abfangen, bevor sie sich negativ auf die Kunden auswirkten. Wir überprüfen diese Seite ständig während des Rollouts von Versionen, auch in unserer Staging-Umgebung.
Es ist erstaunlich, wie die subtilsten Race-Conditions in großen verteilten Systemen regelmäßig zu Problemen führen.
Fehlersuche
Traces
Log Traces werden automatisch für einen bestimmten Anteil der Anwendungsanfragen aufgezeichnet. Sie geben einen Überblick darüber, was bei der Anfrage passiert ist und wie lange jeder Vorgang gedauert hat - Datenspeicherzugriff, externe API-Aufrufe. Dies kann wichtige Erkenntnisse für Leistungsoptimierungen liefern.
Cloud-Debugger
Der Cloud-Debugger ist extrem leistungsfähig und kann sogar in einer Produktionsumgebung sicher verwendet werden. Keine Sorge, Haltepunkte unterbrechen nicht die eigentlichen Anfragen; es wird nur ein kurzer Schnappschuss gemacht.
Wenn Sie eine Anfrage betrachten, die einen seltsamen Ausführungspfad nimmt, fragen Sie sich vielleicht, welche Werte bestimmte Variablen während der Ausführung haben. Mit dem Cloud Debugger können Sie die Anwendung on-the-fly instrumentieren, um:
Sie können diese "Haltepunkte" auch an Bedingungen knüpfen.
Die Verwendung des Cloud-Debuggers setzt natürlich voraus, dass der Fehler von Zeit zu Zeit wieder auftritt. Sie können ihn also nicht verwenden, um einen vergangenen Vorfall zu untersuchen, aber wenn der Fehler reproduziert wird, können Sie die genauen Bedingungen sehr effizient überprüfen.
Die Macht der Daten
Ich kann nicht genug betonen, wie mächtig es ist, Daten über Ihre Anwendung zu haben. Alle Anwendungsprotokolle und Metriken sind auch in BigQuery leicht verfügbar, einem praktisch unerschöpflichen Speicher für alles, was Sie brauchen.
Sie können leicht Fragen darüber beantworten
Wenn Sie auf GCP arbeiten, erhalten Sie BigQuery und Data Studio sofort einsatzbereit. Sie zahlen nur für das gespeicherte Datenvolumen und das Volumen, das Ihre Abfragen lesen. Es gibt sicherlich anspruchsvollere BI-Tools (die Sie auch integrieren können, wenn Sie dies wünschen), aber die Tools, die Sie in GCP erhalten, sind bereits sehr leistungsstark.
BigQuery - benutzerdefinierte Metriksammlung
Sie können GCP-Protokolle automatisch an BigQuery streamen, um sie für Ad-hoc-Abfragen oder Berichte verfügbar zu machen.
Sie können sich auch auf BigQuery verlassen, um benutzerdefinierte Datenpunkte aus Ihrer Anwendung zu sammeln. In AODocs sammeln wir verschiedene benutzerdefinierte Diagnosedatenpunkte, um einen genaueren Überblick über die Nutzung bestimmter Funktionen zu erhalten. Wir sammeln auch detailliertere Daten über die aufgeschobenen Aufgaben, die wir in Aufgabenwarteschlangen ausführen. In unserem Spielbeispiel können wir auf einfache Weise historische Daten zu allen Spielergebnissen sammeln.
Dies ist ein guter Mechanismus, um historische Daten von transaktionalen Daten in einer Datenbank zu trennen. So wie Sie Ihre Anwendungsprotokolle nicht in derselben Datenbank speichern, in der sich auch Ihre Kundendaten befinden, werden die historischen Daten für BI-Berichte zugänglich gemacht, ohne Ihre Transaktionsdatenbank zu überlasten, egal ob es sich um Cloud Datastore oder Cloud SQL handelt.
Data Studio - kundenspezifische technische und geschäftliche Berichte
Data Studio ist ein eher allgemeines BI-Tool, das Sie auch außerhalb von GCP nutzen können. Im Anwendungsbetrieb auf GCP verwenden wir es, um Dashboards auf der Grundlage unserer benutzerdefinierten Daten aus BigQuery zu erstellen, aber Sie können auch verschiedene andere Datenquellen konfigurieren. Diese Dashboards ähneln den bereits erwähnten Stackdriver-Dashboards, aber mit Data Studio können wir unsere eigenen Abfragen, benutzerdefinierten Datendimensionen, Filter- und Drilldown-Optionen verwenden.
Sehen Sie sich den Bericht an, den wir für das Tic-Tac-Toe-Spiel erstellt haben.
