Üretilen backend'ler için günlükleme stratejisi: neler kaydedilmeli ve nasıl karartılmalı

Neden günlüklemenin bir planı olmalı (sadece daha fazla satır değil)

Günlükler ancak gerçek soruları hızlıca yanıtladıklarında yardımcı olur: ne bozuldu, kim etkilendi ve olanları kanıtlayabiliyor musunuz? Sağlam bir günlükleme stratejisi üç ihtiyacı aynı anda dengeler: hızlı teşhis, kritik eylemler için güvenilir denetim izi ve kullanıcı verilerinin korunması.

Bir plan yoksa ekipler genellikle iki sorundan birine takılır. Ya üretimde hata ayıklamak için yeterli ayrıntı yoktur, ya da çok fazla ayrıntı vardır ve hassas bilgiler sızar. İkinci sorun geri döndürülemezdir çünkü günlükler panolara, yedeklere ve üçüncü taraf araçlara kopyalanır.

Yarar ile maruziyet arasında sürekli bir gerilim vardır. Bir isteği servisler ve iş akışları boyunca izleyebilmek için yeterli bağlama ihtiyaç duyarsınız, ama aynı zamanda sırlar ve kişisel veriler için net sınırlar belirlemelisiniz. "Her şeyi kaydet" bir strateji değil, bir risk kaynağıdır.

Farklı insanlar günlükleri farklı nedenlerle okur ve bu ne yazacağınızı etkilemelidir. Geliştiriciler stack trace'ler, başarısız girişler ve zamanlamalar arar. Destek ekipleri kullanıcı açısından güvenli iz kırıntılarına (breadcrumbs) ihtiyaç duyar ki sorunu yeniden üretebilsinler. Güvenlik ekipleri tekrarlayan başarısız girişler gibi kalıpları izler. Uyumluluk ekipleri ve denetçiler kim ne yaptı ve ne zaman diye ilgilenir.

Teknik olmayan ekipler için beklentileri erkenden belirleyin: günlükler bir veritabanı değildir ve "ileriye dönük saklamak için" kullanılacak bir yer değildir. Müşteri tarafına görünür kayıtlar gerekiyorsa, bunları uygun erişim kontrolleri, saklama kuralları ve onay ile gerçek tablolara saklayın. Günlükler kısa ömürlü operasyonel kanıtlardır.

AppMaster gibi bir platformla inşa ediyorsanız, günlüklemeyi backend ürününün bir parçası olarak görün, sonradan yapılacak bir iş değil. Hangi olayların izlenebilir olması gerektiğine (auth, ödemeler, iş akışları, entegrasyonlar), hangi alanların her zaman güvenli olduğuna ve nelerin karartılması gerektiğine önceden karar verin. Bu, uygulamanız yeniden üretildiğinde ve büyüdüğünde günlüklerin tutarlı kalmasını sağlar.

Düz anlatımla günlük türleri ve seviyeleri

Pratik bir strateji, kaydettiğiniz mesaj türleri için ortak isimlerle başlar. Herkes aynı seviyeleri ve olay isimlerini kullandığında daha hızlı arama yapabilir, uyarılar güvenle kurulabilir ve gerçek sorunları saklayan gürültülü günlüklerden kaçınılır.

Gerçekçi kullanılabilir günlük seviyeleri

Günlük seviyeleri aciliyetle ilgilidir, "ne kadar metin" ile değil. Küçük bir set çoğu ekip için yeterlidir:

• Debug: hata ayıklama için geliştirici ayrıntıları (genelde prod'ta kapalı).
• Info: normal, beklenen olaylar (bir kullanıcı profili güncelledi, bir iş tamamlandı).
• Warn: beklenmeyen ama sistemin hâlâ çalıştığı durumlar (yeniden deneme, yavaş sorgu).
• Error: işlem başarısız oldu ve ilgi gerekiyor (ödeme oluşturma başarısız oldu, DB hatası).
• Security: şüpheli veya hassas durumlar (token suistimali kalıpları, tekrarlayan başarısız girişler).
• Audit: uyumluluk ve soruşturmalar için "kim ne yaptı ve ne zaman".

Security ve audit sık karıştırılır. Security günlükleri tehditleri tespit etmenize yardım eder. Audit günlükleri daha sonra olanları yeniden kurup kanıtlamaya yarar.

Yapılandırılmış günlükler: tutarlı alanlar serbest metinden üstündür

Serbest metin günlükleri filtrelemesi zor ve yanlış yapması kolaydır. Yapılandırılmış günlükler her seferinde aynı alanlara (genelde JSON) sahip olur, böylece aramalar ve panolar güvenilir kalır. Bu, kod üretildiğinde daha da önemlidir çünkü tutarlılık korunması gereken en büyük avantajlardan biridir.

Bir olayı kısa bir paragraf yerine alanlarla (event_name, request_id, user_id, status) kaydetmeyi hedefleyin.

Olay vs iz vs metrik

Bu terimler günlük konuşmada örtüşür ama farklı problemleri çözerler:

• Olay (log): olan tek bir şey (giriş başarılı, webhook alındı).
• İz (trace): tek bir isteğin servisler arasındaki yolu.
• Metrik: zaman içinde bir sayı (hata oranı, kuyruk uzunluğu, ödeme gecikmesi).

Zaman kuralları: birini seçin ve ona bağlı kalın

ISO 8601 zaman damgaları kullanın ve her şeyi UTC olarak kaydedin. Görüntüleme için kullanıcının zaman dilimi gerekiyorsa ayrı bir alan olarak saklayın. Bu, olaylarda zaman dilimi karışıklığını önler.

Pratik bir taksonomi: her günlüğün sahip olması gereken ortak alanlar

Ana karar basittir: her önemli olay bir insan tarafından okunabilir ve bir makine tarafından filtrelenebilir olmalıdır. Bu, kısa mesajlar ve tutarlı alanlar demektir.

Temel alanlar (her yerde kullanın)

Her günlük girdisinin aynı omurgaya sahip olması, tek bir isteği servisler ve dağıtımlar arasında izlemeyi kolaylaştırır; uygulama yeniden üretildiğinde bile.

• timestamp ve severity (info/warn/error)
• event (ör. auth.login.succeeded gibi stabil bir isim)
• service, environment ve build (sürüm veya commit)
• request_id (gelen istek başına benzersiz)
• route, status ve duration_ms

severity, event ve request_id'yi zorunlu kabul edin. Bunlar olmadan günlükleri güvenilir şekilde arayamaz, gruplayamaz veya ilişkilendiremezsiniz.

Bağlam alanları (ilgili olduğunda ekleyin)

Bağlam, günlükleri yararlı kılar ama bunları veri yığınına çevirmemelidir. Sistemin ne yapmaya çalıştığını açıklayan alanları ekleyin.

• user_id (e-posta veya telefon değil, dahili ID)
• tenant_id veya org_id (çok kiracılı uygulamalar için)
• workflow (süreç adı veya adım)
• integration (sağlayıcı/sistem adı)
• feature_flag (davranışı değiştiren bayrak anahtarı)

AppMaster arka ucunda mantık Business Process üzerinden çalışıyorsa workflow ve step günlükleyerek bir isteğin nerede takıldığını gösterebilirsiniz ve mesajlar kısa kalır.

Mesaj metnini tek satırlık bir özetle sınırlayın (ne oldu), ayrıntıları ise alanlarda tutun (neden oldu). Yapılandırılmış bir günlük girdisi şöyle olabilir:

{
  "severity": "info",
  "event": "payment.intent.created",
  "service": "backend",
  "environment": "prod",
  "build": "2026.01.25-1420",
  "request_id": "req_8f3a...",
  "route": "POST /checkout",
  "status": 200,
  "duration_ms": 184,
  "user_id": 48291,
  "tenant_id": 110,
  "integration": "stripe"
}

Bu yaklaşımla kodu yeniden üretebilir, altyapıyı değiştirebilir ve yeni iş akışları ekleyebilirsiniz; günlükler zaman içinde karşılaştırılabilir kalır.

Kimlik doğrulama günlükleri: kimlik bilgilerini açığa çıkarmadan neler kaydedilmeli

Auth günlükleri, hesap ele geçirme denemelerini veya kullanıcıların "giriş yapamadım" demesinin nedenini öğrendiğiniz yerdir. Aynı zamanda ekiplerin yanlışlıkla sırları sızdırdığı alandır. Amaç yüksek izlenebilirlik ve sıfır hassas değer sızıntısıdır.

Auth'u şu iki hatta ele alın:

• Audit günlükleri "kim ne yaptı ve ne zaman" sorusunu cevaplarken;
• Debug/ops günlükleri "neden başarısız oldu" sorusunu açıklar.

Kimlik doğrulama ve oturumlar için neler kaydedilmeli

Ana olayları stabil isimlerle ve korelasyon veya istek ID'si ile yapılandırılmış girdiler olarak kaydedin ki bir oturum açma olayını sistemler arasında takip edebilin.

Başarılı/başarısız oturum açma denemelerini bad_password, unknown_user, mfa_required veya account_locked gibi neden kodlarıyla kaydedin. MFA yaşam döngüsünü (challenge verildi, yöntem, başarı/başarısızlık, fallback kullanıldı) izleyin. Parola sıfırlama olaylarını (istek, token gönderildi, token doğrulandı, parola değiştirildi) ve oturum/token yaşam döngüsü olaylarını (oluşturuldu, yenilendi, iptal edildi, süresi doldu) kaydedin. Ayrıca rol değişiklikleri ve hesap devre dışı bırakma/etkinleştirme gibi yönetici işlemlerini kaydedin.

AppMaster'ın üretilen backend ve kimlik doğrulama modüllerini kullanıyorsanız, uygulama yeniden üretildiğinde günlüklerin stabil kalması için iç uygulama detayları yerine iş sonucuna (izin verildi veya reddedildi) odaklanın.

Yetkilendirme kararları (erişim kontrolü)

Her önemli izin/vergi kararı açıklanabilir olmalıdır. Kaynak türünü ve eylemi, kullanıcı rolünü ve kısa bir neden kodunu günlükleyin. Tam nesneleri veya sorgu sonuçlarını günlüklemeyin.

Örnek: bir destek ajanı yönetici ekranını açmaya çalışıyor. decision=deny, role=support, resource=admin_panel, reason=insufficient_role kaydedin.

Sırları karartın ve güvenlik sinyallerini yakalayın

Parolaları, tek kullanımlık kodları, kurtarma kodlarını, ham erişim/yenileme tokenlarını, oturum ID'lerini, API anahtarlarını, Authorization başlıklarını, çerezleri, tam JWT'leri veya e-posta/SMS doğrulama mesajlarının tam içeriğini asla günlüklemeyin.

Bunların yerine güvenli sinyaller günlükleyin: hash'lenmiş veya kırpılmış tanımlayıcılar (ör. token hash'inin son 4 hanesi), IP ve user agent (maskeleme düşünülebilir) ve anomali sayıcıları (çok sayıda başarısız deneme, sıra dışı konum değişiklikleri, tekrarlayan token suistimali). Bu sinyaller, saldırıları sızdırmadan tespit etmeye yardım eder.

