Observability 2.0: OpenTelemetry, Paylanmış İzləmə (Distributed Tracing) və Cloud-Native Sistemlərdə APM Arxitekturası

Müasir proqram təminatı arxitekturası monolit strukturlardan sürətlə cloud-native, mikroservis və serverless arxitekturalarına doğru təkamül edir. Bu keçid çevikliyi, miqyaslana bilənliyi (scalability) və sistemlərin dözümlülüyünü artırsa da, özü ilə böyük bir mürəkkəblik gətirir. Yüzlərlə mikroservisin bir-biri ilə asinxron şəkildə əlaqə saxladığı, Kubernetes mühitində saniyələr ərzində konteynerlərin yaradılıb məhv edildiyi bir ekosistemdə ənənəvi monitorinq alətləri artıq yetərsiz qalır.

Bu nöqtədə qarşımıza Observability 2.0 konsepsiyası çıxır. Observability 2.0, sadəcə sistemin işlək olub-olmadığını yoxlamaqdan kənara çıxaraq, onun daxili vəziyyətini, performans darboğazlarını və xətaların kök səbəblərini (root cause) real zamanlı olaraq anlamağa imkan verir. Bu texniki məqalədə OpenTelemetry (OTel) standartını, paylanmış izləmə (distributed tracing) mexanizmlərini və müasir APM (Application Performance Monitoring) arxitekturasının qurulmasını dərindən təhlil edəcəyik.

---

Monitorinqdən Observability-yə Keçid: Niyə Ənənəvi Metodlar Kifayət Etmir?#

Ənənəvi monitorinq sistemləri (məsələn, sadə CPU/RAM metrik izləyiciləri və ya mərkəzləşdirilməmiş loq toplama alətləri) "məlum naməlumlar" (known-unknowns) üçün nəzərdə tutulmuşdur. Yəni, biz əvvəlcədən hansı metriklərin kritik olduğunu bilirik (məsələn, verilənlər bazası bağlantı limitinin aşılması) və bu göstəricilər üçün xəbərdarlıqlar (alerts) qururuq.

Lakin cloud-native sistemlərdə qarşılaşdığımız problemlərin böyük hissəsi "naməlum naməlumlar" (unknown-unknowns) kateqoriyasına aiddir. Sistemdə baş verən bir xəta eyni anda bir neçə fərqli mikroservisin, şəbəkə gecikməsinin (network latency) və ya üçüncü tərəf API-nin nasazlığının kombinasiyasından yarana bilər.

Observability-nin Qızıl Qaydası: Monitorinq sizə sistemin nə vaxt sıradan çıxdığını bildirir; Observability isə sistemin niyə və harada sıradan çıxdığını, hətta bu problemin hansı spesifik istifadəçi sorğusuna təsir etdiyini göstərir.

Ənənəvi APM alətlərinin ən böyük çatışmazlığı onların mülkiyyətçi (proprietary) agentlərdən asılı olmasıdır. Bu, həm yüksək resurs istehlakına (overhead), həm də vendor kilidinə (vendor lock-in) səbəb olur. Observability 2.0 isə tamamilə açıq standartlara və vahid məlumat modelinə əsaslanır.

---

Observability 2.0-ın Sütunları: M.E.L.T. Modeli#

Observability-nin təməlini dörd əsas məlumat növü təşkil edir. Bunlar ingilis dilində M.E.L.T. (Metrics, Events, Logs, Traces) abreviaturası ilə tanınır:

1. Metriklər (Metrics): Müəyyən zaman kəsiyində aqreqasiya olunmuş rəqəmsal göstəricilərdir (məsələn, CPU istifadəsi, saniyədə gələn sorğu sayı - RPS, xəta dərəcəsi). Metriklər sistemin ümumi sağlamlıq vəziyyətini anlamaq üçün ucuz və sürətli üsuldur.
2. Hadisələr (Events): Sistemdə baş verən və diskret zaman nöqtələrinə malik olan mühüm dəyişikliklərdir (məsələn, yeni bir versiyanın tətbiqi - deployment, avtomatik miqyaslanma hadisəsi).
3. Loqlar (Logs): Müəyyən bir hadisə baş verdikdə tətbiq tərəfindən yaradılan strukturlaşdırılmış və ya strukturlaşdırılmamış mətn sətirləridir. Loqlar detal baxımından zəngindir, lakin paylanmış sistemlərdə təkbaşına xətanın izini tapmaq üçün kifayət etmir.
4. İzlər (Traces): Bir istifadəçi sorğusunun (məsələn, "Səbətə əlavə et" düyməsinə kliklənməsi) sistem daxilində keçdiyi bütün yolu və mikroservislər arasındakı qarşılıqlı əlaqəni göstərən zəncirdir.

Observability 2.0-da bu dörd komponent bir-birindən ayrı silolar şəklində deyil, vahid bir kontekst daxilində birləşdirilir. Məsələn, bir trace daxilindəki xüsusi bir addım (span) birbaşa həmin saniyədə yaranmış loqlara və həmin mikroservisin metrik göstəricilərinə keçid imkanı verir.

