Paylanmış tracing və telemetriya

1. Giriş

Müasir servis- orientasiyalı arxitektura (SOA), mikroxidmətlər və bulud həlləri dünyasında bir istifadəçi sorğusu nəticəni qaytarmazdan əvvəl onlarla müxtəlif xidmətdən "uçub" keçə bilər. Həmin "marşrut"un hər bir node-u öz loqlarını yazır, amma necə başa düşmək olar ki, səhv və ya gecikmə məhz bu konkret sorğu ilə bağlıdır?

Paylanmış tracing logistika üzrə göndərişin tracking sistemi kimidir: göndərişinizin hansı məntəqələrdən keçdiyini, harada gecikdiyini və harada problem yarandığını görürsünüz. Proqramlaşdırma dünyasında isə bu, bir sorğunun bütün servis boyunca "səyahətini" izləmək, harada nə qədər vaxt sərf edildiyini və harada səhv və ya gecikmə olduğunu anlamaq imkanıdır.

Niyə tracing lazımdır?

• Səhvləri lokallaşdırmaq: Nəsə səhv gedərsə, dərhal görürsünüz ki, hansı servisdə, hansı mərhələdə və hətta hansı konkret metod çağırılıb.
• "Dar boğaz"ları tapmaq: Tracing göstərəcək ki, xidmətləriniz harada "yavaşlayır" və hansı mərhələdə ən çox vaxt itirilir.
• İstifadəçi ssenarilərinin analitikası: Müştərilərin xidmətlərinizi necə istifadə etdiyini başa düşə və haraya optimizasiya yatırmaq lazım olduğunu müəyyən edə bilərsiniz.

Necə işləyir?

Hər sorğuya unikal track identifikator (TraceId) verilir və bu identifikator sorğu ilə birlikdə bütün servis stacki boyunca "səyahət edir": frontend-dən backend-ə, API-dən verilənlər bazasına və geri. Hər mərhələdə "span"lar yaranır (spans), hansılar ki, əməliyyatın icra müddətini və əlavə hadisələri qeyd edir. Nəticədə əməliyyatların davamlılığı və onların əlaqələri ilə ağac (qraf) əldə edirsiniz.

Paylanmış tracing-in əsas obyektləri və terminləri

2. OpenTelemetry: observability üçün açıq standart

OpenTelemetry haqqında qısa

OpenTelemetry — müxtəlif tətbiqlərdən telemetriya (tracing, metrics, logs) toplamaq üçün açıq standart və alətlər toplusudur. O, Cloud Native Computing Foundation (CNCF) tərəfindən dəstəklənir və bulud və paylanmış tətbiqlər dünyasında de-facto standart olub.

OpenTelemetry (qısa OTel) edə bilir:

• Avtomatik olaraq traces, metrics və logs toplamaq və göndərmək;
• Əsas proqramlaşdırma dilləri ilə işləmək — o cümlədən C#, Java, Python və başqaları;
• Məlumatları observability sistemlərinə — Jaeger, Zipkin, Azure Monitor, Grafana və s. — ötürmək;
• Plugins vasitəsilə genişlənmək və hər cür stack-ə konfiqurasiya olunmaq.

Niyə məhz OpenTelemetry?

• Vendor-dan asılı olmamaq: OTel konkret şirkətin məhsulu deyil, standartdır.
• Uyğunluq: Əsas tracing formatlarını dəstəkləyir, APM sistemləri ilə asan inteqrasiya olur.
• Avtomatizasiya: İşin böyük hissəsini (məsələn, HTTP sorğularının tracing-i) minimal konfiqurasiya ilə özü edə bilər.
• Miqyaslana bilənlik: OTel kiçik və çox böyük sistemlərdə yaxşı işləyir.

OpenTelemetry arxitekturası: sadə izah

Qatıları çaşdırmamaq üçün OTel-də tipik tracing data axınını təsəvvür edək.

flowchart LR
    subgraph Tətbiq
        A[OpenTelemetry SDK]
    end
    A -->|Traces, metrics, logs| B[OpenTelemetry Collector]
    B -->|Eksport| C[Jaeger/Zipkin/Grafana/Azure/Application Insights və s.]

1. OpenTelemetry SDK: Birbaşa tətbiqinizə inteqrasiya olunur (məsələn .NET üçün NuGet paketləri vasitəsilə).
2. OTel Collector: Ayrı bir servis-konsentrator (tez-tez Docker konteyner kimi deploy edilir), bütün tətbiqlərdən trace məlumatlarını qəbul edir və onları istədiyiniz yerə eksport edir.
3. Observability frontend: Gözəl qrafiklər, ağaclar olan sistem, burada trace-ləri filterləyib analiz edirsiniz.

3. C#/.NET-də tracing ilə tez başlamaq

Gəlin tədris tətbiqimizə əsas paylanmış tracing əlavə edək. Əsas addımlar kifayət qədər sadədir.

NuGet paketlərini quraşdırmaq

dotnet add package OpenTelemetry
dotnet add package OpenTelemetry.Exporter.Console

OpenTelemetry — SDK-nın əsas implementasiyası;
OpenTelemetry.Exporter.Console — trace-ləri konsola eksport edir (əvəz etmək olar Jaeger, Zipkin və s. ilə).

Tracing-in minimal konfiqurasiyası

Konsole tətbiqi üçün Program.cs faylında:

using OpenTelemetry;
using OpenTelemetry.Trace;