Ödemeler günlükleri: Stripe ve benzeri sağlayıcılar için izlenebilirlik

Ödeme günlükleri tek bir soruyu hızlıca yanıtlamalı: bu ödemeye ne oldu ve kanıtlayabiliyor musunuz? Odak izlenebilirlikte, ham yükte değil.

Ödeme yaşam döngüsünü küçük, tutarlı olaylar dizisi olarak kaydedin. Her şeyi tutmanız gerekmez ama ana evreleri (intent oluşturuldu, onaylandı, başarısız oldu, iade edildi, itiraz veya chargeback) yakalayın.

Her olay için sağlayıcı panoları ve destek talepleriyle eşleştirebilecek kompakt referanslar saklayın:

• provider (ör. Stripe)
• provider_object_id (payment_intent, charge, refund, dispute ID)
• amount ve currency
• status (created, confirmed, failed, refunded, disputed)
• error_code ve kısa, normalleştirilmiş error_message

Hassas verileri günlüklerde tutmayın, hatta debug modunda bile. Tam kart numaralarını, CVC'yi veya tam fatura adreslerini asla günlüklemeyin. Müşteri korelasyonu gerekiyorsa dahili customer_id ve order_id kullanın; tam isim, e-posta veya adres yerine.

Webhook'lar: gövdeyi değil zarfı günlükleyin

Webhook'lar gürültülü olabilir ve genelde beklenenden daha fazla kişisel veri içerir. Varsayılan olarak sadece event_id, event_type ve işleme sonucu (accepted, rejected, retried) kaydedin. Eğer reddederseniz net bir sebep (imza kontrolü başarısız, bilinmeyen nesne, çoğaltılmış olay) kaydedin. Tam yükü yalnızca gerçekten gerektiğinde güvenli, erişim kontrollü bir yerde saklayın.

