Verteilte Rückverfolgung in der Praxis

Kapitel 11. Jenseits von Einzelanträgen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Du hast bereits gesehen, wie Traces nützliche Informationen über das End-to-End-Verhalten einzelner Anfragen erfassen. Dazu gehören die Zeit, die jeder einzelne RPC benötigt, wie viele Daten bei jedem Hop übertragen wurden, Timeouts und Fehlerantworten. Wenn du dir einen einzelnen Trace genau ansiehst, kannst du oft erklären, warum die Anfrage so lange gedauert hat, wie sie gedauert hat. Du könntest zum Beispiel feststellen, dass eine bestimmte Anfrage nicht in den Cache gelangt ist. Vielleicht hat ein Dienst einen außergewöhnlich großen Antwortdatensatz zurückgeschickt, der lange Zeit für die Serialisierung und Deserialisierung brauchte. Vielleicht gibt es einen Nachzügler in einem großen RPC-Fanout, der viele Millisekunden nach seinen Kollegen antwortet. Vielleicht zeigt der Trace das gefürchtete Treppenmuster, bei dem RPC-Aufrufe, die eigentlich parallel sein sollten, in Wirklichkeit seriell ausgeführt werden.

Jede dieser Situationen würde etwas Wichtiges über die jeweilige Spur verraten, aber wie das Timing-Diagramm in Abbildung 11-1 zeigt, ist es schwierig, diese Verhaltensweisen isoliert zu interpretieren. Aus einzelnen Traces lässt sich nicht ablesen, wie oft die Situation auftritt und auf welche Arten von Anfragen sie reagiert. Solltest du, der Betreiber oder Eigentümer des Dienstes, etwas unternehmen, ...