Die Workers Analytics Engine ist ein neues Tool, das Anfang des Jahres vorgestellt wurde und mit dem Entwickler und Produktteams Zeitreihenanalysen über alles Mögliche erstellen können – und zwar mit hoher Dimensionalität, hoher Kardinalität und müheloser Skalierung. Wir haben die Analytics Engine entwickelt, damit Teams Einblicke in ihren (in Workers laufenden) Code gewinnen können, sowie Analysen für Endkunden bereitstellen oder sogar nutzungsbasierte Abrechnungen erstellen.
In diesem Blogbeitrag berichten wir darüber, wie wir die Analytics Engine für die Entwicklung der Analytics Engine selbst verwenden. Wir haben unsere eigene Analytics Engine SQL API mit Analytics Engine selbst instrumentiert; mit diesen Daten spüren wir Bugs auf und setzen Prioritäten für neue Produktfeatures. Wir hoffen, dass dies anderen Teams als Inspiration dient, die nach Möglichkeiten suchen, ihre eigenen Produkte zu instrumentieren und Feedback zu sammeln.
Warum brauchen wir die Analytics Engine?
Mit der Analytics Engine können Sie mit nur wenigen Codezeilen Events (oder „Datenpunkte“) von Workern erzeugen. Mit der GraphQL oder SQL-API können Sie diese Events abfragen und nützliche Erkenntnisse über das Unternehmen oder den Technologie-Stack gewinnen. Mehr über die ersten Schritte mit der Analytics Engine erfahren in unserer Entwicklerdokumentation.
Nach der Veröffentlichung der offenen Beta-Version der Analytics Engine im September haben wir auf der Grundlage des Entwickler-Feedbacks in raschem Rhythmus neue Features hinzugefügt. Allerdings klafften zwei große Lücken in unserem Einblick in das Produkt.
Zunächst muss unser Entwicklerteam klassische Fragen zur Beobachtbarkeit beantworten, z. B.: Wie viele Anfragen erhalten wir, wie viele dieser Anfragen führen zu Fehlern, welcher Art sind diese Fehler usw. Sie müssen in der Lage sein, sowohl aggregierte Daten (wie die durchschnittliche Fehlerrate oder die p99-Reaktionszeit) zu betrachten als auch einzelne Events zu analysieren.
Zweitens: Da es ein neu eingeführtes Produkt ist, benötigen wir Einblicke in das Produkt. Durch die Instrumentierung der SQL-API verstehen wir die Abfragen, die unsere Kunden schreiben, und die Fehler, die sie sehen. Das uns hilft, fehlende Features zu priorisieren.
Wir stellten fest, dass Analytics Engine ein hervorragendes Werkzeug ist, um sowohl unsere Fragen zur technischen Beobachtbarkeit zu beantworten als auch Einblicke in das Produkt zu erhalten. Denn wir können für jede Abfrage an unsere SQL-API ein Event protokollieren und dann sowohl nach aggregierten Performance-Problemen abfragen als auch nach einzelnen Fehlern und Abfragen, die unsere Kunden ausführen.
Im nächsten Abschnitt zeigen wir Ihnen, wie wir diese API mit der Analytics Engine überwachen.
Instrumentierung zu unserer SQL-API hinzufügen
Mit der Analytics Engine SQL API können Sie Event-Daten genauso abfragen wie eine gewöhnliche Datenbank. SQL ist seit Jahrzehnten die gängigste Sprache für die Abfrage von Daten. Wir wollten eine Schnittstelle bereitstellen, über die Sie sofort Fragen zu Ihren Daten stellen können, ohne eine neue Abfragesprache lernen zu müssen.
Unsere SQL-API analysiert die SQL-Abfragen von Nutzern, transformiert und validiert sie und führt sie dann gegen Backend-Datenbankserver aus. Anschließend schreiben wir Informationen über die Abfrage zurück in Analytics Engine, so dass wir unsere eigenen Analytics durchführen können.
Daten von einem Cloudflare Worker in Analytics Engine zu schreiben, ist sehr einfach und wird in unserer Dokumentation erklärt. Wir instrumentieren unsere SQL-API auf dieselbe Weise, wie es unsere Nutzer tun. Dieser Codeauszug zeigt die Daten, die wir in der Analytics Engine schreiben:
Da diese Daten nun in der Analytics Engine gespeichert sind, erhalten wir Einblicke in jedes Feld, über das wir berichten.
Für Einblicke abfragen
Da unsere Analytics in einer SQL-Datenbank gespeichert sind, können Sie jede beliebige Abfrage schreiben. Im Gegensatz zur Verwendung von Metriken, die oft vordefiniert und zweckgebunden sind, können Sie jeden beliebigen benutzerspezifischen Datensatz definieren und Ihre Daten mit Leichtigkeit abfragen, um neue Fragen zu stellen.
Wir müssen Datensätze mit Billionen von Datenpunkten unterstützen. Zu diesem Zweck haben wir eine Sampling-Methode namens Adaptive Bit Rate (ABR) eingeführt. Wenn Sie über große Datenmengen verfügen, können Ihre Abfragen mit ABR Stichproben von Events zurückgeben, um in angemessener Zeit antworten zu können. Wenn Sie typischere Datenmengen haben, fragt Analytics Engine alle Ihre Daten ab. So können Sie jede beliebige Abfrage durchführen und erhalten trotzdem in kurzer Zeit Antworten. Im Moment müssen Sie bei der Erstellung Ihrer Abfragen die Stichproben berücksichtigen, aber wir arbeiten daran, diesen Prozess zu automatisieren.
Jedes Datenvisualisierungstool kann für die Visualisierung Ihrer Analytics verwendet werden. Bei Cloudflare setzen wir Grafana ein (und Sie können das auch tun). Dies ist besonders nützlich für Anwendungsfälle der Beobachtbarkeit.
Reaktionszeit auf Abfragen beobachten
Eine Abfrage, auf die wir achten, gibt uns Auskunft über die Performance unserer Backend-Datenbankcluster:
Wie Sie sehen können, steigt das 99%-Perzentil (das entspricht den 1 % der komplexesten Abfragen, die ausgeführt werden müssen) manchmal auf bis zu 300 ms an. Aber im Durchschnitt antwortet unser Backend auf Abfragen innerhalb von 100 ms.
Diese Visualisierung wird selbst aus einer SQL-Abfrage generiert:
Kundeneinblicke aus hochkardinalen Daten
Eine weitere Verwendung der Analytics Engine: Sie können Erkenntnisse aus dem Kundenverhalten gewinnen. Unsere SQL-API ist dafür besonders gut geeignet, da Sie die Leistungsfähigkeit von SQL voll ausschöpfen können. Dank unserer ABR-Technologie lassen sich auch teure Abfragen gegen riesige Datensätze durchführen.
Wir nutzen diese Fähigkeit, um die Prioritäten für Verbesserungen der Analytics Engine festzulegen. Unsere SQL-API unterstützt einen ziemlich standardmäßigen SQL-Dialekt, ist aber noch nicht vollständig mit Features ausgestattet. Wenn ein Nutzer in einer SQL-Abfrage etwas versucht, das nicht unterstützt wird, erhält er eine strukturierte Fehlermeldung zurück. Diese Fehlermeldungen werden an die Analytics Engine übermittelt. Wir sammeln die Fehlerarten, auf die unsere Kunden stoßen, und wissen so, welche Features wir als nächstes priorisieren müssen.
Die SQL-API gibt Fehler im Format von type of error: more details zurück, und so erhalten wir aus dem ersten Teil vor dem Doppelpunkt die Art des Fehlers. Danach gruppieren wir und ermitteln, wie oft der Fehler aufgetreten ist und wie viele Nutzer davon betroffen waren:
Um die obige Abfrage mit einem gewöhnlichen Metriksystem durchzuführen, müssten wir jeden Fehlertyp mit einer anderen Metrik darstellen. Die Meldung so vieler Metriken von jedem Microservice verursacht Probleme mit der Skalierbarkeit. Dieses Problem entfällt bei der Analytics Engine, da sie für die Verarbeitung von Daten mit hoher Kardinalität konzipiert ist.
Ein weiterer großer Vorteil eines Speichers mit hoher Kardinalität wie Analytics Engine: Sie können bis ins kleinste Detail gehen. Wenn eine Spitze bei den SQL-Fehlern auftritt, möchten wir vielleicht herausfinden, welche Kunden ein Problem haben, um ihnen zu helfen oder zu verstehen, welche Funktion sie verwenden möchten. Das lässt sich mit einer weiteren SQL-Abfrage leicht bewerkstelligen:
Bei Cloudflare haben wir diese Art von Informationen bisher nur durch Abfragen unserer Backend-Datenbankserver erhalten. Mit der SQL-API der Analytics Engine können wir unsere Technologie nun für unsere Kunden öffnen, so dass sie auf einfache Weise Erkenntnisse über ihre Dienste in beliebigem Umfang gewinnen können!
Fazit und was als nächstes folgt
Die Erkenntnis aus der Nutzung der SQL-API helfen uns extrem bei unseren Entscheidungen zur Produktpriorisierung. Wir haben bereits Unterstützung für die Funktionen substring und position hinzugefügt, sie werden in den obigen Visualisierungen verwendet.
Ein Blick auf die häufigsten SQL-Fehler zeigt, dass zahlreiche Fehler im Zusammenhang mit der Auswahl von Spalten auftreten. Diese Fehler entstehen meist durch Probleme mit der Benutzerfreundlichkeit des Grafana-Plugins. Helfen sollte hier die Unterstützung der DESCRIBE-Funktion, denn ohne diese Funktion versteht das Grafana-Plugin die Tabellenstruktur nicht. Dies sowie weitere Verbesserungen unseres Grafana-Plugins stehen auf unserer Roadmap.
Wir sehen auch, dass Nutzer versuchen, Zeitbereiche für ältere nicht mehr vorhandene Daten abzufragen. Das deutet darauf hin, dass unsere Kunden sich eine längere Datenaufbewahrung wünschen. Wir haben vor kurzem die Aufbewahrungsdauer von 31 auf 92 Tage verlängert, und wir halten ein Auge auf diese Entwicklung, um zu sehen, ob wir eine weitere Verlängerung anbieten sollten.
Wir fanden viele Fehler rund um häufige Irrtümer oder Missverständnisse der korrekten SQL-Syntax. Dies zeigt, dass wir in unserer Dokumentation bessere Beispiele oder Fehlererklärungen bereitstellen könnten, um Nutzern bei der Fehlersuche in ihren Abfragen zu helfen.
Behalten Sie unsere Entwicklerdokumente im Auge und bleiben Sie auf dem Laufenden, wenn wir uns weiterentwickeln und neue Features hinzufügen!
Sie können die Workers Analytics Engine jetzt nutzen! Analytics Engine ist jetzt in der offenen Beta-Phase mit kostenloser 90-tägiger Speicherung. Starten Sie noch heute oder treten Sie unserer Discord-Community bei, um mit dem Team zu sprechen.