İadeler ve itirazlar için denetim izi gerekli

İadeler ve itiraz yanıtları yüksek risklidir. Kim tetikledi (user_id veya service_account), ne zaman oldu ve ne istendi (iade miktarı, neden kodu) gibi bilgileri kaydedin. AppMaster'da bu genellikle Stripe'ı çağıran Business Process içinde açık bir günlük adımı eklemek demektir.

Örnek: bir destek ajanı 49$'lık bir siparişi iade ediyor. Günlükleriniz order_id, Stripe'tan gelen iade ID'si, ajanın user_id'si, zaman damgası ve nihai durumu göstermelidir; kart veya adres detaylarını asla açığa çıkarmadan.

İş akışı günlükleri: iş süreçlerini gözlemlenebilir tutun

İş akışları işin gerçekten gerçekleştiği yerdir: bir sipariş onaylanır, bir bilet yönlendirilir, bir iade talep edilir, müşteri bilgilendirilir. Eğer backendiniz görsel bir süreçten (AppMaster'ın Business Process Editor gibi) oluşturuluyorsa, günlükleme iş akışını takip etmeli, sadece kodu değil. Aksi halde hataları hikâyeden kopuk görürsünüz.

Bir iş akışı çalışmasını olay dizisi olarak ele alın. Basit tutun: bir adım başladı, tamamlandı, başarısız oldu veya yeniden denendi. Bu modelle birçok çalışmanın aynı anda olduğu durumlarda bile ne olduğunu yeniden kurabilirsiniz.

Her iş akışı olayı için küçük, tutarlı bir alan seti ekleyin:

• iş akışı adı ve sürümü (veya son düzenleme zaman damgası)
• run_id (o yürütme için benzersiz ID)
• adım adı, adım türü, deneme sayısı
• olay türü (started, completed, failed, retried) ve durum
• zamanlama (adım süresi ve şu ana kadarki toplam çalışma süresi)

Girdiler ve çıktılar ekipleri genelde zor duruma sokar. Verinin şeklini günlükleyin, verinin kendisini değil. Şema adlarını, bulunan alanların listelerini veya stabil hash'leri tercih edin. Daha fazla hata ayıklama ayrıntısı gerekiyorsa sayılar ve aralıklar kaydedin (ör. items=3, total_cents=1299) doğrudan isimler, e-postalar, adresler veya serbest metin yerine.

Operatör eylemleri birinci sınıf olaylar olmalıdır çünkü sonuçları değiştirirler. Bir yönetici bir isteği onayladıysa, bir koşuyu iptal ettiyse veya bir adımı geçersiz kıldıysa, kim yaptığını (user_id, rol), ne yaptığını (action), nedenini (reason_code) ve önce/sonra durumunu kaydedin.

Örnek: bir “Gider onayı” iş akışı “Yöneticiyi bildir” adımında mesajlaşma kesintisi nedeniyle başarısız oldu. İyi günlükler run_id, başarısız adım, yeniden deneme sayıları ve bekleme süresini gösterir. Böylece olayın sonunda gönderilip gönderilmediği, kim onayladığı ve hangi yürütmelerin takılı kaldığı cevaplanabilir.

Entegrasyon günlükleri: API'ler, mesajlaşma ve üçüncü taraf servisler

Entegrasyonlar backendlerin sessizce başarısız olduğu yerlerdir. Kullanıcı “bir şeyler yanlış” görürken gerçek neden bir hız limiti, süresi dolmuş token veya yavaş bir sağlayıcı olabilir. Günlükleme her dış çağrıyı günlüklerken bunları izlemeyi kolaylaştırmalı ama üçüncü taraf verilerin kopyası olmamalıdır.

Her entegrasyon çağrısını tutarlı biçimde bir olay olarak kaydedin. "Ne oldu" ve "ne kadar sürdü" üzerine odaklanın, yükü dökmeyin.

Her dış çağrı için neler kaydedilmeli

Hata ayıklamak, ölçmek ve denetlemek için yeterince bilgiyi yakalayın:

• sağlayıcı adı (ör. Stripe, Telegram, email/SMS, AWS, OpenAI)
• endpoint veya işlem adı (dahili adınız, tam URL değil)
• method/aksiyon, durum/sonuç, gecikme ms olarak, yeniden deneme sayısı
• korelasyon tanımlayıcıları (sizin request_id'niz ve sağlayıcı tarafı ID varsa)
• circuit breaker ve backoff olayları (opened, half-open, closed, retry_scheduled)

Korelasyon ID'leri, bir iş akışı birden çok sistemi tetiklediğinde en önemli olanlardır. Tek bir müşteri eylemi hem bir e-posta hem bir ödeme kontrolü tetikliyorsa, aynı request_id ilgili tüm günlüklerde görünmeli ve sağlayıcının mesaj ID'si veya ödeme ID'si de mevcutsa eklenmelidir.

Bir çağrı başarısız olduğunda, sağlayıcılar arasında tutarlı sınıflandırma yapın. Panolar ve uyarılar ham hata metninden çok daha kullanışlı olur.

• auth hatası (süresi dolmuş token, geçersiz imza)
• rate limit (HTTP 429 veya sağlayıcıya özgü kod)
• validation hatası (kötü parametreler, şema uyumsuzluğu)
• timeout/ağ (bağlantı zaman aşımı, DNS, TLS)
• sağlayıcı hatası (5xx, service unavailable)

Varsayılan olarak ham istek veya yanıt gövdelerini günlüklemeyin. Hata ayıklama için bir örnek yakalamanız gerekiyorsa bunu kısa ömürlü bir bayrağın arkasına koyup önce temizleyin (tokenlar, sırlar, e-postalar, telefonlar, tam adresler kaldırılmalı). AppMaster gibi birçok entegrasyonun görsel olarak yapılandırıldığı platformlarda, akış değişse bile alanları tutarlı tutun.

Geliştiricilerin takip edebileceği PII-güvenli karartma kuralları

Karartma en iyi sıkıcı ve otomatik olduğunda çalışır. Günlükler hata ayıklamaya ve denetlemeye yardımcı olmalı, bir kişinin kimliğini yeniden oluşturmayı veya loglar sızarsa erişim çalmayı mümkün kılmamalıdır.

Hassas verileri birkaç gruba ayırın ki herkes aynı terimleri kullansın:

• tanımlayıcılar: tam isim, ulusal kimlikler, kişiye bağlı müşteri ID'leri
• iletişim bilgileri: e-posta, telefon, posta adresi
• finansal: kart numaraları, banka bilgileri, ödeme detayları
• konum ve sağlık: hassas konum, tıbbi veriler
• kimlik bilgileri: parolalar, API anahtarları, oturum çerezleri, OAuth kodları, yenileme tokenları

Sonra her grup için bir eylem seçin ve buna uyun:

• tamamen sil: kimlik bilgileri, sırlar, ham tokenlar, tam kart numaraları
• maskele: e-postalar ve telefonlar (destek için küçük bir kısım saklanabilir)
• kırp: uzun serbest metin alanları (destek notları PII içerebilir)
• hash: gruplayıp değeri gizlemek gerektiğinde (anahtarlı hash kullanın, düz SHA değil)
• tokenize: dahili bir referansla değiştirin (ör. user_id) ve gerçek değeri başka yerde saklayın

Güvenli örnekler (günlüklere ne koyulmalı):

• e-posta: j***@example.com (yerel kısmı maskeler, domain kalır)
• telefon: ***-***-0199 (son 2-4 hane bırakılabilir)
• adres: tam adresi bırakmayın; gerektiğinde sadece country veya region kaydedin
• tokenlar: tamamen kaldırın; sadece token_present:true veya token türünü kaydedin

Karartma, iç içe nesneler ve diziler içinde de çalışmalı, sadece üst düzey alanlarda değil. Bir ödeme yükü customer.email ve charges[].billing_details.address içerebilir. Logger'ınız yalnızca ilk seviyeyi kontrol ediyorsa gerçek sızıntıları kaçırır.

İzin listesi (allowlist) ilk yaklaşımı kullanın. Her zaman güvenli kabul edilen küçük bir alan seti (request_id, user_id, event, status, duration_ms) tanımlayın ve bilinen hassas anahtarların (password, authorization, cookie, token, secret, card_number) bir reddetme listesi olsun. AppMaster gibi üretilen backendlerin paylaşılan middleware'inde bu kuralları koymak, her endpoint ve iş akışının aynı güvenlik varsayımlarını miras almasını sağlar.

Stratejiyi adım adım nasıl uygulamalısınız

Günlükleme şemanızı koda dokunmadan önce yazın. Eğer backendiniz üretiliyorsa (ör. AppMaster tarafından üretilen bir Go servisi), yeniden üretime dayanacak bir plan gerekir: tutarlı olay adları, tutarlı alanlar ve karartmanın tek yerde zorunlu kılınması.

Basit bir yayılma planı

Aynı kuralları her yerde uygulayın: API handler'lar, arka plan işler, webhook'lar, zamanlanmış iş akışları.

• auth.login_succeeded, payment.webhook_received, workflow.step_failed, integration.request_sent gibi yeniden kullanılabilir olay adları tanımlayın. Her biri için hangi alanların gerekli olduğunu kararlaştırın.
• Korelasyon alanlarını erkenden ekleyin ve zorunlu kılın: request_id, trace_id (varsa), user_id (veya anonim), ve çok kiracılı uygulamalar için tenant_id. request_id'yi kenarda oluşturun ve tüm iç çağrılar boyunca aktarın.
• Karartmayı günlükleme sınırında, yazılmadan önce uygulayın. İstek ve yanıt gövdelerinden hassas anahtarları kaldıran middleware veya bir logging wrapper kullanın.
• Ortam bazlı log seviyeleri ayarlayın. Prod'ta ana olaylar için info, hatalar için warn/error tercih edin. Verbose debug dökümlerinden kaçının. Geliştirmede daha fazla ayrıntıya izin verin ama karartmayı açık tutun.
• Gerçekçi test yükleriyle çalıştığını kanıtlayın. Bilinçli olarak PII ekleyin (e-postalar, telefonlar, erişim tokenları) ve kaydedilen günlüklerin yalnızca güvenli değerler içerdiğini doğrulayın.

Dağıttıktan sonra ayda bir olay tatbikatı yapın. Bir senaryo seçin (başarısız bir Stripe webhook yeniden oynatma, bir giriş seli, takılmış bir iş akışı) ve günlüklerin ne olduğunu, kimin etkilendiğini, ne zaman ve nerede olduğunu ifşa etmeden cevaplayıp cevaplayamadığını kontrol edin.

Şemanın kendini düzeltmesini sağlayın

Eksik zorunlu alanları görmezden gelmeyi zorlaştırın. İyi bir uygulama, zorunlu alanlar eksikse build'in başarısız olması veya üretim günlüklerinden örneklemeler yapmaktır:

• ham parolalar, tokenlar veya tam kart detayları yok
• her isteğin request_id ve (ilgiliyse) tenant_id'si var
• hatalar tam gövde dökümü yerine güvenli error_code + bağlam içeriyor

Risk veya kör noktalar yaratan yaygın hatalar

Günlükler bir döküm deposuna dönüşünce (ya işe yaramaz ya da tehlikelidir) amaç bozulur. Hedef netliktir: ne oldu, neden oldu ve kim/tetikleyen neydi.

1) Sırlar fark edilmeden sızdırılıyor

Çoğu sızıntı kazayla olur. Yaygın nedenler istek başlıkları, auth tokenları, çerezler, webhook imzaları ve "yararlı" diye yapılan tam gövde dökümleridir. Authorization başlığını veya ödeme sağlayıcı webhook sırrını içeren tek bir log satırı log deposunu kimlik bilgisi kasasına çevirebilir.

Eğer kod üreten bir platform kullanıyorsanız, kenarlarda (ingress, webhook handler, entegrasyon istemcileri) karartma kurallarını ayarlayın ki her servis aynı varsayılan güvenlik davranışını devralsın.

2) Aranamaz serbest metin günlükleri

