Sampling, Volumen und Kosten

Sampling, Volumen und Kosten

0:00 Jetzt wird es wirtschaftlich. Traces sind das teuerste der drei Signale, weil ihr Volumen mit jeder einzelnen Anfrage wächst. Irgendwann steht deshalb die Frage im Raum, ob man wirklich alles speichern muss. Die Antwort lautet: nein — aber die Auswahl will überlegt sein. Vollständigkeit ist kein Selbstzweck. Der Fehlerfall ist es.

0:20 Genau darum dreht sich dieses Modul: wie man Datenmengen reduziert, ohne ausgerechnet die Vorgänge zu verlieren, für die man das ganze System gebaut hat.

Sampling, Volumen und Kosten

0:30 Drei Kapitel. Zuerst die Verfahren, die früh entscheiden — Head Sampling, mit dem Kernthema Konsistenz über Dienste hinweg. Dann Tail Sampling, das erst nach dem Ansehen entscheidet und deshalb ganz andere Anforderungen stellt. Und zum Schluss die kaufmännische Seite: Wie rechnet man ein Telemetrievolumen überhaupt aus, und welche Stellschrauben gibt es?

0:51 In der Übung richten Sie Tail Sampling so ein, dass Fehlerfälle garantiert überleben.

Sampling-Verfahren

0:56 Beginnen wir mit der einfacheren Familie: Entscheidungen, die am Anfang fallen, bevor der Trace überhaupt vollständig ist. Der Charme dieser Verfahren liegt darin, dass sie nichts speichern und nichts abstimmen müssen — die Entscheidung ergibt sich rechnerisch aus der Trace-ID. Das macht sie günstig und robust. Es gibt allerdings genau eine Bedingung, an der sie in der Praxis meistens scheitern, und um die geht es in diesem Kapitel.

1:21 Head Sampling entscheidet früh in der Kette, ohne den ganzen Trace zu kennen. Die verbreitetste Form ist die konsistente Wahrscheinlichkeitsauswahl: Die Entscheidung wird aus der Trace-ID und einem gewünschten Anteil abgeleitet. Und darin steckt der eigentliche Trick — weil alle Dienste dieselbe Trace-ID sehen, kommen alle zum selben Ergebnis, ohne sich abzustimmen.

1:42 So werden immer ganze Traces erfasst und nicht einzelne Spans daraus. Ein Trace mit Löchern wäre nämlich schlimmer als gar keiner: Er sieht vollständig aus und ist es nicht. Vier Werte, die Sie kennen sollten. Alles erfassen ist für die Entwicklung richtig. Nichts erfassen ist ein gezieltes Abschaltwerkzeug, kein Fehler.

2:01 Die reine Ratio-Variante ist selten allein sinnvoll — und das ist die interessante Zeile. Denn der Regelfall ist die parent-basierte Variante: Sie übernimmt die Entscheidung des Aufrufers und trifft nur dann selbst eine, wenn sie am Anfang der Kette steht. Damit bleibt der Trace zusammen. Die Wahrscheinlichkeit selbst kommt über einen zweiten Konfigurationswert dazu, ein Wert zwischen null und eins.

2:24 Das ist die zentrale Bedingung dieses Kapitels. Entscheidet jeder Dienst neu, entstehen Traces mit Löchern — und die sind wertlos. Die Ableitung aus der Trace-ID sorgt dafür, dass alle zum selben Ergebnis kommen, ohne Kommunikation. Parent-based übernimmt die Entscheidung des Aufrufers und hält den Trace zusammen. Und der letzte Punkt ist die Warnung: Ein einziger abweichend konfigurierter Dienst genügt, um die Konsistenz zu brechen.

2:50 Das ist ein starkes Argument dafür, Sampling zentral zu konfigurieren statt in jedem Deployment einzeln. Der erste Punkt ist genau das gerade beschriebene Szenario, und es kommt erschreckend häufig vor. Der zweite ist der wirtschaftliche Trugschluss: Die Rate wird gesenkt, um Kosten zu sparen, und die seltenen Fehler verschwinden als Erstes — denn sie sind selten, und eine Zufallsauswahl trifft Seltenes selten.

3:15 Der dritte ist doppeltes Sampling in Anwendung und Collector, was die effektive Rate multipliziert. Und der vierte ist ein handfester Fehler: Metriken werden mitgesampelt. Metriken sind Aggregate — wer sie sampelt, bekommt Absolutwerte, die schlicht falsch sind.

Tail Sampling

