Əsas fikir
İstifadəçinin gördüyü gecikmə və xətanı ölçün, sonra eyni vaxt aralığında uyğun trace, log və asılılıq metriklərinə keçin. Alət problemi avtomatik izah etmir; düzgün instrumentasiya və kontekst lazımdır.
Monitorinq və observability bir-birini tamamlayır
Monitorinq əvvəlcədən məlum olan şərtləri izləyir və hədd aşıldıqda komandaya xəbər verir: məsələn, xətaların artması və ya xidmətin cavab verməməsi. Observability sistemin daxili vəziyyətini onun yaratdığı telemetry-dən anlamaq qabiliyyətidir; loglar hadisəni, metriklər zaman üzrə ölçünü, trace isə sorğunun xidmətlər arasındakı yolunu göstərir. Monitorinq “problem varmı?” sualına, əlaqələndirilmiş telemetry isə “bu sorğu niyə yavaşdır?” sualına kömək edir. Heç biri düzgün mənbə, alət və sahə olmadan avtomatik kök səbəb zəmanəti vermir.
| Siqnal | Əsas sual | Nümunə |
|---|---|---|
| Metrik | Nə qədər, nə vaxt və hansı dəyişmə ilə? | Sorğu sayı, xəta payı, gecikmə. |
| Log | Hansı hadisə və kontekst baş verdi? | Asılılıq timeout-u və xəta kodu. |
| Trace | Bir sorğu hansı komponentlərdən keçdi? | API → xidmət → verilənlər bazası span-ları. |
APM-də istifadəçi sorğusundan asılılığa keçin
Application Performance Monitoring (APM) tətbiq və asılılıqların cavab vaxtı, xəta, sorğu həcmi və resurs istifadəsini izləyir. Sorğu yavaşdırsa, onun API-dən hansı servislərə, verilənlər bazasına, cache və mesaj növbəsinə keçdiyini yoxlayın. Buraxılış vaxtını, versiyanı və təsirlənən regionu eyni paneldə göstərmək geriləmənin harada başladığını tapmağa kömək edə bilər. Agent və ya bytecode instrumentasiyası əlavə yük və məxfilik təsiri yarada bilər; əvvəlcə kritik tətbiqdə miqyas və məlumat sahələrini sınaqdan keçirin.
Təsiri təsdiqləyin
Real istifadəçi sorğularında gecikmə, xəta və əhatəni ölçün.
Yolun izini sürün
Trace ID ilə API, xidmət və asılılıq span-larını əlaqələndirin.
Dəyişiklikləri müqayisə edin
Versiya, konfiqurasiya və yük fərqini yoxlayın; eyni problemi başqa ölçüdə müşahidə edin.
Logları trace və metriklərlə əlaqələndirin
Paylanmış tətbiqdə trace/span identifikatorları və xidmət konteksti jurnal qeydlərini sorğu izindəki əməliyyatlarla əlaqələndirə bilər. Span əməliyyatın başlanma və bitmə vaxtını, statusunu və təhlükəsiz seçilmiş atributlarını təsvir edir; əməliyyat bir xidmət daxilində də baş verə bilər. Bütün sorğu izlərini böyük həcmdə saxlamaq xərci artırır. Nümunə seçimi həcmi azaldır, lakin nadir sorğu və xətaları itirə bilər. Bunu tipik trafikdə yoxlayın; əməliyyat bitdikdən sonra seçim xətalara üstünlük verə bilər, amma əvvəl atılmış məlumatı bərpa etmir. OpenTelemetry ümumi siqnal modelləri, toplama və ötürmə komponentləri təqdim edir.
Log
Tək hadisənin mətni və sahələri.
Metrik
Sayğac, paylanma və ya gauge kimi zaman sırası.
Trace
Sorğudakı qeydə alınmış əməliyyatlar və onların müddəti.
DevOps əks-əlaqəsini buraxılışlarla əlaqələndirin
Monitorinq inkişaf, test, buraxılış və işlək mühitdə istismar mərhələlərində eyni əsas göstəriciləri izləyəndə buraxılışın təsirini müqayisə etmək asanlaşır. İdarəetmə paneli bütün komandalar üçün eyni vaxtı və xidmət adlarını göstərməli, xəbərdarlıq isə konkret xidmət sahibi və yoxlama addımı ilə əlaqələnməlidir. CPU və yaddaş hədləri təkbaşına istifadəçi təsirini ifadə etmir; gecikmə, xəta və mövcudluq göstəricilərini xidmət məqsədi ilə əlaqələndirin. Prometheus metrikləri toplayıb qaydalarla xəbərdarlıq yarada, Grafana isə qoşulmuş məlumat mənbələrindən panellər və vizuallaşdırma qura bilər.
RUM və sintetik monitorinq fərqli boşluqları tapır
Real User Monitoring (RUM) dəstəklənən brauzerlərdən real sessiyalarda performans ölçüləri toplayır; sintetik monitorinq isə əvvəlcədən qurulmuş sorğu və istifadəçi axınlarını plan üzrə təkrarlayır. RUM cihaz, brauzer, şəbəkə və region üzrə fərqləri göstərə bilər, amma az trafik olan yol üçün zəif nümunə yarana bilər. Sintetik yoxlama kritik giriş və checkout kimi axınları trafikdən asılı olmadan sınayır, lakin real istifadəçinin cihaz və şəbəkə şəraitini tam əks etdirmir. Birgə istifadə edin və RUM script-inin hansı məlumatı topladığını, saxlandığını və ötürüldüyünü əvvəlcədən yoxlayın.
| Yanaşma | Güclü tərəf | Məhdudiyyət |
|---|---|---|
| RUM | Real cihaz və şəbəkə təcrübəsi. | Trafik və skriptin əhatəsi ilə məhdudlaşır. |
| Sintetik | Təkrarlanan ssenari və planlı yoxlama. | Real istifadəçinin mühitini tam əks etdirmir. |
Real istifadəçi ölçülərini şərh edin
Google Core Web Vitals real istifadəçi təcrübəsində yüklənmə, interaktivlik və vizual sabitliyi ölçür: LCP görünən sahədə ən böyük şəkil və ya mətn blokunun göstərilmə vaxtını, INP qarşılıqlı əlaqəyə cavabı, CLS isə gözlənilməz tərpənməni əhatə edir. RUM-da ölçüləri region, cihaz və səhifə növünə görə qruplaşdırın; tək orta göstərici zəif qrupları gizlədə bilər. TTFB və FCP kimi əlavə vaxtlar serverdən brauzerə qədər olan yolu araşdırmağa kömək edir.