Çoklu Sunucuda Merkezi Loglama: ELK ve Loki

İş yükü büyüdükçe tek bir VPS veya dedicated sunucu yetersiz kalabilir; web, API, veritabanı, cache, queue ve edge bileşenleri farklı sunuculara dağılıyor. Bu noktada en temel soru şuna dönüşüyor: Bu kadar çok sunucunun loglarını tek bir yerden, tutarlı ve aranabilir şekilde nasıl yöneteceğiz?

Dağınık loglar, hem performans sorunlarında hem de güvenlik olaylarında en büyük zaman kaybı sebeplerinden biri. Bir 5xx hatasının peşine düşmek için üç farklı sunucuya SSH ile bağlanmak, farklı formatlarda log dosyalarıyla boğuşmak; verimli bir operasyon değil. Özellikle de KVKK/GDPR gibi regülasyonlarla birlikte, logların nerede saklandığı, ne kadar tutulduğu ve kimlerin erişebildiği netleşmek zorunda.

Bu rehber, ELK (Elasticsearch, Logstash, Kibana) ve Loki, Alloy, Grafana seçenekleriyle birden fazla sunucudan log toplama mimarisini karşılaştırır. Ajan örnekleri, veri formatı, erişim ve saklama kararlarını birlikte ele alır; hazır bir yönetilen log hizmeti veya tek komutla kurulacak tam bir küme sunmaz. Promtail 2 Mart 2026’da kullanım ömrünü tamamladı; yeni Loki ajanı örneğinde Alloy kullanıyoruz.

Neden Merkezi Loglama?

Önce problemi doğru tarif edelim. 3–5 sunuculuk basit bir mimariden bile şunlar çıkıyor:

• Her web sunucusunda ayrı Nginx/Apache access ve error logları
• Ayrı bir sunucuda MySQL/PostgreSQL logları
• Uygulama framework’lerinin (Laravel, Node.js, Django, vb.) uygulama logları
• cPanel/DirectAdmin gibi panellerin, mail sunucularının, firewall’ların logları

Bu loglar aynı problemi anlatıyor olabilir ama farklı formatlarda, farklı saat dilimlerinde, farklı saklama süreleriyle tutuluyor. Sonuç:

• Olay anında log ararken ciddi zaman kaybı
• Geriye dönük incelemelerde eksik veya silinmiş loglar
• Güvenlik denetimlerinde istenen raporları çıkarmakta zorlanma
• Log dosyalarının kontrolsüz büyümesi nedeniyle disk dolması sorunları

Daha önce yayınladığımız Apache ve Nginx loglarını okuyarak 4xx–5xx hatalarını teşhis etmeyi anlattığımız rehberde tek sunucu üzerinde neler yapılabileceğini detaylandırmıştık. Bu yazıda ise ölçeği büyütüp, onlarca sunuculuk bir ortamda logları tek merkezde toplayıp yönetmeyi ele alıyoruz.

Toplamamız Gereken Log Türleri ve Minimum Standartlar

Merkezi loglama mimarisine geçmeden önce, ortamınızdaki servisler ve inceleme ihtiyaçları için hangi logların gerekli olduğunu belirleyin:

• Web sunucusu logları: Nginx/Apache access + error
• Uygulama logları: Laravel, Symfony, Node.js, .NET, vb. framework logları
• Veritabanı logları: Hata logları ve ihtiyaca göre yavaş sorgu logları; tüm sorguların kaydı ise veri hassasiyeti, performans ve saklama maliyeti değerlendirilerek seçilmelidir.
• OS ve güvenlik logları: syslog/journal, SSH erişim logları, firewall logları
• Mail altyapısı logları: SMTP, IMAP, spam filtresi, teslim logları
• Kontrol paneli logları: cPanel/DirectAdmin/plesk türü panellerin yönetim logları

JSON Lines gibi ortak bir format, alanların ayrıştırılmasını kolaylaştırır; tek başına doğru veri modeli oluşturmaz. Her kayıt için zamanın anlamını ve saat dilimini, servis ve sabit sunucu kimliğini, seviye ve korelasyon alanlarını tanımlayın. Saatleri eşitleyin. Şema değişikliklerini sürümleyin; eksik alan, bozuk JSON ve zaman ayrıştırma hatalarını izleyin. İstek veya kullanıcı kimliğini ancak gerekli ve uygun olduğunda toplayın; bu değerleri Loki indeks etiketi yapmayın.

