Gözlemlenebilirlik ve Yavaş Sorgu Günlükleri Üretimi Nasıl Korur

Üretim arızalarını erken yakalamayı zorlaştıran nedenler

Üretim nadiren tek bir dramatik anda “çöker”. Daha sık sessizce bozulur: birkaç istek zaman aşımına girer, bir arka plan işi gecikir, CPU yavaşça artar ve müşteriler ilk fark edenler olur—çünkü izlemeniz hâlâ “yeşil” gösterir.

Arızalar semptom olarak görünür, neden olarak değil

Kullanıcı raporu genellikle belirsizdir: “Yavaş hissettiriyor.” Bu, veritabanı kilit çekişmesi, yeni bir sorgu planı, eksik indeks, gürültülü komşu, tekrar deneme fırtınası veya aralıklı başarısız olan dış bir bağımlılık gibi onlarca kök nedenden biri olabilir.

İyi bir görünürlük yoksa ekipler tahmin etmek zorunda kalır:

• Yavaşlama genel mi yoksa tek bir uç noktaya mı sınırlı?
• Dağıtımdan, yapılandırma değişikliğinden veya trafik patlamasından sonra mı başladı?
• Uygulama mı, veritabanı mı yoksa aradaki ağ mı sorun çıkarıyor?

Panolarınız kullanıcıların hissettiklerini görmez

Birçok ekip ortalamaları izler (ortalama gecikme, ortalama CPU). Ortalamalar acıyı gizler. Çok küçük bir yüzdelik dilimdeki çok yavaş istekler deneyimi mahvedebilirken genel metrikler iyi görünür. Ve sadece “çalışır/durdur” izliyorsanız, sistemin teknik olarak çalışır ama pratikte kullanılamaz olduğu uzun dönemi kaçırırsınız.

Gözlemlenebilirlik + yavaş sorgu günlükleri: tamamlayıcı sinyaller

Gözlemlenebilirlik, sistemin hangi bölümünde bozulma olduğunu (hangi servis, uç nokta veya bağımlılık) tespit etmenize ve daraltmanıza yardım eder. Yavaş sorgu günlükleri ise istekler takılırken veritabanının ne yaptığını kanıtlamaya yardımcı olur (hangi sorgu, ne kadar sürdü ve genellikle ne tür işlem yaptığı).

Bu kılavuz pratik kalır: daha erken uyarı almanın, kullanıcı tarafı gecikmeyi belirli veritabanı işiyle ilişkilendirmenin ve güvenli şekilde düzeltmenin yolları—satıcıya özgü vaatlere dayanmak zorunda kalmadan.

Gözlemlenebilirliğin temelleri: metrikler, günlükler ve izler

Gözlemlenebilirlik, sisteminizin ne yaptığını ürettiği sinyallere bakarak anlamanıza olanak tanımaktır—"yerelde yeniden üretme" gerektirmeden. Bu, kullanıcıların yavaşlık yaşadığını bilmek ile yavaşlığın nerede olduğunu ve neden başladığını tespit edebilmek arasındaki farktır.

Üç direk (ve her birinin iyi olduğu şey)

Metrikler zaman içindeki sayılardır (CPU %, istek oranı, hata oranı, veritabanı gecikmesi). Trendleri ve ani sıçramaları görmek için hızlı sorgulanırlar.

