Log Yönetimi: Bahis Platformunda Merkezi İzleme Rehberi

Bir güvenlik olayını ya da ödeme sorununu çözmek, çoğu zaman doğru logun doğru yerde olup olmadığına bağlıdır. Her servisin kendi sunucusunda farklı biçimde log tuttuğu bir yapıda, tek bir oyuncunun şikâyetini izlemek saatler alabilir. Merkezi log yönetimi, tüm kayıtları tek bir yerde, aranabilir ve birbiriyle ilişkilendirilebilir hale getirir. Bu rehberde neyi toplayacağını, nasıl yapılandıracağını, ne kadar saklayacağını ve loglardan nasıl uyarı üreteceğini ele alıyoruz.

Hangi loglar toplanmalı?

• API erişim logları: Zaman damgası, uç nokta, HTTP durum kodu, yanıt süresi ve istek kimliği.
• Kimlik doğrulama olayları: Başarılı ve başarısız girişler, ikinci adım doğrulama, oturum sonlandırma.
• Ödeme olayları: Yatırım ve çekim talepleri, onay ve red durumları, sağlayıcı yanıt kodları.
• Yönetici işlemleri: Yapılandırma değişiklikleri, rol atamaları, bonus ve limit düzenlemeleri.
• Sistem olayları: Servis yeniden başlatmaları, bağımlılık hataları, kaynak eşiklerinin aşılması.
• Dış kaynaklı sinyaller: Sağlayıcı bildirimleri ve erişilebilirlik kontrolü sonuçları gibi dışarıdan gelen veriler.

Yapılandırılmış log

Düz metin loglar insan için okunaklıdır ama makine için değildir. Her kaydı alanları sabit bir JSON nesnesi olarak yazmak; aramayı, filtrelemeyi ve uyarı kurmayı kolaylaştırır. Örnek bir kimlik doğrulama kaydı:

{
  "ts": "2026-09-28T09:14:03.512Z",
  "level": "warn",
  "service": "auth",
  "event": "login_failed",
  "requestId": "req_7f3a1c",
  "userId": "u_48213",
  "ip": "203.0.113.***",
  "reason": "invalid_otp"
}

• Her isteğe bir kimlik ver ve bu kimliği tüm servislerde taşı; bir işlemin izini uçtan uca bu sayede sürersin.
• Alan adlarını tüm servislerde aynı tut: bir serviste "userId", diğerinde "user_id" olması sorguları zorlaştırır.
• Log seviyelerini tutarlı kullan; her şeyi "error" olarak yazmak gerçek hataları görünmez kılar.
• Zaman damgalarını tek bir saat diliminde, tercihen UTC olarak yaz.

Kişisel veriyi ve sırları loglama

Log sistemleri genellikle üretim veritabanından daha geniş bir ekibin erişimine açıktır. Bu yüzden loga yazılan her şeyi, sızabilecek bir veri olarak düşünmelisin.

• Parola, jeton, API anahtarı ve kart bilgisi gibi sırları hiçbir koşulda loglama.
• E-posta, telefon ve IP adresi gibi kişisel verileri maskele ya da kısalt.
• İstek ve yanıt gövdelerini olduğu gibi yazmak yerine yalnızca gerekli alanları seç.
• Kullanıcı girdisini loga yazarken satır sonu gibi kontrol karakterlerini temizle; aksi halde sahte log satırı eklenebilir.

Kişisel verilerin korunmasıyla ilgili yükümlülükler için GDPR ve veri koruma yazımıza bakabilirsin.

ELK mi, Grafana Loki mi?

Merkezi loglamada en sık karşılaşılan iki seçenek ELK Stack (Elasticsearch, Logstash, Kibana) ve Grafana Loki'dir.