Aşağıdaki Nginx örneğinde log_format yalnızca http {} bağlamına eklenir; escape=json Nginx 1.11.8 ve sonrasında bulunur. access_log satırını amaçlanan sanal sunucuya yerleştirin ve miras alınan ayarları kontrol edin. Sorgu dizisi, IP, referer ve user-agent bu örnekte toplanmaz. $uri de kişisel veri içerebilir; rota şablonu veya uygulamada maskeleme gereksinimini değerlendirin. IP incelemesi gerekiyorsa yalnızca yetkili amaç için tanımlanmış alanı, erişimi ve silme politikasını ayrıca ekleyin.

# Add inside http {}; Nginx 1.11.8+ supports escape=json.
log_format json_central escape=json '{"time":"$time_iso8601",'
  '"method":"$request_method",'
  '"uri":"$uri",'
  '"status":$status,'
  '"body_bytes":$body_bytes_sent,'
  '"request_time":$request_time}';

# Place in the intended server {} (or http {} for inherited defaults).
access_log /var/log/nginx/access_json.log json_central;

Değişiklikten önce yapılandırmayı yedekleyin. nginx -t başarılıysa işletim sisteminizin Nginx servis yönetimiyle kontrollü reload uygulayın; test başarısızsa yüklemeyin. Bir deneme isteğinden sonra yeni dosyada geçerli JSON, sayısal status, saniye cinsinden request_time ve saat dilimli time değerini doğrulayın. Bu biçim Nginx error log’una uygulanmaz.

Merkezi Loglama Mimarilerinin Ortak Bileşenleri

ELK veya Loki seçiminiz ne olursa olsun, mimari prensipler büyük ölçüde benzer:

• Kaynaklar: Web, uygulama, veritabanı, mail ve işletim sistemi kayıtları.
• Ajanlar: Filebeat, Alloy, Fluent Bit veya uygun syslog göndericisi; her kaynak ve biçim için ayrı toplama ayarı gerekir.
• Aktarım: Filebeat–Logstash için Beats protokolü/TLS, Loki push API için HTTPS; protokoller birbirinin yerine geçmez. Kuyruk eklenirse kapasite, onaylama ve taşma davranışı da tasarlanır.
• Toplama ve işleme: Logstash pipeline’ı veya Loki alım bileşenleri; bunlar otomatik olarak bir mesaj kuyruğuyla aynı dayanıklılığı sağlamaz.
• Depolama ve arama: Elasticsearch indeksleri veya Loki indeks ve chunk verisi; sorgu arayüzü Kibana/Grafana.
• Uyarı: Test edilmiş sorgu, eşik, değerlendirme aralığı ve bildirim kanalı; kayıt gelmemesi ayrıca izlenir.

Hem VPS hem de dedicated/colocation ortamlarda uygulanabilecek bir desen; her sunucuya bir log toplama ajanı kurup, seçilen logları merkezi bir log kümesine göndermektir. Bu küme, ihtiyaçlara göre ELK veya Loki ile tasarlanabilir.

ELK Stack ile Birden Fazla Sunucuda Log Yönetimi

ELK Stack (Elasticsearch, Logstash, Kibana) uzun yıllardır log yönetimi denince akla gelen ilk çözümlerden. Özellikle:

• Yüksek hacimli log akışları
• Karmaşık sorgular (örneğin IP, endpoint, HTTP status ve response time filtreleri)
• Güçlü raporlama ve görselleştirme ihtiyaçları

Bu ihtiyaçlar için Elasticsearch’ün alan tiplerini, sorgularını ve raporlama seçeneklerini gerçek kayıtlarla değerlendirin.

ELK Bileşenleri Kısaca

• Elasticsearch: Logların indekslendiği, arandığı, sorgulandığı dağıtık arama/veri motoru.
• Logstash: Gelen logları parse eden, zenginleştiren, filtreleyen ve Elasticsearch’e yazan pipeline motoru.
• Kibana: Loglara sorgu atmak, dashboard hazırlamak, görseller üretmek için web arayüzü.
• Beats/Filebeat: Uç sunuculardan logları toplayıp Logstash veya Elasticsearch’e gönderen hafif ajanlar.

Çoklu Sunucu İçin Temel ELK Mimarisi

Basitleştirilmiş bir senaryo üzerinden gidelim: 4 web sunucusu ve 1 veritabanı sunucunuz var. Her web sunucusunda Nginx çalışıyor, uygulama loglarını da ayrı bir dosyaya yazıyorsunuz.

1. Her sunucuya Filebeat kurarsınız.
2. Filebeat, Nginx access/error ve uygulama loglarını okuyup Logstash’e gönderir.
3. Logstash, grok/regex veya JSON parser ile log satırlarını alanlara ayırır.
4. Logstash, parse ettiği event’leri Elasticsearch’e yazar.
5. Kibana üzerinden toplama için yapılandırdığınız sunucu ve servislerin loglarına tek yerden bakabilirsiniz.

