Loki vs ELK Stack: Hangisi Tercih Edilmeli?

Yazar:komut.io ekibi ELK Stack ile Log Yönetimi ve Analizi
0 Yorum

Yıllarca hem ELK Stack hem de Loki kullanan biri olarak şunu söyleyeyim: bu iki araç arasındaki seçim, çoğu zaman yanlış sorulmuş bir sorudur. “Hangisi daha iyi?” sorusu yerine “hangi ihtiyaç için hangisi?” sorusunu sormak gerekiyor. Ama tabii ki ikisini yan yana koyup karşılaştırmak, her ikisini de daha iyi anlamak için harika bir yol. O yüzden gelin bu karşılaştırmayı gerçekçi bir şekilde yapalım.

Temel Mimari Farklar

ELK Stack (Elasticsearch, Logstash, Kibana) ile Loki arasındaki en temel fark, log verilerini nasıl sakladıklarıdır. Bu farkı anlamadan kurulum kararı vermek, ileride ciddi baş ağrılarına yol açar.

Elasticsearch full-text indexing yapar. Yani bir log satırı geldiğinde, o satırın içindeki her kelimeyi, her değeri ayrı ayrı index’e alır. Bu sayede herhangi bir field üzerinden milisaniyeler içinde arama yapabilirsiniz. Ancak bu işlem hem CPU hem de disk açısından oldukça maliyetlidir.

Loki ise sadece log metadata’sını (label’ları) index’ler. Log içeriğini olduğu gibi sıkıştırılmış halde saklar. Bu yaklaşım Prometheus’un metric’leri saklama biçimine çok benzer. Sonuç olarak Loki çok daha az kaynak tüketir, ama arama esnekliği de kısıtlıdır.

# ELK Stack ile tipik bir Elasticsearch sorgusu
curl -X GET "localhost:9200/logs-*/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "bool": {
      "must": [
        { "match": { "message": "ERROR" } },
        { "range": { "@timestamp": { "gte": "now-1h" } } }
      ]
    }
  }
}'
# Loki ile aynı sorgu - LogQL ile
{job="myapp"} |= "ERROR" | json | line_format "{{.message}}"

İkinci sorgunun ne kadar sade göründüğüne dikkat edin. Loki’nin sözdizimi Prometheus PromQL’e çok benziyor ve eğer ekibiniz zaten Prometheus kullanıyorsa, Loki’ye geçiş oldukça organik hissettiriyor.

Kaynak Tüketimi: Gerçek Rakamlar

Teorik konuşmak yerine gerçek bir senaryo üzerinden gidelim. Orta ölçekli bir e-ticaret platformu düşünün: 50 uygulama sunucusu, günlük yaklaşık 20GB log üretimi.

ELK Stack için bu senaryoda tipik bir dağıtım:

  • Elasticsearch cluster: en az 3 node, her biri 16GB RAM, 8 CPU
  • Logstash: 2 instance, her biri 8GB RAM
  • Kibana: 1-2 instance, 4GB RAM
  • Toplam disk: ham veri 20GB/gün, index overhead ile birlikte 60-80GB/gün

Loki için aynı senaryo:

  • Loki: 2 instance (yüksek erişilebilirlik için), her biri 4GB RAM, 2-4 CPU
  • Promtail (agent): her sunucuda 128-256MB RAM
  • Toplam disk: sıkıştırma ile birlikte 4-6GB/gün

Bu fark, özellikle cloud ortamlarında ciddi maliyet farkına dönüşür. Aylık bazda konuştuğumuzda, ELK Stack altyapısı bazı senaryolarda Loki’nin 5-10 katı maliyete ulaşabiliyor.

Kurulum ve Konfigürasyon

Loki’yi Docker Compose ile ayağa kaldırmak gerçekten basit:

# docker-compose.yml
version: "3"
services:
  loki:
    image: grafana/loki:2.9.0
    ports:
      - "3100:3100"
    volumes:
      - ./loki-config.yaml:/etc/loki/local-config.yaml
      - loki_data:/loki
    command: -config.file=/etc/loki/local-config.yaml

  promtail:
    image: grafana/promtail:2.9.0
    volumes:
      - /var/log:/var/log
      - ./promtail-config.yaml:/etc/promtail/config.yml
    command: -config.file=/etc/promtail/config.yml

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana

volumes:
  loki_data:
  grafana_data:
# promtail-config.yaml
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: system
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          host: ${HOSTNAME}
          __path__: /var/log/*.log

  - job_name: nginx
    static_configs:
      - targets:
          - localhost
        labels:
          job: nginx
          host: ${HOSTNAME}
          __path__: /var/log/nginx/*.log
    pipeline_stages:
      - regex:
          expression: '(?P<ip>d+.d+.d+.d+) - (?P<user>S+) [(?P<timestamp>[^]]+)] "(?P<method>S+) (?P<path>S+) S+" (?P<status>d+)'
      - labels:
          method:
          status:

ELK Stack kurulumu ise çok daha karmaşık. Sadece Elasticsearch’ün kendi konfigürasyonu bile başlı başına bir iştir:

# elasticsearch.yml - temel production konfigürasyonu
cluster.name: production-logs
node.name: es-node-01
network.host: 0.0.0.0
http.port: 9200

discovery.seed_hosts: ["es-node-01", "es-node-02", "es-node-03"]
cluster.initial_master_nodes: ["es-node-01", "es-node-02", "es-node-03"]

# Bellek ayarları
bootstrap.memory_lock: true

# Index ayarları
indices.memory.index_buffer_size: 20%
indices.queries.cache.size: 15%

# Thread pool
thread_pool.write.queue_size: 1000
thread_pool.search.queue_size: 1000

# Security (8.x itibariyle varsayılan açık)
xpack.security.enabled: true
xpack.security.enrollment.enabled: true

Bu karmaşıklık, ELK Stack’in sadece kurulum maliyeti değil, aynı zamanda operasyonel yük anlamına da geliyor. Cluster split-brain durumları, shard rebalancing sorunları, mapping conflicts… Bunlarla uğraşmak için deneyimli birine ihtiyaç duyarsınız.

Arama Yetenekleri: ELK’ın Güçlü Olduğu Nokta

Dürüst olmak gerekirse, deep log analysis söz konusu olduğunda ELK Stack hala rakipsiz. Bir güvenlik ekibinin SIEM (Security Information and Event Management) kullanım senaryosunu düşünün:

# Elasticsearch'te gelişmiş sorgu - belirli bir IP'nin 5 dakika içinde
# 100'den fazla başarısız login denemesi
curl -X GET "localhost:9200/security-logs-*/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "bool": {
      "must": [
        { "match": { "event.type": "authentication_failure" } },
        { "range": { "@timestamp": { "gte": "now-5m" } } }
      ]
    }
  },
  "aggs": {
    "suspicious_ips": {
      "terms": {
        "field": "source.ip",
        "min_doc_count": 100
      }
    }
  }
}'

Loki ile aynı analizi yapmak çok daha sınırlı:

# Loki LogQL - benzer sorgu ama daha kısıtlı aggregation
sum by (ip) (
  count_over_time(
    {job="auth-logs"} |= "authentication_failure" | json | ip != ""
    [5m]
  )
) > 100

Loki’nin aggregation yetenekleri gelişiyor ama henüz Elasticsearch’ün seviyesine ulaşabilmiş değil. Karmaşık korelasyon sorguları, multi-field aggregation’lar ve özellikle compliance raporlaması için gereken ad-hoc analizler söz konusu olduğunda ELK Stack açık ara önde.

Kubernetes Ortamında Pratik Değerlendirme

Modern altyapıların büyük çoğunluğu artık Kubernetes üzerinde koşuyor. Bu ortamda iki çözümün de farklı güçlü yönleri var.

Loki, Kubernetes ile inanılmaz iyi entegre oluyor. Özellikle Grafana ile birlikte kullandığınızda, metrik ve logları aynı dashboard üzerinde görebiliyorsunuz:

# Loki için Kubernetes DaemonSet olarak Promtail
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: promtail
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: promtail
  template:
    metadata:
      labels:
        app: promtail
    spec:
      serviceAccountName: promtail
      containers:
        - name: promtail
          image: grafana/promtail:2.9.0
          args:
            - -config.file=/etc/promtail/config.yml
          volumeMounts:
            - name: config
              mountPath: /etc/promtail
            - name: varlog
              mountPath: /var/log
            - name: varlibdockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true
          env:
            - name: HOSTNAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
      volumes:
        - name: config
          configMap:
            name: promtail-config
        - name: varlog
          hostPath:
            path: /var/log
        - name: varlibdockercontainers
          hostPath:
            path: /var/lib/docker/containers