• ELK: Log içeriğini tam metin olarak indeksler. Serbest metin aramalarında güçlüdür; buna karşılık depolama ve kaynak ihtiyacı daha yüksektir.
• Loki: İçeriği değil etiketleri indeksler ve log satırlarını sıkıştırılmış olarak saklar. Daha düşük maliyetle çalışır; sorgular önce etiketlerle daraltılır, sonra içerikte filtrelenir.

Zaten Prometheus ve Grafana kullanıyorsan Loki, metriklerle logları aynı panelde görmeni sağlar. Bu yapının genel resmi için izleme yığını yazımıza göz atabilirsin.

Saklama politikası

Ne kadar süre saklayacağın; lisans koşullarına, yargı bölgesindeki mevzuata ve iç denetim ihtiyaçlarına bağlıdır. Bu yüzden tek bir evrensel süre yoktur, ama politikanın yapısı her yerde benzerdir:

1. Her log türü için saklama süresini hukuk ve uyum ekibiyle birlikte yazılı olarak belirle.
2. Sık erişilen yakın dönemi hızlı depolamada, eski kayıtları sıkıştırılmış nesne depolamada tut.
3. Süresi dolan kayıtları otomatik olarak sil; "belki lazım olur" diye tutulan kişisel veri bir risktir.
4. Denetim açısından kritik kayıtları değiştirilemez biçimde sakla ve erişimini sınırlı tut.

Log tabanlı uyarılar

Loglar yalnızca olay sonrası inceleme için değil, olay anında uyarı üretmek için de kullanılır. Grafana Loki'de, aynı hesap için beş dakika içinde beşten fazla başarısız giriş yapılmasını yakalayan bir kural şöyle yazılabilir:

sum by (userId) (
  count_over_time({service="auth"} | json | event="login_failed" [5m])
) > 5

Benzer kurallarla izlemeye değer diğer örüntüler şunlardır:

• Olağan dışı hacimde çekim talebi.
• Mesai dışında yönetici hesabıyla yapılan yapılandırma değişikliği.
• Ödeme sağlayıcısından art arda gelen hata kodları.

Log hacmini kontrol altında tutmak

Her şeyi loglamak kulağa güvenli gelir ama maliyeti ve gürültüyü hızla artırır. Hacmi yönetmek için:

• Üretimde hata ayıklama seviyesini kapalı tut; gerektiğinde servis bazında ve geçici olarak aç.
• Sağlık kontrolü gibi tekrarlayan ve bilgi taşımayan istekleri örnekle ya da hiç loglama.
• Etiket sayısını sınırlı tut; Loki'de kullanıcı kimliği gibi çok çeşitli değerleri etiket yerine log içeriğinde taşı. Yukarıdaki sorgu da userId alanını bu yüzden etiketten değil, json ayrıştırmasından alır.

Başlangıç kontrol listesi

1. Tüm servislerde ortak bir JSON log şeması belirle.
2. İstek kimliğini servisler arasında taşı.
3. Sırları ve kişisel verileri maskeleyen ortak bir kütüphane kullan.
4. Logları merkezi sisteme gönder ve erişimi rol bazında sınırla.
5. Saklama sürelerini yazılı hale getir ve otomatik silmeyi aç.
6. İlk üç uyarı kuralını kur ve bir hafta boyunca ne kadar gürültü ürettiklerini ölç.

LLCBullet verisini log yığınına eklemek

Bahis altyapılarındaki sitelerin erişilebilirlik verisini de aynı yerde görmek istiyorsan LLCBullet'in webhook görevini kullanabilirsin. Görev, seçtiğin altyapıdaki sitelerin durumunu ve yanıt süresini belirlediğin zamanlamayla imzalı JSON olarak kendi HTTPS adresine gönderir. Alıcı servisin imzayı doğruladıktan sonra her siteyi ayrı bir yapılandırılmış log satırı olarak yazabilir; böylece erişilebilirlik sorunlarını kendi uygulama loglarınla aynı zaman çizelgesinde incelersin. Kurulum ve imza doğrulama için webhook rehberine bak.