Aşağıdaki gönderici örneği Filebeat 9.2.0 hedeflenerek hazırlanmıştır; kurulumda desteklenen sürümü sabitleyip test edin. Her sunucuda server_id: web01 değerini o makinenin kararlı kimliğiyle değiştirin. Örnek yalnızca Nginx JSON access ve Laravel dosyasını seçer; error, journal ve veritabanı toplama ayarlarını ayrıca tanımlayın. logs.example.com size ait hazırlanmış Logstash alıcısının yer tutucusudur, DCHost hizmet adresi değildir. Örnek iki dosyanın satırlarını message olarak gönderir; Logstash Beats input, JSON/metin ayrıştırma, Elasticsearch TLS/kimlik doğrulama, indeks şablonu ve Kibana bu taslağın dışında kurulmalıdır.

# Sender example targeting Filebeat 9.2.0; provision the receiver first.
filebeat.inputs:
  - type: filestream
    id: nginx-json-v1
    paths: ["/var/log/nginx/access_json.log*"]
    prospector.scanner.exclude_files: ['\.gz$']
    fields:
      app: web
      server_role: frontend
      server_id: web01
      environment: prod
    fields_under_root: true
  - type: filestream
    id: laravel-v1
    paths: ["/var/www/myapp/storage/logs/laravel.log*"]
    prospector.scanner.exclude_files: ['\.gz$']
    fields:
      app: myapp
      server_role: app
      server_id: web01
      environment: prod
    fields_under_root: true

path.data: /var/lib/filebeat
queue.disk:
  max_size: 1GB

output.logstash:
  hosts: ["logs.example.com:5044"]
  ssl.certificate_authorities: ["/etc/filebeat/certs/ca.crt"]
  ssl.certificate: "/etc/filebeat/certs/client.crt"
  ssl.key: "/etc/filebeat/certs/client.key"

Alıcı, 5044 üzerinde sertifika doğrulayan Beats/TLS dinleyicisi olmalı; burada istemci sertifikası kullanıldığı için sunucu tarafında güvenilen CA ve istemci doğrulaması da yapılandırılmalıdır. Sertifika adı gerçek hedef adıyla eşleşsin. Anahtarları yalnızca servis hesabının okuyabilmesini sağlayın. filebeat test config -c /etc/filebeat/filebeat.yml ve ardından filebeat test output -c /etc/filebeat/filebeat.yml çalıştırın; bağlantı testi kayıtların ayrıştırılıp aranabildiğini kanıtlamaz. Her kaynaktan sentetik kayıt gönderip hedef indeks ve alan tiplerini ayrıca kontrol edin.

log input 7.16’da deprecated oldu, 9.0’da devre dışı bırakıldı. filestream için kararlı ve benzersiz input ID kullanın; mevcut registry’yi silmeyin. Bu yeni kurulum taslağını çalışan bir log input’unun üzerine kopyalamak durum taşıma işlemi değildir: sürümünüzün filestream geçiş rehberini izleyip eski okuyucuyla çakışmayı, tekrarı ve eksik kayıtları test edin. Varsayılan fingerprint en az 1024 baytlık içerik bekler; küçük test dosyası hemen gönderilmeyebilir. Parmak izi veya ID değişikliği yeniden okumaya yol açabilir.

path.data registry ve disk kuyruğu için kalıcı ve yazılabilir olmalı. Örnekteki 1 GB kuyruk yalnızca bir deneme sınırıdır; gerçek boyutu giriş hızı, hedef kesinti süresi ve disk payına göre belirleyin. Sonlu kuyruk dolabilir, disk bozulabilir ve dönüşen dosyalar okunmadan silinebilir. Rename/reopen rotasyonunu ve yeniden başlatmayı test edin; copytruncate kayıp/tekrar riski taşır. Laravel çok satırlı stack trace üretiyorsa kaynakta JSON Lines veya uygun multiline parser gereklidir.

Gönderici yolları aktif dosya ve aynı önekteki sıkıştırılmamış rotasyonları kapsar; .gz dosyaları dışlanır. Okunmamış rotasyonları hemen sıkıştırmayın veya silmeyin; dosya adlarını kendi rotasyon politikanızla eşleştirin. Alloy örneği yalnızca aktif yolları izler; uzun kesintiden sonra arşivleri geri alma işini ayrıca planlayın.

ELK’nin Avantajları