"Kullanıcı giriş yapamadı" gibi günlükler okunaklıdır ama analiz edilemez. Serbest metin olayları türüne göre filtrelemeyi, hata nedenlerini karşılaştırmayı veya uyarılar kurmayı zorlaştırır.

Yapılandırılmış alanları tercih edin (event, actor_id, request_id, outcome, reason_code). İnsan cümlesi opsiyonel bağlam olsun, tek gerçek kaynak olmasın.

3) Yükleri aşırı günlükleyip kararları az günlüklemek

Ekipler genelde istek/yanıt gövdelerini kaydeder ama önemli kararları kaçırır. Örnek: "ödeme reddedildi" kaydedilir ama sağlayıcı durumu yoktur; "erişim reddedildi" vardır ama politika kuralı yoktur; "iş akışı başarısız oldu" vardır ama adım ve neden kodu yoktur.

Bir şey ters gittiğinde genelde ham yükten çok karar izine ihtiyaç duyarsınız.

4) Denetim ve debug günlüklerini karıştırma

Denetim günlükleri stabil ve incelenmesi kolay olmalı. Debug günlükleri gürültülüdür ve sık değişir. Karıştırıldıklarında uyumluluk incelemeleri zorlaşır ve önemli denetim olayları kaybolur.

Çizgiyi net tutun: denetim günlükleri kim ne yaptı ve ne zaman kaydeder; debug günlükleri sistemi oraya nasıl getirdiğini açıklar.

