Birden Fazla Sunucuda Log Yönetimi: ELK ve Loki Stack ile Merkezi Hosting Loglama

Bir noktadan sonra tek bir VPS veya dedicated sunucu ile işler yürümüyor; 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 rehberde, DCHost ekibi olarak sahada sıkça kurduğumuz iki temel yaklaşımı detaylıca anlatacağız: ELK Stack (Elasticsearch, Logstash, Kibana) ve Loki Stack (Loki, Promtail, Grafana). Amacımız; birden fazla sunucuda log yönetimini, sadece teorik olarak değil, gerçekten uygulayabileceğiniz mimari desenler, örnek konfigürasyonlar ve adım adım planlarla netleştirmek.

Neden Merkezi Loglama? Çoklu Sunucu Ortamlarında Yaşanan Temel Sorunlar

Ö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, hangi logları minimumda toplamanız gerektiğini netleştirelim:

• Web sunucusu logları: Nginx/Apache access + error
• Uygulama logları: Laravel, Symfony, Node.js, .NET, vb. framework logları
• Veritabanı logları: Sorgu logları, yavaş sorgu logları, hata logları
• 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ı

Bir sonraki kritik adım, bu logların mümkünse standart bir formatta (örneğin JSON satırları) üretilmesini sağlamak. ELK ve Loki gibi merkezi sistemlerde, field bazlı sorgu yapabilmek için log satırlarının içindeki verilerin parse edilebilir olması şart.

Örneğin Nginx access log’unu şöyle bir JSON formatına çevirmek, ileride hem ELK hem Loki tarafında hayatınızı çok kolaylaştırır:

log_format json_combined escape=json '{"time":"$time_iso8601",'
  '"ip":"$remote_addr",'
  '"method":"$request_method",'
  '"uri":"$request_uri",'
  '"status":$status,'
  '"body_bytes":$body_bytes_sent,'
  '"referer":"$http_referer",'
  '"user_agent":"$http_user_agent"}';

access_log /var/log/nginx/access_json.log json_combined;

Merkezi Loglama Mimarilerinin Ortak Bileşenleri

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

• Log üreten sunucular (sources): Web, uygulama, veritabanı, mail, vb.
• Log toplayıcı ajanlar (shippers/agents): Filebeat, Promtail, Fluent Bit, syslog forwarder
• Merkezi toplama katmanı: Logstash, Loki ingester, syslog receiver, Kafka, vb.
• Depolama ve indeksleme: Elasticsearch index’leri veya Loki + object storage
• Görselleştirme ve arama: Kibana veya Grafana üzerinden sorgu ve dashboard
• Alarm ve otomasyon: Belirli pattern’lere göre mail, webhook veya chat uyarıları

DCHost tarafında hem VPS hem de dedicated/colocation ortamlarda en sık gördüğümüz desen; her sunucuya küçük, hafif bir ajan kurup, tüm logları merkezi bir log kümesine göndermek. Bu küme, müşterinin tercihine göre ELK veya Loki ile inşa edilebiliyor.

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ı

olan ortamlarda oldukça güçlü.

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 tüm sunucuların loglarına tek yerden bakabilirsiniz.

Örnek bir Filebeat konfigürasyonu şöyle olabilir:

filebeat.inputs:
  - type: log
    paths:
      - /var/log/nginx/access_json.log
    fields:
      app: web
      server_role: frontend
    fields_under_root: true

  - type: log
    paths:
      - /var/www/myapp/storage/logs/laravel.log
    fields:
      app: myapp
      server_role: app
    fields_under_root: true

output.logstash:
  hosts: ["log01.internal.dchost:5044"]

ELK’nin Avantajları

• Güçlü sorgu dili: Belirli bir kullanıcı, IP, endpoint veya hata pattern’ini hızlıca yakalayabilirsiniz.
• Zengin ekosistem: Beats ailesi, Filebeat modülleri, hazır dashboard’lar.
• Gelişmiş raporlama: Management raporları, SLA takipleri, kapasite planlama grafikleri.

ELK’nin Dezavantajları ve Dikkat Edilmesi Gerekenler

• Kaynak tüketimi: Elasticsearch ciddi CPU, RAM ve disk I/O ister. Küçük VPS’lerde değil, daha güçlü VPS veya dedicated sunucularda konumlandırmak gerekir.
• Disk maliyeti: Full-text index’leme, disk alanını agresif tüketir; iyi bir Index Lifecycle Management (ILM) planı şart.
• Operasyonel karmaşıklık: Cluster yönetimi, shard ayarları, yedekleme, versiyon yükseltme gibi işler deneyim ister.

Bu yüzden ELK’yi genellikle:

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

ortamlarda tercih ediyoruz. Sadece operasyonel gözlemlenebilirlik için, daha hafif bir alternatif olan Loki Stack çoğu zaman daha ekonomik ve yönetilebilir oluyor.

