Verteilte Rückverfolgung in der Praxis

Vorwort

Menschen haben schon so lange damit zu kämpfen, Produktionssoftware zu verstehen, wie es Produktionssoftware für Menschen gibt. Wir haben diese wunderbar schnellen Maschinen, aber sie sprechen nicht unsere Sprache und sind - trotz ihrer Geschwindigkeit und des ganzen Hypes um künstliche Intelligenz - immer noch völlig unreflektiert und undurchsichtig.

Viele (viele) Jahrzehnte lang beschränkten sich unsere Bemühungen, Produktionssoftware zu verstehen, letztlich auf zwei Arten von Telemetriedaten: Logdaten und Zeitreihenstatistiken. Die Zeitreihendaten - auch bekannt als Metriken - halfen uns zu verstehen, dass "etwas Schreckliches" in unseren Computern passierte. Wenn wir Glück hatten, halfen uns die Protokolldaten dabei, herauszufinden, was genau diese schreckliche Sache war.

Doch dann änderte sich alles: Unsere Software brauchte mehr als nur einen Computer. Tatsächlich brauchte sie Tausende davon.

Wir zerlegten die Software in winzige, unabhängig betriebene Dienste und verteilten diese fragmentierten Dienste über den ganzen Planeten, atomisiert auf Millionen von Computern in riesigen Rechenzentren. Und bei so vielen Prozessen, die an jeder Endbenutzeranfrage beteiligt waren, sagten die Protokolle und Statistiken der einzelnen Rechner nur einen Bruchteil der Geschichte aus. Es fühlte sich an, als würden wir im Blindflug fliegen.

Ich habe Anfang 2005 angefangen, mich mit verteiltem Tracing zu beschäftigen. Damals war ich ein 25-jähriger Softwareentwickler, der - etwas widerwillig, wenn ich ehrlich sein soll - in einem weit entfernten Dienst innerhalb der Google AdWords Backend-Infrastruktur arbeitete. Wie der Rest des Unternehmens versuchte auch ich, eine Software zu schreiben, die einer enormen Belastung von außen standhalten konnte (zu diesem Zeitpunkt war Google bereits ein Begriff und wir hatten uns in ein für Standardhardware unbekanntes Gebiet vorgewagt). Wir arbeiteten mit Microservices, bevor der Begriff erfunden wurde, und wenn wir eine neue Abstraktionsschicht oder Infrastruktur brauchten, waren wir fast immer gezwungen, sie selbst zu schreiben (GitHub war noch nicht einmal integriert).

Um es kurz zu machen: Wir haben das Schiff über Wasser gehalten... aber es war ein Chaos. Und niemand außer den altgedienten Supergenies (sprich: ich nicht) hatte eine Ahnung, wo die Leichen begraben waren oder wie das alles zusammenpasste.

Damals lernte ich Sharon Perl kennen, eigentlich durch Zufall. Sie war in den 1990er Jahren Forschungswissenschaftlerin im Systems Research Center von DEC (als das noch cool war!) und kam ganz am Anfang zu Google: 2001, wenn ich mich recht erinnere. In dem kurzen Gespräch mit Sharon fragte ich sie, woran sie arbeitete, und sie ratterte eine Liste interessanter Softwareprojekte herunter: ein verteilter Blob-Store, ein Identitätsdienst im Google-Maßstab, ein verteilter Lockservice ... und dann diese Sache namens Dapper. Dapper war "ein verteiltes Verfolgungssystem", was auch immer das sein sollte.