class Program
{
    static void Main(string[] args)
    {
        // Tracing-i konfiqurasiya edirik
        using var tracerProvider = Sdk.CreateTracerProviderBuilder()
            .AddSource("DemoApp") // Mənbə adını göstəririk
            .AddConsoleExporter() // Trace-ləri konsola eksport edirik
            .Build();

        var source = new System.Diagnostics.ActivitySource("DemoApp");

        // Yeni trace başlatmaq (root span)
        using (var activity = source.StartActivity("Bəsit əməliyyat"))
        {
            DoWork();
        }
    }

    static void DoWork()
    {
        // Tətbiqin bəzi loqikası...
        System.Threading.Thread.Sleep(300);
    }
}

Burada nə baş verir?

• Tracer provider yaradırıq, mənbəni ("DemoApp") qeyd edirik və konsol exporter əlavə edirik AddConsoleExporter().
• Proqramın kökündə ActivitySource vasitəsilə yeni "activity" (span) başladılır.
• İçəridə izləmaq istədiyimiz faydalı işi edirik.

Nəticə:

Activity.Id:          0b69e3e97ca5f14d
Activity.Operation:   Bəsit əməliyyat
Duration: 00:00:00.3001082
...

HTTP və verilənlər bazası üçün avtomatik instrumentasiya

OpenTelemetry populyar kitabxanalar üçün instrumentasiya — avtomatik tracing dəstəyi təklif edir. Məsələn, HttpClient vasitəsilə çağırışlar və ADO.NET sorğuları sizin kodunuza müdaxilə etmədən toplanıla bilər.

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddHttpClientInstrumentation() // HTTP sorğular
    .AddSqlClientInstrumentation()  // SQL sorğular (əgər istifadə edirsinizsə)
    .AddConsoleExporter()
    .Build();

İndi HttpClient vasitəsilə etdiyiniz çağırışlar və SQL ilə iş avtomatik olaraq trace-lərdə görünəcək.

4. Tracing-in vizuallaşdırılması

Konsola çıxış yalnız ilk addımdır. Həqiqi fayda üçün vizuallaşdırma frontend-i istifadə etmək daha yaxşıdır.

Jaeger

Jaeger — tracing vizuallaşdırması üçün ən məşhur open-source sistemlərdən biridir.

1. Jaeger-i yerləşdirirsiniz (məsələn, Docker vasitəsilə).
2. AddConsoleExporter() əvəzinə istifadə edirsiniz:

   .AddJaegerExporter(options =>
   {
       options.AgentHost = "localhost";
       options.AgentPort = 6831;
   })
   

3. İndi bütün trace-lər Jaeger UI-də göstəriləcək — TraceId üzrə filtrləmək, detallı zaman diaqramlarına baxmaq mümkündür.

Tam təlimat: OpenTelemetry Jaeger Exporter for .NET

5. Faydalı nüanslar

Yanaşmaların müqayisəsi

OTel yoxdursa, siz əl ilə TraceId-ni loglara kopyalayır, onu ötürməyi unutmamağı ümid edirsiniz və insident analizi zamanı əziyyət çəkirsiniz. OTel ilə bütün zəncir avtomatik qurulur və bir kliklə vizuallaşdırılır.

Arxitektura nümunəsi

[Veb-müştəri] --> [API-servis] --> [Auth-servis] --> [DB-servis]

İstifadəçi düyməni kliklədikdə sorğu bu servislerden keçir. OTel ilə siz hər birində TraceId "ipini" çəkib logikanı birləşdirə biləcəksiniz.

• Hər servisdə OTel SDK HTTP başlıqlarından TraceId-ni avtomatik aşkar edir və zənciri davam etdirir.
• Nəticədə tək bir trace açmaqla harada neçə millisekund sərf olunduğunu, nə baş verdiyini və harada səhv olduğunu görə bilərsiniz.

Real layihələrdə tətbiqi və müsahibələrdə

• Mikroxidmət sistemləri və paylanmış tətbiqlər (fintech, marketplace-lər, SaaS və s.).
• DevOps/SRE: problemlərin tez lokallaşdırılması.
• SLA və xidmətlərin cavabvermə qabiliyyətinin yaxşılaşdırılması.
• Profilinq və optimizasiya.
• Müsahibələrdə — yetkin mühəndislik praktikasını göstərmək üçün.

6. Tipik səhvlər və tətbiq xüsusiyyətləri

TraceContext-i ötürməyi unutmusunuz. Əgər servislər arasında TraceId ötürülmürsə (məsələn, lazım olan HTTP başlıqları ötürülmədi), trace-lər qırılacaq — onlar izolyasiya olunmuş "nöqtələr" kimi görünəcək və observability-nin gözəlliyi itəcək.

Instrumentasiya olunmamış kod. Əgər sizin kitabxana və ya framework instrumentasiya dəstəkləmir, bəzi əməliyyatlar trac-e daxil olmayacaq (amma həmişə span-ları əl ilə ActivitySource və StartActivity() vasitəsilə yarada bilərsiniz).

Verilənlərin həddindən artıq toplanması. Hər sorğu üçün trace toplamaq baha başa gələ bilər, xüsusən böyük production-da. Adətən tracing-i ya sample rate ilə məhdudlaşdırırlar, ya da yalnız müəyyən sorğular (səhvlər, yavaş sorğular) üçün aktiv edirlər.

Performans. OTel tətbiqi asinxron eksportdan istifadə edərkən performansa minimal təsir edir, amma çox yüksək trafik zamanı overhead-ı izləyin və sampling dərəcəsini tənzimləyin.