İçeriğe geç
LLCBullet
Otomasyon

Bahis Operasyonu için İzleme Yığını: Prometheus, Grafana ve LLCBullet

Bahis operasyonu için katmanlı izleme: Prometheus ile metrik, Grafana ile görselleştirme, Loki ile log, Alertmanager ile Telegram uyarıları ve LLCBullet ile dışarıdan erişilebilirlik kontrolü.

4 dk okuma

Bahis Operasyonu için İzleme Yığını: Prometheus, Grafana ve LLCBullet

Bir bahis operasyonunda sorunu ilk fark eden oyuncular olmamalı. Oyuncular şikâyet ettiğinde kayıp çoktan yaşanmıştır. Profesyonel bir izleme yığını, sistemi hem içeriden hem dışarıdan görerek sorunları erken yakalar ve doğru kişiye doğru anda haber verir. Bu yazıda yaygın açık kaynak araçlarla katmanlı bir izleme yığınının nasıl kurulacağını ve LLCBullet'in bu yığında nerede durduğunu anlatıyoruz.

İçeriden ve dışarıdan izleme

İç izleme; sunucuların, uygulamaların ve veritabanlarının kendi ürettiği metriklere ve loglara dayanır. Sistemin nasıl çalıştığını ayrıntılı gösterir, ama bir sınırı vardır: sistem kendini sağlıklı görse de kullanıcı siteye ulaşamıyor olabilir. DNS sorunları, CDN yapılandırma hataları, sertifika problemleri ya da ağ yolundaki kesintiler iç metriklerde görünmeyebilir. Dış izleme bu boşluğu kapatır: siteye internetten, gerçek bir istemci gibi istek atar ve sonucu kaydeder. İyi bir yığın ikisini birlikte kullanır.

Yığının bileşenleri

  • Prometheus: Uygulamalardan, veritabanlarından ve sunuculardan zaman serisi metrikleri toplar. HTTP istek sayısı, hata oranı ve kupon oluşturma gecikmesi gibi bahise özgü metrikler tanımlayabilirsin.
  • Grafana: Metrikleri panolara dönüştürür; farklı ekipler için farklı görünümler kurmanı sağlar.
  • Loki: Logları toplar ve etiketlerle metriklere bağlar. Bir metrik anomalisinden ilgili log satırlarına hızla geçebilirsin.
  • Alertmanager: Prometheus alarmlarını gruplar, susturur ve e-posta, webhook ya da Telegram gibi kanallara yönlendirir.
  • LLCBullet: Paketindeki altyapılara bağlı sitelerin erişilebilirliğini ve yanıt sürelerini dışarıdan kontrol eder, sonucu Telegram bildirimi ya da imzalı webhook olarak iletir.

Log tarafını daha ayrıntılı kurmak için merkezi log yönetimi rehberimize göz atabilirsin.

SLI ve SLO'ları tanımla

SLI (Service Level Indicator) ölçtüğün kalite göstergesi, SLO (Service Level Objective) ise bu gösterge için belirlediğin hedeftir. Hedefler iş gereksinimlerinden gelmelidir; başka bir şirketin rakamlarını kopyalamak yerine kendi trafiğini ve kullanıcı beklentini esas al. Başlangıç için şu göstergeleri tanımlayabilirsin:

  • Kupon oluşturma isteklerinin başarı oranı.
  • Canlı oran güncellemelerinin oyuncuya ulaşma gecikmesi.
  • Yatırım ve çekim isteklerinin hata oranı.
  • Sitenin dışarıdan yapılan kontrollerde erişilebilir bulunma oranı.

Son gösterge iç metriklerle ölçülemez; dış kontrol verisi gerektirir. Her gösterge için hedefi belirledikten sonra bir 'hata bütçesi' tanımla: hedefin altına düşülmesine izin verilen süre dolmaya yaklaştığında yeni sürüm çıkışlarını yavaşlatmak gibi somut kurallar koy.

Alarm kuralları: örnek

Aşağıdaki Prometheus kuralı, son 10 dakikadır 5xx yanıt oranı yüksek seyreden bir API için kritik alarm üretir. Eşik değeri yalnızca örnektir; kendi trafik profiline göre ayarlamalısın:

yaml
groups:
  - name: bet-api
    rules:
      - alert: BetApiHighErrorRate
        expr: |
          sum(rate(http_requests_total{job="bet-api", status=~"5.."}[5m]))
            /
          sum(rate(http_requests_total{job="bet-api"}[5m])) > 0.02
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "bet-api 5xx oranı son 10 dakikadır eşiğin üzerinde"
          runbook_url: "https://wiki.example.com/runbooks/bet-api-5xx"