Loki Stack ile Hafif ve Ölçeklenebilir Log Yönetimi

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

• Disk kullanımını ciddi şekilde azaltır
• Object storage (S3/MinIO gibi) üzerinde uzun süreli saklama sağlar
• Grafana ile aynı arayüzden metrikler ve logları birlikte görebilirsiniz

DCHost blogunda daha önce VPS log yönetimini Loki + Promtail ile nasıl merkezi hâle getirebileceğinizi detaylı anlattı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ı etiketlerine göre indeksleyen ve saklayan sunucu bileşeni.
• Promtail: Sunucularda çalışan, log dosyalarını okuyup Loki’ye gönderen ajan.
• Grafana: Hem metrikleri (Prometheus, Node Exporter, vs.) hem logları (Loki) görüntüleyen arayüz.

Promtail ile Çoklu Sunucudan Loki’ye Log Gönderimi

Tipik bir senaryoda her VPS veya dedicated sunucunuza Promtail kurarsınız. Promtail, lokaldeki log dosyalarını okuyup, belirlediğiniz etiketlerle birlikte merkezi Loki’ye yollar.

Basit bir Promtail konfigürasyonu şöyle görünebilir:

server:
  http_listen_port: 9080
  grpc_listen_port: 0

clients:
  - url: http://loki.internal.dchost:3100/loki/api/v1/push

positions:
  filename: /var/lib/promtail/positions.yaml