Ich muss nicht erwähnen, dass ich noch nie von einem verteilten Suchsystem gehört hatte - 2005 hatte das kaum ein Nicht-Akademiker - aber es klang faszinierend. Damals war Dapper nur ein Prototyp, den Sharon zusammen mit Mike Burrows und Luiz Barroso entwickelt hatte. Sie hatten Googles internes RPC-Subsystem und die Kontrollflusspakete so gepatcht, dass bei jeder Anfrage ein paar GUIDs mitgesendet wurden, wenn die Anfrage von einem Dienst zum anderen weitergereicht wurde. Das System war noch nicht voll funktionsfähig, aber ein erster Proof-of-Concept zeigte, dass die Grundlagen stimmig waren. Zum ersten Mal konnte ein gewöhnlicher Google-Ingenieur nachvollziehen, was mit einer einzelnen Webanfrage in den 150 Millisekunden geschah, die es brauchte, um Hunderte oder Tausende von verschiedenen Microservices zu erreichen.

Ich war süchtig. Hier gab es etwas wirklich Neues, Mächtiges und - vom persönlichen Standpunkt aus betrachtet - viel zu wenig Personal! Also begann ich, mich in die Codebasis von Dapper zu vertiefen, Dinge zu bereinigen, Kanten abzurunden und mich mit mehr als meinem Anteil an interner Bürokratie auseinanderzusetzen (unter anderem hatte Dapper einen Daemon, der mit Root-Rechten auf jeder Produktionshardware bei Google lief, und klugerweise haben sie einen Prozess um diese Dinge herum aufgebaut). Es genügt zu sagen, dass wir Dapper nach ein oder zwei Jahren Wandzeit und phänomenaler Arbeit eines Teams von Ingenieuren in der Lage waren, die gesamte Backend-Software von Google einzusetzen. Soweit ich weiß, war dies das erste Mal, dass ein Unternehmen verteiltes Tracing kontinuierlich für ein Produktionssystem in großem Umfang eingesetzt hat.

...und so haben wir Dapper in ganz Google eingesetzt und die Beobachtbarkeit gelöst.

Wenn doch nur! Die Wahrheit ist, dass Dapper eine punktuelle Lösung für einige schmerzhafte, aber isolierte Probleme war. In den ersten Tagen war es schwer, die Leute dazu zu bringen, es überhaupt zu nutzen, geschweige denn davon zu profitieren. Der wichtigste Indikator für mein Team war die Anzahl der wöchentlichen Anmeldungen, und ich erinnere mich, wie sich diese Zahl Monat für Monat im niedrigen zweistelligen Bereich bewegte. Wir dachten uns clevere Analysefunktionen aus, setzten sie ein, warteten auf die donnernden Herden begeisterter Nutzer und waren dann enttäuscht.

Schließlich fanden wir einen Weg, die Nutzung und damit den organisatorischen Wert für Google zu erhöhen, aber nicht durch neue Analysefunktionen oder aufschlussreiche Visualisierungen. Vielmehr war es etwas ganz Einfaches, das nur ein paar hundert Codezeilen erforderte: Einer meiner Kollegen integrierte Links zu relevanten Dapper-Spuren in ein Tool, das Google-Ingenieure bereits viele Male am Tag nutzten. Es stellte sich heraus, dass ein kleiner Teil der Leute auf diese Links klickte, und manchmal fanden sie auf der anderen Seite etwas wirklich Wertvolles.

Das war's. Nur eine einfache Integration in einen bestehenden Arbeitsablauf. Abgesehen von den Herausforderungen bei der Datentechnik und der Instrumentierung ist die verteilte Rückverfolgung schwierig, weil sie oft nicht nur als neue Telemetrie, sondern als eigenständige Produkterfahrung betrachtet wird. Egal wie überzeugend diese Produkterfahrung ist, Entwickler/innen sind (wie alle Menschen) Gewohnheitstiere, die kein neues Tool lernen wollen, um proaktiv zu prüfen. Rückverfolgungsdaten und -erkenntnisse müssen in den Kontext bereits bestehender Arbeitsabläufe und zu erledigender Aufgaben passen. Das ist der beste Weg, um verfolgungsorientierten Erkenntnissen die nötige Aufmerksamkeit zu verschaffen, um die Investition in eine grundlegend neue Datenquelle zu rechtfertigen.

