Gün bir için üretim izlenebilirliği başlangıç paketi

Yeni bir uygulama gerçek kullanıcılara ulaştığında ilk ne bozulur

Genelde tüm uygulama birden gözden kaybolmaz. Çoğunlukla bir adım aniden yoğunlaşır, testlerde sorunsuz olan bir sorgu üretimde takılır veya bir bağımlılık zaman aşımına girer. Gerçek kullanıcılar gerçek çeşitlilik getirir: daha yavaş telefonlar, dalgalanan ağlar, beklenmedik girişler ve uygun olmayan zamanlardaki trafik sıçramaları.

Birisi “yavaş” dediğinde çok farklı şeylerden bahsediyor olabilir. Sayfa çok uzun sürede yükleniyor olabilir, etkileşimler gecikiyor olabilir, bir API çağrısı zaman aşımına uğruyor olabilir, arka plan işler birikiyor olabilir veya üçüncü taraf bir servis her şeyi yavaşlatıyor olabilir.

Bu yüzden panolardan önce sinyallere ihtiyacınız var. İlk gün, her uç nokta için mükemmel grafiklere gerek yok. Zamanın nereye gittiğini hızlıca cevaplayacak kadar log, metrik ve iz yeterlidir.

Erken aşamada aşırı enstrümantasyonun da gerçek bir riski vardır. Çok fazla etkinlik gürültü yaratır, maliyet getirir ve uygulamayı yavaşlatabilir. Daha da kötüsü, ekipler telemetriye güvenmeyi bırakır çünkü dağınık ve tutarsız hisseder.

Gerçekçi bir gün-bir hedefi basit olmalı: bir “yavaş” raporu geldiğinde, 15 dakikadan kısa sürede yavaş adımı bulabilmelisiniz. Tıkanmanın istemci render'ında mı, API handler ve bağımlılıklarında mı, veritabanı/önbellekte mi yoksa arka plan işlerinde/dış serviste mi olduğunu söyleyebilmelisiniz.

Örnek: yeni bir ödeme akışı yavaş hissediliyor. Dağ gibi araçlar olmadan bile “zamanın %95'i ödeme sağlayıcı çağrılarında” veya “sepet sorgusu çok fazla satır tarıyor” diyebilmek istersiniz. Koder.ai gibi araçlarla hızlıca uygulama geliştiriyorsanız bu gün-bir temel daha da önemli olur; çünkü hızlı göndermek, hızlı debug edebildiğinizde işe yarar.

Loglar, metrikler ve izler (traces) basitçe ne söyler

İyi bir üretim izlenebilirliği başlangıç paketi aynı uygulamanın üç farklı “görünümünü” kullanır; çünkü her biri farklı bir soruya yanıt verir.

Loglar hikayedir. Bir istek, bir kullanıcı veya bir arka plan işi için ne olduğunu söyler. Bir log satırı “order 123 için ödeme başarısız” veya “DB zaman aşımı 2s sonra” gibi ifadeler içerebilir; ayrıca request_id, user_id ve hata mesajı gibi detaylar da bulunur. Garip tekil bir sorun rapor edildiğinde, loglar genellikle bunun olup olmadığını ve kimi etkilediğini doğrulamanın en hızlı yoludur.

Metrikler skor tablosudur. Trendleyip alarmla besleyebileceğiniz sayılardır: istek hızı, hata oranı, gecikme yüzdelikleri, CPU, kuyruk derinliği. Metrikler bir şeyin nadir mi yoksa yaygın mı olduğunu ve kötüleşip kötüleşmediğini gösterir. Eğer gecikme herkes için 10:05’te arttıysa, metrikler bunu gösterecektir.

İzler (traces) haritadır. Bir trace tek bir isteği sisteminizde takip eder (web -> API -> veritabanı -> üçüncü taraf). Zamanın hangi adımda harcandığını adım adım gösterir. Çünkü “yavaş” neredeyse hiç büyük bir gizem değildir; genelde tek bir yavaş halka vardır.

Bir olay sırasında pratik bir akış şöyle görünür:

• Etkiyi doğrulamak için metrikleri kullanın (kaç kullanıcı, ne kadar kötü, ne zaman başladı).\n- En yavaş adımı bulmak için izleri kullanın (müdahale edebileceğiniz tek bir darboğaz).\n- Darboğazı açıklamak için logları kullanın (hangi hatalar, girdiler veya kenar durumları).

Basit bir kural: birkaç dakika sonra tek bir darboğaz işaret edemiyorsanız, daha fazla alarm eklemeye değil, daha iyi izlere ve izleri loglara bağlayan tutarlı ID'lere ihtiyacınız var.

Gün-bir kuralları: kaosu önlemek

Çoğu “bulamıyoruz” vakası verinin eksikliğinden ziyade aynı şeyin hizmetler arasında farklı şekilde kaydedilmesinden kaynaklanır. Gün birde birkaç ortak kural logların, metriklerin ve izlerin hızlıca hizalanmasını sağlar.

Başlamak için her deploy edilebilir birim için tek bir servis adı seçin ve bunu sabit tutun. Eğer checkout-api panoların yarısında checkout oluyorsa geçmişi kaybedersiniz ve alarmlar bozulur. Ortam etiketleri için de aynı şeyi yapın: küçük bir set seçin (prod ve staging gibi) ve her yerde kullanın.

Sonra her isteği takip etmeyi kolaylaştırın. Kenarda (API gateway, web sunucusu veya ilk handler) bir request_id oluşturun ve bunu HTTP çağrıları, mesaj kuyrukları ve arka plan işlerinde iletin. Bir destek bileti “10:42’de yavaşladı” diyorsa, tek bir ID ile tam logları ve trace'i tahmin etmeden çekebilirsiniz.

Gün birde işe yarayan bir kural seti:

• Kimlik: servis adı, ortam, sürüm (veya build SHA)\n- Korrelasyon: hizmetler ve işler arasında iletilen request_id\n- Temel etiketler: rota (veya handler), method, status code, ve çok kiracılı iseniz tenant/org ID\n- İzleme operasyonları: operasyon adlarını endpoint veya arka plan işleri olarak adlandırın (rastgele fonksiyon isimleri değil)\n- Tutarlılık: tek bir isimlendirme stili ve zaman birimi

Zaman birimlerinde erken anlaşın. API gecikmesi için milisaniye, uzun işler için saniye seçin ve ona bağlı kalın. Karışık birimler görsellerin iyi görünmesine rağmen yanlış hikaye anlatır.

Somut örnek: her API duration_ms, route, status ve request_id logluyorsa, “tenant 418 için checkout yavaş” gibi bir rapor hızlıca filtrelenir, tartışma değil.

Gün-bir için minimum loglama

Eğer tek bir şey yapacaksanız logları aranabilir yapın. Bu yapılandırılmış loglarla (genelde JSON) ve her hizmette aynı alanlarla başlar. Düz metin loglar yerelde yeterli olabilir ama gerçek trafik, retry'ler ve birden fazla instance olunca gürültüye dönüşür.

İyi bir kural: bir olay sırasında gerçekten kullanacağınız şeyleri loglayın. Çoğu ekip şu soruları yanıtlamalı: Bu hangi istekti? Bunu kim yaptı? Nerede başarısız oldu? Neye dokundu? Bir log satırı bu sorulardan birine yardımcı olmuyorsa büyük olasılıkla gereksizdir.

Gün bir için küçük ve tutarlı alan seti filtreleme ve servisler arası birleştirme yapmanızı sağlar:

• Zaman damgası, seviye ve servis kimliği (service name, version, environment)\n- İstek korrelasyonu (request_id, varsa trace_id)\n- Kim/nerede (user_id veya session_id, rota, method)\n- Sonuç (status code, duration_ms)\n- Dağıtım bağlamı (region/instance, release veya commit)

Bir hata olduğunda, onu bir kez bağlamla loglayın. Bir hata tipi (veya kod), kısa bir mesaj, sunucu hataları için stack trace ve ilişkili upstream bağımlılığı (ör. postgres, payment provider, cache) ekleyin. Aynı stack trace'i her retry'de tekrar etmekten kaçının; bunun yerine request_id ekleyin ki zinciri takip edebilin.