Alarmları önem derecesine göre yönlendir: servis çökmesi ve ödeme hataları gibi kritik alarmlar doğrudan nöbetçi teknik ekibe, yüksek gecikme gibi uyarı seviyesindeki alarmlar operasyon kanalına gitmeli. Her alarmın bir sahibi ve bir runbook bağlantısı olmalı.

LLCBullet'i yığına bağlamak

LLCBullet'teki site kontrolü görevleri seçtiğin siteleri kendi zamanlamanla kontrol eder: HTTPS isteği gönderir, 5xx yanıtları ve bağlantı hatalarını erişilemez olarak kaydeder, her site için yanıt süresini ölçer. Sonuçları iki yolla kullanabilirsin:

  1. Doğrudan bildirim: Erişilemeyen site bulunduğunda Telegram, panel ya da tarayıcı bildirimi al. Küçük ekipler için çoğu zaman bu yeterlidir.
  2. Webhook ile yığına aktarma: Bir webhook görevi kur; LLCBullet belirlediğin zamanlamayla HTTPS adresine site durumlarını içeren imzalı bir JSON gönderir. Alıcı servisin imzayı doğruladıktan sonra bu veriyi Prometheus metriğine dönüştürebilir ya da doğrudan Alertmanager'a iletebilir.

Webhook gövdesi, site listesi açıksa her site için son erişilebilirlik durumunu ve yanıt süresini içerir. İmza doğrulamanın ayrıntıları için webhook görevleri rehberine, görevin kurulumu için site erişilebilirlik kontrolü rehberine bakabilirsin.

Nöbet ve eskalasyon

En iyi alarm kuralı bile kimse telefonuna bakmıyorsa işe yaramaz. Maç takvimine göre bir nöbet çizelgesi hazırla: büyük etkinliklerin olduğu akşamlarda teknik ve operasyon ekibinden birer kişinin ulaşılabilir olduğundan emin ol. Kritik bir alarm belirli bir süre içinde onaylanmazsa ikinci kişiye, ardından ekip liderine iletilmesini sağlayan basit bir eskalasyon zinciri kur. Telegram bu zincirin ilk halkası için pratik bir kanaldır; LLCBullet bildirimlerini ve Alertmanager uyarılarını aynı ekip sohbetinde değil, nöbetçi kişinin doğrudan göreceği bir yerde toplamak tepki süresini kısaltır.

Hangi panolara ihtiyacın var?

  1. Genel bakış: Tüm servislerin anlık durumu, aktif kullanıcılar ve son bir saatteki bahis hacmi.
  2. Performans: API yanıt süreleri (p50, p95, p99), veritabanı sorgu süreleri ve önbellek isabet oranı.
  3. İş metrikleri: Açık kuponlar, sonuçlanmayı bekleyen etkinlikler, ödeme başarı ve hata oranları.
  4. Altyapı sağlığı: CPU, bellek, disk doluluğu ve ağ trafiği.
  5. Dış görünüm: LLCBullet'ten gelen erişilebilirlik ve yanıt süresi verisi, altyapı bazında.

Sık yapılan hatalar

  • Her şeye alarm kurmak: Gürültülü alarmlar gerçek alarmların görmezden gelinmesine yol açar.
  • Yalnızca iç metriklere güvenmek: Sistem yeşil görünürken kullanıcı siteye ulaşamıyor olabilir.
  • Bakımı hesaba katmamak: Planlı bakımlarda alarmları susturmayan bir yığın ekibi yanlış alarmlarla yorar. LLCBullet'te bakımdaki altyapı ve siteler için görevler zaten atlanır.
  • Alarmı sahipsiz bırakmak: Kimin müdahale edeceği belli olmayan alarm, kimsenin müdahale etmediği alarmdır.

Sonuç

İç izleme sistemin nasıl çalıştığını, dış izleme ise kullanıcının ne yaşadığını gösterir. Prometheus, Grafana, Loki ve Alertmanager ile içeriyi; LLCBullet görevleri ve webhook'larıyla dışarıyı izleyerek sorunları oyunculardan önce görebilirsin.

  • prometheus
  • grafana
  • izleme yığını
  • observability
  • slo
  • llcbullet webhook

Bu yazıyı paylaş

Ortak etiket sayısına göre sıralanır.