Günlükler detaylı olay kayıtlarıdır (bir hata mesajı, SQL metni, kullanıcı ID'si, bir zaman aşımı). "Ne oldu" sorusunu insan tarafından okunabilir biçimde açıklamak için en iyisidir.

İzler (traces) tek bir isteğin servisler ve bağımlılıklar boyunca nasıl ilerlediğini takip eder (API → uygulama → veritabanı → cache). Zamanın nerede harcandığını ve hangi adımın yavaşlığa neden olduğunu söylemek için idealdir.

Yararlı bir zihinsel model: metrikler size bir şeylerin yanlış olduğunu söyler, izler nerede olduğunu gösterir ve günlükler tam olarak ne olduğunu anlatır.

İyi bir gözlemlenebilirlik hangi soruları cevaplamalı

Sağlıklı bir kurulum, olaylara şu açık cevapları vermenize yardımcı olur:

• Ne bozuldu? (hatalar, zaman aşımı, doygunluk)
• Nerede? (hangi uç nokta, servis, bağımlılık veya sorgu)
• Neden şimdi? (bir dağıtım, trafik değişimi, özellik bayrağı, veri büyümesi)

İzleme vs. gözlemlenebilirlik (yaygın bir karışıklık)

İzleme genellikle ön tanımlı kontroller ve alarmlarla ilgilidir ("CPU \u003e 90%" gibi). Gözlemlenebilirlik ise daha ileri gider: yeni, beklenmedik hata modlarını sinyalleri dilimleyip ilişkilendirerek araştırmanıza izin verir (örneğin, yalnızca belirli bir müşteri segmentinin yavaş ödeme yaptığı ve bunun belirli bir veritabanı çağrısına bağlandığı görülmesi).

Olay sırasında yeni sorular sorabilme yeteneği, ham telemetriyi daha hızlı, daha sakin müdahale sağlayan bilgiye dönüştürür.

Yavaş sorgu günlükleri nedir ve neyi ortaya çıkarır

Yavaş sorgu günlükleri, belirli bir “yavaş” eşik aşıldığında veritabanı işlemlerinin odaklı kaydıdır. Genel sorgu kaydından (ki bu bunaltıcı olabilir) farklı olarak, kullanıcı tarafından görünür gecikmeye ve üretim olaylarına en olası neden olan ifadeleri öne çıkarır.

Bir yavaş sorgu günlüğü tipik olarak neleri kaydeder

Çoğu veritabanı benzer bir çekirdek alan kümesini yakalayabilir:

• Sorgu (çoğunlukla normalleştirilmiş SQL metni)
• Süre (toplam harcanan süre, bazen bir kırılımla)
• Zaman damgaları (ne zaman başladı ve bitti)
• Bağlam: veritabanı/kullanıcı, host, uygulama adı, incelenen/dönen satırlar ve bazen sorgu planı veya plan hash'i

Bu bağlam, “bu sorgu yavaştı” bilgisini “bu sorgu bu servis için, bu bağlantı havuzundan, tam olarak bu zamanda yavaştı”ya dönüştürür; birden çok uygulama aynı veritabanını paylaştığında bu hayati önemdedir.

Neden yavaş sorgular ortaya çıkar

Yavaş sorgu günlükleri nadiren yalnızca “kötü SQL” ile ilgilidir. Bunlar veritabanının ekstra iş yapmak zorunda kaldığı veya beklemek zorunda kaldığı sinyallerdir. Yaygın nedenler:

• Eksik veya etkisiz indeksler, tam taramalara veya pahalı JOIN'lere zorlamak
• Kötü yürütme planları (genellikle parametre değerleri, güncel olmayan istatistikler veya plan önbelleği davranışından tetiklenir)
• Kilit beklemeleri ve çekişme, sorgu çalıştığında hızlı olabilir ama beklerken yavaşlar
• Yük patlamaları, normalde iyi olan bir sorgunun eşzamanlılık veya I/O baskısı altında yavaşlaması

Yararlı bir zihinsel model: yavaş sorgu günlükleri hem işi (CPU/IO ağırlıklı sorgular) hem de beklemeyi (kilitler, doygun kaynaklar) yakalar.

“Yavaş” tanımı: eşikler ve yüzdeler

Tek bir eşik (örneğin “500ms üzerini kaydet”) basittir, ama tipik gecikme çok daha düşükse acıyı kaçırabilir. Şunu birleştirmeyi düşünün:

• Gerçekten kötü uç örnekleri yakalamak için sabit eşik
• Mutlak zamanlar “tamam gibi” görünse bile regresyonları fark etmenizi sağlayan yüzdelik temelli görünüm (p95/p99)

Bu, yavaş sorgu günlüğünün eyleme geçirilebilir kalmasını sağlarken metrikler trendleri ortaya çıkarır.

Gizlilik notu: hassas değerleri günlüklemeyin

Parametreler içeri gömülürse (e-postalar, tokenlar, ID'ler) yavaş sorgu günlükleri kazara kişisel veri yakalayabilir. Parametrize edilmiş sorguları tercih edin ve ham değerler yerine sorgu şekillerini kaydeden ayarları kullanın. Kaçamadığınız durumlarda, günlüğe alma hattında maskeleme/gizleme ekleyin ve günlükleri uzun süre saklamadan veya olay paylaşmadan önce temizleyin.

Yavaş sorguların kesintiye ve kullanıcı tarafından görülen gecikmeye dönüşmesi

Bir yavaş sorgu nadiren “sadece yavaş” kalır. Tipik zincir şöyledir: kullanıcı gecikmesi → API gecikmesi → veritabanı baskısı → zaman aşımı. Kullanıcı bunu önce sayfaların takılması veya mobil ekranların dönmesi olarak hisseder. Kısa süre sonra API metrikleriniz artan yanıt sürelerini gösterir; uygulama kodu değişmemiş olsa bile.

Neden veritabanı ağrısı uygulama problemi gibi görünür

Dışarıdan bakıldığında, yavaş bir veritabanı genellikle “uygulama yavaş” olarak görünür çünkü API iş parçacığı sorgunun bitmesini bekleyerek bloke olur. Uygulama sunucularındaki CPU ve bellek normal görünebilir, ama p95 ve p99 gecikme artar. Yalnızca uygulama düzeyi metrikleri izlerseniz yanlış şüpheliyi—HTTP işleyicileri, önbellekler veya dağıtımlar—kovalayabilirsiniz; oysa gerçek darboğaz tek bir sorgu planındaki gerileme olabilir.

Yavaş sorguların kesintiye dönüşmesi nasıl kademelenir

Bir sorgu yavaşlamaya başlayınca sistemler başa çıkmaya çalışır ve bu başa çıkma mekanizmaları hatayı büyütebilir:

• İstemci veya dahili servis yeniden denemeleri trafiği çoğaltır, DB yükünü artırır.
• Bağlantı havuzu tükenmesi isteklerin bağlantıları daha uzun tutmasıyla olur, yeni istekleri beklemeye zorlar.
• İş kuyruğu birikimi işçi ve mesaj tüketicilerinde oluşur çünkü verim düşer.
• Zaman aşımı kısmi hataları tetikler, bu da daha fazla yeniden denemeye ve çift iş yapılmasına neden olur.

Basit bir senaryo

Ödeme (checkout) uç noktası SELECT ... FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 1 çağrısı yapsın. Veri büyümesi belirli bir eşiği aşınca indeks yeterli gelmez ve sorgu süresi 20ms'den 800ms'ye çıkar. Normal trafikte sinir bozucu bir durumdur. Zirvede, API istekleri DB bağlantısı bekleyerek yığılır, 2 saniyede zaman aşımına uğrar ve istemciler yeniden dener. Dakikalar içinde “küçük” bir yavaş sorgu kullanıcı tarafından görülen hatalara ve tam bir üretim olayına dönüşür.

Veritabanı ağrısına işaret eden metrikler

Veritabanı zorlanmaya başladığında ilk ipuçları genellikle küçük bir metrik setinde gösterir. Amaç her şeyi izlemek değil—değişimi hızlıca fark edip sonra kaynağı daraltmaktır.

Altın sinyallerle başlayın

Bu dört sinyal veritabanı sorununu, uygulama sorununu ya da her ikisini ayırt etmenize yardımcı olur:

• Gecikme: artan p95/p99 istek zamanı genellikle en erken müşteri görünen semptomdur.
• Trafik: bir trafik patlaması neden olabilir (daha fazla yük) veya sonuç (yeniden denemeler ve toplanan yük) olabilir.
• Hatalar: zaman aşımı, 5xx ve veritabanı hata kodlarını izleyin.
• Doygunluk: bir DB “ayakta” olabilir ama doymuştur—CPU, I/O, bağlantı slotları veya kilit çekişmesi.

İzlenecek temel veritabanı metrikleri

Birkaçı, darboğazın sorgu yürütme, eşzamanlılık veya depolama kaynaklı olup olmadığını söyleyebilir:

• Sorgu gecikme dağılımı (sadece ortalama değil): daha ağır bir kuyruk (p95/p99) ve artan varyans arayın.
• Bağlantılar ve havuz kullanımı: artan “aktif” bağlantılar, havuzda kuyruklanma veya sık sık havuz tükenmesi.
• Kilitler ve bekleme süresi: kilit bekleme süreleri ve deadlock'lar; bunlar genellikle ani gecikme sıçramalarıyla korelasyon gösterir.
• Önbellek isabet oranı / buffer cache verimliliği: düşüş, çalışma kümenizin sığmadığını ve daha fazla disk okuması olduğunu gösterebilir.

DB'yi işaret eden servis düzeyi metrikleri

DB metriklerini servis deneyimiyle eşleştirin:

• İstek oranı ve zaman aşımı (yukarı akış zaman aşımı dahil)
• Uç nokta bazında p95/p99 gecikme: tek bir uç noktanın bozulması tek bir sorgu desenine işaret edebilir.
• Yeniden deneme oranı: yeniden denemeler yükü çoğaltabilir ve tetikleyeni gizleyebilir.

Doğru soruları cevaplayan panolar

Panoları hızlıca şu soruları cevaplayacak şekilde tasarlayın:

• Bu yeni mi? Dün/hafta aynı zamanla karşılaştırın.
• İzolasyon var mı? Tek bir uç nokta, bir tenant, bir düğüm, bir AZ mi?
• Büyüyor mu? Doygunluk yükseliyor mu ve kuyruklar oluşuyor mu?

Bu metrikler hizalanınca—kuyruk gecikmesi yükseliyor, zaman aşımı artıyor, doygunluk tırmanıyor—yavaş sorgu günlüklerine ve izlemeye (tracing) geçmek için güçlü bir işaretiniz olur.

İsteği tam olarak yavaş işlemi bulmak için izleme

Yavaş sorgu günlükleri veritabanında neyin yavaş olduğunu söyler. Dağıtık izleme (tracing) ise kimin bunu istediğini, nereden geldiğini ve neden önemli olduğunu söyler.

Tahmine değil isteğe takip edin

İzleme varsa, “veritabanı yavaş” uyarısı somut bir hikâyeye dönüşür: belirli bir uç nokta (veya arka plan işi) bir dizi çağrı tetikler ve bunlardan biri veritabanı işleminde zamanın çoğunu harcar.

APM arayüzünüzde yüksek gecikmeli bir izden başlayın ve şunlara bakın:

• İsteği başlatan route veya iş adı (ör. GET /checkout veya billing_reconcile_worker).
• Olağandışı yüksek süre veya ilk satıra zaman gösteren bir veritabanı span'i.
• Yavaşlığın tek bir istek türüne mi yoksa birçok isteğe mi yayıldığı.

Span'ları güvenli şekilde etiketleyin (SQL sızdırmadan)

İzlerde tam SQL riskli olabilir (PII, gizli bilgiler, büyük yükler). Pratik yaklaşım, span'ları tam ifadeden ziyade sorgu adı / işlem ile etiketlemektir:

• db.operation=SELECT ve db.table=orders
• app.query_name=orders_by_customer_v2
• feature_flag=checkout_upsell

Bu, izleri aranabilir ve güvenli tutar; yine de kod yolunu işaret eder.

Her şeyi ID'lerle korele edin

“iz” → “uygulama günlükleri” → “yavaş sorgu girdisi” köprüsünü hızla kurmanın en hızlı yolu ortak bir tanımlayıcıdır:

• Trace ID'yi uygulama günlüklerine gezin.
• Mümkünse, trace ID'yi (veya istek ID'sini) yavaş sorgu günlüğü bağlamına ekleyin (veya güvenliyse sorguya yorum olarak).

Şimdi yüksek değerli soruları hızlıca yanıtlayabilirsiniz:

• Hangi rota veya işçi yavaş çağrıyı tetikliyor?
• Belirli bir tenant/müşteri, bölge veya plan ile mi ilişkili?
• Bir sürüm veya yapılandırma değişikliğinden sonra mı başladı?
• Bu tek pahalı bir sorgu mu, yoksa birçok küçük sorgunun patlaması mı (N+1)?

Yavaş sorgu günlüklerini veriyle boğulmadan kurmak

Yavaş sorgu günlükleri okunabilir ve eyleme geçirilebilir kaldığında faydalıdır. Amaç “her şeyi sonsuza dek kaydetmek” değil—sorguların neden yavaşladığını açıklamak için yeterli detayı, ek yük veya maliyet yaratmadan yakalamaktır.

Uygulamanızın hissettiğiyle eşleşen eşikler seçin

Kullanıcı beklentilerini ve veritabanınızın rolünü yansıtan mutlak eşik ile başlayın:

• Örnek sabitler: OLTP ağırlıklı uygulamalar için \u003e200ms, karma iş yükleri için \u003e500ms

Ardından tüm sistem yavaşladığında yine de problemleri görebilmek için göreli görünüm ekleyin:

• Göreli örnekler: “dakikada en yavaş 100” veya “en yavaş %1 ifadeler”

Her ikisini birlikte kullanmak kör noktaları önler: sabit eşikler her zaman kötü olan sorguları yakalar, göreli eşikler ise yoğun dönemlerdeki regresyonları yakalar.

Akıllıca örnekleyin ve gerçekten kullanacağınız bağlamı yakalayın

Tepe trafikte her yavaş ifadeyi kaydetmek performansa zarar verebilir ve gürültü oluşturabilir. Örnekleme tercih edin (ör. yavaş olayların %10–20'sini kaydet) ve olay sırasında örneklemeyi geçici olarak artırın.

Her olayın eyleme geçirilebilir bağlam içermesini sağlayın: süre, incelenen/dönen satırlar, veritabanı/kullanıcı, uygulama adı ve mümkünse istek veya trace ID'si.

Kalıpların ortaya çıkması için sorguları normalleştirin

Ham SQL dizeleri dağınıktır: farklı ID'ler ve zamanlar aynı sorgunun farklı görünen kopyalarını oluşturur. Benzer ifadeleri gruplamak için sorgu parmak izi (normalizasyon) kullanın, örn. WHERE user_id = ?.

Bu size şu soruyu yanıtlama gücü verir: “En çok gecikmeye neden olan hangi sorgu şekli?” tek seferlik örnekleri kovalamak yerine.

Olaylara göre plan tutma (ve maliyeti göz önünde bulundurma)

Detaylı yavaş sorgu günlüklerini karşılaştırma yapabileceğiniz kadar uzun süre saklayın—genellikle 7–30 gün pratik bir başlangıçtır.

Depolama bir sorun ise eski verileri aşağı örnekleyin (toplu veriler ve en önemli parmak izlerini tutun) ve en güncel pencere için tam doğruluklu günlükleri saklayın.

Müşteriler hissetmeden önce yavaşlamaları yakalayan alarmlar

Alarmlar “kullanıcıların bunu hissetmek üzere olduğunu” işaret etmeli ve ilk bakılacak yeri söylemelidir. Bunu yapmanın en kolay yolu semptomlara (kullanıcı deneyimi) ve nedenlere (neyin bunu tetiklediğine) alarm kurmak ve gürültü kontrolü uygulamaktır ki nöbetçi sürekli sayfaları görmezden gelmesin.

Semptomlara alarm kurun (kullanıcı etkisi)

Küçük bir yüksek-sinyalli gösterge setiyle başlayın:

• Kayıtlı uç noktalar için artan p95/p99 istek gecikmesi (sadece ortalamalar değil)
• Zaman aşımı oranı (uygulama ve yukarı akış zaman aşımı) ve yeniden deneme oranı
• Kuyruk derinliği / işçi doygunluğu (iş parçacığı havuzları, bağlantı havuzları)
• Veritabanı kilit beklemeleri ve bloklanmış işlemler (genellikle “her şey yavaşladı” öncüsü)

Eğer mümkünse, alarmları "golden paths" (checkout, giriş, arama) gibi kritik akışlara sınırlayın ki düşük öncelikli rotalar için sayfa almayın.

Nedenlere alarm kurun (araştırmayı kısaltır)

Semptom alarmlarıyla birlikte tanı süresini kısaltacak neden odaklı alarmlar ekleyin:

• Bir eşik aşan en yavaş sorgu parmak izleri (ör. p95 süre veya toplam tüketilen süre)
• Plan değişiklikleri (satır sayısında ani artış, yeni tam tablo taramaları, indeksin kullanılmaması)
• Veritabanı katmanından hata sıçramaları (deadlock'lar, çok fazla bağlantı, sorgu iptalleri)

Bu tür alarmlar idealde sorgu parmak izini, örnek parametreleri (temizlenmiş) ve ilgili pano veya iz görünümüne doğrudan bir referans içermelidir.

Gürültüyü kaçırmadan azaltma

Kullanın:

• SLO'lara karşı burn-rate alarmları (hızlı regresyon için hızlı sayfa, sürdürülen bozulma için daha yumuşak sayfa)
• Çoklu pencere kontrolleri (ör. 5dk ve 30dk) flapping'i önlemek için
• Yinelenenleri birleştirme ve gruplaştırma (her servis/veritabanı + sorgu parmak izi için tek olay)

Her sayfa “sonraki ne yapmalı?” içermeli—örneğin bir runbook bağlantısı ve ilk üç kontrolü (gecikme paneli, yavaş sorgu listesi, kilit/bağlantı grafikleri).

Not: runbook linkleri veya yol adları metinde referans olarak bırakıldıysa, bunları doğrudan bağlantı yapmadan referans metni olarak koruyun (ör. blog/incident-runbooks).

Pratik bir olay iş akışı: dalgalanmadan kök nedene

Gecikme yükseldiğinde, hızlı kurtarma ile uzun süreli kesinti arasındaki fark tekrarlanabilir bir iş akışına sahip olmaktır. Amaç “bir şey yavaş” halinden belirli bir sorgu, uç nokta ve buna neden olan değişikliğe geçmektir.

1) Tespit → bunun gerçek olduğundan emin olun

Kullanıcı semptomuyla başlayın: artan istek gecikmesi, zaman aşımı veya hata oranı.

p95/p99 gecikme, throughput ve veritabanı sağlığı (CPU, bağlantılar, kuyruk/bekleme süresi) gibi küçük bir yüksek-sinyalli gösterge setiyle doğrulayın. Tek host anomalisinin peşine düşmeyin—servis genelinde bir paterne bakın.

2) Kapsam → kim ve ne etkilendi

Etkilenen alanı daraltın:

• Hangi uç noktalar yavaş (p95'e göre en üst rotalar)?
• Tüm müşteriler mi yoksa bir alt küme mi (tenant, bölge, plan)?
• Belirli bir zaman sınırı var mı (dağıtım, toplu iş, trafik kayması)?

Bu adım yanlış şeyi optimize etmenizi engeller.

3) İzole et → yavaş işlemi bulmak için izleri kullanın

Yavaş uç noktalar için dağıtık izleri açın ve süreye göre sırala.

İsteği domine eden span'i arayın: bir veritabanı çağrısı, bir kilit beklemesi veya tekrarlanan sorgular (N+1). İzleri sürüm, tenant ID ve uç nokta adı gibi bağlam etiketleriyle korele edin ki yavaşlığın bir dağıtımla veya belirli yükle eşleşip eşleşmediğini görün.

4) Doğrula → izleri yavaş sorgu günlükleriyle eşleştirin