---

OpenTelemetry (OTel): Vahid Standartın Arxitekturası#

OpenTelemetry, CNCF (Cloud Native Computing Foundation) tərəfindən idarə olunan və sənayedə qəbul edilmiş vahid observability çərçivəsidir (framework). OTel, tətbiqlərdən telemetriya məlumatlarının (metrics, logs, traces) toplanması, emalı və istənilən analitik platformaya (Jaeger, Prometheus, Datadog, Dynatrace və s.) göndərilməsi üçün vahid API, SDK və alətlər dəsti təqdim edir.

OpenTelemetry arxitekturası üç əsas komponentdən ibarətdir:

• OpenTelemetry API: Tətbiq kodunda telemetriya məlumatlarını yaratmaq üçün istifadə olunan proqramlaşdırma interfeysidir. API tamamilə asılılıqsızdır və heç bir tətbiqetmə (implementation) detallarını ehtiva etmir.
• OpenTelemetry SDK: API tərəfindən yaradılan məlumatları toplayan, buferləyən, emal edən və ixrac edən (export) real tətbiqetmə hissəsidir. SDK proqramlaşdırma dilinə spesifikdir.
• OpenTelemetry Collector: Tətbiqlərdən gələn telemetriya məlumatlarını qəbul edən, filtrasiya və transformasiya edən və sonda hədəf analitik bazalara göndərən müstəqil proxy xidmətidir.

OpenTelemetry Collector İş Axını (Pipeline)

Collector-un daxili iş prinsipi üç mərhələli konveyer (pipeline) arxitekturasına əsaslanır:

[ Receivers ]  --->  [ Processors ]  --->  [ Exporters ]

• Receivers (Qəbuledicilər): Müxtəlif formatlarda (OTLP, Prometheus, Jaeger, Zipkin) gələn məlumatları qəbul edir.
• Processors (Emal edənlər): Məlumatları təmizləyir, fərdiləşdirir (məsələn, fərdi məlumatların - PII maskalanması), toplu şəkildə qruplaşdırır (batching) və ya nümunələmə (sampling) tətbiq edir.
• Exporters (İxracatçılar): Emal olunmuş məlumatları təyin olunmuş hədəf sistemlərə (məsələn, Prometheus və ya Elasticsearch) göndərir.

---

Paylanmış İzləmə (Distributed Tracing) və Kontekst Ötürülməsi (Context Propagation)#

Paylanmış izləmənin təməlində Kontekst Ötürülməsi (Context Propagation) dayanır. Bir sorğu sistemə daxil olduqda, ona unikal bir Trace ID təyin edilir. Sorğu bir mikroservisdən digərinə HTTP, gRPC və ya mesaj növbələri (Message Queues) vasitəsilə keçdikdə, bu Trace ID və digər metadata (məsələn, Span ID, Baggage) sorğunun başlıqlarında (headers) ötürülür.

W3C Trace Context standartına əsasən, HTTP başlıqlarında bu məlumat aşağıdakı formatda ötürülür:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

Burada:

• 00: Versiya nömrəsi.
• 4bf92f3577b34da6a3ce929d0e0e4736: Unikal Trace ID.
• 00f067aa0ba902b7: Cari əməliyyatı təmsil edən Span ID.
• 01: Trace seçimləri (məsələn, sorğunun nümunələnib-nümunələnmədiyi - sampled flag).

---

Müqayisə Cədvəli: Ənənəvi APM və OpenTelemetry Əsaslı Observability 2.0#

---

Praktik Tətbiq: Node.js və OpenTelemetry SDK ilə Paylanmış İzləmənin Qurulması#

Aşağıdakı nümunədə, Node.js və Express.js mühitində OpenTelemetry SDK-nın necə qurulacağını və avtomatik instrumentasiya (auto-instrumentation) vasitəsilə HTTP sorğularının necə izlənəcəyini addım-addım görəcəyik.

Addım 1: Lazımi Paketlərin Quraşdırılması

İlk növbədə, terminalda aşağıdakı paketləri quraşdırırıq:

npm install @opentelemetry/sdk-node \
            @opentelemetry/auto-instrumentations-node \
            @opentelemetry/exporter-trace-otlp-grpc \
            @opentelemetry/api

Addım 2: OpenTelemetry İnitializasiya Skriptinin Yazılması

Tətbiqimiz işə düşməzdən əvvəl işləyəcək tracing.js faylını yaradırıq. Bu fayl SDK-nı konfiqurasiya edir və telemetriya məlumatlarını yerli OpenTelemetry Collector-a (və ya birbaşa analitik backend-ə) göndərir:

// tracing.js
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-grpc');
const { Resource } = require('@opentelemetry/resources');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');

// Telemetriya məlumatlarının göndəriləcəyi OTLP Exporter konfiqurasiyası
const traceExporter = new OTLPTraceExporter({
  // Yerli və ya uzaqdakı OTel Collector ünvanı
  url: 'grpc://localhost:4317',
});