Örnek: bir kullanıcı ayarları kaydedemiyor diyor. Bir request_id araması PATCH /settings üzerinde 500 gösteriyor, sonra Postgres zaman aşımı ve duration_ms bulunuyor. Tam payloadlara gerek yoktu; rota, kullanıcı/oturum ve bağımlılık adı yeterliydi.

Gizlilik loglamanın bir parçasıdır, sonradan yapılacak bir iş değil. Parolaları, tokenları, auth header'ları, tam istek gövdelerini veya hassas PII'yı loglamayın. Kullanıcıyı tanımlamanız gerekiyorsa, e-posta veya telefon yerine sabit bir kimlik veya hash'lenmiş bir değer loglayın.

Koder.ai üzerinde uygulama inşa ediyorsanız (React, Go, Flutter), bu alanları her üretilen servise baştan dahil etmek yararlı olur; böylece ilk olay sırasında “loglamayı düzeltmek” zorunda kalmazsınız.

Çoğu üretim sorununu yakalayan minimum metrikler

İyi bir başlangıç paketi, sistemin şu an sağlıklı olup olmadığını ve eğer değilse nerede sorun olduğunu hızlıca cevaplayan küçük bir metrik setiyle başlar.

Altın sinyaller

Çoğu üretim sorunu dört “altın sinyal”den biri olarak görünür: latency (cevaplar yavaş), traffic (yük değişti), errors (başarısızlıklar) ve saturation (paylaşılan bir kaynak doldu). Uygulamanızın her ana parçası için bu dört sinyali görebiliyorsanız, çoğu olayı tahmin etmeden triage edebilirsiniz.

Gecikme yüzdelikler olmalı, ortalamalar değil. p50, p95 ve p99 takip edin ki küçük bir kullanıcı grubunun kötü deneyimini görsün. Trafik için istek/s veya worker'lar için işler/dk ile başlayın. Hatalar için 4xx ve 5xx'u ayırın: 4xx artışı genelde istemci davranışı veya doğrulamaya işaret eder; 5xx artışı uygulama veya bağımlılıklara işaret eder. Doyma, “bir şeyimizin tükeniyor” sinyalidir (CPU, bellek, DB bağlantıları, kuyruk backlog).

Bileşene göre metrik kontrol listesi

Çoğu uygulamayı kapsayan minimum set:

• HTTP/API: istekler/s, p50/p95/p99 gecikme, 4xx oranı, 5xx oranı\n- Veritabanı: sorgu gecikmesi (en az p95), bağlantı havuzu kullanımı (in-use vs max), zaman aşımı sayısı, yavaş sorgu sayısı\n- Worker/kuyruk: kuyruk derinliği, iş çalışma süresi p95, retry'ler, dead-letter sayısı (veya başarısız işler)\n- Kaynaklar: CPU %, bellek kullanımı, disk kullanımı (ve I/O gerekiyorsa), container restart'ları\n- Dağıtım sağlığı: aktif sürüm, deploy sonrası hata oranı, restart döngüleri

Somut örnek: kullanıcılar “yavaş” dediğinde API p95 yükselip trafik sabit kalıyorsa, doyma kontrolü için DB havuzu kullanımına bakın. Eğer DB havuzu maksimuma yakınsa ve zaman aşımı artıyorsa muhtemel darboğaz orasıdır. DB normal görünüyorsa ama kuyruk derinliği hızla artıyorsa arka plan işler kaynakları yiyor olabilir.

Koder.ai ile uygulama geliştiriyorsanız, bu checklist'i gün bir bitmişlik tanımınızın parçası olarak ele alın. Uygulama küçükken bu metrikleri eklemek, ilk gerçek olay sırasında eklemekten daha kolaydır.

“Yavaş”u debug edilebilir kılan minimum izleme

Bir kullanıcı “yavaş” dediğinde loglar genelde ne olduğunu söyler, metrikler ne sıklıkta olduğunu gösterir. İzler ise bu isteğin içinde zamanın nereye gittiğini söyler. Bu tek zaman çizgisi bulanık bir şikayeti net bir düzeltmeye çevirmek için kritiktir.