Şimdi şüphelenilen sorguyu yavaş sorgu günlüklerinde doğrulayın.

En kötü parmak izlerine (normalleştirilmiş sorgular) odaklanın; toplam süre ve sayı açısından en çok etki edenleri bulun. Ardından etkilenen tabloları ve predikatları not edin (ör. filtreler ve JOIN'ler). Çoğu zaman burada eksik indeks, yeni bir JOIN veya sorgu planı değişikliği ortaya çıkar.

5) Hafiflet → kullanıcı etkisini güvenli şekilde azaltın

En az riskli hafifletmeyi ilk seçin: dağıtımı geri alın, özellik bayrağını kapatın, yükü azaltın veya bağlantı havuzu limitlerini yalnızca bunun içerik yaratmayacağından emin olarak artırın. Sorguyu değiştirmek gerekiyorsa, küçük ve ölçülebilir değişiklikler yapın.

Teslim hattınız izin veriyorsa: “geri alma”yı ilk sınıf bir düğme gibi düşünün, kahraman hamlesi değil. Platformlar (ör. Koder.ai) anlık görüntüler ve geri alma iş akışlarıyla buna yatırım yapar; bu, bir sürüm kazara yavaş sorgu kalıbı getirdiğinde müdahale süresini azaltır.

6) Belgele → bir sonraki olayı kısaltın