• Alan tabanlı analiz: Yetkili olarak toplanan kullanıcı/IP, endpoint, status ve süre alanlarında filtre ve agregasyonlar; alan tipleri ve sorgu yükü önemlidir.
• Ekosistem: Filebeat modülleri toplama ayarı, Elasticsearch ingest pipeline ve dashboard varlıkları sağlayabilir. Logstash çıkışı kullanılırken bu pipeline/şablonların yüklenmesi ve yönlendirilmesi ayrıca gerekir.
• Raporlama: Hata, kapasite veya hizmet göstergeleri için dashboard ve rapor oluşturulabilir; ölçüm kapsamı, lisans ve uyarı özelliklerini kontrol edin.

ELK’nin Dezavantajları ve Dikkat Edilmesi Gerekenler

• Kaynak tüketimi: Elasticsearch’ün CPU, RAM ve disk I/O ihtiyacı log hacmine, sorgu yüküne ve saklama süresine bağlıdır. Küçük bir deneme ortamı ile yüksek hacimli üretim ortamı aynı kaynaklarla boyutlandırılmamalıdır.
• Disk maliyeti: Full-text indeksleme ek disk alanı gerektirebilir; indekslenen alanları ve saklama sürelerini planlayın. Index Lifecycle Management (ILM) bu yaşam döngüsünü yönetmek için bir seçenektir.
• Operasyonel karmaşıklık: Cluster yönetimi, shard ayarları, yedekleme, versiyon yükseltme gibi işler deneyim ister.

Bu yüzden ELK genellikle şu özelliklere sahip ortamlarda değerlendirilebilir:

• Log hacmi yüksek
• Geriye dönük derin analiz gereken (güvenlik, denetim, compliance)
• Raporlama ihtiyacı güçlü

Operasyonel gözlemlenebilirlik odaklı kullanımda Loki Stack daha ekonomik ve yönetilebilir bir alternatif olabilir; karşılaştırma log hacmi, sorgu ihtiyaçları, saklama süresi ve işletim yükü üzerinden yapılmalıdır.

Loki ile Çoklu Sunucudan Log Toplama

Loki, Grafana ekosisteminin log tarafındaki oyuncusu. Tasarım felsefesi şu: log satırlarının tamamını indeksleme, sadece etiketleri indeksle. Böylece:

• Tam metin indekslemeye kıyasla indeks için gereken disk alanını azaltabilir; toplam depolama ihtiyacı log hacmine, etiket tasarımına ve saklama süresine bağlıdır
• Uygun object storage üzerinde, tanımlanan retention ve kurtarma politikasıyla saklanabilir
• Grafana ile aynı arayüzden metrikler ve logları birlikte görebilirsiniz

DCHost blogunda daha önce VPS’te Loki etiket tasarımı, saklama, alarmlar ve toplayıcı geçişini ele aldık. Bu yazıda ölçeği büyütüp, birden fazla sunuculu hosting mimarilerinde Loki’nin nasıl konumlandırılacağını ele alıyoruz.

Loki Mimarisi Kısaca

• Loki: Logları akış etiketleriyle indeksleyen, metni chunk olarak saklayan sistem.
• Alloy: Her sunucuda seçilen dosya veya journal kayıtlarını toplayıp işleyerek Loki’ye gönderebilen ajan. Promtail artık güncel kurulum seçeneği değildir.
• Grafana: Loki logları ve ayrı veri kaynaklarındaki metrikleri görüntüler; eşleştirme alanları ve sorgular ayrıca kurulur.

Alloy ile Çoklu Sunucudan Loki’ye Gönderim

Her kaynak sunucuya Alloy kurup gerçek ve değişmeyen host değerini atayın. Aynı şablondaki web01 değerini bütün makinelerde bırakmayın. Yeni kurulum aşağıdaki örnekle başlayabilir; mevcut Promtail yapılandırmasını geçirmek için resmî alloy convert --source-format=promtail --output=/tmp/config.converted.alloy /etc/promtail/config.yml akışını izleyin, dönüştürülmüş ayarı ve okuma konumlarını test edin. Eski/yeni ajanı aynı akışa gelişigüzel birlikte göndermek tekrar oluşturabilir.

Alloy v1.21.3 için aşağıdaki örnek, Nginx’in yukarıdaki JSON dosyasını ve önceden JSON Lines biçimine geçirilmiş Laravel dosyasını okur. Uygulama her satırda time alanında RFC3339/RFC3339Nano zaman üretmelidir. Varsayılan düz metin Laravel log’una bu varsayımı uygulamayın; uygun parser veya ayrı pipeline kullanın. Nginx error, PHP-FPM, veritabanı ve journal için yol, biçim, izin ve etiketleri ayrıca ekleyin.

// Alloy v1.21.3; change the stable host label on every sending server.
loki.source.file "nginx" {
  targets = [
    {__path__ = "/var/log/nginx/access_json.log", job = "nginx_access", host = "web01", environment = "prod", project = "shop"},
  ]
  file_match {
    enabled = true
  }
  forward_to = [loki.process.json_logs.receiver]
}
loki.source.file "app" {
  targets = [
    {__path__ = "/var/www/myapp/storage/logs/laravel.log", job = "myapp", host = "web01", environment = "prod", project = "shop"},
  ]
  file_match {
    enabled = true
  }
  forward_to = [loki.process.json_logs.receiver]
}
loki.process "json_logs" {
  // Both files must contain one JSON object per line with RFC3339 time.
  stage.json {
    expressions = {event_time = "time"}
  }
  stage.timestamp {
    source = "event_time"
    format = "RFC3339Nano"
    action_on_failure = "skip"
  }
  stage.label_drop {
    values = ["filename"]
  }
  forward_to = [loki.write.central.receiver]
}
loki.write "central" {
  endpoint {
    url = "https://logs.example.com/loki/api/v1/push"
    basic_auth {
      username = "web01"
      password_file = "/etc/alloy/secrets/loki_password"
    }
    tls_config {
      ca_file = "/etc/alloy/certs/ca.crt"
    }
  }
}

Bu bir kaynak sunucu ayarıdır; Loki, HTTPS ağ geçidi ve Grafana önceden hazırlanmalıdır. Gerçek alan adı, güvenilen CA ve bu sunucuya ait parola dosyasını kullanın; doğrulamayı kapatmayın. Alloy servis hesabına yalnızca gereken logları ve sır dosyalarını okuma izni verin. Kalıcı --storage.path=/var/lib/alloy kullanın, yönetim HTTP dinleyicisini --server.http.listen-addr=127.0.0.1:12345 ile sınırlandırın. Önce alloy validate /etc/alloy/config.alloy, sonra kontrollü servis başlatma/yeniden yükleme ve sentetik kayıt testi uygulayın.

Okuma konumları teslimat kuyruğu değildir. Bu örnek deneysel loki.write WAL özelliğini açmaz; yeniden deneme sınırı aşıldığında veya yeniden başlatma sırasında bekleyen kayıtlar kaybolabilir. Gerekli dayanıklılığı ayrıca tasarlayın; loki_write_dropped_entries_total, yeniden denemeler, kaynak–hedef gecikmesi ve disk doluluğunu izleyin. Yerel dosya saklama ve rotasyonu beklenen kesintiyi karşılamalı; eski kayıtlar Loki’nin yaş sınırına da takılabilir. Zaman ayrıştırması başarısızsa örnekteki skip mevcut toplama zamanını korur, doğru olay zamanı üretmez.

Etiket sözleşmesi bütün sunucularda aynı olmalıdır:

• job: Kaynak sınıfı; örnekte nginx_access veya myapp.
• host: Değişmeyen kaynak makine kimliği; environment ve project: kontrollü, sınırlı değer kümeleri.
• Kullanıcı, IP, request ID, tam URL ve sınırsız tenant değerlerini indeks etiketi yapmak akış sayısını büyütür. Gerekiyorsa log alanı/uygun structured metadata olarak tutun; sorguda ayrıştırın.

{job="nginx_access", environment="prod"} seçicisi, bu etiketlerle gerçekten toplanan bütün sunucuları kapsar. project veya customer etiketi yetkilendirme sağlamaz. Loki’de uygulama düzeyinde yerleşik kullanıcı oturumu/RBAC yoktur; bu tasarımın güvenilir ağ geçidi kimliği doğrulamalı ve çok kiracılı kullanımda X-Scope-OrgID değerini yetkiye göre kendisi belirlemelidir. İstemcinin seçtiği tenant başlığına güvenmeyin. Grafana klasör izni tek başına veri kaynağı sorgularını müşteriye göre sınırlandırmaz; tenant/data-source erişimini ayrıca test edin. Kullanılan Grafana sürüm/lisansında erişim denetiminin kapsamını kontrol edin; veri kaynağı izinleri gibi bazı özellikler Enterprise/Cloud ile sınırlıdır.

Loki’nin Avantajları

• Kaynak dostu: Etiket indekslemesi indeks yükünü azaltabilir; toplam CPU/RAM/disk tüketimini veri ve sorgularınızla ölçün.
• Object storage entegrasyonu: Uygun object storage ile çalışabilir; kapasite, istek, retrieval ve egress ücretlerini birlikte hesaplayın. (Daha önce S3 uyumlu depolamanın web uygulamaları için avantajlarını detaylı anlatmıştık.)
• Grafana ile sıkı entegrasyon: Metrik ve logları aynı dashboard’da görebilir, tek panelden hem CPU grafiğine hem hata loguna bakabilirsiniz.
• Basit operasyon: Tek süreçli bir POC küçük başlayabilir; üretim erişimi, dayanıklılığı ve yükseltmeleri yine işletim gerektirir.

Loki’nin Sınırları

• Sorgu biçimi: Loki etiketle akış seçip metni/JSON alanlarını sorgu sırasında ayrıştırabilir; çok geniş alan taramalarının maliyetini gerçek sorgularla ölçün.
• Kardinalite: Çok sayıda etiket kombinasyonu küçük chunk ve büyük indeks yükü oluşturabilir.
• İşletim: Tek süreç/tek disk denemesi yüksek erişilebilirlik sağlamaz. Üretimde replikasyon, ring/quorum, storage, failure domain ve kurtarma birlikte tasarlanır.

Operasyonel inceleme için Loki; alan ağırlıklı analiz için Elasticsearch değerlendirilebilir. Güvenlik veya mevzuat ihtiyacı tek başına bir ürün seçmez: erişim, kayıt bütünlüğü, silme, rapor ve kurtarma gereksinimlerini her iki sistemde de doğrulayın. Belirli logları iki sisteme gönderen hibrit yapı sorgu esnekliği sağlar, fakat iki kopyanın maliyetini, erişimini ve silme sürecini artırır.

ELK vs Loki: Hangi Senaryoda Hangisini Tercih Etmeli?

Özet bir karşılaştırma yapalım:

• Alan bazlı sorgu ve raporlama: Elasticsearch’te gerekli mapping, agregasyon ve dashboard işlevlerini örnek veriyle deneyin.
• Akış seçip olay inceleme: Loki’nin etiket ve LogQL modeli mevcut sorgularınızı karşılıyorsa adaydır.
• Güvenlik/denetim: Gerekli entegrasyon, yetki, bütünlük ve saklama özelliklerini kullanılan sürüm/lisansta kontrol edin.
• Prometheus + Grafana: Loki aynı arayüzde log incelemesini ekler; CPU ve uygulama metrikleri ayrı kaynaktan gelmeye devam eder.

Aşağıdaki seçimler başlangıç hipotezidir; aynı log örnekleri, sorgular ve saklama hedefiyle POC yapın:

• SaaS, e-ticaret ve içerik sitelerinin operasyonel kayıtları: Loki + Alloy + Grafana seçeneğini ölçün.
• Kapsamlı alan analizi ve rapor ihtiyacı: ELK veya belirlenmiş alt küme için hibrit mimariyi değerlendirin.

Örnek Mimari: 5 Sunuculuk Bir Hosting Kümesinde Merkezi Loglama

Diyelim ki DCHost üzerinde şu yapıyı çalıştırıyorsunuz:

• 2 x web sunucusu (Nginx + PHP-FPM)
• 1 x API sunucusu (Node.js)
• 1 x veritabanı sunucusu (MySQL/PostgreSQL)
• 1 x load balancer (Nginx/HAProxy)

Merkezi loglama için tipik adımlar şöyle olabilir:

• Ajan: Her kaynakta Filebeat veya Alloy; gerçek kaynak/etiket envanteri ve servis hesabı izinleri.
• Biçim: JSON Lines veya belgelenmiş parser; saat dilimi, multiline, hassas veri ve rotasyon sözleşmesi.
• Merkez: Uygulama kaynaklarından ayrılmış log sistemi; ayrı VPS tek başına yedeklilik değildir. Boyut için bayt/saniye, günlük büyüme, sorgu ve kesinti hedefini ölçün.
• Dashboard/uyarı: Hata sorguları yanında log gelmemesi, ayrıştırma hatası, gönderim kaybı ve gecikmeyi izleyin.
• Saklama: Her log sınıfı için amaç, süre, silme, yedek ve geri yükleme hedefini yazın.

Log saklama süreleri konusu, sadece teknik değil aynı zamanda hukuki bir konu. Hosting ve e-posta altyapısında log saklama sürelerini anlattığımız yazıda farklı mevzuatların ve pratik ihtiyaçların bu süreleri nasıl etkilediğini detaylıca işledik. Merkezi log mimarinizi planlarken, o yazıdaki yol haritasını da mutlaka gözden geçirmenizi öneririz.

Log Saklama, Maliyet ve Arşiv Stratejileri

Saklama, hızlı sorgulanabilir dönem ve arşiv erişimi ayrı kararlardır. Aşağıdaki süreler yalnızca maliyet hesabını anlatan bir örnektir; genel öneri veya yasal alt sınır değildir:

• 7–14 günlük örnek aktif dönem: Sık yapılan incident sorguları için ölçülen gecikme hedefi.
• 30–90 günlük örnek geçmiş: Daha seyrek sorguların kabul edilen bekleme süresi ve depolama maliyeti.
• 90 gün sonrası: Ancak gerekli ve hukuken uygun kayıtlar için ayrıca tanımlanmış arşiv, erişim ve silme süreci. Object storage otomatik olarak soğuk/yavaş arşiv demek değildir.

Elasticsearch ILM, uygun indeks/data stream politikalarıyla rollover, taşıma ve silmeyi yönetebilir; sunucu sürümü ve deployment türündeki desteği kontrol edin. Loki’nin Compactor retention ayarı hot/warm/cold katman geçişi değildir. TSDB retention için uygun şema, 24 saatlik index period, Compactor ve silme deposu gerekir. Bucket yaşam döngüsünün indeksleri veya canlı chunk’ları silmesi sorguları bozabilir; yalnızca retention süresi ve silme gecikmesinin toplamından daha uzun ve doğru prefix’e kısıtlı bir kural ayrıca doğrulanarak kullanılmalıdır. Depolama sınıfı değişikliklerinin anlık okuma, retrieval ve geri yükleme koşullarını da test edin.

Dashboard, Alarm ve Gözlemlenebilirlik

Dashboard tasarımını gerçek inceleme sorularından başlatın; sorgu hızını veri hacmi ve yük altında ölçün:

• Son 10 dakikada 500 hatası üreten endpoint’ler hangileri?
• Bugün en çok 404 veren URL desenleri neler?
• Belirli bir IP aralığından şüpheli girişim var mı?
• Ödeme adımında hata alan kullanıcıların ortak özellikleri neler?

Yukarıdaki Nginx JSON ve Alloy etiketleri için, beş dakikalık gerçek 5xx sayısını host/project bazında şu LogQL sorgusuyla hesaplayabilirsiniz. Status bir indeks etiketi olarak varsayılmaz; JSON alanı ayrıştırılır:

sum by (host, project) (count_over_time({job="nginx_access", environment="prod"} | json | status >= 500 and status < 600 | __error__="" [5m]))

200, 500, 503, 600 ve bozuk JSON örnekleriyle deneyin; yalnızca 500/503 sayılmalı. {job="nginx_access", environment="prod"} | json | __error__!="" sorgusuyla bozuk JSON’u ayrıca izleyin. Sıfır hata ile hiç log gelmemesi aynı şey değildir. Uyarı için eşik, değerlendirme aralığı, bekleme/no-data davranışı ve bildirim yolunu ayrıca tanımlayıp tetiklenme/iyileşmeyi test edin.

Grafana + Loki veya Kibana + Elasticsearch ile bu soruları kayıt kapsamına uygun sorgularla araştırabilirsiniz; olay zamanı ve korelasyon alanlarını eşleştirin. Daha ileri seviyede, logları metrikler ve izler (traces) ile birleştirmek istiyorsanız, OpenTelemetry ile izlenebilirliği adım adım anlattığımız rehber iyi bir eşlikçi olacaktır.

Ayrıca, Loki, Alloy ve Grafana ile merkezi loglama yazımızda, tek VPS üzerindeki backend, toplama ve sorgu adımlarını bulabilirsiniz. Buradaki odak, bu temeli birden fazla kaynak sunucuya yayma ve ELK ile karşılaştırmadır.

Adım Adım Uygulama Planı: Kaostan Düzenli Log Mimarisine Geçiş

Kademeli uygulama planı, bütün sunucuları bir anda değiştirmeden veri doğruluğunu ve işletim maliyetini görmenizi sağlar:

1. Envanter ve önceliklendirme

• Tüm sunucuların ve üzerinde çalışan servislerin envanterini çıkarın.
• Her servis için hangi log dosyalarının kritik olduğunu belirleyin.
• Öncelikle müşteri deneyimini doğrudan etkileyen akışlara (login, sepet, ödeme) odaklanın.

2. Log formatlarını iyileştirme

• Her kaynak için geçerli JSON Lines veya açıkça tanımlanmış metin parser’ı seçin.
• Olay zamanı ve saat dilimini, servis/sunucu kimliğini, gerekli korelasyon alanlarını standartlaştırın. Kullanıcı/tenant alanları yalnızca meşru amaçla toplansın ve sınırsız Loki etiketi olmasın.
• Laravel Monolog gibi structured logging araçlarında JSON handler, tek satır ve time alanı sözleşmesini gerçekten doğrulayın. Stack trace’in tek olay olarak korunmasını test edin.

3. Küçük bir POC kümesi kurma

