Wann greifst du zu einem Distributed Trace statt zu einer Metrik oder einem Log?

Metriken sagen dir, dass etwas kaputt ist und grob wo. Logs sagen dir, was innerhalb eines Prozesses passiert ist. Traces sagen dir, wo für einen einzelnen Request über Services hinweg die Zeit hingegangen ist. Greif zum Trace, wenn die Latenz hoch ist, aber kein einzelner Service ungesund aussieht, oder wenn ein Request viele Hops überquert. Metriken sind billig und aggregiert, Logs sind detailliert und teuer, Traces sind gesampelt und relational.

Ich denke in drei Fragen. Metriken beantworten, ob und wie stark etwas kaputt ist, Logs beantworten, was in genau diesem Prozess passiert ist, und Traces beantworten, wo über den gesamten Request die Zeit hingegangen ist. Zum Trace greife ich in dem Moment, in dem die Gesamtlatenz hoch ist, aber jedes einzelne Service-Dashboard gut aussieht, denn dann steckt die Zeit fast immer in einem Hop, den niemand besitzt. Das ist uns mit einem Service-Mesh-Sidecar passiert, der Retries hinzugefügt hat, von denen wir nichts wussten. Der Trace hat es in etwa einer Minute offensichtlich gemacht, weil wir drei identische Spans unter einem Aufruf verschachtelt gesehen haben. Der praktische Klebstoff ist, Trace- und Span-IDs in jede Logzeile zu schreiben, damit du von einer aggregierten Metrik zu einem langsamen Exemplar-Trace und von dort zu den exakten Logzeilen dieses Requests springen kannst. Und ich würde Traces head-based mit niedriger Rate sampeln, dazu tail-based Sampling für Fehler und langsame Requests, denn alles aufzuheben ist die Rechnung nicht wert.