5) Saklama planı yok

Günlükleri sonsuza kadar saklamak risk ve maliyeti artırır. Çok hızlı silmek ise olay yanıtı ve chargeback soruşturmalarını kırar.

Log türüne göre farklı saklama pencereleri belirleyin (audit vs debug) ve dışa aktarımlar, yedekler ve üçüncü taraf log hedeflerinin aynı politikayı takip ettiğinden emin olun.

Hızlı kontrol listesi ve sonraki adımlar

Günlükler işini yapıyorsa şu soruya hızlıca cevap verebilmelisiniz: "Bu isteğe ne oldu?" Aşağıdaki kontrolleri kullanarak geçici sorunları uzun gece nöbetlerine dönüşmeden önce tespit edin.

Hızlı kontrol listesi

Gerçek üretim isteği (veya benzerini yansıtan staging) ile şu kontrolleri yapın:

• Uçtan uca iz: tek bir request_id ile bir kullanıcı eylemini servisler arasında takip edebiliyor musunuz? Ana adımları görebiliyor musunuz?
• Auth güvenliği: kimlik doğrulama günlükleri parolaları, oturum çerezlerini, JWT'leri, API anahtarlarını, sihirli bağlantıları ve sıfırlama tokenlarını %100 oranında atlıyor mu?
• Ödeme izlenebilirliği: ödeme günlükleri sağlayıcı tanımlayıcıları ve durum değişikliklerini kaydediyor; kart verisi veya tam fatura detaylarını asla içermiyor mu?
• İş akışı görünürlüğü: iş süreçleri run_id ve step_name ile aranabilir mi; açık başlangıç/başarı/hata ve süre bilgisi var mı?
• Entegrasyon açıklığı: üçüncü taraf çağrılar için sağlayıcı, işlem adı, gecikme, durum ve güvenli hata özeti kaydediliyor mu; gövdeler dökülmüyor mu?