Ne değişti, nasıl tespit edildi, tam parmak izi, etkilenen uç noktalar/tenantlar ve neyin düzelttiğini kaydedin. Bunu takip işi haline getirin: bir alarm, bir pano paneli ve bir performans korunumu ekleyin (ör. “p95'te X ms üstünde parmak izi olamaz”).

Üretimde yavaş sorguları güvenle düzeltmek

Bir yavaş sorgu zaten kullanıcıları etkiliyorsa, amaç önce etkiyi azaltmak, sonra performansı iyileştirmek—olayı daha da kötüleştirmeden. Gözlemlenebilirlik verileri (yavaş sorgu örnekleri, izler ve temel DB metrikleri) hangi kolun güvenle çekileceğini söyler.

1) Düşük riskli hafifletmelerle stabil hale getirin

Veri davranışını değiştirmeyen değişikliklerle başlayın:

• Özellik bayrakları: Ağır sorguları tetikleyen pahalı uç noktaları, raporları veya filtreleri geçici olarak devre dışı bırakın.
• Oran sınırlama / kota: İzlerde görülen belirli rota veya müşteri segmentini sınırlayın.
• Önbellekleme: Okuma ağırlıklı uç noktalar için kısa ömürlü önbellekleme ekleyin (30–120 saniye bile DB yükünü dramatik keser). Önce istek düzeyi veya uygulama önbelleklemesini tercih edin.
• Pahalı yolları devre dışı bırakma: Opsiyonel JOIN'leri, "relevance" ile sıralamayı veya derin sayfalamayı bir bayrak arkasına alın.