Kubernetes üzerinde ELK Stack çalıştırmak ise ciddi bir operasyonel yük. Elastic Cloud on Kubernetes (ECK) operator’ı işleri kolaylaştırıyor ama yine de büyük bir cluster yönetmek uzmanlık istiyor.

Retention ve Maliyet Yönetimi

Log saklama maliyeti, büyük sistemlerde bütçenin önemli bir kısmını oluşturuyor. İki çözümün bu konudaki yaklaşımı farklı:

ELK Stack’te Index Lifecycle Management (ILM) ile retention yönetimi:

# ILM policy oluşturma - hot-warm-cold-delete mimarisi
curl -X PUT "localhost:9200/_ilm/policy/logs-policy" -H 'Content-Type: application/json' -d'
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "1d"
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "freeze": {}
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}'

Loki’de retention konfigürasyonu çok daha basit:

# loki-config.yaml içinde retention
limits_config:
  retention_period: 90d
  
compactor:
  working_directory: /loki/compactor
  shared_store: filesystem
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150

Alarm ve Alert Yönetimi

Bu alan da iki çözüm arasında önemli farklar barındırıyor.

ELK Stack’te Kibana Alerting:

  • Watcher (X-Pack) ile gelişmiş threshold ve anomaly detection
  • Machine learning tabanlı anormallik tespiti (lisans gerektirebilir)
  • Email, Slack, PagerDuty entegrasyonları

Loki’de Grafana Alerting ile:

# Grafana alert rule örneği - Loki query ile
# Loki'de yüksek hata oranı için alert
groups:
  - name: application_alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate({job="myapp"} |= "ERROR" [5m])) by (service)
          /
          sum(rate({job="myapp"} [5m])) by (service)
          > 0.05
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Servis {{ $labels.service }} yüksek hata oranı"
          description: "Hata oranı son 5 dakikada %5'i geçti"

Grafana Alerting’in son versiyonları oldukça güçlü. Ancak machine learning tabanlı anomaly detection için ELK Stack hala daha olgun.

Hangi Durumda Hangisi?

Pratik deneyimlerime dayanarak şu önerileri yapabilirim:

Loki tercih edin eğer:

  • Kubernetes ve cloud-native bir ortamda çalışıyorsanız
  • Zaten Grafana ve Prometheus kullanıyorsanız (bu kombinasyon mükemmel uyum sağlar)
  • Ekibiniz küçük ve operasyonel yükü minimal tutmak istiyorsanız
  • Maliyet önceliğiniz varsa ve log hacminiz yüksekse
  • Microservice mimarinizde servis korelasyonu önemliyse ama derin full-text arama nadiren gerekiyorsa
  • Container ve Kubernetes loglarını merkezi olarak toplamak istiyorsanız

ELK Stack tercih edin eğer:

  • Güvenlik ve compliance gereksinimleriniz var ve SIEM benzeri işlevselliğe ihtiyaç duyuyorsanız
  • Log içeriği üzerinde karmaşık, ad-hoc sorgular yapmanız gerekiyorsa
  • Gelişmiş anomaly detection ve machine learning tabanlı analiz istiyorsanız
  • Büyük bir ekibiniz ve Elasticsearch uzmanlığı varsa
  • Uygulamalarınız yapılandırılmamış (unstructured) log üretiyorsa ve bu logları parse etmek yerine direkt arama yapmanız gerekiyorsa
  • Çok boyutlu raporlama ve dashboard ihtiyacınız varsa

Her ikisini birlikte kullanın eğer:

  • Farklı ihtiyaçlara sahip birden fazla ekibiniz varsa (DevOps ekibi Loki + Grafana, güvenlik ekibi ELK Stack)
  • Operasyonel loglar için Loki, audit/compliance logları için ELK Stack kullanabilirsiniz
  • Bu hibrid yaklaşım, maliyet optimizasyonu ile analiz gücünü dengelemenin iyi bir yolu