Sunucu tarafından başlayın. Gelen istekleri uygulamanın ilk handler'ında instrument edin ki her istek bir trace üretebilsin. İstemci tarafı izleme bekleyebilir.

Gün bir için iyi bir trace, genelde slowness yaratan parçalara karşılık gelen span'lara sahip olur:

• Tüm isteği kapsayan request handler spanı\n- Her sorgu veya işlem için veritabanı spanı\n- Önbellek get/set çağrıları için span\n- Her dış HTTP çağrısı için span\n- İstek bir iş kuyruğuna koyduysa arka plan işi spanı

İzleri aranabilir ve karşılaştırılabilir kılmak için birkaç anahtar özniteliği tutarlı yakalayın.

Gelen istek spanı için route (şablon formunda), HTTP methodu, status kodu ve gecikmeyi kaydedin. DB spanları için DB sistemi (PostgreSQL, MySQL), işlem tipi (select, update) ve tablo adı eklenebilir. Dış çağrılarda bağımlılık adı (payments, email, maps), hedef host ve durum bilgisi olsun.

Örnekleme gün birde önemlidir; aksi halde maliyet ve gürültü hızla artar. Basit bir baş-temelli kural kullanın: tüm hataların ve yavaş isteklerin %100'ünü trace edin (SDK destekliyorsa) ve normal trafiğin küçük bir yüzdesini örnekleyin (1–10%). Trafik düşükken daha yüksek başlayın, sonra azaltın.

İyi bir görünüm: bir trace'te hikayeyi baştan sona okuyabiliyor olmanız. Örnek: GET /checkout 2.4s sürdü; DB 120ms, cache 10ms, dış ödeme çağrısı 2.1s ve retry içeriyordu. Artık sorun bağımlılıkta olduğu için doğru yere odaklanabilirsiniz. Bu, üretim izlenebilirliği başlangıç paketinin özü.

“Yavaş” raporları için basit bir triage akışı

Birisi “yavaş” dediğinde en hızlı kazanç o belirsiz hissi birkaç somut soruya çevirmektir. Bu başlangıç paketi triage akışı uygulamanız çok yeni olsa bile işe yarar.

5 adımlı triage

Sorunu daraltıp sonra kanıtı sırayla takip edin. Doğrudan veritabanına atlamayın.

1. Kapsamı doğrulayın. Bir kullanıcı mı, bir müşteri hesabı mı, bir bölge mi yoksa herkes mi etkilendi? Ayrıca sorun Wi‑Fi ve hücreselde, birden fazla tarayıcı/cihaza da oluyor mu?\n2. Önce ne değişti kontrol edin. İstek hacmi mi sıçradı, hata oranı mı arttı yoksa sadece gecikme mi yükseldi? Trafik artışı genelde kuyruğa yol açar; hata artışı bir bağımlılığın bozulduğunu gösterebilir.\n3. Yavaşlamayı rota veya işe ayırın. Etkilenen uç nokta(lar)ın p95 gecikmesini kontrol edin ve en kötü olanı bulun. Tek bir rota yavaşsa oraya odaklanın; tüm rotalar yavaşsa paylaşılan bağımlılıklara veya kapasiteye bakın.\n4. Yavaş yol için bir trace açın. Son 15 dakikadaki yavaş isteğin trace'ini alın ve span'ları süreye göre sıralayın. Amaç tek bir cümle: “Zamanın çoğu X'te.”\n5. Bağımlılıkları doğrulayın ve rollback kararını verin. DB doyumunu, yavaş sorguları, önbellek isabet oranını ve üçüncü taraf yanıt sürelerini kontrol edin. Eğer yavaşlama deploy veya konfig değişikliğinden hemen sonra başladıysa rollback genellikle güvenli ilk adımdır.

Stabilize ettikten sonra bir küçük iyileştirme yapın: ne olduğunu yazın ve eksik olan bir sinyali ekleyin (ör. bölge etiketi, daha açıklayıcı sorgu etiketi vb.).