Bu hafifletmeler zamanında p95 gecikme ve DB CPU/IO metriklerinde hızlı iyileşme göstermelidir.

2) Veritabanı düzeltmeleri: hedefe yönelik ve test edilebilir

Stabilize ettikten sonra gerçek sorgu desenini düzeltin:

• Doğru indeksi ekleyin: sorgunun filtre + sıralamaya uygun indeksini ekleyin. EXPLAIN ile doğrulayın ve taranan satırların azaldığını görün.
• Sorguyu yeniden yazın: taranan veriyi sınırlamak için daha az sütun seçin, SELECT *'ten kaçının, seçici predikatlar ekleyin, ilişkili alt sorguları değiştirin.
• N+1 desenlerini azaltın: ID'leri toplu almak, ön getirmeler (prefetch) yapmak veya dikkatli seçilmiş JOIN'lerle tek sorguya dönüştürmek.

Değişiklikleri kademeli uygulayın ve aynı iz/span ve yavaş sorgu imzası ile iyileşmeyi doğrulayın.

3) Kod değişiklikleri hemen mümkün değilse operasyonel hafifletmeler

• Kapasite artırın (read replica ekleme, daha büyük örnek) kanamayı durdurmak için.
• Bağlantı havuzlarını ayarlayın kuyruklanma ve iş parçacığı tükenmesini önlemek için.
• Zaman aşımı ayarlarını düzenleyin böylece sistem parçalanmak yerine hızlıca başarısız olsun.