// SDK-nın yaradılması və konfiqurasiyası
const sdk = new NodeSDK({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: 'payment-service',
    [SemanticResourceAttributes.SERVICE_VERSION]: '1.0.0',
    [SemanticResourceAttributes.DEPLOYMENT_ENVIRONMENT]: 'production',
  }),
  traceExporter: traceExporter,
  // HTTP, Express, gRPC, MongoDB və s. üçün avtomatik izləməni aktivləşdiririk
  instrumentations: [getNodeAutoInstrumentations()],
});

// SDK-nı işə salırıq
sdk.start();

// Tətbiq dayandıqda SDK-nı təhlükəsiz şəkildə bağlayırıq
process.on('SIGTERM', () => {
  sdk.shutdown()
    .then(() => console.log('Tracing uğurla dayandırıldı'))
    .catch((error) => console.log('Tracing dayandırılarkən xəta:', error))
    .finally(() => process.exit(0));
});

Addım 3: Tətbiqin İşə Salınması

Tətbiqimizi işə salarkən tracing.js faylını ən birinci yükləməliyik ki, bütün digər modullar (məsələn, express, pg və s.) düzgün şəkildə instrumentasiya olunsun:

node -r ./tracing.js app.js

Bu sadə konfiqurasiya ilə tətbiqinizə gələn hər bir HTTP sorğusu, verilənlər bazası sorğuları və xarici API çağırışları avtomatik olaraq izlənəcək və vahid bir trace daxilində qruplaşdırılacaqdır.

---

Cloud-Native Sistemlərdə Observability-nin Biznes və Texniki ROI-si#

Observability-yə investisiya etmək, sadəcə mühəndislərin işini asanlaşdırmır, həm də birbaşa biznes göstəricilərinə (KPI) təsir edir.

MTTR (Mean Time to Resolution) Göstəricisinin Azaldılması

Ənənəvi sistemlərdə bir xətanın tapılması və həll edilməsi saatlar, bəzən günlər çəkə bilər. Mühəndislər fərqli serverlərin loqlarını əllə analiz etməli, vaxt fərqlərini müqayisə etməli olurlar. Observability 2.0 və paylanmış izləmə sayəsində xətanın hansı mikroservisdə, hansı kod sətirində və hansı verilənlər bazası sorğusunda baş verdiyi saniyələr ərzində vizual olaraq müəyyən edilir. Bu, MTTR göstəricisini orta hesabla 70-80% azaldır.

Resurs Optimizasiyası və Bulud Xərclərinin Azaldılması

OpenTelemetry vasitəsilə əldə edilən dərin performans metrikləri sayəsində sistemdəki gizli darboğazlar (bottlenecks) aşkar edilir. Məsələn, lazımsız yerə təkrar olunan verilənlər bazası sorğuları (N+1 problemi) və ya yaddaş sızmaları (memory leaks) müəyyən edilərək aradan qaldırılır. Bu isə öz növbəsində Kubernetes klasterlərinin və bulud infrastrukturunun (AWS, GCP, Azure) daha səmərəli istifadəsinə və xərclərin optimallaşdırılmasına gətirib çıxarır.

İstifadəçi Təcrübəsinin (UX) Yaxşılaşdırılması

Sistemdəki yavaşlamalar (latency spikes) birbaşa müştəri məmnuniyyətinə və dönüşüm nisbətinə (conversion rate) təsir edir. Paylanmış izləmə sayəsində ən yavaş işləyən API son nöqtələri (endpoints) və asinxron proseslər müəyyən edilərək optimallaşdırılır, nəticədə ultra-sürətli və stabil bir istifadəçi təcrübəsi təmin olunur.

---

Nəticə və Gələcək Trendlər#

Observability 2.0, müasir proqram mühəndisliyində lüks deyil, cloud-native sistemlərin idarə olunması üçün təməl bir ehtiyacdır. OpenTelemetry-nin sənaye standartına çevrilməsi ilə birlikdə, proqram təminatı inkişaf etdiriciləri və DevOps mühəndisləri vendor asılılığından xilas olaraq daha çevik, miqyaslana bilən və şəffaf sistemlər qura bilirlər.

Gələcəkdə observability sahəsində iki böyük trendin ön plana çıxacağını görəcəyik:

• eBPF (Extended Berkeley Packet Filter) İnteqrasiyası: Tətbiq koduna heç bir SDK və ya agent əlavə etmədən, birbaşa Linux nüvəsi (kernel) səviyyəsində telemetriya məlumatlarının sıfır performans itkisi ilə toplanması.
• AIOps və Süni İntellekt Dəstəkli Anomaliya Təyini: Toplanan milyardlarla metrik və trace məlumatlarının AI modelləri tərəfindən analiz edilərək, potensial sistem qəzalarının hələ baş vermədən əvvəl proqnozlaşdırılması və avtomatik həll edilməsi (self-healing).

Müasir rəqəmsal dünyada rəqabət üstünlüyü qazanmaq və istifadəçilərə kəsintisiz xidmət təklif etmək üçün tətbiqlərinizdə bu gündən etibarən OpenTelemetry standartlarına keçid etməli və Observability 2.0 arxitekturasını tətbiq etməlisiniz.