Loki 3.3 Mimarisi ve 2026 Production Topolojisi

Grafana Loki 3.3 sürümü, 2026 yılında üretim ortamlarındaki log aggregation mimarilerinin neredeyse %47’sinde varsayılan tercih hâline geldi. CNCF 2025 Annual Survey raporuna göre, Kubernetes üzerinde çalışan kuruluşların %63’ü Loki’yi en az bir production cluster’ında etkin kullanıyor. Bu rakam, ELK Stack’in 2022’deki %71’lik pazar payını ters yüz eden net bir kayma gösteriyor. Çünkü Loki’nin “index sadece label” tasarımı, depolama maliyetlerini Elasticsearch’e göre %78’e varan oranda düşürürken sorgu gecikmesini 2 saniyenin altına çekiyor.

Bu yazıda Loki 3.3’ün 2026 production pattern’lerini Schema v13, Bloom Filter, TSDB index ve Memcached katmanları üzerinden ele alacağız. Hedef kitle, günde 5 TB ile 50 TB arasında log üreten orta-büyük ölçekli platformların SRE ekipleri. Datadog gibi SaaS çözümlerin yıllık 1.2 milyon dolarlık faturalarını 180 bin dolara indiren saha vakalarına da değineceğiz.

Loki 3.3 Mimarisi ve 2026 Production Topolojisi

Loki 3.3, microservices deployment modunda 7 ana bileşeni ayrı pod’larda çalıştırır: Distributor, Ingester, Querier, Query Frontend, Compactor, Index Gateway ve Ruler. Production’da en kritik karar, monolithic ile microservices arasında değil, “Simple Scalable Deployment” (SSD) modu ile microservices arasındadır. SSD modu read/write yollarını ikiye böler ve günde 10 TB’a kadar log için yeterlidir. Bunun ötesinde microservices şart olur.

2026 itibarıyla en yaygın production topolojisi şu şekilde kuruluyor: 3 Distributor pod (her biri 4 vCPU, 8 GB RAM), 6 Ingester pod (8 vCPU, 32 GB RAM, persistent volume 200 GB), 4 Querier pod (8 vCPU, 16 GB RAM) ve 1 Compactor pod (4 vCPU, 16 GB RAM). Object storage olarak S3 veya GCS tercih edilirken, MinIO da on-prem senaryolarda %23 oranında kullanılıyor.

Schema v13 ve TSDB Index Migration

Loki 2.9’dan 3.3’e geçişin en önemli adımı Schema v13 ve TSDB index store kullanımıdır. Eski BoltDB Shipper, milyar satır seviyesinde sorgularda yavaşlıyordu. TSDB index ise Prometheus’tan ödünç alınan veri yapısı sayesinde label cardinality 5 milyonun üzerinde dahi 800 ms altında yanıt veriyor. Migration sırasında schema_config bloğuna yeni bir from tarihi eklenir ve eski şema dondurulur. Geçiş süresi 7 gün retention için ortalama 12 saat sürer.

schema_config:
  configs:
    - from: 2024-01-01
      store: boltdb-shipper
      object_store: s3
      schema: v12
    - from: 2026-03-15
      store: tsdb
      object_store: s3
      schema: v13
      index:
        prefix: loki_index_
        period: 24h

Bu yapı sayesinde geriye dönük 90 günlük sorgular eski şemada, yeni sorgular TSDB’de çalışır. Tek bir LogQL sorgusu her iki indeksi de transparan olarak okur. Üretim ekiplerinin %91’i bu kademeli geçişi tercih ediyor.

Bloom Filter ve Sorgu Hızlandırma

Loki 3.0 ile gelen, 3.3’te stabilize edilen Bloom Filter özelliği, log içeriğinde substring araması yapan sorguları 4 kat ile 12 kat arasında hızlandırıyor. |= "trace_id=abc" gibi pinpoint sorgular, bloom filter olmadan tüm chunk’ları indiriyordu. Bloom filter aktifken sadece %3 ile %8 arasındaki chunk’lar okunuyor. Bu da S3 GET çağrılarını ayda 47 milyondan 3.8 milyona düşürüyor; AWS faturasında ayda 1840 dolarlık net tasarruf demek.

Bloom Filter, Compactor’ın yanına eklenen Bloom Builder ve Bloom Gateway bileşenleri üzerinden çalışır. Production’da 2 Bloom Builder pod ve 2 Bloom Gateway pod yeterli olur. Bellek tüketimi her pod için 8 GB seviyesinde stabilize olur.

Multi-Tenant İzolasyon ve Limit Yönetimi

2026’da Loki’yi merkezi platform olarak çalıştıran kurumlar ortalama 47 tenant barındırıyor. Her tenant’ın X-Scope-OrgID header’ı ile izolasyonu zorunlu. limits_config içinde tenant başına ingestion_rate_mb, max_streams_per_user ve max_query_series ayrı belirlenir.

Bu sınıflandırma sayesinde tek bir tenant’ın “noisy neighbor” etkisi engellenir. Grafana Labs’ın 2025 Loki Best Practices dokümanı, her tenant için ayrı runtime config dosyası önerir.

Memcached Katmanı ve Cache Stratejisi

Loki 3.3 production’da 4 ayrı Memcached cluster ile çalışır: chunks cache, index cache, results cache ve write-dedupe cache. En kritik olanı chunks cache’dir; doğru boyutlandırılırsa S3 GET çağrılarının %78’i cache’den döner. Önerilen boyutlar:

• chunks-cache: 6 pod, her biri 16 GB. TTL 24 saat. Hit oranı hedef %75 üzeri.
• index-cache: 3 pod, her biri 8 GB. TTL 1 saat. Hit oranı hedef %92 üzeri.
• results-cache: 2 pod, her biri 4 GB. TTL 5 dakika. Sorgu sonuçları için.
• write-dedupe-cache: 3 pod, her biri 4 GB. Distributor’ın duplicate engellemesi için.

Memcached yerine Redis kullanmak Loki dökümantasyonunda desteklenmiyor; çünkü Memcached’in slab allocation modeli log chunk’ları için 3 kat daha verimli. Üretim ekiplerinin %96’sı bu yüzden Memcached’e bağlı kalıyor.

LogQL Optimizasyonu ve Query Patterns

LogQL sorgularının %43’ü production’da yanlış yazılıyor. En yaygın hata, label filter’ı line filter’dan sonra koymaktır. Doğru sıra şudur: {job="api"} |= "error" | json | line_format "{{.message}}". Label filter en başta olduğunda sadece ilgili stream’ler okunur; line filter, gelen chunk’ları memory’de tarar; parser (json/logfmt) en son çalışır.

2026’da OpenTelemetry log protokolü artık Loki’ye doğrudan akıyor. Loki 3.3’ün OTLP receiver’ı, otlp_config bloğu ile etkinleştirilir ve service.name, severity_text, trace_id gibi resource attribute’larını otomatik label’a çevirir. Bu sayede ekipler OpenTelemetry Collector’ı Loki için ayrı yapılandırmak zorunda kalmıyor; tek bir pipeline yeterli.

Retention, Compaction ve Maliyet Mühendisliği

Production Loki’de retention 3 katmanlı kurulur. Sıcak katman 7 gün, Memcached + S3 Standard. Ilık katman 30 gün, S3 Standard-IA. Soğuk katman 365 gün, S3 Glacier Instant Retrieval. Bu yapı ile günde 8 TB log üreten bir platformda yıllık depolama maliyeti 87.000 dolardan 23.400 dolara düşer; tam %73 tasarruf.

Compactor pod’u günde 2 kez (gece 02:00 ve 14:00 UTC) çalışacak şekilde planlanır. Compaction sırasında küçük chunk’lar birleştirilir, retention policy uygulanır ve duplicate stream’ler temizlenir. 2025 Loki sürümlerinde compactor’ın horizontal scaling’i geldi; 50 TB’ın üzerindeki kurulumlarda 3 compactor pod kullanılır.

Promtail’den Alloy’a Geçiş

Grafana Labs, Promtail’i 2025 sonunda deprecate etti. 2026’da yeni standart agent Grafana Alloy. Alloy, Promtail’in tüm pipeline’larını destekler ama bunlara ek olarak OpenTelemetry, Prometheus scrape ve Pyroscope profiling’i tek bir binary altında birleştirir. Migration için Alloy’ın convert komutu eski Promtail YAML’larını otomatik dönüştürür. 1200 satırlık bir Promtail config’i ortalama 4 dakikada Alloy formatına geçer.

Alloy’un River configuration language’i başta zorlayıcı görünür ama component-based mimari sayesinde aynı pipeline’ı 38 satırla yazmak mümkün olur. Grafana Loki resmi dökümantasyonu, 2026 itibarıyla tüm örneklerini Alloy üzerinden veriyor.

Gözlemlenebilirlik ve Self-Monitoring

Loki’nin kendisini de izlemek şart. loki_distributor_bytes_received_total, loki_ingester_chunks_flushed_total ve loki_request_duration_seconds metrikleri en kritik 3 metriktir. Bunlara ek olarak cortex_ingester_memory_streams sayısı tenant başına 50.000 üzerine çıktığında alarm kurulmalı; aksi takdirde ingester restart’larında WAL replay süresi 25 dakikayı aşar.

Loki, doğru kurulduğunda ELK stack’in 1/4’ü maliyetle aynı sorgu performansını verir. Yanlış kurulduğunda ise ingester OOM’larıyla geceyi geçirirsiniz. Fark, Schema v13 + TSDB + Bloom Filter + Memcached dörtlüsünü doğru hizalamakta.

Disaster Recovery ve Multi-Region

Production Loki’de DR senaryosu üç katmanlı kurulur: WAL replication (ingester pod’unun persistent volume’unda), object storage cross-region replication (S3 CRR, 15 dakika RPO) ve ring state backup (Consul/etcd snapshot, saatlik). RTO hedefi 30 dakika, RPO hedefi 15 dakika olarak belirlenir.

Multi-region active-active Loki kurulumu, Loki 3.0’dan itibaresi memberlist protokolü ile destekleniyor. İki bölge arasında cluster_label ayrımı yapılarak tenant trafiği DNS routing ile yönlendirilir. 2026’da Türkiye’deki bankacılık ve telekom sektöründe bu mimari fiili standart hâline geldi.

FAQ

Loki 3.3 ile 2.9 arasında upgrade riski nedir?

Schema v13 yalnızca yeni dilimler için aktif olduğundan in-place upgrade güvenlidir. Eski şema okunmaya devam eder. Yine de upgrade öncesi compactor durdurulmalı, snapshot alınmalı ve rolling restart 6 ingester için 24 dakikada tamamlanmalıdır.

ELK’den Loki’ye migration ne kadar sürer?

Tipik kurumsal bir platform için 6 ile 12 hafta arası. İlk 4 hafta paralel çalıştırma, sonraki 4 hafta dashboard ve alert migration, son 4 hafta ELK’nin decommissioning’i. Toplam tasarruf 12 ay içinde 380.000 dolardan başlar.

Loki’de full-text search neden yok?

Loki, label-based index kullanır; içerik tam metin olarak indekslenmez. Ancak Bloom Filter ile substring araması 3 saniyenin altında çalışır. Full-text gerektiren senaryolarda OpenSearch ile Loki yan yana kurulur; loglar Loki’ye, kritik audit kayıtları OpenSearch’e yazılır.

Tenant cardinality limit nasıl belirlenir?

Genel kural, max_streams_per_user değerini günlük aktif container sayısının 8 katı tutmaktır. 1000 container çalışan tenant için 8000 stream limit yeterli olur. Bu limit aşılınca Loki per-stream rate limit exceeded hatası verir.

OpenTelemetry Collector ile Loki entegrasyonu nasıl?

OTel Collector’ın otlphttp exporter’ı Loki’nin /otlp/v1/logs endpoint’ine doğrudan POST eder. X-Scope-OrgID header’ı zorunlu. Resource attribute’ları otomatik Loki label’ına dönüşür; ancak yüksek cardinality’li attribute’lar (ör. k8s.pod.uid) structured_metadata olarak işaretlenmeli.

Kurumsal Loki Dönüşümünde Tipik Sorunlar

Türkiye’deki kurumsal Loki kurulumlarında en sık karşılaşılan 6 sorun şu sırayla görülüyor. Birincisi, ingester OOM kill’leri; %78 oranında chunk_idle_period ve chunk_target_size dengesizliğinden kaynaklanıyor. İkincisi, label cardinality patlaması; özellikle request_id veya user_id‘nin label olarak yazılması her tenant için ayda 14.000 dolarlık ek S3 maliyeti yaratabiliyor.

Üçüncü sorun, Promtail’den Alloy’a geçişte pipeline’ların yarısının çevrilememesi; bu durum genelde custom regex stage’lerinde olur ve manuel müdahale gerektirir. Dördüncüsü, multi-tenant’ta X-Scope-OrgID header’ının frontend reverse proxy’de unutulması; %23 vakada güvenlik açığına dönüşüyor. Beşinci sorun, retention policy’nin yanlış kurulması; soğuk katmanı atlayan kurumlar 18 ay sonra depolama maliyetlerinin 4 katına çıktığını fark ediyor. Altıncı ve en pahalısı, ring state’in etcd yerine memberlist’te tutulmaması nedeniyle yaşanan split-brain senaryoları; 2025’te Türkiye’deki 3 büyük bankada 47 dakikalık log kaybına yol açtı.

Sonuç

Grafana Loki 3.3, 2026 yılında log aggregation alanında olgun, maliyet-etkin ve OpenTelemetry-native bir çözüm olarak öne çıkıyor. Schema v13, TSDB, Bloom Filter ve Memcached dörtlüsü doğru kurulduğunda Datadog’un %15’i maliyetle aynı sorgu deneyimini sağlıyor. 2026’da Promtail’in deprecate edilmesiyle Alloy ekosistemine geçmek artık opsiyonel değil, zorunlu. Doğru topoloji, doğru retention katmanı ve doğru multi-tenant izolasyonu kurulduğunda Loki, günde 50 TB’a kadar ölçeklenebilen, %99.95 SLA hedefini tutturan bir platform hâline gelir. Ekiplerin bu yola çıkarken en kritik adım, ilk 90 günde label cardinality disiplini kurmak ve query review pipeline’ı oluşturmaktır.

Uzman Görüşü

Ömer ÖNAL — Observability danışmanlığı perspektifinden: Loki’yi kuruluma sokmadan önce ekiplerinizin LogQL okuryazarlığını ölçün. 2025’te danışmanlık verdiğim 14 kurumun 9’unda en büyük sorun teknik mimari değil, geliştiricilerin {job="api"} yerine |~ ".*" yazmasıydı. Bloom Filter dahil her optimizasyon, yanlış sorgu karşısında devre dışı kalır. Önce 4 saatlik LogQL workshop’u, sonra production rollout. Bu sırayı tersine çevirenler 6 ay sonra ELK’ye geri dönüyor.