• Önce 1–2 kaynağı bağlayın; sentetik 200,500 ve bozuk JSON kayıtlarının hedefteki sonucunu kontrol edin.
• Okuma izni hatası, yanlış sertifika/parola, alıcı kesintisi, ajan yeniden başlatma ve log rotasyonunu POC ortamında test edin. Eksik/tekrar kayıt ve kuyruk davranışını ölçün.
• Retention silmesini ve örnek eski kayıtların geri yüklenmesini deneyin; yalnızca dashboard’un açılması kabul testi değildir.

4. Kademeli yaygınlaştırma

• POC kabul ölçütlerini sağladıkça yeni sunucular ekleyin.
• Her servis türünün job/biçim/izin sözleşmesini sürüm kontrollü şablonda tutun; sırları depoya koymayın.
• Giriş bayt/saniye, günlük saklanan boyut, sorgu gecikmesi, stream/shard sayısı, retry/drop ve serbest disk eğilimlerini izleyin.

5. Runbook ve operasyonel süreçler

• “Şu alarm çaldığında ilk bakılacak dashboard şudur” türü runbook’lar yazın.
• Geliştirici ve operasyon ekiplerine kısa eğitimler verin; her sorun için SSH yerine önce dashboard’a bakma alışkanlığını oturtun.

VPS, Dedicated ve Colocation İçin Kapasite Planı

VPS, dedicated ve colocation seçeneklerini karşılaştırırken log sunucusunun gerçek CPU/RAM, disk/IOPS, ağ ve yönetim koşullarını inceleyin. Log yazılımını kurma ve işletme sorumluluğunu hizmet kapsamından ayrı doğrulayın:

• Operasyonel inceleme veya alan analizi hedefini belirleyip Loki, ELK ya da hibrit için ölçülmüş kapasite çıkarın.
• Log sistemini ayrı kaynaklara taşımak uygulamayla rekabeti azaltabilir; ortak fiziksel host, ağ ve depolama hâlâ ortak hata alanı olabilir.
• Yüksek erişilebilirlik gerekiyorsa desteklenen deployment modeli, replika yerleşimi, ring/quorum ve storage yedekliliğini birlikte tasarlayın; birkaç örnek çalıştırmak bunu otomatik sağlamaz.
• Backup planında Loki chunk/index ve gerekli yerel state, yapılandırma, Grafana verisi ve sırların güvenli kurtarılması bulunsun. Object storage dayanıklılığı yanlış silmeye karşı bağımsız yedek değildir. Elasticsearch için desteklenen snapshot/restore mekanizmasını kullanın.

Eğer altyapınızda zaten Prometheus + Grafana tabanlı bir izleme kurduysanız, VPS izleme ve uyarı rehberimizde anlattığımız desenleri, ayrı Loki veri kaynağıyla genişletebilirsiniz. Zaman aralığı ve host/servis alanlarını uyumlu tutun. Böylece tek panelden CPU, RAM, disk I/O, HTTP istek grafikleri ve log satırlarını yan yana görebilirsiniz.

Sonuç ve Sonraki Adım: Loglardan Gerçek Değer Üretmek

Birden fazla sunucuda log yönetimini ciddiye almak, yalnızca sorun çıktığında log aramayı kolaylaştırmak için değil; altyapınızı daha öngörülebilir, güvenli ve ölçeklenebilir hâle getirmek için kritik. ELK ve Loki stack’leri, doğru kurgulandığında:

• Toplandığı ve saklandığı doğrulanan olayları sunucular arasında aramayı kolaylaştırır.
• Metriklerle birlikte yorumlanan kayıtlar kapasite kararlarını destekler; haftalar önceden arıza tahmini garantisi vermez.
• Erişimi ve bütünlüğü korunmuş kayıtlar olay incelemesine katkı sağlar; log tek başına eksiksiz kanıt değildir.
• Ortak alanlar ve runbook’lar hata ayıklamayı daha sistematik hâle getirir.

Tek VPS’ten çok sunuculu SaaS’a kadar, log toplama kapsamını uygulama mimarisiyle birlikte planlayın. VPS, dedicated veya colocation kapasitesini değerlendirirken ölçüm sonuçlarını, erişim modelini ve yönetim sorumluluklarını açıkça belirtin.

DCHost ile altyapı seçeneklerini görüşürken günlük log hacmi, sorgu yükü, saklama ve kurtarma hedefini paylaşın. ELK/Loki kurulumu veya yönetimi için sunulan hizmet kapsamını ayrıca teyit edin; bu rehber belirli bir log hizmeti ya da performans garantisi değildir.

Resmî Teknik Kaynaklar

• Promtail EOL
• Promtail → Alloy
• Filebeat filestream
• Loki kimlik doğrulaması
• Loki saklama politikası