Welche Trace-Sampling-Strategie hält seltene Fehlschläge in einem Dienst mit wenig Datenverkehr sichtbar?

Offene Frage

Veröffentlichte Empfehlungen zum Sampling gehen meist von hohem Volumen aus: einen kleinen Prozentsatz behalten, am Ende (Tail) sampeln, um Fehler und langsame Anfragen zu behalten, und sich für den Rest auf das Gesetz der grossen Zahlen verlassen. Die Sampling-Seite von OpenTelemetry selbst nennt die Erzeugung sehr geringer Datenmengen (Dutzende kleine Traces pro Sekunde oder weniger) als einen der Gründe, überhaupt nicht zu sampeln, und lässt es dabei bewenden. Ein kleiner Dienst sieht wenige Anfragen pro Sekunde, die meisten davon unauffällig, und die relevanten Ereignisse sind selten: ein Timeout am Tag, eine fehlerhafte Payload pro Woche. Eine feste Head-Sampling-Rate verwirft die meisten davon; bei diesem Volumen ist es oft erschwinglich, alles zu behalten, doch dann wird die Aufbewahrung zum Kostenhebel, und Tail Sampling braucht einen Collector, der ganze Traces zwischenspeichert.

Was haben Betreiberinnen und Betreiber von Diensten mit wenig Datenverkehr tatsächlich getan, und was hat es sie gekostet? Kandidaten sind: jeden Trace für ein kurzes Zeitfenster behalten und nur Fehler- oder langsame Traces für ein langes; Head Sampling zu 100 Prozent mit einer Ausnahmeregel pro Route für Health-Checks und Crawler; Tail Sampling mit Regeln zu Status, Latenz und bestimmten Attributen; sowie dynamische Raten, die steigen, wenn der Datenverkehr sinkt. Unklar ist, welche dieser Ansätze Teams dauerhaft beibehalten haben, welche sie wieder aufgegeben haben und wie oft eine Vorfallsanalyse ergab, dass der benötigte Trace wegsampled worden war.

Was eine nützliche Antwort enthält

Die Anfragerate des Dienstes und die Anzahl der Dienste pro Trace; der Sampling-Mechanismus und seine Regeln; die Aufbewahrung pro Trace-Klasse; die Speicher- und Collector-Kosten in einer angegebenen Einheit; Beispiele von Vorfällen, bei denen der Trace vorhanden war, und solchen, bei denen er fehlte; sowie ob die Konfiguration eine Änderung des Datenverkehrs oder des Teams überstanden hat. Anbieter-Standardwerte sollten als solche benannt und Anekdoten als Einzelfälle gekennzeichnet werden.