Eğer herhangi bir madde "çoğunlukla" ise onu "hayır" olarak değerlendirin. Bu ancak kurallar tutarlı ve otomatik olduğunda işe yarar.

Sonraki adımlar

Kontrol listesini ekibinizin uygulayabileceği kurallara dönüştürün. Küçük başlayın: bir paylaşılan şema, bir karartma politikası ve hassas alanlar sızarsa testleri başarısız eden birkaç test.

Günlükleme şemanızı (ortak alanlar ve adlandırma) ve karartma listenizi yazılı hale getirin. Kaba istek gövdeleri, başlıklar veya filtrelenmemiş kullanıcı nesneleri içeren günlükleri reddeden kod inceleme kuralları ekleyin. Auth, ödeme, iş akışları ve entegrasyonlar için birkaç "güvenli günlük olayı" oluşturun ki ekipler tutarlı desenleri kopyalasın. password, token ve authorization gibi yasaklı alanları tespit eden otomatik testler (unit testleri veya lint kuralları) ekleyin. Üç aylık periyotlarda örnekleme, log seviyeleri ve saklama sürelerini risk ve uyumluluk gereksinimlerinize göre gözden geçirin.

AppMaster üzerinde inşa ediyorsanız, bu kuralları bir kez merkezileştirip üretilen Go backend'leriniz, iş akışlarınız ve entegrasyonlarınız genelinde yeniden kullanmak yardımcı olur. Şema ve karartma mantığını tek bir yerde tutmak, uygulamanız appmaster.io üzerinde yeniden üretildiğinde korunmasını kolaylaştırır.