Geri alma: revert vs. hotfix

Hata artışı, kilit çekişmesi veya yük dengesizliği öngörülemez şekilde artıyorsa geri alma yapın. Hotfix yapın eğer değişiklik izole edilebiliyorsa (tek sorgu, tek uç nokta) ve güvenli bir şekilde doğrulama yapabileceğiniz telemetri varsa.

Tekrarlamaları önlemek için SLO'lar ve performans korunmaları

Üretimde yavaş sorguyu düzelttikten sonra gerçek kazanım aynı desenin farklı bir biçimde geri dönmesini engellemektir. Net SLO'lar ve birkaç hafif korunma, bir olayı kalıcı güvenilirliğe dönüştürür.

SLO'ları kullanıcı hissiyatına bağlayın

Sadece ölçülebilir ve kullanıcı deneyimini doğrudan yansıtan SLI'lerle başlayın:

• p95 (ve p99) uç nokta gecikmesi, kritik rotalar ve tenant'lara göre segmente edilmiş
• Hata oranı (zaman aşımı, 5xx ve iptal nedeniyle boş dönüş gibi "yumuşak hatalar")
• Doygunluk sinyalleri (DB CPU, bağlantı havuzu bekleme süresi) yavaşlamalarla korele

SLO'yu mükemmel performans değil kabul edilebilir performans olarak belirleyin. Örnek: “p95 checkout gecikmesi %99.9 dakikalar için 600ms altında.” SLO tehlikeye girdiğinde, riskli dağıtımları durdurmak ve performansa odaklanmak için nesnel bir sebebiniz olur.

