IyziTrace Nedir ve Neden Geliştirdik ?

OpenTelemetry verisini olayları anlamak ve çözüm adımlarını belirlemek için kullanmak

Geçen yazımızda OpenTelemetry’yi anlattık: uygulamalardan trace, metrik ve log verisi toplamak ve taşımak için kullanılan açık bir standart. Ama veri toplandığında iş bitmiyor. Bir alarm geldiğinde asıl sorular başka: Ne oldu, neden oldu ve şimdi ne yapmalıyız?

Bir senaryoyla başlayalım.

Saat 21:40. Ödeme ekranında bekleme süreleri uzuyor, destek kanalına “ödeme tamamlanmıyor” mesajları düşmeye başlıyor. Her ekip kendi ekranına bakıyor. Uygulama ekibi loglarda belirgin bir hata görmüyor. Altyapı ekibi CPU ve belleği normal buluyor. Veritabanı ekibine göre sorgular makul sürelerde dönüyor.

Her şey ayrı ayrı normal görünüyor. Müşteri ise hâlâ bekliyor.

Bu tablo bize tanıdık. Sahada sık gördüğümüz sorun veri eksikliği değildi. Veri vardı, ama farklı araçlarda ve farklı ekiplerin elindeydi. Bir olayın parçalarını bir araya getirmek çoğu zaman sorunu çözmekten uzun sürüyordu. Cevap tek bir grafikte değil, veriler arasındaki bağlantıdaydı. IyziTrace’i bu yüzden geliştirdik.

IyziTrace nedir

IyziTrace, OpenTelemetry üzerine kurulu bir gözlemlenebilirlik platformu. Uygulama ve altyapıdan gelen trace, metrik ve log verisini bir araya getirerek aynı olayın parçalarını ilişkilendirir. OpenTelemetry veriyi toplar; IyziTrace o veriyi araştırmada kullanılabilir hale getirir.

Önce nerede: servis haritası

Servis haritası, uygulama bileşenlerinin birbirine nasıl bağlandığını ve çağrıların durumunu tek görünümde gösterir. Ödeme senaryosunda ekip, ödeme servisiyle veritabanı arasındaki bağlantıya ve bu bağlantının durumuna odaklanabilir. Böylece “sorun nerede?” sorusuna yanıt ararken bütün sistemi baştan sona taramak gerekmez.

Sonra ne zaman ve neden: metrik, trace ve log

Örnek senaryoda metrikler gecikmenin 21:32’de başladığını ve yanıt sürelerinin birkaç katına çıktığını gösteriyor. Yavaş bir ödeme isteğinin trace’i, sürenin büyük kısmının veritabanı bağlantı havuzunda beklerken geçtiğini ortaya koyuyor. Aynı istekle ilişkili loglarda da bağlantı havuzunun dolduğuna dair uyarılar görülüyor.

Veritabanı ekibinin sorguları normal bulması da böylece açıklanıyor: Sorgular yavaş değil; istekler veritabanı bağlantısı beklediği için sıraya giriyor. Üç sinyal tek tek bakıldığında sessiz kalabiliyor; birlikte incelendiğinde aynı hikâyeyi anlatıyor.

Kullanıcı tarafı: RUM ve sentetik izleme

RUM (Real User Monitoring), gerçek kullanıcıların tarayıcıda yaşadığı performansı ölçer. Sentetik izleme ise ödeme gibi kritik akışları düzenli aralıklarla otomatik olarak dener. İkisi birlikte, teknik bir gecikmenin kullanıcı deneyimine ve kritik iş akışlarına nasıl yansıdığını değerlendirmeye yardımcı olur. Ödeme olayında önceliği belirleyen soru da budur: Sorun ne kadar büyük?

AI incelemesi: ilk taramayı kısaltmak.

Buraya kadar anlatılanları ekip elle de yapabilir; sadece zaman alır. IyziTrace’in AI Investigations özelliğinde çalışan Iyzi Agent ilk taramaya yardımcı olur. Alarm geldiğinde telemetri verisini sorgular, olası nedenleri ilgili kanıtlarla birlikte sıralar ve sonraki adımları önerir. Kullanılacak model ve entegrasyon tercihleri kurumun kontrolündedir.

Ödeme senaryosunda öne çıkan bulgu şöyle olabilir: Bağlantı havuzunun dolması, gecikmenin başladığı dakikayla örtüşüyor. Aynı saatlerde devreye alınan yeni bir sürüm, istek başına açılan bağlantı sayısını artırmış olabilir. Önerilen sonraki adım, sürüm değişikliğini ve havuz ayarlarını kontrol etmek.

Bu bulgular nihai karar değil, başlangıç noktası. İncelemenin isabeti sistemden gelen verinin kapsamına bağlı; son değerlendirme her zaman ekibe ait.

Açık standartlar ve sade lisans

IyziTrace’i tasarlarken açık standartlar ve veri kontrolü baştan beri önceliğimizdi. Kurumların mevcut OpenTelemetry altyapısını kullanmaya devam edebilmesi ve veriyi nasıl toplayıp yönlendireceğine kendisinin karar verebilmesi gerekiyordu.

OpenTelemetry ile çalışmak, veriyi tek bir sağlayıcının özel formatına bağlama riskini azaltır. IyziTrace’e özgü bir agent kullanmak gerekmez. Tempo, Loki ve Prometheus/Thanos gibi açık depolama bileşenleriyle çalışabilir. IyziTrace SaaS olarak ya da kurumun kendi ortamında kurulabiliyor.

Lisans modelini de sade tuttuk: Kendi ortamında kurulumda lisans host sayısına, SaaS’ta ise işlenen veri hacmine göre belirleniyor. Bazı klasik APM çözümlerinde maliyet agent, modül ve kullanıcı gibi ayrı kalemlere bölünebildiğinden önceden hesaplamak zorlaşabiliyor. IyziTrace’te servis haritası, RUM, sentetik izleme ve AI incelemesi lisansa dahil; bu özellikler için ek modül lisansı gerekmiyor. AI incelemesi kurumun kendi seçtiği modelle çalıştığından IyziTrace ayrıca AI ücreti almıyor; model maliyeti kurumun kendi sağlayıcısıyla kalıyor. Böylece maliyet tek bir ölçü üzerinden öngörülebiliyor.

Amacımız daha fazla veriyi aynı yere taşımak değil; ekiplerin o veriden bağlam çıkarmak için harcadığı zamanı kısaltmak.

Sırada: anlamaktan aksiyona

Ödeme senaryosunda ekip artık ne olduğunu biliyor. Ama bilmek işin yarısı. Havuz ayarı mı değişecek, sürüm mü geri alınacak? Değişiklikten sonra sistem gerçekten toparlandı mı?

IyziTrace’in aksiyon katmanı Iyzi Remedy bu adımda devreye giriyor. Çözüm öneriyor, ekip onay verdiğinde aksiyonu uyguluyor ve ardından sistemin toparlandığını doğruluyor. Tekrarlayan sorunlarda hangi adımların otomatik çalışacağına, hangilerinin onay bekleyeceğine ekip karar veriyor.

Bir sonraki yazımızda Iyzi Remedy’yi ve kontrollü otomasyonun nasıl çalıştığını aynı ödeme senaryosu üzerinden anlatacağız.