OpenTelemetry – Teil 1: Die Edge rückt näher

In den frühen Tagen der Entwicklung verteilter Anwendungen für das Web musste man sich zunächst über die einzelnen Komponenten der Anwendungsarchitektur klar werden: physische Server, Betriebssysteme, Serversoftware, Datenbanken und natürlich den Code.

Mit der revolutionären Serverless-Technologie wird all das praktisch überflüssig. Sie können Code mithilfe von Cloud-Funktionen schreiben oder eine Datenbank von einem SaaS-Anbieter abonnieren und Sekunden später Queries über Ihren Code versenden, ohne auch nur das Geringste installieren zu müssen.

Das Ergebnis: Sie können Ihren Code an immer mehr Stellen und auf immer kurzlebigeren Plattformen ausführen. Wenn die Umgebung, in der Ihr Code ausgeführt wird, mühelos bereitgestellt werden kann, ist es egal, ob sie nur wenige Sekunden lang besteht. Dies bringt jedoch auch eine neue Herausforderung mit sich: Wie behält man den Überblick darüber, was, wo und für wen ausgeführt wurde – und vor allem, was, wo und warum passiert ist, wenn etwas schiefgeht?

Stellen Sie sich vor, Sie haben eine Microservices-Architektur, auf der eine Zeitungswebsite basiert und die folgendermaßen aussieht:

Hierbei handelt es sich um eine relativ einfache Architektur, die jedoch bereits einige interessante Merkmale aufweist:

1. Zwei Fastly Layer fassen global verteilte Anfragen an einem Punkt in der Nähe Ihrer Kerninfrastruktur zusammen (wir nennen das Abschirmung oder Shielding).

2. Einige Anfragen können vollständig an einem Edge-Standort bearbeitet werden, andere wiederum können einen direkten Call vom Edge-Standort an einen Service erfordern, der nicht von Fastly bereitgestellt wird.

3. Ein Gateway-Service, der in Ihrer Core-Cloud-Plattform ausgeführt wird, greift auf mehrere Microservices zu.

4. Möglicherweise handelt es sich bei einigen dieser Microservices um SaaS-Services von „undurchsichtigen” Anbietern. Wiederum andere sind Ihre eigenen, aber manche stammen vielleicht auch von Fastly oder werden von Fastly gehostet.

Mehrere Anbieter, eine unbekannte und unüberschaubare Anzahl von Layern, undurchsichtige Services, scheinbar zirkuläre Referenzen ... das alles klingt ziemlich erschreckend. Wenn aber all diese Komponenten OpenTelemetry (OTel) unterstützen, lassen sich alle Wege durch dieses System in einer einzigen Übersicht darstellen:

Durch die Verwendung von OpenTelemetry können Sie nicht nur jede einzelne Komponente in Ihrem System instrumentieren, sondern sich auch von der Bindung an einen bestimmten Observability-Anbieter lösen. Der obige Trace wird von Honeycomb gerendert – einem wirklich großartigen Service. Aber wenn Sie möchten, können Sie Lightstep oder New Relic verwenden oder sogar Ihre eigene Analyse mit einem selbst gehosteten Open-Source-Tool wie Zipkin durchführen. Sie alle unterstützen dasselbe Telemetrieformat.

Dieses Beispiel zeigt, wie sich Spans von Fastly Edge-Servern um Spans in einer Google App Engine Instanz gruppieren. Der Vorteil des offenen Standards ist, dass Tracing-Daten von jedem System und in jeder Sprache generiert und von demselben Collector erkannt und analysiert werden können. Für die meisten Sprachen gibt es Bibliotheken – in meiner Demo verwende ich zum Beispiel die Standard-Instrumentierung für NodeJS, die Spans aus einer ExpressJS Anwendung automatisch erfasst.

OpenTelemetry und Fastly

Sie können Ihre Anwendung innerhalb des Edge-Netzwerks von Fastly auf zweierlei Arten ausführen: mithilfe unserer VCL Plattform oder mit Compute. Der Abruf von OpenTelemetry Daten ist mit beiden möglich, allerdings gibt es Unterschiede bei der Vorgehensweise:

• Wenn Sie einen VCL Service haben, nutzen Sie unser Echtzeit-Logging und einen HTTPS-Endpoint, um einen OpenTelemetry Trace im JSON Format an einen OpenTelemery Collector zu senden, der so konfiguriert ist, dass er OLTP über HTTP akzeptiert.

• Wenn Sie Compute verwenden, nutzen Sie unsere Fastly OpenTelemetry Bibliotheken für JavaScript, die wir für die vereinfachte Verwendung von OpenTelemetry in Compute Projekten entwickelt haben.

Beide Ansätze werden bereits von vielen Fastly Großkunden in zahlreichen Branchen und Ländern genutzt (zum Beispiel arbeite ich seit Kurzem mit Condé Nast – dem Verlag von Magazinen wie Wired, GQ und Vogue – an seiner Telemetrie). Diese Kunden haben komplexe, bunte Architekturen, die On-Premise-Technologie, Cloud Computing, PaaS von Anbietern, SaaS und serverlose Services, Frontend-Single-Page-Anwendungen und native Apps miteinander vereinen!  

So langsam beginnen alle Teile der komplexen Systeme unseres digitalen Zeitalters dieselbe Sprache zu sprechen: Open Telemetry schafft eine gemeinsame Basis für alle unterschiedlichen Transaktionen und Anfragen, die durch diese Systeme fließen.  

Wir wissen, dass Fastly selten die einzige Plattform ist, die Sie nutzen. Die beste Lösung für jedes erdenkliche Problem zu sein ist aber auch gar nicht unser Ziel. Wir schätzen OpenTelemetry, weil es Fastly hilft, als Teil der Architektur, die Sie aufbauen wollen, erfolgreich zu sein:

• Sie sind nicht an einen bestimmten Anbieter (einschließlich uns) gebunden.

• Sie können die für Sie am besten geeigneten Analysetools nutzen.

• Fastly wird zu einer erstklassigen Komponente in Ihrer Systemarchitektur.

In den nächsten Wochen folgen weitere Blogposts, die ausführlich auf die Verwendung von OpenTelemetry mit VCL und Compute Services eingehen. Außerdem wird es eine Fallstudie darüber geben, wie wir OpenTelemetry für das Monitoring unseres eigenen Fiddle Tools einsetzen.

Alle vier Teile unserer OpenTelemetry Blogserie sind nun online:

• OpenTelemetry – Teil 1: Die Edge rückt näher

• OpenTelemetry – Teil 2: So nutzen Sie OpenTelemetry in VCL

• OpenTelemetry – Teil 3: So nutzen Sie OpenTelemetry in Compute

• OpenTelemetry – Teil 4: So instrumentieren Sie Fastly Fiddle