Front end Development
Kusto Query Language (KQL) Nedir?
Ağustos 22, 2025
Azure Application Insights üzerinden KQL ile API Kontrolleri
Modern yazılım geliştirme süreçlerinde log analizi, sistem gözlemi ve performans takibi kritik öneme sahiptir. Bu ihtiyaçları karşılamak üzere Microsoft’un geliştirdiği Kusto Query Language (KQL), büyük veri kümeleri üzerinde hızlı ve etkili sorgular yapmamıza olanak tanır.
KQL, Azure Monitor, Application Insights ve Log Analytics gibi servislerde kullanılır. SQL’e benzer sözdizimi sayesinde öğrenilmesi kolay, kullanımı ise oldukça esnektir. Özellikle telemetri verilerini analiz etmek ve görselleştirmek için idealdir.
Bu yazımızda, Azure Application Insights kullanarak API servislerimizin durumunu ve performansını KQL ile nasıl gözlemleyebileceğimizi inceleyeceğiz.
Azure Application Insights’ta KQL ile API Kontrolleri Nasıl Yapılır?
Azure Application Insights, uygulamalarınızdan gelen log’ları, hataları ve performans verilerini toplar. Bu veriler üzerinde KQL ile sorgular çalıştırarak detaylı analizler yapılabilir. Özellikle API endpoint’lerinin ne kadar hızlı çalıştığını, ne sıklıkta hata verdiğini ve hangi saatlerde yoğunluk yaşandığını tespit etmek mümkündür.
1. Temel Sorgu ile Başlayalım
Application Insights üzerinde en çok kullanılan tablo requests tablosudur. Tüm HTTP istekleri burada kaydedilir.
requests
| where timestamp > ago(1h)
| where name startswith “POST /api/”
| project timestamp, name, resultCode, duration
Bu sorgu:
- Son 1 saat içindeki
- POST /api/ ile başlayan endpoint’leri
- Yanıt kodu ve süresi ile birlikte listeler.
2. Variable (Let) Kullanımı ile Okunabilirliği Artırma
Kod tekrarını azaltmak ve sorguyu daha okunabilir hale getirmek için let ifadeleriyle değişkenler tanımlanabilir.
let timeRange = 24h;
let endpoint = “GET /api/products”;
requests
| where timestamp > ago(timeRange)
| where name == endpoint
| project timestamp, duration, resultCode
Bu yöntemle timeRange veya endpoint değerini sadece bir yerden değiştirerek tüm sorguyu etkileyebilirsiniz.
3. Performans Özetleme: summarize ve İstatistiksel Fonksiyonlar
API performansını sadece ortalama sürelere göre analiz etmek çoğu zaman yeterli değildir. Kullanıcı deneyimini daha doğru yorumlayabilmek için persentil, medyan ve standart sapma gibi daha gelişmiş metrikleri kullanmak oldukça etkilidir.
Aşağıdaki sorgu, bir API endpoint’ine ait performansı istatistiksel olarak özetlemektedir:
requests
| where name == “POST /api/login”
| where timestamp > ago(7d)
| summarize
OrtalamaSureMs = avg(duration),
EnYavasMs = max(duration),
EnHizliMs = min(duration),
Yuzde95SureMs = percentile(toint(duration), 95),
MedyanSureMs = percentile(toint(duration), 50),
StandartSapmaMs = stdev(toint(duration)),
ToplamCagri = count()
Bu sorgu son 7 gündeki /api/login endpoint çağrılarını analiz eder. Peki bu metrikler ne ifade eder?
OrtalamaSureMs (avg): Tüm çağrıların ortalama yanıt süresini verir. Ancak aşırı yavaş veya çok hızlı yanıtlar bu değeri bozabilir.
EnYavasMs / EnHizliMs: Ölçülen en uzun ve en kısa yanıt süresidir.
Yuzde95SureMs (percentile 95): Tüm isteklerin %95’i bu süreden daha kısa sürede tamamlanmıştır. Özellikle outlier (uç değer) etkisini azaltarak gerçek kullanıcı deneyimini daha doğru temsil eder.
MedyanSureMs (percentile 50): Verilerin tam ortasındaki değerdir. İsteklerin yarısı bu süreden daha kısa, diğer yarısı daha uzun sürede yanıtlanmıştır. Ortalama süreden daha az etkilenir.
StandartSapmaMs (stdev): Sürelerin ne kadar değişken olduğunu gösterir. Yüksekse sistem performansında tutarsızlıklar vardır.
ToplamCagri (count): İlgili API endpoint’ine yapılan toplam istek sayısını gösterir.
4. Hata Oranı Analizi
API’lerin hata oranlarını görmek, sistem sağlığı için oldukça önemlidir. Örnek bir hata oranı sorgusu:
requests
| where timestamp > ago(1d)
| summarize
Toplam = count(),
Hatali = countif(resultCode !in (“200”, “201”))
| extend HataOrani = todouble(Hatali) / Toplam * 100
Bu sorgu:
- Son 1 gündeki tüm istekleri analiz eder.
- 200 ve 201 dışındaki cevapları “hatalı” kabul eder.
- Hata oranını yüzde olarak verir.
5. Saatlik Performans Dağılımı
API performansının günün saatlerine göre nasıl değiştiğini analiz etmek için saatlik bazda summarize kullanılabilir:
requests
| where timestamp > ago(1d)
| where name == “GET /api/orders”
| summarize OrtalamaSüre=avg(duration) by bin(timestamp, 1h)
| render timechart
- Bu sorgu, son 24 saat için her saatlik ortalama yanıt süresini çizer.
- render timechart ifadesi ile grafik olarak sunulur.
6. Contains Kullanımı ve Diğer Özellikler
KQL, metin bazlı veri filtrelemesi için güçlü operatörler sunar. API endpoint’leri, kullanıcı ajanları, hata mesajları gibi string ifadelerle çalışırken bu operatörleri kullanmak hem esneklik hem de hız sağlar.
Aşağıdaki örnek sorguda contains, !contains, startswith ve in gibi KQL’de yaygın kullanılan metin operatörlerinin nasıl kullanıldığını görebilirsiniz:
requests
| where timestamp > ago(1d)
| where name contains “/api”
and name !contains “internal”
and name startswith “POST”
and cloud_RoleName in (“backend-service”, “api-gateway”)
| summarize OrtalamaSure = avg(duration)
, EnYavas = max(duration)
, EnHizli = min(duration)
| order by OrtalamaSure desc
Bu sorgudaki ifadeler bize ne söyler?
- contains: Belirtilen metni içeren kayıtları getirir.
name contains “/api” → “/api” geçen endpoint’leri filtreler. - !contains: Belirtilen metni içermeyen kayıtları getirir.
name !contains “internal” → “internal” içermeyen kayıtlar alınır. - startswith: Belirtilen metinle başlayan değerleri filtreler.
name startswith “POST” → Sadece POST ile başlayan HTTP çağrıları gelir. - in: Birden fazla değeri tek seferde kontrol eder.
cloud_RoleName in (“backend-service”, “api-gateway”)
Yalnızca bu iki servis rolüne ait istekleri içerir.
Bu tür metin filtreleme fonksiyonları ile, sisteminizdeki belirli API gruplarını, istek tiplerini ya da hizmet rollerini kolayca izole edebilir ve analiz edebilirsiniz.
Sonuç
KQL, Azure Application Insights ile birlikte kullanıldığında güçlü bir gözlem ve analiz aracına dönüşür. API’lerinizin:
- Gerçek zamanlı performansını izleyebilir,
- Hata oranlarını tespit edebilir,
- Trafik ve yanıt süresi değişimlerini analiz edebilirsiniz.
Bu sayede, kullanıcı deneyimini iyileştirme ve sistem iyileştirme adımlarını veriyle destekleyerek atabilirsiniz.
Yazar: Berk Üstünel
