Problem: "checkout yavaşdır" və səbəbi tapmaq üçün yol yoxdur

İstifadəçi checkout-un uzun çəkdiyini bildirir. Servisdə log var, amma hər sətir sərbəst mətndir, dörd instance işləyir və bir sorğu üç başqa servisə toxunur. İstifadəçinin email-ini grep edirsiniz, bir instance-da bir neçə sətir tapırsınız, digərlərində heç nə, və vaxtın bazaya, ödəniş çağırışına, yoxsa garbage collection pauzasına getdiyini deyə bilmirsiniz.

Observability işləyən sistemin yaydığı datadan, hər sual üçün yeni kod göndərmədən yeni suallar vermək bacarığıdır. Üç növ siqnal bunun çoxunu əhatə edir: log, metrik və trace. Onlar fərqli suallara cavab verir və bir-birinə bağlı olanda ən güclüdür.

Log: nə baş verdi, ətraflı

Log-lar ayrı-ayrı hadisələrdir. Dəyəri strukturdan asılıdır. Payment failed for order 42 kimi sətri etibarlı filtrləmək olmur; sahələri olan JSON hadisəsini olur.

{"ts":"2026-10-19T09:14:03Z","level":"WARN","service":"checkout", "traceId":"4bf92f3577b34da6a3ce929d0e0e4736","orderId":"42", "event":"payment_declined","reasonCode":"INSUFFICIENT_FUNDS"}

Fayda verən qaydalar:

  • Deploy olunan mühitlərdə JSON (və ya başqa structured format), lokal mühitdə insan üçün oxunaqlı çıxış istifadə edin.
  • Hər sətirə correlation id qoyun. Micrometer Tracing olan Spring Boot-da trace id və span id logging MDC-yə yazılır, ona görə id-ləri əllə ötürmək əvəzinə onları log pattern-ə və ya JSON encoder-ə əlavə edirsiniz.
  • Bütün payload-ları yox, hadisələri və identifikatorları log-layın. Parolları, token-ləri, kart datasını və lazımsız şəxsi məlumatı heç vaxt yazmayın. Log-lara saxlanmalı, girişi nəzarətdə olan və cədvəl üzrə silinən data kimi baxın.
  • Səviyyələri məqsədlə seçin: ERROR kimsənin baxması lazım olduğunu, WARN qeyri-adi, amma idarə olunan halı, INFO biznes baxımından vacib hadisələri bildirir. Exception-ı yayıldıqca hər qatda log-lamaq təkrarlar yaradır; onu bir dəfə, idarə olunduğu yerdə yazın.

Metrik: sistem zaman keçdikcə necə davranır

Metriklər zamana görə aqreqasiya olunmuş rəqəmlərdir. Saxlamaq ucuzdur, dashboard və alert üçün yaxşıdır, konkret bir sorğunu izah etmək üçün zəifdir. Nəyi ölçəcəyinizi seçmək üçün iki siyahı kömək edir.

  • Sorğu əsaslı servislər üçün RED: Rate (saniyədə sorğu), Errors (uğursuz sorğuların sayı və ya nisbəti), Duration (gecikmə paylanması).
  • CPU, yaddaş, connection pool və növbə kimi resurslar üçün USE: Utilization, Saturation, Errors.

Micrometer ilə Spring Boot Actuator HTTP server metriklərini, JVM yaddaşı və GC-ni, thread pool-ları və HikariCP connection pool-u artıq təqdim edir. Biznes metriklərini özünüz əlavə edin.

@Componentclass PaymentMetrics {    private final Counter declined;    private final Timer gatewayCall;    PaymentMetrics(MeterRegistry registry) {        declined = registry.counter("payments.declined",            "reason", "insufficient_funds");        gatewayCall = registry.timer("payments.gateway.duration");    }    void declined() { declined.increment(); }    <T> T timed(Supplier<T> call) { return gatewayCall.record(call); }}

İki xəbərdarlıq. Birincisi, gecikmə paylanmadır: orta qiymət istifadəçilərin həqiqətən hiss etdiyi yavaş sorğuları gizlədir, ona görə percentile və ya histogram-lara baxın. İkincisi, cardinality: tag dəyərlərinin hər unikal kombinasiyası yeni time series yaradır. userId kimi tag və ya id-li xam URL series sayını metrik backend-in çətinlik çəkəcəyi qədər artıra bilər. Tag-ların dəyərləri az və məhdud olmalıdır.

Trace: vaxt hara getdi

Trace bir sorğunu servislər boyunca izləyir. O span-lardan ibarətdir: span-ın adı, başlama və bitmə vaxtı, atributları və parent-i var. Trace id servislər arasında sorğu header-lərində gedir (ümumi standart W3C Trace Context formatıdır), fərqli proseslərin bir mənzərəyə töhfə verməsi məhz bununla mümkün olur.