scrape_configs:
  - job_name: nginx
    static_configs:
      - targets:
          - localhost
        labels:
          job: nginx
          host: web01
          __path__: /var/log/nginx/access_json.log

  - job_name: app
    static_configs:
      - targets:
          - localhost
        labels:
          job: myapp
          host: web01
          __path__: /var/www/myapp/storage/logs/*.log

Buradaki en kritik nokta; labels kısmı. Örneğin:

• job: Uygulama veya servis adı (nginx, myapp, redis, mysql, vb.)
• host: Sunucu adı (web01, web02, db01, lb01, vb.)

Grafana üzerinden log sorgularken, bu etiketler sayesinde tek sorguyla tüm web sunucularındaki nginx loglarını filtreleyebiliyorsunuz.

Loki’nin Avantajları

• Kaynak dostu: Full-text index yerine sadece label index tuttuğu için CPU/RAM/disk kullanımı daha düşüktür.
• Object storage entegrasyonu: S3/MinIO gibi sistemlerde uzun süreli log saklama maliyetini düşürür. (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: Özellikle küçük–orta ölçekli kümelerde kurulumu ve yönetimi ELK’ye göre daha hafiftir.

Loki’nin Sınırları

• Full-text arama kısıtları: Çok karmaşık ad-hoc sorgularda Elasticsearch kadar esnek değildir.
• Label tasarımı önemli: Yanlış label stratejisi, hem performansı hem maliyeti olumsuz etkileyebilir.

Operasyonel log izleme, hata ayıklama ve temel güvenlik izleri için Loki çoğu senaryoda fazlasıyla yeterli oluyor. Çok karmaşık analitik raporlar veya hukuki/compliance gereği gerektiren sorgularınız varsa, hibrit bir yaklaşım (kritik subset ELK’de, operasyonel loglar Loki’de) değerlendirebilirsiniz.

ELK vs Loki: Hangi Senaryoda Hangisini Tercih Etmeli?

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

• Log hacmi çok yüksek, karmaşık sorgular ve raporlama önemli: ELK çoğu zaman doğru seçim.
• Operasyonel gözlemlenebilirlik, hızlı kurulum, düşük maliyet: Loki daha uygun.
• Regülasyonlar, denetim raporları, SIEM entegrasyonları: ELK veya ELK tabanlı çözümler baskın.
• Prometheus + Grafana kullanan mevcut gözlem altyapısı: Loki ile tek panelden metrik + log yönetimi çok rahat.

DCHost tarafında pratikte gördüğümüz desen şu:

• Küçük/orta ölçekli SaaS, e-ticaret ve içerik siteleri: Loki + Promtail + Grafana
• Geniş ekipli, güvenlik ve denetim baskısı yüksek kurumsal yapılar: ELK veya hibrit mimariler

Ö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:

1. Her sunucuya ajan kurulumu: Loki tarafı için Promtail, ELK tarafı için Filebeat.
2. Log formatlarını netleştirme: Mümkünse Nginx/Apache ve uygulama loglarını JSON formatına almak.
3. Merkezi log kümesi: Ayrı bir VPS veya dedicated sunucuda Loki veya ELK cluster’ı.
4. Dashboard ve alarm kuralları: En kritik hata ve performans metrikleri için alarmlar.
5. Log saklama politikası: 7/30/90 gün sıcak saklama, sonrası için arşiv.

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

ELK veya Loki fark etmeksizin, logları ne kadar süre hızlı erişilebilir tutacağınız kritik bir karar. Genelde şu yaklaşım sağlıklı:

• 7–14 gün: Sıcak depolama (SSD, hızlı sorgu için optimize index’ler)
• 30–90 gün: Ilık depolama (daha az performanslı disk, daha agresif sıkıştırma)
• 90+ gün: Soğuk arşiv (object storage, düşük maliyetli ama daha yavaş erişim)

Loki tarafında bu katmanlama görece doğal; çünkü log satırları zaten parça parça object storage’a yazılabiliyor. ELK tarafında ise Index Lifecycle Management ile benzer bir yapı kurmak mümkün. DCHost altyapısında, müşterilerimizin ihtiyacına göre hem SSD tabanlı hızlı VPS’ler hem de S3 uyumlu arşiv depolama birlikte kullanılabiliyor.

Dashboard, Alarm ve Gözlemlenebilirlik

Merkezi loglamanın gerçek değeri, kritik soruları saniyeler içinde cevaplayabildiğinizde ortaya çıkıyor:

• 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?

Grafana + Loki veya Kibana + Elasticsearch ile bu soruların çoğuna saniyeler içinde yanıt verebilmeniz mümkün. 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 + Promtail + Grafana ile merkezi loglama ve gözlemlenebilirlik yazımızda, özellikle küçük–orta ölçekli VPS kümelerinde nasıl pratik dashboard’lar kurulacağını ve hangi alarm eşiklerinin işe yaradığını sahadan örneklerle paylaştık.

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

Teoride her şey güzel, peki pratiğe nasıl dökülecek? DCHost müşterileriyle yürüttüğümüz projelerde genelde şu adımları izliyoruz:

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

• Mümkün olan her yerde log formatını JSON’a yakınlaştırın.
• Timestamp, request_id, user_id, tenant_id gibi alanları standartlaştırın.
• Uygulama tarafında structured logging (ör. Laravel Monolog JSON handler) kullanın.

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

• Önce 1–2 sunucuyu merkezi loglamaya bağlayın.
• İlk dashboard ve alarmları bu küçük kümeyle test edin.
• Maliyet ve performans profilinizi gözlemleyin.

4. Kademeli yaygınlaştırma

• POC stabil ve faydalı olduğunda, diğer sunucuları da yavaş yavaş ekleyin.
• Her yeni servis türü için (örneğin veritabanı, cache, queue) ayrı job/label yapıları tanımlayın.

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.

DCHost Altyapısında ELK ve Loki’yi Nasıl Konumlandırıyoruz?

DCHost olarak hem VPS hem de dedicated sunucu ve colocation ortamlarında merkezi loglama mimarilerini sık sık kuruyoruz. Genel yaklaşımımız şöyle:

• Küçük–orta ölçekli projelerde, ilk aşamada Loki + Promtail + Grafana öneriyoruz.
• Güvenlik/regülasyon baskısı yüksek, log hacmi çok büyük ortamlarda ELK veya hibrit mimariler planlıyoruz.
• Log kümesini genellikle ayrı, izole bir VPS veya dedicated sunucuya alarak, uygulama sunucularının CPU/RAM kaynaklarını boşa harcamıyoruz.
• SSD tabanlı hızlı diskleri sıcak verilerde, S3 uyumlu depolamayı uzun süreli arşivde kullanarak maliyeti dengeliyoruz.

Eğer altyapınızda zaten Prometheus + Grafana tabanlı bir izleme kurduysanız, VPS izleme ve uyarı rehberimizde anlattığımız desenleri, Loki entegrasyonuyla çok rahat genişletebilirsiniz. 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:

• SSH ile sunucudan sunucuya atlayarak log arama dönemini bitiriyor
• Performans darboğazlarını haftalar öncesinden görmenizi sağlıyor
• Güvenlik olaylarında geriye dönük net bir iz bırakıyor
• Geliştirici ekiplerin hata ayıklama hızını ciddi şekilde artırıyor

DCHost ekibi olarak, ister tek VPS’ten oluşan mütevazı bir başlangıç yapın, ister onlarca sunuculuk bir SaaS altyapısını yönetin; log yönetimini mimarinin temel bir bileşeni haline getirmenizi öneriyoruz. İhtiyaçlarınıza uygun VPS, dedicated veya colocation altyapısını belirlerken, merkezi loglama tasarımını da beraber planlamak isterseniz, altyapınızı birlikte masaya yatırmaktan memnuniyet duyarız.

Mevcut yapınızda hangi yaklaşımın (ELK mi, Loki mi, hibrit mi) daha mantıklı olduğunu netleştirmek, log saklama süreleri ve maliyet dengesini gözden geçirmek için bizimle iletişime geçebilir; DCHost altyapısında size özel, sürdürülebilir bir log mimarisi tasarlayabiliriz.