GERÇEK CTK KULLANIMI
Docker bellek hatasından sağlıklı worker’a.
Projenin geri kalanı çalışırken bir worker duruyor. Bu kontrollü yerel demo; etkilenen servisi, runtime’ın bildirdiği nedeni ve geliştiricinin kaynak kod değişikliğini takip ediyor. Otomatik bir düzeltmeyi değil.
Kontrollü yerel demo · Müşteri verisi içermez · 1:13 dk
01
Çalışan projeden başla
Yerel orders-engine reposunu bağla ve Watch with Docker’ı seç. CTK mevcut iş yükünü okur; bu watch işlemini başlatmak Docker Compose’u çalıştırmaz.
İlk görünümde sekiz servis ve sıfır olay bulunuyor. Bu başlangıç durumu, kontrollü hata oluştuğunda hangi servisin değiştiğini ayırt etmeyi sağlıyor.
02
Gözlenen durmayı, bildirilen nedenden ayır
order-worker konteyneri bellek yetersizliği nedeniyle duruyor. Diğer servisler çalışmaya devam ederken CTK etkilenen worker’ı işaretliyor. Alarms alanında ilgili alarmı açıp Observe ekranındaki kaynak kaydına geçiyoruz.
Kaynağın bildirdiği neden, konteynerin belleğinin tükendiğini söylüyor. Bu, tek başına OOM nedenini kanıtlamayacak bir başarısız sağlık kontrolünden daha belirgin bir bilgi. Bir log satırı veya sağlıksız işareti, bu kanıtın yerini tutmuyor.
03
Kaynak değişikliğini geliştirici olarak yap
Bu demoda worker, her biri 8 MiB veri taşıyan 32 kaydı tek batch içinde işliyor. Geliştirici gerçek kaynak kodunu inceleyip BATCH_SIZE değerini 32’den 2’ye değiştiriyor ve dosyayı kaydediyor.
Batch’i küçültmek bu iş yüküne ait bir değişiklik; tüm bellek hataları için genel çözüm değil. CTK runtime kaydını görünür kılıyor; neyin değişeceğine geliştirici karar veriyor ve düzenlemeyi CTK dışında yapıyor.
04
Müdahaleden sonraki durumu kontrol et
Worker yeniden başlatıldıktan sonra Overview’a dönüyoruz. Kayıtta worker’ın tekrar çalıştığı, sağlık kontrollerinin geçtiği ve güncel olay bulunmadığı görülüyor.
Bu, CTK’da görünen servis toparlanmasını doğrular. Tek başına her iş operasyonunun tamamlandığını veya bellek sorununun bir daha yaşanmayacağını kanıtlamaz. Doğrulama, yanıt aradığımız soruyla eşleşmeli.
Bu demo neyi kanıtlar, neyi kanıtlamaz?
Müşteri üretim olayı değil, kontrollü yerel testten gerçek uygulama kaydıdır. Bu kurgu kaynak değişikliğini ve CTK’daki toparlanmayı gösterir; yeniden başlatma komutu ve 32/32 iş çıktısı doğrulaması videoda yer almaz. CTK kaynak kodunu otomatik düzenlemez ve kaynak bildirmediğinde kök neden garantisi vermez.
Ekran metinlerini oku
- 0:00
Yerel bir repo ile başla.
- 0:04
orders-engine bağlandı. Repoyu aç.
- 0:10
Docker servislerini izlemeye başla.
- 0:14
CTK yerel runtime’ı okumaya başlıyor.
- 0:19
Sekiz servis. Olay yok.
- 0:23
Kontrollü bellek hatası order-worker’ı durduruyor.
- 0:27
CTK etkilenen worker’ı gösteriyor.
- 0:31
Runtime kanıtı için Alarms’ı aç.
- 0:34
order-worker alarmını aç.
- 0:36
CTK, worker’ın runtime kaydına götürüyor.
- 0:40
Neden: konteynerin belleği tükendi.
- 0:43
Şimdi worker’ın kaynak kodunu incele.
- 0:47
Bu demo worker, her biri 8 MiB veri taşıyan 32 kaydı tek batch’te işliyor.
- 0:51
BATCH_SIZE değerini 32’den 2’ye düşür.
- 0:54
Kaynak değişikliğini kaydet.
- 0:57
Worker yeniden başladıktan sonra CTK’ya dön.
- 1:00
Güncel servis durumu için Overview’ı aç.
- 1:03
Olay yok. Sağlık kontrolleri geçiyor.
- 1:06
order-worker yeniden çalışıyor.