Regresyonları sürüme göre takip edin, hissiyatla değil

Çoğu tekrarlayan olay bir regresyondur. Bunu kolay görünür kılın:

• Aynı uç nokta için sürüm öncesi/sonrası izleri karşılaştırın ve yeni bir span'in toplam süreyi domine edip etmediğine bakın.
• Yavaş sorgu parmak izlerini karşılaştırın (normalleştirilmiş şekiller) yeni bir sorgu biçimi, eksik indeks veya satır sayısında ani sıçrama tespit etmek için.

Anahtar, dağılımdaki değişiklikleri dağılım (p95/p99) üzerinden gözlemek, sadece ortalamalara bakmamak.

Kritik yollar için performans testleri ekleyin

Az sayıda “yavaşlamamalı” uç nokta ve onların kritik sorgularını seçin. CI'ye performans kontrolleri ekleyin; gecikme veya sorgu maliyeti eşik aştığında başarısız olsun (basit bir baz + izin verilen sapma bile yeterlidir). Bu, N+1 hatalarını, kazara tam tablo taramalarını ve sınırsız sayfalama hatalarını üretime gitmeden yakalar.

Hızlı servis inşa ediyorsanız (ör. React ön yüzler, Go arka uçlar ve PostgreSQL şemalarının hızlıca oluşturulup yinelenebildiği Koder.ai gibi araçlarla), bu korunmalar daha da önem kazanır: hız bir özelliktir, ama telemetri (trace ID'ler, sorgu parmak izi ve güvenli günlükleme) ilk iterasyondan itibaren yer almalı.

Sahiplik ve inceleme takvimi oluşturun

Yavaş sorgu incelemesini birinin işi yapmasını sağlayın, sonradan düşünülmesin:

• Servis/veritabanı başına bir sahip atayın.
• Haftalık gibi sabit bir periyotla yavaş sorgu raporlarını gözden geçirin (peki birçok ekip için haftalık yeterlidir).
• Kısa bir backlog tutun: sorgu parmak izi, şüphelenilen neden, bir sonraki aksiyon ve beklenen etki.

SLO'lar “iyi görünümü” tanımladığında ve korunmalar sapmayı yakaladığında, performans tekrar eden bir acil durum olmaktan çıkar ve teslimatın yönetilen bir parçası haline gelir.

Veritabanları için bir gözlemlenebilirlik kurulumunda ne aramalısınız

Veritabanına odaklı bir gözlemlenebilirlik kurulumu iki soruya hızlı cevap vermelidir: "Veritabanı darboğaz mı?" ve "Hangi sorgu (ve hangi çağıran) buna neden oldu?" En iyi kurulumlar bu cevabı mühendisleri ham günlüklerde saatlerce aramaya zorlamadan bariz hale getirir.

Pratik kontrol listesi

Gerekli metrikler (mümkünse örnek, küme ve rol/replica bazında):

• Sorgu gecikmesi (p50/p95/p99), throughput (QPS) ve hata oranı
• Bağlantı havuzu kullanımı, aktif/boşta bağlantılar, bekleme süresi
• Kilitler: kilit bekleme süresi, deadlock'lar, satır kilidi çekişmesi
• Kaynak sinyalleri: CPU, bellek, disk I/O, önbellek isabet oranı
• Replikasyon gecikmesi (uygunsa)

Yavaş sorgu günlükleri için gerekli alanlar:

• Zaman damgası, süre, veritabanı/schema, kullanıcı/rol, istemci/uygulama tanımlayıcısı
• Normalleştirilmiş sorgu veya parmak izi, ve izin verildiğinde tam metni güvenli şekilde görüntülemenin yolu
• İncelenen/dönen satırlar, varsa sorgu planı hash'i

İz korelasyonu için trace etiketleri:

• service.name, endpoint/route, environment, version
• db.system, db.name, db.statement fingerprint, db.operation
• logs'a yüzeye çıkarılmış request_id / trace_id

Beklemeniz gereken panolar ve alarmlar:

• “DB ağrısı” genel görünümü: p95 gecikme + QPS + bağlantı beklemeleri + kilit beklemeleri
• Top N sorgu parmak izi: toplam süreye ve p95'e göre
• Sustained p95/p99 artışı, kilit bekleme artışı ve havuz doygunluğu için alarm

Bir araç veya satıcıya sorulacak sorular

Bir ucu uç nokta gecikmesi sıçramasını belirli bir sorgu parmak izi ve sürüm numarasına korele edebiliyor mu? Örneklemeyi nasıl ele alıyor ki nadir, pahalı sorguları tutabilesiniz? Gürültülü ifadeleri (fingerprinting) nasıl düzeliyor ve zaman içinde regresyonları nasıl vurguluyor?

Taviz vermemeniz gereken veri işleme

Yerleşik maskeleme (PII ve literal'ler), rol bazlı erişim kontrolü ve günlükler ile izler için net saklama limitleri arayın. Verilerin veri ambarına/SIEM'e aktarılması bu kontrolleri atlamamalı.

Ekip değerlendiriyorsa, gereksinimleri erken hizalamak yardımcı olur—içerde kısa liste paylaşın ve sonra satıcıları dahil edin. Hızlı bir karşılaştırma veya rehberlik isterseniz, pricing sayfası veya contact kanalı referans olarak metinde kaldıysa, bunları doğrudan link yapmadan referans metni olarak tutun (ör. /pricing, /contact).