OBSERVABILITY

Graylog’dan başlayan bir log mimarisi nasıl ölçeklenir?

Tek node’dan başlayıp 12 milyon olay/gün’e çıkan bir kurulumun anlattıkları.

İki yıl önce bir orta ölçekli kurumda tek Graylog node’u ile başladık. Bugün üç node’luk bir küme, günde 12 milyon olay alıyor. Aradaki yolculuk lineer değildi — bazı dersler ancak çıktığı anda ortaya çıktı.

1. Önce ne topladığını bil

Birinci hafta her şeyi loglamak isteyeceksiniz. İkinci ay disk dolmaya başlayacak. Üçüncü ayda artık kimsenin bakmadığı debug log’lar yüzünden gerçek olayları bulamayacaksınız.

Log mimarisinin birinci kuralı: ne tuttuğunu bilmek. İkincisi: tutmaman gerekenleri çöpe yönlendirmek.

2. Index tasarımı kaderdir

  • Günlük rotasyon → küçük sistemler için iyi, milyonlarca olayda fragmantasyon yaratır.
  • Boyut bazlı rotasyon (10–20 GB) → orta ölçek için en istikrarlı.
  • Streams ile mantıksal ayrım: güvenlik, uygulama, ağ, sistem. Saklama süreleri farklı olabilir.
  • Sıcak/soğuk katman: son 30 gün SSD, ötesi arşiv.

3. Alarm yorgunluğu sessiz katildir

Bir ekipte ilk üç ay 80 alarm kuralı yazıldı. Altıncı ayda kimse alarm e-postalarını okumuyordu. Doğru kural sayısı bizim için 12 oldu — kalitesi düşük olanı silmek, yenisini eklemek kadar önemli.

4. KVKK saklama süresi ihtiyari değildir

Kişisel veri içeren log’ları sonsuza kadar tutamazsınız. Aynı zamanda denetim için yeterli süre tutmak zorundasınız. Streams + saklama politikası kombinasyonu, bu çelişkiyi tek noktada çözer.

5. Kümeye geçiş — ne zaman?

Tek node’un dolduğu anda değil. Aramaların yavaşladığı, indeksleme gecikmelerinin görüldüğü anda. Bizim için yaklaşık 4 milyon olay/gün eşiğiydi. Daha önce küme kurmak, hem fazladan iş hem fazladan bütçedir.