Vaka Çalışması

Gece yarısı kilitlenen cihaz servisinin izini sürmek

Problem

Bir müşteri ortamında, gece boyunca ekranlara bağlanan cihaz servisi yeni bağlantı kabul etmez hâle geldi. Ekranlar içerik güncellemesi alamadı; sabah servis yeniden başlatılınca her şey düzeldi. Altyapıda bir arıza yoktu; yeniden başlatmanın sorunu çözmesi, sorunun uygulamanın kendi içinde olduğunu gösteriyordu.

Ne olmuştu?

Logları geriye doğru izleyince bir zincir ortaya çıktı:

  • Gece yarısı, günlük log kaydının tutulduğu alan yenileniyor ve küçük bir kurulum adımı çalışıyordu. Bu adım, gelen bütün istekleri bekleten bir kilidin içinde yapılıyordu ve hata alınca kendini toparlayamıyordu.
  • Bekleyen istekler sunucunun kaynaklarını saatler içinde tüketti; veritabanı ve önbellek bağlantıları yanıt veremez hâle geldi.
  • Aynı sırada zaman aşımına düşen bir zamanlanmış iş, her hatada büyüyen loglar üretti ve birkaç saatte gigabaytlarca log yazdı; üstelik uygulamanın kendi veritabanına.

Düzeltmeler

  • Kurulum adımını istek akışından çıkardık; hata alsa bile istekleri bekletmiyor ve sürekli yeniden denemiyor.
  • Cihazlardan gelen log yüklemelerini sınırlı bir kuyruğa aldık. Yoğunlukta cihaz kısa süre sonra yeniden deniyor, sunucu boğulmuyor.
  • İstekleri gereksiz yere bekleten çağrıları temizledik.
  • Sık yapılan cihaz sorgularına bellek içi önbellek ekledik.
  • Tek bir hatanın log fırtınasına dönüşmemesi için log boyutunu sınırlandırdık.

Sıradaki adım, logları uygulamanın veritabanından ayırmak ve kaynak kullanımına alarm koymak.

Öğrenilenler

  • Bütün istekleri bekleten bir kilidin içinde yavaş işlem yapılmamalı; hata durumu da hesaba katılmalı.
  • Logu, izlediği sistemle aynı veritabanına yazmak, olay anında iki sorunu birbirine bağlıyor.

Benim katkım

Log analizini, sorunun kaynağının bulunmasını ve düzeltmelerin uygulanmasını ben yaptım.

Teknoloji

  • .NET 8
  • SignalR
  • MongoDB
  • Redis