Gözlemlenebilirlik ve yavaş sorgu günlüklerinin üretim kesintilerini nasıl erken tespit, teşhis ve önlediğini öğrenin—ölçümlendirme, uyarı kurma ve sorguları güvenle iyileştirme için pratik adımlar dahil.
Ü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.
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:
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, 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ö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.
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.
Sağlıklı bir kurulum, olaylara şu açık cevapları vermenize yardımcı olur:
İ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, 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.
Çoğu veritabanı benzer bir çekirdek alan kümesini yakalayabilir:
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.
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:
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.
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:
Bu, yavaş sorgu günlüğünün eyleme geçirilebilir kalmasını sağlarken metrikler trendleri ortaya çıkarır.
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.
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.
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.
Bir sorgu yavaşlamaya başlayınca sistemler başa çıkmaya çalışır ve bu başa çıkma mekanizmaları hatayı büyütebilir:
Ö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ı 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.
Bu dört sinyal veritabanı sorununu, uygulama sorununu ya da her ikisini ayırt etmenize yardımcı olur:
Birkaçı, darboğazın sorgu yürütme, eşzamanlılık veya depolama kaynaklı olup olmadığını söyleyebilir:
DB metriklerini servis deneyimiyle eşleştirin:
Panoları hızlıca şu soruları cevaplayacak şekilde tasarlayın:
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.
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.
İ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:
GET /checkout veya billing_reconcile_worker).İ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=ordersapp.query_name=orders_by_customer_v2feature_flag=checkout_upsellBu, izleri aranabilir ve güvenli tutar; yine de kod yolunu işaret eder.
“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:
Şimdi yüksek değerli soruları hızlıca yanıtlayabilirsiniz:
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.
Kullanıcı beklentilerini ve veritabanınızın rolünü yansıtan mutlak eşik ile başlayın:
\u003e200ms, karma iş yükleri için \u003e500msArdından tüm sistem yavaşladığında yine de problemleri görebilmek için göreli görünüm ekleyin:
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.
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.
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.
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.
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.
Küçük bir yüksek-sinyalli gösterge setiyle başlayın:
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.
Semptom alarmlarıyla birlikte tanı süresini kısaltacak neden odaklı alarmlar ekleyin:
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.
Kullanın:
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).
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.
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.
Etkilenen alanı daraltın:
Bu adım yanlış şeyi optimize etmenizi engeller.
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.
Ş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.
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.
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”).
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.
Veri davranışını değiştirmeyen değişikliklerle başlayın:
Bu hafifletmeler zamanında p95 gecikme ve DB CPU/IO metriklerinde hızlı iyileşme göstermelidir.
Stabilize ettikten sonra gerçek sorgu desenini düzeltin:
EXPLAIN ile doğrulayın ve taranan satırların azaldığını görün.SELECT *'ten kaçının, seçici predikatlar ekleyin, ilişkili alt sorguları değiştirin.Değişiklikleri kademeli uygulayın ve aynı iz/span ve yavaş sorgu imzası ile iyileşmeyi doğrulayın.
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.
Ü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.
Sadece ölçülebilir ve kullanıcı deneyimini doğrudan yansıtan SLI'lerle başlayın:
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.
Çoğu tekrarlayan olay bir regresyondur. Bunu kolay görünür kılın:
Anahtar, dağılımdaki değişiklikleri dağılım (p95/p99) üzerinden gözlemek, sadece ortalamalara bakmamak.
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ı.
Yavaş sorgu incelemesini birinin işi yapmasını sağlayın, sonradan düşünülmesin:
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.
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.
Gerekli metrikler (mümkünse örnek, küme ve rol/replica bazında):
Yavaş sorgu günlükleri için gerekli alanlar:
İz korelasyonu için trace etiketleri:
Beklemeniz gereken panolar ve alarmlar:
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?
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).
Öncelikle uç nokta başına kuyruk gecikmesini (p95/p99) inceleyin, sadece ortalamalara bakmayın. Ardından zaman aşımı, yeniden deneme oranları ve veritabanı doygunluk sinyalleriyle (bağlantı beklemeleri, kilit beklemeleri, CPU/IO) korele edin.
Bu göstergeler birlikte hareket ediyorsa, yavaş olan span'i bulmak için izlere (tracing) geçin ve ardından arkasındaki tam sorgu parmak izini belirlemek için yavaş sorgu günlüklerine bakın.
Ortalama değerler uç örnekleri gizler. Çok küçük bir yüzdeye tekabül eden çok yavaş istekler ürünün kırık hissettirmesine yol açabilir, ortalama ise "normal" görünmeye devam eder.
İzleyin:
Bunlar kullanıcıların gerçekten deneyimlediği uzun kuyruğu ortaya çıkarır.
Birlikte kullanıldıklarında “neresi” + “ne” olarak çalışırlar.
Bu kombinasyon kök neden bulunma süresini dramatik biçimde kısaltır.
Genellikle içerir:
Önceliklendirin: Hangi servis tetikledi, ne zaman ve bu tekrarlayan bir sorgu kalıbı mı? sorularını cevaplayacak alanlar en faydalı olanlardır.
Kullanıcı deneyimine ve iş yükünüze göre eşikler belirleyin.
Pratik bir yaklaşım:
Hedef eyleme geçirilebilir olmak; her şeyi kaydetmek değil.
Sorgu parmak izi (normalizasyon) kullanın, böylece aynı sorgu şekli farklı ID'ler veya zaman damgaları yüzünden ayrı ayrı görünmez.
Örnek: WHERE user_id = ? yerine WHERE user_id = 12345 gibi benzersiz literal'lerden kaçının.
Ardından parmak izlerini şu kriterlerle sıralayın:
Ham hassas literal'leri saklamayın.
İyi uygulamalar:
Yaygın bir çöküş zinciri şöyledir:
Döngüyü kırmak genellikle yeniden denemeleri azaltmak, havuzu geri kazanmak ve yavaş sorgu parmak izini düzeltmek anlamına gelir.
Hem belirtilere hem de muhtemel nedenlere alarm kurun.
Belirtiler (kullanıcı etkisi):
Nedenler (araştırmayı hızlandırır):
Önce düşük riskli hafifletmelerle başlayın, sonra sorguyu düzeltin.
Hızlı hafifletme:
Sonra düzeltin:
Bu, olay zamanında veri maruziyeti riskini azaltır.
Gürültüyü azaltmak için çoklu pencere/burn-rate desenleri kullanın.
Aynı iz span'i ve yavaş sorgu parmak izi ile önce/sonra doğrulayın.