Tracing: τι είναι, αρχές και συλλογή δεδομένων

Τι είναι το tracing στην παρακολούθηση

Η ιχνηλάτηση είναι μια μέθοδος κατανεμημένης παρατήρησης όπου κάθε εισερχόμενο αίτημα παρακολουθείται μέσω όλων των υπηρεσιών και συστατικών του συστήματος. Σε αντίθεση με τις μετρικές, που εμφανίζουν συγκεντρωτικές τιμές (μέσος χρόνος απόκρισης, αριθμός σφαλμάτων), η ιχνηλάτηση διατηρεί το πλήρες περιεχόμενο ενός συγκεκριμένου αιτήματος.

Κάθε βήμα επεξεργασίας — κλήση βάσης δεδομένων, αίτημα HTTP προς μια άλλη μικροϋπηρεσία, εκτέλεση εργασίας υποβάθρου — καταγράφεται ως ξεχωριστή μονάδα με χρονική σφραγίδα, κατάσταση και γνωρίσματα. Σύμφωνα με τα δεδομένα Google Dapper (αρχική δημοσίευση 2010), η ιχνηλάτηση επιτρέπει τον εντοπισμό καθυστερήσεων σε κατανεμημένα συστήματα με ακρίβεια μιας κλήσης.

Η ιχνηλάτηση είναι ιδιαίτερα σημαντική για τις κινητές εφαρμογές, όπου το backend αποτελείται από δεκάδες μικροϋπηρεσίες. Μια ενέργεια χρήστη — για παράδειγμα, σύνδεση σε λογαριασμό — μπορεί να περάσει από API Gateway, υπηρεσία ταυτοποίησης, βάση δεδομένων και υπηρεσία Push. Χωρίς trace, είναι πρακτικά αδύνατο να προσδιοριστεί ποιο συστατικό επιβραδύνει την απάντηση.

Spans και traces: βασική δομή δεδομένων

Η βασική μονάδα της ιχνηλάτησης είναι το span. Κάθε span αντιπροσωπεύει μια λογική λειτουργία: αίτημα HTTP, ερώτημα SQL, κλήση gRPC, σειριοποίηση JSON. Ένα span περιέχει ένα μοναδικό αναγνωριστικό, αναγνωριστικό γονέα, όνομα λειτουργίας, χρόνο έναρξης, διάρκεια, κατάσταση και ένα σύνολο γνωρισμάτων.

Ιεραρχία span σε ένα trace

Όλα τα span που ανήκουν σε ένα κεντρικό αίτημα ενώνονται σε ένα trace. Το κεντρικό span (root span) αντιπροσωπεύει το σημείο εισόδου — ένα αίτημα HTTP από τον κινητό πελάτη προς το API. Τα θυγατρικά span δημιουργούν ένα δέντρο όπου κάθε span αναφέρεται στον γονέα μέσω του πεδίου parent_span_id.

Η διάρκεια ενός trace ισούται με το άθροισμα των μοναδικών χρονικών τμημάτων όλων των span. Αν δύο θυγατρικά span εκτελούνται παράλληλα, ο χρόνος τους δεν προστίθεται — αυτό είναι κρίσιμο για τη σωστή ανάλυση καθυστερήσεων που προκαλούνται από παράλληλες κλήσεις μικροϋπηρεσιών.

Γνωρίσματα και συμβάντα span

Κάθε span μπορεί να περιέχει γνωρίσματα — ζεύγη κλειδιού-τιμής με μεταπληροφορίες: URL του αιτήματος, ID χρήστη, έκδοση API, όνομα διακομιστή. Τα γνωρίσματα χρησιμοποιούνται για φιλτράρισμα και ομαδοποίηση των trace. Εκτός από τα γνωρίσματα, το span υποστηρίζει συμβάντα — χρονικές σφραγίδες με περιγραφή κειμένου, για παράδειγμα “αστοχία cache” ή “προσπάθεια επανασύνδεσης”.

Πώς λειτουργεί το distributed tracing

Το distributed tracing λύνει το πρόβλημα σύνδεσης span που δημιουργούνται σε διαφορετικές διεργασίες και σε διαφορετικές μηχανές. Ο μηχανισμός βασίζεται στη μεταφορά περιεχομένου: κατά την κλήση της υπηρεσίας B από την υπηρεσία A, στο εξερχόμενο αίτημα προστίθεται μια κεφαλίδα με το αναγνωριστικό του τρέχοντος trace και του γονικού span.