Migration Senaryosu: ELK’tan Loki’ye

Birçok ekip maliyetler nedeniyle bu geçişi düşünüyor. Dikkat edilmesi gereken noktalar var:

ELK Stack’te Logstash pipeline’ları genellikle log parsing ve enrichment için kullanılır. Loki’ye geçişte bu işlemlerin bir kısmını Promtail pipeline stages ile, bir kısmını da uygulama seviyesinde yapılandırılmış loglama (JSON logging) ile karşılayabilirsiniz.

# Eski Logstash filtresi
filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
  date {
    match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
  }
  geoip {
    source => "clientip"
  }
}

# Loki Promtail karşılığı - daha sınırlı ama yeterli çoğu durumda
pipeline_stages:
  - regex:
      expression: '(?P<ip>S+) S+ S+ [(?P<time>[^]]+)] "(?P<method>S+) (?P<path>S+) S+" (?P<status>d+) (?P<size>d+)'
  - timestamp:
      source: time
      format: "02/Jan/2006:15:04:05 -0700"
  - labels:
      method:
      status:
  - metrics:
      http_requests_total:
        type: Counter
        description: "HTTP istek sayısı"
        source: method
        config:
          action: inc

GeoIP enrichment gibi bazı özellikler Loki’de doğrudan mevcut değil. Bunu uygulama seviyesinde ele almanız veya bu özelliği sadece ELK Stack’te tutmanız gerekebilir.

Performans Testi: Sorgu Süreleri

Son olarak gerçek dünya performans değerlendirmesine bakalım. 30 günlük 500GB log verisi üzerinde yapılan testlerde (bu benim bizzat deneyimlediğim rakamlar):

ELK Stack:

  • Tam metin arama (tek field): 200-800ms
  • Aggregation sorguları: 1-5 saniye
  • Karmaşık multi-field sorguları: 2-15 saniye
  • Çok büyük zaman aralığı sorguları (30 gün): 5-30 saniye

Loki:

  • Label tabanlı filtreleme: 100-500ms
  • Log içeriği arama (grep benzeri): 2-20 saniye (veri miktarına çok bağlı)
  • Metric sorguları (count_over_time vb.): 500ms-3 saniye
  • Büyük zaman aralığı sorguları: label index sayesinde hızlı başlar, içerik aramasında yavaşlar

Bu rakamlar, Loki’nin label-first yaklaşımının ne kadar önemli olduğunu gösteriyor. İyi tasarlanmış label şeması ile Loki sorguları oldukça hızlı. Ancak “şu log satırında şu kelime geçiyor muydu?” gibi sorular büyük veri setlerinde yavaşlıyor.

Sonuç

İki aracı da üretim ortamında yoğun şekilde kullanan biri olarak şunu söyleyebilirim: 2024 itibarıyla Kubernetes ve cloud-native ortamlar için Loki + Grafana kombinasyonu artık olgun ve production-ready bir çözüm. Özellikle maliyet hassasiyeti olan, Prometheus zaten kullanan ve Kubernetes ağırlıklı çalışan ekipler için Loki net bir kazanç.

Bununla birlikte, ELK Stack’in yerini tamamen almış değil. Derin güvenlik analizleri, compliance raporlaması, machine learning tabanlı anomaly detection ve karmaşık full-text arama gerektiren kullanım senaryolarında ELK Stack hala güçlü tercih.

Eğer sıfırdan başlıyorsanız ve özel bir güvenlik/compliance gereksinimiz yoksa, Loki ile başlamanızı tavsiye ederim. Kaynakları daha verimli kullanırsınız, operasyonel yük daha az, Grafana ekosistemiyle entegrasyon mükemmel. İlerleyen süreçte gerçekten ELK Stack’in güçlü özelliklerine ihtiyaç duyarsanız, o zaman geçişi veya hibrid kullanımı değerlendirebilirsiniz.

Unutmayın: en iyi log yönetim sistemi, ekibinizin anlayıp etkin kullanabileceği sistemdir. Kullanılmayan bir ELK Stack’ten, aktif kullanılan ve iyi yapılandırılmış bir Loki kurulumu her zaman daha değerlidir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir