Mikroservis memarlığında hər bir sorğu bir neçə xidmətin arasından keçir. Bu xidmətlərin hər birinin öz logu və metrikası var, amma bunlar təkbaşına suala cavab vermir: "Bu konkret sorğu niyə yavaş idi?" Distributed tracing (paylanmış izləmə) məhz bu sualı cavablandırmaq üçün yaranıb — o, bir sorğunun bütün səyahətini, hansı xidmətdən nə qədər vaxt keçirdiyini və harada gözləməyə düşdüyünü vahid şəkildə göstərir.
Yeni praktiki bələdçidə vurğulanan əsas anlayışlardan biri span ağacıdır. Hər span bir iş vahidini təmsil edir və bir-birinə valideyn-uşaq əlaqəsi ilə bağlıdır. Burada ən vacib göstərici self time — yəni spanın öz işinə sərf etdiyi vaxtdır, uşaq spanların vaxtı çıxılmaqla. Məsələn, OrderService 1820 millisaniyə görünə bilər, amma əslində onun öz kodu cəmi 23 millisaniyə çəkib, qalan vaxt isə PaymentService çağırışını gözləməkdə keçib. Bu ayırma olmadan səhv xidməti araşdırmaq çox asandır.
Bələdçinin diqqət çəkən məqamlarından biri də propagation — yəni iz kontekstinin bütün sərhədlərdən ötürülməsidir. HTTP və gRPC çağırışlarında OpenTelemetry avtomatik olaraq "W3C Trace Context" başlığını yayır, amma mesaj brokerləri, background işləri və bəzi verilənlər bazası kitabxanaları üçün konteksti əl ilə ötürmək lazımdır. Əgər bir yerdə bu ötürülməni unutsanız, trace sakitcə qırılır və hadisənin sonrakı hissəsini heç kim görə bilmir.
Praktikada diaqnostika adətən flame graph ilə başlayır: bu qrafikdə hər span üfüqi zolaq kimi göstərilir və ən geniş zolaq dərhal gözə dəyir. Standart iş axını belədir: alert və ya metrik göstəricisi — məsələn, p99 latensiyasının artması — əsasında nümunə trace tapılır, flame graph'da dominant span müəyyən edilir və onun atributlarına baxılır. Çox vaxt kök səbəb sizin kodunuz deyil, xarici ödəniş şlüzü kimi üçüncü tərəf bir xidmət olur. Buna görə də sərhəd spanlarına URL, status kodu, retry sayı kimi zəngin atributlar yazmaq tövsiyə edilir.
Müəllif həmçinin xatırladır ki, hər xidmətin müstəqil sampling qərarı versə, çoxxidmətli zəncirdə tam trace tutmaq ehtimalı kəskin azalır. Buna görə qərar trace'in başlanğıcında bir dəfə verilməli və traceparent flag'i ilə bütün xidmətlərə ötürülməlidir. Asinxron hadisə zəncirlərində isə OpenTelemetry trace-ləri çox vaxt ayrı olur — onları bir-birinə bağlamaq üçün correlation ID və ya span link istifadə edilir. Nəticədə distributed tracing mikroservis sistemlərinin ən güclü diaqnostika vasitəsinə çevrilir, amma düzgün konfiqurasiya və intizam tələb edir.