GET /checkout                          [==================== 840 ms]
  ├─ SELECT cart                        [==                   ]
  ├─ POST /payments (payment-service)   [==============       ]
  │    └─ INSERT payment                [===                  ]
  └─ publish OrderPlaced                [=                    ]

Bu cür waterfall giriş sualına tez cavab verir: vaxt bazada yox, payment servisinə çağırışın içindədir. OpenTelemetry trace, metrik və log yaymaq üçün vendor-neytral API, SDK və wire protokol toplusudur. Spring Boot 3-də adi yol Micrometer Observation və Micrometer Tracing ilə OpenTelemetry bridge-i və seçdiyiniz backend-ə exporter-dir. HTTP client, server və JDBC üçün instrumentasiya avtomatik ola bilər; vacib biznes addımlarının ətrafına əllə span əlavə edin.

Hər sorğunu trace etmək bahalı ola bilər, ona görə əksər sistemlər sampling edir. Head sampling qərarı sorğunun əvvəlində, tail sampling isə bütün trace görüləndən sonra verir, məsələn xətalı bütün trace-ləri saxlamaq üçün. Siyasəti seçərkən nəzərə alın ki, nadir problemləri sampling ilə itirmək asandır.

Üçü necə bağlanır

İş axını adətən belədir: metrikdən gələn alert nəsə səhv olduğunu bildirir; dashboard hansı servis və ya endpoint olduğunu daraldır; trace sorğu yolunda vaxtın və ya xətanın harada olduğunu göstərir; trace id ilə əlaqələndirilmiş log-lar detalı verir. Log-larda trace id yoxdursa və ya metrikləri deploy versiyası ilə bağlamaq mümkün deyilsə, zəncir qırılır. Tətbiq versiyasını və instance-ı resource atributu kimi əlavə edin ki, release-dən sonra davranış dəyişikliyi görünsün.

Alert dizaynı

İstifadəçinin hiss etdiyi simptomlar üzərində alert qurun, hər daxili səbəb üzərində yox. "Checkout-un xəta nisbəti bir neçə dəqiqə razılaşdırılmış həddən yuxarıdır" simptomdur. "CPU müəyyən rəqəmdən yuxarıdır" çox vaxt simptom deyil: servis normal ola bilər. Səbəblər diaqnostika üçün dashboard-larda yer almalıdır.

  • Hər alert əməli olmalıdır. Heç kimin etməli işi yoxdursa, bu səs-küydür və insanları pager-i ignor etməyə öyrədir.
  • Hər alert-i qısa runbook-a bağlayın: nə deməkdir, necə yoxlamaq, necə yumşaltmaq.
  • Service level objective təyin edin (məsələn, əlçatanlıq və ya gecikmə hədəfi) və tək sıçrayışlara yox, error budget-in nə sürətlə sərf olunduğuna alert qurun.
  • Yoxluğa da alert qurun: heç metrik göndərməyən servis sağlam deyil.

Tez-tez edilən səhvlər

  • Id-siz sərbəst mətn log-lar.
  • Production-da daimi DEBUG səviyyəsi; saxlama xərci və data ifşası.
  • Məhdud olmayan tag-lı metriklər.
  • Yeganə gecikmə rəqəmi kimi orta qiymət.
  • Heç kimin oxumadığı əlli panelli dashboard-lar; RED-ə bağlı yuxarı səviyyəli görünüş və servis üzrə detal səhifələri saxlayın.
  • Hər exception üçün alert.
  • Observability-yə funksiyanın hissəsi kimi yox, insidentdən sonrakı iş kimi yanaşmaq.

Güzəştlər

Bütün telemetriya CPU, şəbəkə və saxlama baxımından pul tələb edir. Sampling, saxlama müddəti və log səviyyələri tənzimləmə vasitələridir. Monolit ilə işləyən kiçik komanda structured log, Actuator metrikləri və əsas health alert-ləri ilə yaxşı keçinə bilər, sorğular proses sərhədlərini keçməyə başlayanda trace əlavə edər. Cavab verməli olduğunuz suallardan əvvəl mürəkkəbliyi almayın.

Yoxlama siyahısı

  • Trace id, servis və versiya olan JSON log-lar.
  • Endpoint üzrə RED metrikləri, pool və növbələr üçün USE metrikləri.
  • Percentile və ya histogram gecikməsi, məhdud tag dəyərləri.
  • Hər servis və mesaj addımında trace propagation.
  • Runbook-lu simptom əsaslı alert-lər.
  • Telemetriyada şəxsi məlumat və sirlər yoxdur.

Növbəti addım