Grafana Mimir Loki Tempo Stack: Observability 2026 Rehberi

Grafana stack 2026 itibarıyla açık kaynak observability dünyasının en yaygın kullanılan yığını haline geldi: Mimir metrik (Prometheus uyumlu), Loki log, Tempo distributed trace ve Pyroscope continuous profiling. CNCF 2024 yıllık anketinde katılımcıların %62’si Prometheus tabanlı bir metric backend kullandığını, %38’i ise Loki’yi production’da çalıştırdığını bildirdi. Bu yazıda Mimir/Loki/Tempo üçlüsünün mimarisini, object storage tabanlı uzun süreli saklama avantajını, Datadog/New Relic gibi SaaS alternatiflerine göre TCO farkını ve 2026’da bir DevOps ekibinin neden bu yığını ciddi şekilde değerlendirmesi gerektiğini somut rakamlarla inceleyeceğiz. Hedef kitle: orta-büyük ölçekli (50+ servis, 10TB+ aylık log) Kubernetes platformları işleten SRE ve platform mühendisleri.

Kısa cevap: Grafana stack, Datadog’un yıllık 200K-500K USD’ye mal olan bir gözlemlenebilirlik kurulumunu, object storage (S3, GCS, MinIO) üzerinde aynı veri hacmiyle yaklaşık 25K-60K USD altyapı maliyetiyle replike edebilen tek tutarlı açık kaynak alternatifidir. Pay olduğu yer: işletme yükü (operations overhead) ve ekibin Go/PromQL/LogQL ile derinleşme zorunluluğu.

Grafana Stack 2026: Bileşenler ve Üç Pillar Modeli

Observability disiplini metrics, logs ve traces olmak üzere üç ana sinyal türü etrafında şekillenir; OpenTelemetry spesifikasyonu 2024’te bunlara profiling‘i resmen dördüncü sinyal olarak ekledi. Grafana Labs, her sinyal için ayrı bir backend tasarladı ve hepsini Grafana UI üstünde birleştirdi. Bu modülerlik, monolitik SaaS çözümlerine kıyasla bileşen seçme özgürlüğü sağlıyor: yalnız metric için Mimir, yalnız log için Loki kullanabilirsiniz.

Bileşen	Sinyal Türü	İlk Sürüm	Son Stable (Q1 2026)	GitHub Stars (≈)	Storage Modeli
Mimir	Metrics (Prometheus)	Mart 2022	2.14.x	4.5K	Object storage + index
Loki	Logs	Aralık 2018	3.3.x	23K	Object storage + chunks
Tempo	Traces	Ekim 2020	2.6.x	4.4K	Object storage + bloom filter
Pyroscope	Profiles	2021 (Grafana satın aldı 2023)	1.10.x	10K	Object storage + symbols DB
Grafana OSS	Visualization	Kasım 2013	11.4.x	65K	SQLite/Postgres/MySQL
Alloy (Agent)	Collector	2024 (River config)	1.5.x	1.6K	Stateless

Dört backend’in ortak tasarım kararı, compute ile storage’ı ayırmak. Tüm veriler S3 uyumlu object storage’a yazılır; ingester’lar, querier’lar ve compactor’lar stateless veya near-stateless çalışır. Bu mimari, AWS S3’ün GB başına 0.023 USD aylık fiyatı sayesinde 100TB log saklamayı yaklaşık 2300 USD/ay seviyesine indirir — aynı hacim için Datadog Log Management 30 gün retention ile yaklaşık 25K-40K USD/ay tutar (Datadog public pricing, Q4 2025 takvim listesi).

Mimir Derinlemesine: Cortex’in Devamı, Yüksek Kardinalite İçin Tasarım

Mimir, Grafana Labs’ın 2022’de Cortex projesinden fork edip AGPLv3 lisansına geçirdiği Prometheus uyumlu uzun süreli metric backend’idir. Tasarım hedefi: tek bir tenant’ta milyar seviyesinde aktif seri. Grafana Labs blog’unda yayımlanan benchmark’larda Mimir 2.x, 1 milyar aktif time series ile 1.5M sample/s ingest hızını 30-node bir cluster üzerinde sürdürdüğünü gösteriyor (Grafana Labs, “Scaling Mimir to a billion active series”, 2023).

Mimir’in Prometheus’a göre temel avantajları net rakamlarla şöyle özetlenebilir:

• Horizontal scaling: Tek bir Prometheus instance pratikte 2-3M aktif seriye kadar dayanır; Mimir bu sınırı kaldırır, shard’lar arası dağıtım yapar.
• Multi-tenancy: Tek cluster yüzlerce tenant’a hizmet eder; her tenant için ayrı quota, rate limit ve retention politikası tanımlanabilir.
• Uzun süreli saklama: Prometheus local TSDB 15 gün varsayılan; Mimir S3’te 1 yıl+ retention’ı tek dijit cent/GB seviyesine indirir.
• Query parallelism: Querier’lar büyük range query’leri shard’lara bölerek p99 sorgu süresini Cortex’e göre %30-50 düşürür (Grafana Labs perf tests).
• Avantaj: %100 PromQL uyumluluğu — mevcut Prometheus dashboard’ları sıfır değişiklikle çalışır.
• Dezavantaj: Kurulum karmaşıklığı — minimum 8-10 mikroservis bileşeni (distributor, ingester, querier, compactor, store-gateway, ruler, alertmanager, query-frontend, query-scheduler, overrides-exporter).
• Ne zaman seç: 10M+ aktif seri, multi-tenant platform, 90+ gün retention ihtiyacı.

Mimir’in Cortex’ten ayrılan en kritik mimari kararı blocks storage modelidir: chunks artık 2 saatlik bloklara paketlenip S3’e atılır, query path da bu blokları paralel okur. Bu sayede chunks storage’a göre okuma maliyeti GCS/S3 tarafında %40 daha düşüktür. Üretim öncesi Mimir kurulumlarında Helm chart kullanıyorsanız jsonnet-libs/mimir-mixin dashboard’ları olmadan operate etmeyin; ingester memory tükenmesi ve compactor backlog görünmez kalır.

Loki: Log Aggregation’da Index-on-Labels Yaklaşımı

Loki’nin Elasticsearch’e göre felsefi farkı: log içeriğini full-text index’lemez, sadece label’ları (Kubernetes namespace, pod, container gibi metadata) indeksler. Bu yaklaşım storage maliyetini dramatic olarak düşürür; Grafana Labs’ın Loki vs Elasticsearch karşılaştırması aynı 1TB ham log için Loki’nin yaklaşık 100GB, Elasticsearch’ün ise 1-1.5TB disk tükettiğini gösteriyor (10-15x daha verimli). Trade-off: Loki’de “free-text” arama LogQL üzerinden chunk-by-chunk scan ile yapılır; petabayt seviyesinde geniş zaman aralığı sorguları yavaşlayabilir.

Özellik	Loki 3.x	Elasticsearch 8.x	Splunk Enterprise	OpenSearch 2.x
Lisans	AGPLv3	SSPL / ELv2	Ticari	Apache 2.0
Index modeli	Labels only	Inverted full-text	Inverted full-text	Inverted full-text
Storage (1TB ham log)	~80-120 GB	~1-1.5 TB	~1-1.3 TB	~1-1.5 TB
Sorgu dili	LogQL	Query DSL / KQL	SPL	Query DSL
Multi-tenancy	Native, header bazlı	Index/space bazlı	Index bazlı	Index bazlı
Query latency (1B log, last 1h)	2-5 sn	0.5-1.5 sn	0.5-2 sn	0.5-1.5 sn
Tipik aylık TCO (10TB)	~3-6K USD	~15-25K USD	~30-60K USD	~12-22K USD

Loki 3.0 sürümüyle gelen TSDB index ve Bloom filtreleri (3.1+ stable), düşük frekanslı string’ler için sorgu süresini %70’e kadar kısaltıyor (Grafana Labs, Loki 3.1 release notes, Şubat 2024). Production deploy için zorunlu üç ayar: per_stream_rate_limit en az 10MB/s, max_chunk_age 2h, ve retention_period her tenant için ayrı.

• Avantaj: Kubernetes Promtail/Alloy entegrasyonu zero-config: pod label’ları otomatik scrape edilir.
• Avantaj: Aynı PromQL benzeri syntax (LogQL) ile metric türetilebilir — sum(rate({app="api"} |~ "ERROR" [5m])).
• Dezavantaj: Cardinality kontrol şart — yanlış label tasarımı (örn. user_id label’lanması) cluster’ı 24 saatte çökertir.
• Dezavantaj: Full-text arama Elasticsearch kadar hızlı değil; security forensics use case’lerinde dikkat.
• Ne zaman seç: Kubernetes-native log toplama, maliyet kritik, label’larla yapısal log üretiyorsunuz.

Tempo: Distributed Tracing’i Sample’siz Yapma Sözü