Das verteilte Tracing steckt noch in den Kinderschuhen. Wenn ich an die Anfänge des Dapper-Projekts zurückdenke, als ich gerade mit der Codebasis anfing, fragte ich Luiz Barroso, ob er 30 Minuten Zeit hätte, um mir ein paar Dinge zu erklären. Luiz war schon ziemlich angesehen, aber er war (und ist) bescheiden, freundlich und großzügig mit seiner Zeit, also sagte er zu. Als ich mich mit ihm traf, klang ich wohl etwas naiv, aber ich war auch unheimlich begeistert von dem, was ich mit Dapper machen wollte. Ich wollte einen Just-in-Time-Sampling-Mechanismus einbauen, eine deklarative Programmiersprache für benutzerdefinierte Abfragen entwickeln, die über Anwendungsdienste hinweg ausgeführt werden, Kernel Traces integrieren und vieles mehr. Ich habe ihn gefragt, was er davon hält. Als weise Stimme ließ er mich nicht lange zappeln und erklärte mir, dass es Jahre dauern würde, bis Dapper in Produktion gehen würde. "Fang dort an", sagte er.

Damit hatte Luiz recht. Fünfzehn Jahre später ist ein Großteil unserer Branche noch nicht viel weiter gekommen, zumindest in der Produktion. Verteiltes Tracing lohnt sich, aber es ist schwer! Dennoch ist es eine sehr junge Disziplin, und der letzte Abschnitt dieses Buches gibt einen Ausblick auf das, was noch kommen wird. In 15 Jahren werden wir auf die verteilte Nachverfolgung im Jahr 2020 zurückblicken und sie als kritisch und primitiv bezeichnen. Wenn wir verstehen, wohin sich die Technologie entwickelt, können wir uns besser auf die dynamische Landschaft rund um Tracing und Beobachtbarkeit im Allgemeinen einstellen.

Es ist wichtig, sich daran zu erinnern, dass niemand mit "nur einem Microservice" arbeitet.

Unsere Branche ist auf Microservices umgestiegen, damit unsere Entwicklungsteams unabhängig arbeiten können, und bis zu einem gewissen Grad wurde uns dieser Wunsch erfüllt - zumindest was die kontinuierliche Integration und das kontinuierliche Deployment betrifft. Aber diese "Unabhängigkeit" war eine Illusion; in der Produktion sind diese Microservices tatsächlich stark voneinander abhängig, und ein Ausfall oder eine Verlangsamung in einem Service breitet sich über den gesamten Stapel der Microservices aus und hinterlässt Chaos und Verwirrung (und viele verzweifelte Slack-Nachrichten) in seinem Kielwasser.

Verteilte Traces müssen Teil der Lösung für dieses Problem sein. Sie sind das einzige Fenster, das wir haben, um zu sehen, wie die Hunderte von Diensten in tiefen, vielschichtigen Microservice-Architekturen tatsächlich interagieren, wenn sie End-to-End-Nutzeranfragen erfüllen. Im Vergleich zu Zeitreihenstatistiken und Vanilla Logs sind sie zwar ein relativer Neuling in der Welt der Telemetrie, aber sie sind auch das Wichtigste, wenn es darum geht, das Gesamtsystem zu verstehen. Ohne Tracing-Daten können wir nur raten und prüfen, was in einem Meer von ungeordneten Logging-Daten und Metrik-Dashboards steht.

Es ist jedoch nicht so einfach, verteiltes Tracing hinzuzufügen. Obwohl eine gesunde Beobachtbarkeit in verteilten Systemen verteilte Traces beinhalten muss, müssen wir noch herausfinden, wie. Wie machen wir verteiltes Tracing nützlich? Wie können wir es einführen? Wie integrieren wir sie in unsere bestehenden Arbeitsabläufe und Prozesse? Und wie können wir diese Bemühungen zukunftssicher machen?

Das sind faszinierende und herausfordernde Fragen, und sie sind das Thema dieses Buches. Wir hoffen, dass es dir gefällt.

Ben Sigelman

Mitbegründer und CEO von Lightstep

und Mitschöpfer von Dapper