3:31 Kommen wir zur anspruchsvolleren Familie. Die Idee ist verlockend einfach: erst ansehen, dann entscheiden. Damit lassen sich genau die Traces behalten, die interessant sind — Fehler, Ausreißer, bestimmte Kunden. Der Preis dafür ist allerdings erheblich und vor allem betrieblicher Natur: Aus einem zustandslosen Filter wird ein zustandsbehafteter Dienst, den man dimensionieren, verteilen und absichern muss.

3:56 Tail Sampling entscheidet, nachdem alle oder nahezu alle Spans eines Trace vorliegen. Damit werden Entscheidungen nach Inhalt möglich: alle Traces mit Fehlern behalten, nach Gesamtlatenz auswählen, nach bestimmten Attributen filtern, oder für viel- und wenigfrequentierte Dienste unterschiedliche Raten anwenden. Diese letzte Möglichkeit ist im Alltag Gold wert — ein selten aufgerufener Dienst braucht keine Ausdünnung, ein hochfrequenter schon.

4:20 Mit Head Sampling ist das nicht zu machen, weil dort niemand weiß, um welchen Dienst es sich handelt, wenn die Entscheidung fällt. Vier Konsequenzen, und alle folgen aus einem einzigen Umstand: Man muss warten. Die Spans müssen bis zur Entscheidung irgendwo liegen — das ist Zustandshaltung. Der Sampler wird damit zu einem zustandsbehafteten Dienst mit echtem Speicherbedarf.

4:42 Alle Spans eines Trace müssen dieselbe Instanz erreichen, sonst sieht keine Instanz den ganzen Trace; das ist die Zusammenführung und der häufigste Betriebsfehler. Und weil das alles unter Last schiefgehen kann, braucht es eine Rückfallebene mit einem einfacheren Verfahren. Hier steht, warum sich der Aufwand trotzdem lohnt. Der Fehlerfall ist selten und würde von einer Zufallsauswahl meistens verworfen — genau der Fall, den Sie brauchen.

5:08 Die langsame Anfrage ist die interessante und soll nicht dem Zufall zum Opfer fallen. Der Normalfall dagegen ist redundant: Die zehntausendste erfolgreiche Rücknahme erzählt nichts Neues und lässt sich gefahrlos ausdünnen. Der vierte Punkt ist eine ehrliche Warnung aus der Dokumentation: Die Regeln wachsen mit dem System und werden mit der Zeit umfangreich.

5:28 Das ist kein Anfangsaufwand, das ist Pflege. Der erste Punkt ist der angekündigte Betriebsfehler: Die Spans eines Trace landen auf verschiedenen Instanzen, und die Regel greift ins Leere. Dafür braucht es eine Lastverteilung, die nach Trace-ID zuordnet — nicht die übliche Rundlaufverteilung. Der zweite ist fehlende Redundanz: Ein Neustart verliert alle gerade laufenden Traces. Der dritte ist Pflege — die Regelmenge wächst, und niemand prüft sie auf Widersprüche.

5:56 Und der vierte ist Planung: Der Speicherbedarf wird nicht abgeschätzt und fällt erst im Lastfall auf, wenn es zu spät ist.

Volumen wirtschaftlich steuern

6:04 Im letzten Kapitel wird gerechnet. Das klingt weniger spannend als Tail Sampling und ist die Grundlage jeder vernünftigen Entscheidung. Ohne Zahl bleibt jede Diskussion über Telemetriekosten eine Meinungsäußerung — und sie endet regelmäßig damit, dass dort gespart wird, wo es am leichtesten geht, statt dort, wo es am wenigsten schadet.

6:23 Deshalb überschlagen wir das Volumen jetzt einmal, wenn auch grob. Das Volumen ergibt sich aus vier Faktoren: Anfragerate, Spans je Anfrage, Attribute je Span und Aufbewahrungszeit. Das Schöne daran ist, dass sich jeder einzelne gezielt beeinflussen lässt — durch Sampling, Filterung, Aggregation oder kürzere Aufbewahrung.

6:42 Und der letzte Satz ist mir wichtig: Die Entscheidung ist wirtschaftlich und gehört dokumentiert. Denn in sechs Monaten wird jemand fragen, warum ein bestimmter Trace fehlt. Dann ist der Unterschied zwischen einer dokumentierten Entscheidung und einem unerklärlichen Datenverlust erheblich. Lesen Sie diese Tabelle als Abwägung, nicht als Empfehlungsliste. Jede Stellschraube hat einen Preis. Sampling verliert seltene Fälle. Filterung nimmt Ihnen später den Beleg.