Tempo’nun pazarda farklılaştığı tek nokta var: “100% trace ingestion”. Jaeger, Zipkin ve çoğu SaaS APM (Datadog APM dahil) head-based sampling ile %1-10 trace toplar; Tempo, label’lı indexleme yapmadığı için %100 trace’i object storage’a yazabilir ve trace ID ile direkt fetch eder. TraceQL (Tempo 2.0+) ile artık span attribute’ları üzerinden discovery query’leri de mümkün — örneğin {resource.service.name="checkout" && duration > 500ms}.

Tempo’nun production performans karakteristikleri (Grafana Labs benchmark, 2024):

Metrik	Tempo 2.6	Jaeger 1.6 + Cassandra	Datadog APM	AWS X-Ray
Sample oranı (varsayılan)	%100	Head-based, ~%1-10	Adaptive, ~%5-25	Reservoir, 1 req/s + %5
Storage backend	S3/GCS/Azure Blob	Cassandra/ES/Kafka	Managed	Managed
Ingest throughput (1 node)	~50-80K span/s	~20-30K span/s	Sınırsız (managed)	Throttled
Query dili	TraceQL	Jaeger UI / API	Native UI	Native UI
OpenTelemetry native	Evet	Adapter ile	Evet	Adapter ile
Aylık 1B span TCO	~1.5-3K USD	~8-15K USD (Cassandra ops dahil)	~20-40K USD	~5-8K USD

Tempo’nun arkasındaki sayısal felsefe: trace verileri %99 oranında okunmaz, sadece incident anında sorgulanır. Bu durumda full-text indexleme maliyeti boşa harcamadır. Tempo bu boşa harcamayı keserek storage’ı ucuzlatır; karşılığında “ad-hoc keşif” yavaştır (TraceQL bir trace’i 1-3 saniyede bulabilir, ama 30 günlük arama 30-60 saniyeye çıkabilir). Metric ve log ile exemplar linkleme (Mimir/Loki → Tempo trace ID derin link) bu sınırlamayı pratikte ortadan kaldırır: önce metric anomalisi görürsün, “Tempo’da aç” tıklarsın, trace ID ile saniyede ulaşırsın.

Mimari Karar: Monolithic, Microservices, ya da Read-Write Split

Mimir, Loki ve Tempo’nun her birinin üç farklı deployment modu vardır ve seçim, ölçek ile operate eden ekibin olgunluğuna göre yapılmalıdır. Yanlış mod seçimi, deploy sonrası 6 ayda %200-400 operasyonel yüke dönüşür.

Mod	Bileşen Sayısı	Önerilen Ölçek	Kubernetes Pod	Operasyonel Yük	Önerilen Senaryo
Monolithic / Single Binary	1	< 100GB/gün log, < 1M aktif seri	1 replica	Düşük	Dev, küçük startup, lab
Simple Scalable (Read/Write)	2-3 (read, write, backend)	100GB-10TB/gün log, 1-10M aktif seri	3-15 replica	Orta	SMB, orta ölçek SaaS
Microservices	8-12	10TB+/gün log, 10M+ aktif seri	30-200+ replica	Yüksek	Multi-tenant platform, telco, fintech

Pratik tavsiye: Helm chart’lar (grafana/mimir-distributed, grafana/loki, grafana/tempo-distributed) microservices modunu varsayılan sunar, ama Ömer Önal olarak müşteri sahasında yürüttüğüm danışmanlıklarda gördüğüm kalıp şudur: ekipler 50 servis altında Simple Scalable mod ile başlamalı, ancak gerçek scaling pain hissettiğinde microservices’e geçmeli. Bu geçiş, doğru zaman seçilirse 1-2 sprint’te tamamlanır; erken yapılırsa 6 ay operasyonel kayıp demektir.

Bu kararı verirken benzer bir tartışma Docker Kubernetes Yönetimi sürecindeki monolitik→microservices geçişle paralel ilerler. Aynı disiplin, observability stack’inin kendisi için de geçerli: erken parçalamayın.

Storage Maliyeti: TCO Hesabı ve SaaS Karşılaştırması

Grafana stack’in en güçlü argümanı maliyettir, ancak “ucuz görünüp pahalıya patlamaması” için TCO hesabını storage + compute + operations olarak üç ayaklı yapmak gerekir. Tipik bir orta ölçek senaryoyu (5TB/gün log, 5M aktif metric seri, 500M span/gün trace) modellersek:

Kalem	Grafana Stack (self-hosted, AWS)	Grafana Cloud (managed)	Datadog (Pro tier)	New Relic (Data Plus)
Log ingestion (5TB/gün, 30g retention)	~3.5K USD (S3 + EC2 ingester)	~6-9K USD	~22K USD	~18K USD
Metric (5M aktif seri, 13ay retention)	~2.8K USD (S3 + Mimir)	~5K USD	~15K USD	~12K USD
Trace (500M span/gün, 7g retention)	~1.2K USD (S3 + Tempo)	~3K USD	~8K USD	~5K USD
Egress ve operations buffer	~2K USD	0 (dahil)	0 (dahil)	0 (dahil)
SRE FTE (operations)	~0.3-0.5 FTE (~5-8K USD)	0.1 FTE (~1.5K USD)	0.1 FTE	0.1 FTE
Aylık toplam	~14-20K USD	~15-19K USD	~45-55K USD	~35-45K USD

Sonuç: self-hosted ile Grafana Cloud benzer maliyette gözükür ama farklı senaryolarda fark açılır. 20TB+/gün log’a ulaştığınızda self-hosted lineer ölçeklenirken Grafana Cloud per-GB fiyatı yarım fiyata indirim almaya başlayarak avantajlı hale gelir. Buna karşılık 1TB/gün altındaki ekipler için Grafana Cloud’un “Free tier”ı (50GB log, 10K seri, 50GB trace dahil) self-hosted’tan ekonomik açıdan üstündür.

Bulut fatura kontrolü konusunda detaylı bir bakış için FinOps Bulut Maliyet ve Kubernetes Cost VPA HPA yazıları, observability altyapısının kendi maliyetini optimize etme prensiplerini Kubernetes düzleminde tamamlar.

OpenTelemetry ile Collector Katmanı: Alloy mi, Otel Collector mı?

2024 sonrası Grafana ekosisteminin en önemli değişikliği Grafana Alloy‘un Promtail, Grafana Agent ve Tempo Agent’ın yerini alması oldu. Alloy, OpenTelemetry Collector’a tam uyumlu (otelcol_* component’leri native destekler) ama River config dili ile fonksiyonel bir DSL sunar. OpenTelemetry Collector ise YAML-only ve daha geniş 200+ receiver/exporter ekosistemine sahiptir.

1. Alloy seç ne zaman: Tüm sinyalleri Grafana stack’e yolluyorsanız, Kubernetes Helm ile basit deploy istiyorsanız, River’ın programlanabilir component graph’ından faydalanmak istiyorsanız.
2. OpenTelemetry Collector seç ne zaman: Multi-vendor (örn. metrik Grafana Cloud, trace Honeycomb, log Splunk) yönlendirme yapıyorsanız, vendor-neutral kalmak stratejik öncelik ise, exotic protocol receiver gerekiyorsa (StatsD, Carbon, Riemann).
3. İkisini aynı anda kullan ne zaman: Edge’de Alloy (Kubernetes per-node DaemonSet), regional aggregation katmanında OpenTelemetry Collector. Bu hibrit pattern hyperscale ortamlarda yaygındır.
4. Hiçbiri olmasın ne zaman: Direkt SDK push (Prometheus remote_write client, OTLP exporter app-side) — küçük servislerde işe yarar ama gözlemlenebilirlik veri akışını uygulama kodundan ayırmak best practice’tir.

OTLP (OpenTelemetry Protocol) artık Grafana stack’in resmi default ingest protokolüdür: Mimir 2.10+ OTLP/HTTP, Loki 3.0+ OTLP logs, Tempo 2.x OTLP native receiver olarak işlev görür. Bu birleşik protokol, vendor migration’ı tek endpoint değişikliğine indirir.

Production Operations: Backup, DR ve Cardinality Disiplin

Grafana stack’i ayakta tutmanın görmezden gelinen üç pratik problemi vardır: cardinality patlaması, object storage versioning/replication, ve query path P99 latency. Her biri için kanıtlanmış kontroller mevcuttur:

• Cardinality limitleri: Mimir’de max_global_series_per_user ve max_global_series_per_metric ayarla; Loki’de max_streams_per_user 100K-250K aralığında tut. Aksi halde tek bir buggy deployment 1 saatte ingester memory’i bitirir.
• S3 lifecycle policy: Mimir blocks 13 ay sonra Glacier’a, Loki chunks 90 gün sonra Glacier Deep Archive’a; bu transition GB başına ek 0.004 USD/ay maliyet karşılığı %95 storage tasarrufu sağlar.
• Multi-AZ replication: S3 default Multi-AZ; ancak query performansı için ingester ve store-gateway’ler aynı AZ’de scheduling — topologySpreadConstraints ile zorla.
• Query frontend cache: Redis veya Memcached ile query-frontend cache (default kapalı); açılınca aynı dashboard’un 5 dakikalık refresh’inde Mimir query yükü %60-80 düşer.
• Alert tasarımı: Mimir Ruler ile alert kurarken for: 5m minimum — Prometheus-style flapping engellenir; PagerDuty/OpsGenie noise %40-60 azalır (Datadog State of DevOps 2024 raporundaki tipik aralık).
• DR drill: Object storage region failover senaryosu çeyrekte bir kez gerçek test; aksi halde “S3 multi-region replication kuruldu” yazısı kağıt üstünde kalır.

CI/CD entegrasyonu için Grafana stack ve CI/CD Pipeline Kurulumu‘ndaki pratikler birlikte uygulanmalı: alert rule’ları, dashboard’lar ve provisioning grafana-as-code (Jsonnet, Terraform Grafana provider) ile versionable hale getirilmeli; GitOps Kubernetes akışına dahil edilmeli. Production değişiklik audit trail’i ancak böyle kapatılır.

Güvenlik ve Compliance: Multi-Tenant Stack’te İzolasyon

Grafana stack’in multi-tenancy modeli HTTP header (X-Scope-OrgID) tabanlıdır; bu tasarım kolaylık sağlar ama yanlış kurulumda tenant verisi sızıntısı riskine açıktır. Production’da uygulanması gereken kontroller:

• Reverse proxy ile tenant header enforcement: Nginx/Envoy/Istio katmanı her isteğe doğru X-Scope-OrgID‘yi enjekte etmeli, kullanıcı bunu override edememeli.
• S3 bucket policy: Mimir/Loki/Tempo’nun IAM rolü yalnız belirli prefix’lere yazsın; s3:DeleteObject compactor dışında yasak.
• mTLS: Cluster-içi gRPC trafiği (distributor↔ingester) mTLS ile şifrelensin — service mesh kullanıyorsanız Istio/Linkerd otomatik halleder.
• PII redaction: Alloy/Otel Collector pipeline’da transform processor ile email, IP, credit card pattern’lerini Loki’ye iletmeden önce hash’le veya kes.
• Audit log: Grafana Enterprise audit log feature flag’i; OSS sürümde reverse proxy access log + structured logging yedek.

Bu kontroller DevSecOps Shift-Left ve Service Mesh uygulamalarıyla doğal olarak entegre olur. CNCF Security TAG’ın 2024 tarihli “Observability stack threat model” dokümanı bu tehdit sınıflarını detaylandırır ve Grafana stack için bir baseline checklist sunar.

SSS: Grafana Stack 2026 İçin Sık Sorulan Sorular

Sonuç

Grafana stack 2026’da artık deneysel bir alternatif değil, açık kaynak observability’nin de facto referans mimarisi. Mimir, Loki ve Tempo’nun ortak object-storage tabanlı tasarımı, SaaS APM çözümlerine kıyasla 3-5x TCO avantajı sağlıyor; karşılığında ekibin yığın üzerinde belirli bir mühendislik derinliği geliştirmesi gerekiyor. Karar çerçevesi şudur: 50+ servis, 1TB+/gün log, ve en az 0.3 FTE platform kapasitesi olan organizasyonlar için Grafana stack stratejik kazanım; bu eşiklerin altındakiler için Grafana Cloud managed tier veya Datadog gibi SaaS daha düşük toplam efor demek.

Pratik geçiş yolu: önce mevcut Prometheus kurulumunu Mimir’e remote_write ile bağlayıp uzun süreli retention’ı al, ardından log toplama Loki’ye, son aşamada OpenTelemetry instrument’ı ile Tempo. Bu sıralama her aşamada bir yedek (mevcut sistem) bırakır, geri dönüş riski en aza iner. Daha karmaşık platform migration’ları için Cloud Migration Stratejisi yazısındaki “strangler fig” pattern aynı disiplini observability düzleminde kullanmanı sağlar.

Observability mimarinizi sıfırdan tasarlamak ya da mevcut Datadog/New Relic fatura optimizasyonu için bağımsız ikinci görüş arıyorsanız iletişim sayfası üzerinden değerlendirme talep edebilirsiniz; tipik bir engagement 2-4 haftalık discovery + roadmap çıktısıyla sonuçlanır.

Kaynaklar ve referanslar: Grafana Mimir resmi dokümantasyonu, Grafana Loki dokümantasyonu, Grafana Tempo dokümantasyonu, OpenTelemetry OTLP spesifikasyonu, CNCF Annual Survey 2024, GitHub: grafana/mimir repository, AWS S3 official pricing.