Τα πρότυπα πρωτόκολλα μεταφοράς περιεχομένου — W3C Trace Context (κεφαλίδες traceparent και tracestate) και Zipkin B3 (κεφαλίδες X-B3-TraceId, X-B3-SpanId). Το W3C Trace Context υιοθετήθηκε ως πρότυπο από τον οργανισμό W3C το 2021 και υποστηρίζεται από όλους τους κύριους παρόχους τηλεμετρίας.

Κατά τη λήψη του αιτήματος, η υπηρεσία B εξάγει το trace_id από την κεφαλίδα και δημιουργεί ένα θυγατρικό span με αυτό το trace_id. Έτσι, μετά την ολοκλήρωση του αιτήματος, όλα τα span από διαφορετικές υπηρεσίες ενώνονται σε ένα trace στην πλευρά του συλλέκτη. Για αυτό, κάθε υπηρεσία πρέπει να είναι ενσωματωμένη με την ίδια βιβλιοθήκη ιχνηλάτησης.

Μεταφορά περιεχομένου σε μικροϋπηρεσίες

Στην ανάπτυξη κινητών, η μεταφορά περιεχομένου καλύπτει όχι μόνο το backend, αλλά και την αλληλεπίδραση πελάτη-εξυπηρετητή. Μια κινητή εφαρμογή μπορεί να στέλνει trace_id στην κεφαλίδα κάθε αιτήματος API, επιτρέποντας τη σύνδεση της ενέργειας του πελάτη με την επεξεργασία του εξυπηρετητή. Το OpenTelemetry SDK για iOS και Android υποστηρίζει αυτόματη δημιουργία και μεταφορά περιεχομένου trace μέσω HTTP πελατών.

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

Ο παρουσιαζόμενος interceptor σε Kotlin δημιουργεί ένα span για κάθε αίτημα HTTP προς τον εξυπηρετητή. Το γονικό περιεχόμενο μεταφέρεται από τον καλούντα κώδικα μέσω Context.current(), που επιτρέπει τη σύνδεση του trace στην πλευρά του πελάτη με το trace στην πλευρά του εξυπηρετητή.

Υλοποίηση ιχνηλάτησης μέσω OpenTelemetry

Το OpenTelemetry είναι το de facto πρότυπο για τη συλλογή δεδομένων trace. Παρέχει ενιαίο API για τη δημιουργία span, αυτόματη ενσωμάτωση δημοφιλών βιβλιοθηκών και ευέλικτο μηχανισμό εξαγωγής δεδομένων σε διάφορα backend: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Αυτόματη ενσωμάτωση

Το OpenTelemetry υποστηρίζει αυτόματη δημιουργία span για δημοφιλή frameworks: Spring Boot, Ktor, Flask, Express, gRPC. Ο προγραμματιστής πρέπει απλώς να προσθέσει μια εξάρτηση στο έργο, και η βιβλιοθήκη παρακολουθεί ανεξάρτητα τα εισερχόμενα και εξερχόμενα αιτήματα. Το Auto-instrumentation για Java χρησιμοποιεί javaagent, που τροποποιεί το bytecode εν κινήσει χωρίς να αλλάζει τον πηγαίο κώδικα.

Για κινητές πλατφόρμες, το OpenTelemetry παρέχει Swift SDK και Kotlin SDK. Δημιουργούν αυτόματα span για αιτήματα δικτύου (URLSession, OkHttp), εργασία με βάση δεδομένων (CoreData, Room) και εργασίες υποβάθρου. Ο προγραμματιστής μπορεί να προσθέσει προσαρμοσμένα span για την επιχειρηματική λογική.

Εξαγωγή δεδομένων

Τα συλλεγμένα span αποστέλλονται στον συλλέκτη μέσω του πρωτοκόλλου OTLP (OpenTelemetry Protocol). Ο συλλέκτης μπορεί να αποθηκεύει προσωρινά, να φιλτράρει και να ανακατευθύνει δεδομένα σε ένα ή περισσότερα συστήματα αποθήκευσης. Σύμφωνα με την τεκμηρίωση του OpenTelemetry, η τυπική καθυστέρηση από τη δημιουργία ενός span έως την εμφάνισή του στον πίνακα ελέγχου είναι 2–5 δευτερόλεπτα κατά τη χρήση εξαγωγής gRPC.

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