7:10 Aggregation erschwert die Ursachensuche. Und kürzere Aufbewahrung nimmt Ihnen den Vergleich mit dem Vorjahr — was harmlos klingt, bis jemand eine Kapazitätsplanung möchte. Die Fußzeile enthält die Regel, die unabhängig von allen Varianten gilt: Fehler- und Latenzausreißer bleiben vollständig erhalten. Sie sind der Grund, warum Sie Traces überhaupt sammeln.

7:33 Sie überschlagen jetzt das tägliche Volumen — aus Anfragerate, Spans je Anfrage und Aufbewahrung. Der Hinweis nimmt Ihnen den Druck: Die Rechnung darf grob sein. Sie muss die Größenordnung treffen und nachvollziehbar sein, mehr nicht. Genau das ist der Punkt — die meisten Teams rechnen nämlich gar nicht, weil sie glauben, es müsste exakt sein.

7:53 Dabei reicht schon eine Überschlagsrechnung, um zu erkennen, ob man über Gigabyte oder Terabyte spricht. Und diese Unterscheidung ändert Architekturentscheidungen. Der erste Punkt ist die Konsequenz des Nichtrechnens: Die erste Rechnung entscheidet die Architektur, meist hektisch und schlecht. Der zweite ist der gefährlichste — gespart wird an den Fehlerfällen, weil sie technisch am leichtesten wegfallen.

8:17 Der dritte ist Gewohnheit: Aufbewahrung pauschal auf Monate, obwohl niemand je zurückschaut; prüfen Sie das einmal in Ihren Zugriffszahlen. Und der vierte ist der Dokumentationspunkt von eben — eine nicht dokumentierte Sampling-Entscheidung wird später als Datenverlust gedeutet, und dann wird das Vertrauen in die Telemetrie beschädigt.

Übung

8:36 In der Übung setzen Sie beides zusammen: Sie rechnen das Volumen aus, richten Tail Sampling ein und weisen dann nach, dass die interessanten Traces tatsächlich überlebt haben. Dieser Nachweis ist der eigentliche Kern. Eine Sampling-Regel, die niemand gegen einen echten Fehlerfall geprüft hat, ist eine Hoffnung — und Hoffnungen tragen schlecht in der Nacht, in der Sie den Trace wirklich brauchen.

8:58 Zwei Erfolgskriterien, und sie hängen zusammen. Erstens ist das Volumen gegenüber der Vollerfassung messbar gesunken. Zweitens sind eine absichtlich erzeugte Fehleranfrage und eine langsame Anfrage vollständig im Backend auffindbar. Der Hinweis präzisiert, was vollständig heißt: alle Spans des Trace, nicht nur der fehlerhafte.

9:18 Das ist die typische Enttäuschung beim ersten Versuch — man findet den Fehler-Span, aber der Rest des Vorgangs fehlt. Dann greift die Zusammenführung nicht, und Sie sind beim Stolperstein aus Kapitel zwei. Der rote Faden führt von der Zahl über die Regel zum Beweis. Erst schätzen Sie das Volumen, dann legen Sie ein Reduktionsziel fest — und begründen es, denn eine Zahl ohne Begründung ist willkürlich.

9:42 Dann richten Sie Tail Sampling im Gateway ein, mit den beiden Kriterien Fehler und hohe Latenz. Und dann kommt der Beweis: zwei auffällige Anfragen auslösen, beide vollständig wiederfinden, Volumen erneut messen. Die Fußzeile nennt die Diagnose für den häufigsten Fehlschlag — findet sich nur ein Teil der Spans, verteilen sich die Traces über mehrere Instanzen.

10:04 Der erste Punkt ist eine halbe Übung: Die Reduktion wird gemessen, die Auffindbarkeit der Fehlerfälle nicht geprüft. Damit haben Sie bewiesen, dass Sie sparen können — nicht, dass Sie noch etwas sehen. Der zweite ist ein Reihenfolgeproblem: Head Sampling bleibt zusätzlich aktiv und entfernt die Fehler schon vor dem Gateway; dann kann Tail Sampling nichts mehr retten.

10:24 Der dritte ist ein Konfigurationsfehler mit stiller Wirkung — gefiltert wird auf einen Statuscode, den die Anwendung gar nicht setzt. Und der vierte: Das Ergebnis wird in Produktion übernommen, ohne die dortige Last zu kennen.