Ο κώδικας σε Swift ενεργοποιεί την αυτόματη ενσωμάτωση του επιπέδου δικτύου και δημιουργεί ένα προσαρμοσμένο span για τη λειτουργία λήψης προφίλ χρήστη. Το γνώρισμα user.id επιτρέπει το μεταγενέστερο φιλτράρισμα trace ανά συγκεκριμένο χρήστη.

Στρατηγικές δειγματοληψίας trace

Σε συστήματα υψηλής φόρτωσης, είναι αδύνατη η ιχνηλάτηση κάθε αιτήματος — αυτό θα δημιουργούσε απαράδεκτη φόρτωση στην αποθήκευση και το δίκτυο. Η δειγματοληψία λύνει αυτό το πρόβλημα αποθηκεύοντας μόνο ένα μέρος των trace. Η επιλογή στρατηγικής επηρεάζει άμεσα την πληρότητα των δεδομένων και το κόστος υποδομής.

Head-based sampling

Η απόφαση για αποθήκευση ενός trace λαμβάνεται τη στιγμή της δημιουργίας του — στο κεντρικό span. Η απλούστερη και πιο διαδεδομένη προσέγγιση: ένα σταθερό ποσοστό αιτημάτων (π.χ. 5%) αποθηκεύεται, τα υπόλοιπα απορρίπτονται. Μειονέκτημα — δεν μπορεί να εγγυηθεί ότι σπάνια σφάλματα θα συλληφθούν. Το Probability sampler στο OpenTelemetry υποστηρίζει ρύθμιση πιθανότητας από 0,0 έως 1,0.

Tail-based sampling

Η απόφαση αναβάλλεται μέχρι την ολοκλήρωση όλων των span του trace. Ο αναλυτής αξιολογεί αν το trace περιέχει σφάλματα, υπέρβαση χρόνου ή ενδιαφέροντα γνωρίσματα, και μόνο τότε το αποθηκεύει. Αυτή η προσέγγιση απαιτεί προσωρινή αποθήκευση όλων των span στον συλλέκτη, που αυξάνει την κατανάλωση μνήμης. Σύμφωνα με τα δεδομένα Grafana Labs, η tail-based sampling είναι 40–60% πιο αποδοτική όσον αφορά την αναλογία “τιμής για χρήσιμα δεδομένα” σε συστήματα με σπάνια αλλά κρίσιμα σφάλματα.

Διαφορά μεταξύ tracing και καταγραφής

Η καταγραφή καταγράφει ξεχωριστά συμβάντα με επίπεδο σπουδαιότητας (info, warn, error), αλλά δεν τα συνδέει στο πλαίσιο ενός αιτήματος. Η ιχνηλάτηση, αντίθετα, δημιουργεί ένα δομημένο δέντρο λειτουργιών που ανήκουν σε ένα αίτημα άκρο-προς-άκρο. Στην πράξη, αυτές οι δύο προσεγγίσεις δεν αλληλοαποκλείονται, αλλά αλληλοσυμπληρώνονται.

Τα αρχεία καταγραφής είναι αποτελεσματικά για λεπτομερή ανάλυση ενός συγκεκριμένου σφάλματος: ο προγραμματιστής βλέπει το ακριβές μήνυμα, την αναδρομή στοιχείων, τις τιμές μεταβλητών. Η ιχνηλάτηση απαντά στην ερώτηση “γιατί το αίτημα διαρκεί 5 δευτερόλεπτα” — δείχνει ποια μικροϋπηρεσία ή κλήση πήρε τον περισσότερο χρόνο. Σύμφωνα με τα δεδομένα Honeycomb (2024), οι ομάδες που χρησιμοποιούν ιχνηλάτηση μαζί με καταγραφή βρίσκουν τη βασική αιτία περιστατικών 2,3 φορές γρηγορότερα.

Η σύγχρονη προσέγγιση — observability — συνδυάζει trace, μετρικές και αρχεία καταγραφής σε ένα ενιαίο σύστημα. Το OpenTelemetry υποστηρίζει συσχέτιση μεταξύ αυτών των τριών σημάτων: κάθε span μπορεί να περιέχει αναφορές σε σχετικά αρχεία καταγραφής, και οι μετρικές μπορούν να επισημαίνονται με trace_id για πλοήγηση σε συγκεκριμένα trace.