KURUMSAL EĞİTİM, GRAFANA STACK (PROMETHEUS, GRAFANA)

GRAFANA STACK — PROMETHEUS, LOKI, TEMPO VE MIMIR İLE UÇTAN UCA GÖZLEMLENEBİLİRLİK

2021 yılında Grafana Labs, Loki (log), Grafana (görselleştirme), Tempo (trace) ve Mimir (metrik) bileşenlerini LGTM Stack adı altında birleştirdi. Bugün Grafana Stack; Booking.com, Bloomberg, Deutsche Telekom ve Shopify gibi dünyaca tanınan şirketlerin milyarlarca metriği ve log satırını gerçek zamanlı izlediği, endüstrinin fiili açık kaynak gözlemlenebilirlik standardına dönüşmüş bir platformdur. GitLab'ın kendi izleme altyapısında Grafana+Prometheus+Loki üçlüsünü tek bir dashboard'da konsolide etmesi, bu stack'in kurumsal üretimdeki kararlılığını simgeler.

Gözlemlenebilirliğin (observability) üç sütunu — metrikler, loglar ve trace — ayrı araçlarda yaşadığında gerçek bir incident sırasında "bu API neden yavaşladı?" sorusu yanıtsız kalır. Grafana Stack'in gücü tam burada ortaya çıkar: Prometheus metriğinden anormal bir spike tespit edilir, Exemplar ile ilgili Tempo trace'e atlanır, trace ID üzerinden Loki'de ilgili log satırları korelasyonlu sorgulanır ve kök neden dakikalar içinde tespit edilir; üç araç, tek bir Grafana Explore ekranında konuşur.

Bu eğitim; Prometheus veri modeli ve PromQL, Alertmanager routing ve burn rate alert, Loki label-based indexing ve LogQL, Promtail/OTel Collector log pipeline, Tempo distributed tracing ve Exemplar korelasyonu, Mimir ile uzun vadeli yüksek ölçekli metrik depolama, Grafana dashboard tasarımı ve provisioning, OpenTelemetry ile dil agnostik enstrümantasyon, SLO/Error Budget izleme ve güvenlik sertleştirmesi konularını production senaryolarıyla ele alır.

Her modül gerçek hands-on lab ile pekiştirilir: PromQL sorgusu yazılır, Alertmanager'a Slack routing yapılandırılır, LogQL ile log-based metrik üretilir, Tempo üzerinde dağıtık trace analiz edilir, Grafana provisioning YAML ile GitOps'ta dashboard versiyonlanır. Eğitim sonunda katılımcılar, sıfırdan kurumsal bir observability platformu inşa eden ve SRE ekiplerinin güvendiği Grafana Stack mimarisini production'da işletebilen mühendisler olarak ayrılır.

EĞİTİM HEDEFİ

Eğitim sonunda katılımcılar; Prometheus veri modelini (metric, label, time series) açıklar ve pull-based scrape mimarisini yapılandırır; Counter, Gauge, Histogram, Summary metrik tiplerini doğru senaryoda kullanır; PromQL ile rate(), irate(), histogram_quantile(0.99), topk(), sum by() sorguları yazar; Recording Rule ile sık kullanılan SLO hesaplamalarını önceden hesaplar; Alertmanager ile grouping, routing, inhibition ve silence yapılandırır, Slack/PagerDuty/Webhook bildirim kanalı entegre eder; multi-window burn rate alert (5% 1h + 2% 6h) ile SLO Error Budget izleme kurar; Prometheus Kubernetes Service Discovery ve relabeling ile dinamik hedef keşfi yönetir; Node Exporter, kube-state-metrics ve custom exporter ile çok katmanlı metrik toplama inşa eder; Loki'yi label-based indexing mimarisiyle yapılandırır; Promtail ve OTel Collector ile Kubernetes pod loglarını etiketli toplar; LogQL ile log stream selector, pipe filter ve JSON/logfmt parser yazar; log-based metrik ile log deseninden sayaç/histogram üretir; Tempo'yu distributed tracing backend olarak Kubernetes'te çalıştırır; OpenTelemetry SDK ile uygulama enstrümantasyonu yapar ve trace'i Tempo'ya iletir; Exemplar ile metrik spike'tan ilgili trace'e direkt atlama yapar; Metric-Log-Trace üçlüsünü Grafana Explore'da korelasyonlu inceler; Grafana'da değişken (template variable) bazlı dinamik dashboard tasarlar; Grafana provisioning YAML ile dashboard ve datasource'u GitOps'ta versiyonlar; Mimir/Thanos ile uzun vadeli metrik depolama ve yatay ölçekleme kurar; Grafana RBAC, OAuth/OIDC SSO ve TLS ile güvenlik sertleştirmesi uygulayabilir hale gelir.

EĞİTİM İÇERİĞİ

1. GÖZLEMLENEBİLİRLİK (OBSERVABILITY) TEMELLERİ VE LGTM STACK MİMARİSİ

• Observability vs Monitoring Farkı: Monitoring: önceden bilinen soruları yanıtlar (CPU > %90?); Observability: bilinmeyen soruları yanıtlar (bu servis neden yavaşladı?); observability'nin üç sütunu: metrik + log + trace; WHITE-BOX monitoring (iç sistem verisi) vs BLACK-BOX monitoring (dış davranış); cardinality: yüksek kardinaliteli etiket neden sorun yaratır; USE (Utilization, Saturation, Errors) ve RED (Rate, Errors, Duration) metodolojileri; Dört Altın Sinyal: Latency, Traffic, Errors, Saturation.
• LGTM Stack Genel Mimarisi: Loki (log aggregation) + Grafana (visualization) + Tempo (distributed tracing) + Mimir/Prometheus (metrics) bileşen rolü; bileşenler arası veri akışı: OTel Collector → Prometheus/Loki/Tempo → Grafana; Grafana datasource kavramı: tek dashboard'da çoklu backend; Exemplar: metrik ile trace arasındaki köprü; hands-on: docker-compose ile lokal LGTM stack kurulumu ve ilk dashboard'a bağlanma.
• Kubernetes Observability Gereksinimleri: Dinamik pod yaşam döngüsü ve izleme zorluğu: container ölüp yerine yenisi geldiğinde metrik sürekliliği; Kubernetes metadata (namespace, pod, container, label) ile metrik zenginleştirme; cluster seviyesi: node, kubelet, API server metrikleri; workload seviyesi: deployment, pod, container metrikleri; network seviyesi: CNI plugin metrikleri; kube-state-metrics vs metrics-server: fark ve kullanım alanı.

2. PROMETHEUS: METRİK TOPLAMA, VERİ MODELİ VE EXPORTER MİMARİSİ

• Prometheus Veri Modeli ve Mimari: Pull-based scrape: Prometheus hedefe gider, hedefe gelmeyi beklemez; neden pull tercih edilir: network topolojisi ve firewall uyumu; TSDB (Time-Series Database): her zaman serisi metric_name + label set ile tanımlanır; scrape_interval ve evaluation_interval; Prometheus bileşenleri: Server, Alertmanager, Pushgateway, Exporter; Pushgateway anti-pattern: yanlış kullanım senaryoları; federation: büyük kurumda hiyerarşik Prometheus; remote write/read: uzak backend'e metrik gönderme.
• Metrik Tipleri ve Doğru Kullanımı: Counter: monotonik artan sayaç — asla azalmaz, restart'ta sıfırlanır; rate(counter[5m]) ile anlık hız hesabı; Gauge: anlık değer — memory, temperature, queue size; Histogram: gözlem değerlerini bucket'lara dağıtır; histogram_quantile(0.99, ...) ile p99 hesabı; _bucket, _count, _sum suffix'leri; Summary: istemci tarafında yüzdelik dilim hesabı, dezavantajları; hangi tipte hangi veri: request latency → Histogram, concurrent connections → Gauge, total requests → Counter.
• Exporter Ekosistemi ve Kubernetes Service Discovery: Node Exporter: /proc ve /sys üzerinden host metrikleri (CPU, memory, disk, network, filesystem); kube-state-metrics: Kubernetes objelerinin durumunu metriğe döker (pod phase, deployment replicas, PVC bound); cAdvisor: container kaynak tüketimi (GKE/EKS'de kubelet içinde yerleşik); Kubernetes Service Discovery: role=pod, role=service, role=endpoints, role=node; relabeling: scrape önce label dönüşümü ve filtreleme; keep/drop ile gereksiz hedefleri eleyerek scrape yükü azaltma; custom exporter yazımı: Python prometheus_client ile HTTP server'lı exporter.
• Recording Rules ve Alerting Rules: Recording Rule: sık kullanılan PromQL ifadesini önceden hesapla ve yeni metrik olarak kaydet; SLO availability recording rule: sum(rate(http_requests_total{code=~"2.."}[5m])) / sum(rate(http_requests_total[5m])); Alerting Rule: PENDING → FIRING geçiş süresi (for:); alert annotation ve label'ların Alertmanager routing'e etkisi; alert template: Go template ile dinamik alert mesajı; rule dosyası versiyonlama ve prometheus --check-rules doğrulama.

3. PROMQL: SORGULAMA DİLİ VE İLERİ SEVİYE ANALİZ

• PromQL Temel Yapıları: Instant vector vs range vector farkı; label matcher: = (eşit), != (eşit değil), =~ (regex), !~ (regex değil); Instant vector aritmetiği: metrikler arası bölme, çarpma; Binary operator eşleştirme: on(), group_left(), group_right() ile çok-to-bir join; scalar: tek sayısal değer; String: sınırlı kullanım alanı; offset modifier: geçmiş değerle karşılaştırma (X[5m] offset 1h).
• PromQL İleri Fonksiyonlar: rate(): counter'ın saniyedeki artış hızı (büyük window başına önerilir); irate(): son iki örnekten anlık hız (spike tespiti); increase(): belirtilen aralıkta toplam artış; histogram_quantile(φ, le_buckets): p50/p95/p99 gecikme hesabı; predict_linear(): trend extrapolation ile disk doluluk tahmini; absent(): beklenen metrik gelmezse alarm (deadman switch); topk(N, expr) ve bottomk(): en yüksek/düşük N serisi; changes(): time series'de değer kaç kez değişti; resets(): counter kaç kez sıfırlandı.
• SLO Error Budget Burn Rate PromQL: Availability SLI: sum(rate(http_requests_total{code!~"5.."}[window])) / sum(rate(http_requests_total[window])); Error Budget: 1 - slo_target; Burn Rate: (1 - sli) / (1 - slo_target); multi-window alert: FAST burn (5x hız, 1h window) + SLOW burn (2x hız, 6h window) aynı anda aktif olunca page; Recording Rule ile önceden hesaplanmış burn rate metriği; Grafana SLO dashboardunda burn rate grafiği ve kalan budget göstergesi.

4. ALERTMANAGER VE UYARI YÖNETİMİ

• Alertmanager Mimarisi ve Konfigürasyonu: Alertmanager'ın rolü: Prometheus'tan gelen alertleri duplicasyon önleyerek yönlendirme; deduplication: aynı alert birden fazla Prometheus'tan gelirse tek bildirim; grouping: ilgili alertleri tek mesajda birleştirme (group_by: [alertname, cluster]); routing tree: root route → child routes kaskad eşleme; receiver türleri: email, Slack, PagerDuty, Opsgenie, Webhook; inhibition: kritik alert aktifken daha düşük öncelikli alerti susturma; silence: bakım penceresi için geçici susturma UI üzerinden.
• Slack ve PagerDuty Entegrasyonu: Slack webhook URL ile receiver konfigürasyonu; Go template ile zengin Slack mesajı: renk, başlık, açıklama, link; PagerDuty service key entegrasyonu; severity etiketine göre routing: critical → PagerDuty, warning → Slack; Grafana OnCall ile Alertmanager entegrasyonu: on-call schedule ve eskalasyon politikası; alert yorgunluğu (fatigue) önleme: her alertin actionable olması prensibi; dead man's switch: cluster down olduğunda bildirim gelmezse alarm.
• Grafana Alerting ve Unified Alerting: Grafana 9+ Unified Alerting: tek yerden Prometheus, Loki, Tempo, Graphite kaynaklarından alert; alert rule: PromQL/LogQL sorgusu + threshold + pending duration; contact point: Slack, email, webhook kanalları; notification policy: alert label eşleşmesine göre contact point routing; Grafana alert vs Prometheus alert: hangisi ne zaman kullanılır; alert instance: her label kombinasyonu ayrı alert; mute timing: düzenli sessizlik penceresi (örn. hafta sonu).

5. LOKİ: LOG AGREGASYONU VE LOGQL SORGULAMA

• Loki Mimarisi ve Label-Based Indexing: Loki'nin tasarım felsefesi: "Prometheus ama loglar için"; sadece label'lar indekslenir, log içeriği indekslenmez — bu neden ölçeklenebilirlik ve maliyet avantajı sağlar; Loki bileşenleri: Distributor (ingestion), Ingester (bellek buffer + WAL), Querier (okuma), Compactor (sıkıştırma), Ruler (alert/record rule); monolithic vs microservices mode; object storage backend: S3, GCS, Azure Blob; chunk format: Snappy sıkıştırma; schema_config ve period_config ile veri organizasyonu.
• Promtail ve OTel Collector ile Log Toplama: Promtail: Kubernetes node'unda DaemonSet olarak çalışır, /var/log/pods/ altını scrape eder; scrape_config → pipeline_stages → labels ile log etiketleme; pipeline aşamaları: match, regex, json, labels, timestamp, output; multiline handling: çok satırlı stack trace birleştirme; OTel Collector log receiver: filelog receiver ile dosya bazlı log toplama; Kubernetes metadata enrich: k8sattributes processor ile pod/namespace/container etiketi ekleme; Loki exporter: OTel'den Loki'ye log iletimi.
• LogQL: Log Stream Selector ve Pipeline Filter: Log stream selector: {job="vebende-api", namespace="production"} ile log akışı seçimi; log pipeline: |= (içerir), != (içermez), |~ (regex), !~ (regex değil); JSON parser: | json ile structured log field çıkarımı; logfmt parser: | logfmt ile key=value format ayrıştırma; pattern parser: | pattern ile serbest format extraction; label filter: | level="error" ile parser sonrası filtreleme; line_format template: çıktı formatını özelleştirme; unwrap: label değerini sayısal metriğe çevirme.
• LogQL Metrik Sorguları ve Log-Based Metrics: count_over_time: belirli pencerede log satırı sayısı; rate: saniyedeki log hızı; sum by ile aggregation: sum(rate({job="api"}[5m])) by (namespace); bytes_over_time ve bytes_rate: log hacmi; quantile_over_time: log içindeki sayısal değerin yüzdelik dilimi; log-based Prometheus metrik: Loki ruler ile recording rule → remote write → Prometheus; log-based alert: LogQL + Loki ruler ile doğrudan Alertmanager; Grafana Loki datasource: Logs panel ve Explore'da log arama ve anormallik görselleştirme.

6. TEMPO VE DAĞITIK TRACING

• Distributed Tracing Temelleri: Neden distributed tracing: bir API isteği 15 mikroservisten geçebilir, hangisi yavaşlattı?; Trace: istekle başlayan işlemin tüm servislerdeki iz kaydı; Span: tek bir servisteki operasyonun başlangıç ve bitiş zamanı; Trace ID: tüm servislerde aynı request'i birbirine bağlayan tekil kimlik; Parent-Child span ilişkisi ve gantt-chart görünümü; sampling: head-based (istek başında karar) vs tail-based (sonuç bilinince karar); sampling oranı: production'da %1-10 önerilir.
• OpenTelemetry SDK ile Enstrümantasyon: OTel SDK: Java, Python, Go, .NET, Node.js için resmi kütüphaneler; Tracer Provider ve TracerConfig başlatma; Span oluşturma: manuel ve otomatik enstrümantasyon; Span attribute: request.method, http.status_code, user.id ile zenginleştirme; Span event: span içinde nokta olayı kaydetme; Span status: ERROR ile hata işaretleme; Context Propagation: W3C TraceContext header ile servisler arasında trace ID taşıma; B3 propagation: Zipkin uyumlu eski format; OTel auto-instrumentation: agent ile sıfır kod değişikliği.
• Tempo Mimarisi ve Grafana Entegrasyonu: Tempo bileşenleri: Distributor, Ingester, Querier, Compactor; object storage backend'de trace depolama: S3/GCS'e taşınmış düşük maliyetli mimari (Elasticsearch'ten fark); trace ID bazlı sorgulama: Tempo "trace search" değil "trace lookup" sistemi; TraceQL: Tempo'ya özgü trace arama dili: {span.http.status_code=500}; Grafana Tempo datasource konfigürasyonu; Grafana Explore'da trace waterfall görünümü; Trace→Log jump: trace detail panelinden tarih+trace ID ile Loki sorgusu; hands-on: Python uygulamasını OTel ile enstrümante et ve Tempo'da trace analiz et.
• Exemplars ile Metrik-Trace Korelasyonu: Exemplar: bir metrik sample noktasına eklenmiş trace ID referansı; Prometheus Histogram Exemplar enable etme; Grafana'da Exemplar görünümü: metrik grafiğindeki servis spike'ına tıkla → ilgili Tempo trace'e uç; Metric→Trace→Log drill-down: Grafana Explore Split View ile aynı anda üç panel; trace ID ile Loki korelasyonu: {traceID="abc123"} log sorgusu; kök neden analizi iş akışı: P99 latency spike → exemplar → trace → log → hatalı veritabanı sorgusu tespiti.

7. GRAFANA DASHBOARD TASARIMI VE PROVISIONING

• Grafana Panel Tipleri ve Dashboard Anatomisi: Time series: zaman eksenli metrik grafik; Stat: tek değer büyük gösterge; Gauge: hedef oranı görsel; Bar chart: kategorik karşılaştırma; Heatmap: latency dağılımı ve yoğunluğu; Logs panel: Loki log akışı; Node Graph: servis topoloji haritası; Table: çok boyutlu veri; Geomap: coğrafi dağılım; Dashboard panel repeat: tek paneli çoklu servis için çarpıklıkla yeniden kullan; override: panel içinde belirli seriye farklı renk ve biçim uygulama.
• Template Variables ile Dinamik Dashboard: Query variable: Prometheus label_values() ile dinamik seçim listesi; Custom variable: sabit değer listesi; Constant variable: dashboard-wide sabit değer; Interval variable: zaman dilimi seçimi; Multi-value ve 'All' seçeneği ile çoklu seçim; nested variable: namespace değişkeni → pod listesi değişkeni bağımlılığı; variable hide: URL parametresi ile daraltılmış dashboard paylaşımı; hands-on: namespace + deployment + pod üçlü değişkenli Kubernetes workload dashboard.
• Grafana Provisioning ve GitOps: provisioning/datasources YAML: Datasource otomatik yapılandırma; provisioning/dashboards YAML: dashboard dizini ile otomatik import; dashboard JSON model: her panelin complete tanımı; Terraform Grafana provider: grafana_dashboard, grafana_data_source, grafana_alert_rule resource; Grafana Grizzly (grr) CLI ile dashboard GitOps yönetimi; dashboard versiyonlama: Grafana history ve diff görünümü; folder organizasyonu: platform, uygulamalar, iş metrikleri segmentasyonu; community dashboard: grafana.com/grafana/dashboards'dan import.
• Grafana RBAC ve Güvenlik: Organization ve Team yapısı; Role: Viewer, Editor, Admin, Server Admin; data source permission: takıma göre datasource erişim kısıtı; dashboard permission: klasör bazlı erişim; Grafana OAuth 2.0 SSO: Google, GitHub, Azure AD, Keycloak entegrasyonu; SAML entegrasyonu; auto_assign_org_role ile SSO'dan gelen kullanıcıya otomatik rol; API key ve Service Account: otomasyon için kimlik; Grafana serve TLS: HTTPS ile güvenli erişim; reverse proxy: Nginx ile URL path altında Grafana.

8. PROMETHEUS ÖLÇEKLEME: MİMİR, THANOS VE YÜKSEK ERİŞİLEBİLİRLİK

• Tek Prometheus'un Sınırları: Tek Prometheus: SPOF (Single Point of Failure); long-term storage: varsayılan 15 günlük yerel depolama yetersiz; büyük cluster'da scrape yükü: million-metric ölçeğinde tek Prometheus zorlanır; yatay ölçekleme ihtiyacı: farklı shard'larda farklı hedefler; çok cluster federation: merkezi sorgu noktası; HA için çözümler: Prometheus HA pair + deduplication veya Thanos/Mimir/Cortex.
• Thanos ile Uzun Vadeli Metrik Depolama: Thanos bileşenleri: Sidecar, Store Gateway, Querier, Compactor, Ruler, Receiver; Sidecar: Prometheus'un yanında çalışır, blokları object storage'a yükler; Store Gateway: object storage'dan sorgu cevaplar; Querier: Prometheus ve Store Gateway'den gelen verileri birleştirir (deduplication ile); Compactor: eski blokları birleştirme ve downsampling (5m, 1h resolution); Ruler: global recording/alerting rule yürütme; multi-cluster global view: tek Thanos Querier ile tüm cluster metriklerine erişim.
• Mimir ile Yüksek Ölçekli Production Mimarisi: Mimir: Prometheus uyumlu, yatay ölçeklenebilir metrik backend; Mimir bileşenleri: Distributor, Ingester, Querier, Compactor, Ruler, Alertmanager, Store-Gateway; consistent hashing ile Distributor → Ingester yük dağılımı; zone-aware replication: 3 replica farklı zone'da; object storage backend: S3/GCS/Azure Blob; multi-tenancy: X-Scope-OrgID header ile yapay kiracı ayrımı; Prometheus remote_write → Mimir Distributor → ingestion pipeline; Grafana Cloud'un altındaki managed Mimir mimarisi.

9. DEVSECOPS İZLEME, SLO/ERROR BUDGET VE IaC OTOMATİZASYON

• Kubernetes Güvenlik İzleme: Kubernetes Audit Log: her API server isteğinin audit kaydı; Audit Policy: Level=None, Metadata, Request, RequestResponse; Falco: runtime security — container içi anormal sistem çağrısı tespiti; Falco metrikleri Prometheus'a aktarma; Loki ile audit log toplama: Promtail + Loki Ruler ile yetkisiz pod exec alert; kube-bench ile CIS Kubernetes Benchmark değerlendirmesi; Network Policy ihlali tespiti; PodSecurity alert: privileged container çalışmaya başladığında alarm; RBAC anomali: beklenmedik ClusterRole atama tespiti.
• SLO/Error Budget Production Uygulaması: Prometheus SLO konfigürasyonu: Pyrra veya sloth CLI ile SLO YAML → Recording/Alerting rule; sloth generate komutu ile SLO kurallarını otomatik oluşturma; multi-burn-rate alert page/ticket eşiği kararı; Grafana SLO dashboard: availability, latency p99, error rate; Error Budget panel: kalan bütçe ve günlük tüketim hızı; SLO uyarı yorgunluğu: page sayısını azaltmak için alert tuning; SLO review: haftalık ekip toplantısında SLO kaçırmalarının değerlendirmesi.
• Monitoring Stack IaC ve CI/CD Entegrasyonu: Helm kube-prometheus-stack chart ile Prometheus+Alertmanager+Grafana+Exporters tek komutta dağıtım; Helm values.yaml ile production yapılandırması override; helmfile ile çok ortam (dev/staging/prod) yönetimi; Terraform Helm provider ile stack dağıtımı; ArgoCD Application ile GitOps kube-prometheus-stack; Prometheus Operator: ServiceMonitor, PodMonitor, PrometheusRule, AlertmanagerConfig CRD'leri; ServiceMonitor ile otomatik uygulama scrape: yeni deployment → otomatik metrik toplama; CI pipeline'da promtool check-rules ile alert kural doğrulama; dashboard JSON değişikliği → PR → Grafana provisioning otomatik güncelleme.

10. KAPASİTE PLANLAMA, PERFORMANS ANALİZİ VE KAPSAMLI PROJE

• Kapasite Planlama ve Rightsizing: predict_linear() ile disk doluluk tahmini: "N gün sonra disk dolacak" alert; CPU throttling tespiti: container_cpu_cfs_throttled_periods_total/container_cpu_cfs_periods_total > 0.25; OOMKill izleme: kube_pod_container_status_last_terminated_reason{reason="OOMKilled"}; resource request/limit uyumu: VPA recommendation ile rightsizing; idle node tespiti: kullanılmayan node pool maliyet; HPA scaling event izleme: kube_horizontalpodautoscaler_status_current_replicas delta; load test + monitoring: k6 ile yük uygula, Grafana'da real-time gözlem, bottleneck tespiti.
• Performans Sorun Tespiti ve Kök Neden Analizi: CPU steal: node_cpu_seconds_total{mode="steal"} ile hipervizör kaynaklı CPU kaybı; Disk IO bottleneck: node_disk_io_time_seconds_total ve await süresi; Network congestion: node_network_receive_drop_total/transmit_drop; Memory pressure: node_memory_MemAvailable_bytes azalma trendi; veritabanı bağlantı havuzu tükenmesi: pg_stat_activity ile bağlantı sayısı metriği; lock contention: application custom metrik; korele analiz iş akışı: Grafana Explore'da metrik → trace → log drill-down ile kök neden izolasyonu.
• Kapsamlı Final Projesi — Production Observability Platform: Katılımcılar gruplar halinde sıfırdan eksiksiz bir observability platformu inşa eder: kube-prometheus-stack Helm dağıtımı; ServiceMonitor ile Python/Go uygulaması scrape; PromQL SLO Recording Rule ve multi-window burn rate alert; Alertmanager Slack+PagerDuty routing; Loki + Promtail Kubernetes log pipeline; LogQL log-based metric ve alert; Tempo + OTel SDK distributed tracing; Exemplar ile metrik-trace korelasyonu; Grafana: SLO dashboard, log panel, trace panel — template variable ile dinamik; provisioning YAML ile GitOps; kapasite planlama: predict_linear() ile disk alert. Sunum ve peer review ile eğitim tamamlanır.

EĞİTİM YÖNTEMİ

• Gerçek Incident Vaka Analizleri: Her modül başında endüstriden gerçek bir izleme sorunu analiz edilir: "Shopify'ın Grafana dashboard'unda ani latency spike'ı nasıl tespit etti?", "GitLab'ın Loki migrasyonunda ne öğrendi?", "Netflix'in Exemplar kullanımı nasıl kök neden tespitini hızlandırdı?" — soyut mimari kararlar gerçek olayların ışığında kavranır.
• Hands-On Lab Odaklı Öğrenim: Her modülün ardından katılımcılar gerçek Kubernetes ortamında lab tamamlar: PromQL sorgusu yazar, Alertmanager routing yapılandırır, LogQL ile log filtreler, Tempo'da trace analiz eder, Grafana dashboard paneli ekler. Eğitim süresinin %60'ı hands-on lab ve live demo'dan oluşur.
• Senaryo Bazlı Sorun Giderme Egzersizleri: Eğitmen kasıtlı olarak bir uygulamaya yük artışı, memory leak veya yavaş veritabanı sorgusu enjekte eder; katılımcılar Grafana'yı kullanarak sorunu tespit etmeli, kök nedeni izole etmeli ve çözüm önerisi geliştirmelidir. Bu gerçekçi baskı ortamı SRE "incident" deneyimini simüle eder.
• Dashboard Tasarım Atölyesi: Katılımcılar küçük gruplar halinde bir servis için SLO dashboard, Kubernetes workload dashboard ve güvenlik izleme dashboard tasarlar; her grubun dashboard'u akran değerlendirmesine sunulur; "bu dashboard bir on-call mühendisine yeterli bağlamı veriyor mu?" sorusuyla kalite pekiştirilir.
• GitOps Provisioning Workshop: Dashboard ve alert konfigürasyonu production'da nasıl versiyonlanır? Katılımcılar Grafana provisioning YAML'ı Git'e commit eder, PR açar, otomatik olarak test ortamına uygulanır. Bu iş akışı "kim ne değiştirdi, neden?" sorusunu cevaplar ve configuration drift'i önler.
• Danışmanlık ve Açık Soru-Cevap: Her gün sonunda katılımcılar kendi kurumlarının observability sorunlarını uzmana yöneltir: mevcut ELK Stack'ten Grafana Stack'e geçiş planı, Prometheus cardinality sorunu, SLO tasarımı veya Loki maliyet optimizasyonu konularında kişisel geri bildirim alır.

HEDEF KİTLE

SRE VE DEVOPS MÜHENDİSLERİ

• Production ortamlarında Prometheus+Grafana ile SLO dashboard ve burn rate alert kurmak, Alertmanager ile çok kanallı uyarı yönetimi yapmak isteyen SRE mühendisleri; kube-prometheus-stack Helm chart ile Kubernetes observability altyapısını eksiksiz dağıtmak ve ServiceMonitor CRD ile uygulamaları otomatik scrape etmek isteyen DevOps mühendisleri; Loki ile log toplanmasını ve LogQL bazlı alert'ları Alertmanager'a entegre etmek isteyen platform mühendisleri.

BACKEND VE PLATFORM GELİŞTİRİCİLERİ

• Yazdıkları servislere Prometheus client kütüphanesi ile custom metrik eklemek, OpenTelemetry SDK ile distributed tracing enstrümantasyonu yapmak ve Grafana'da servis sağlığını görselleştirmek isteyen backend geliştiriciler; mikroservis mimarisinde servisler arası gecikme ve hata analizini Exemplar+Tempo+Loki üçlüsüyle yapmak isteyen yazılım mühendisleri.

YAZILIM MİMARLARI VE TEKNİK LİDERLER

• Kurumsal observability platformunu LGTM Stack üzerinde tasarlamak, Mimir veya Thanos ile uzun vadeli ve yüksek ölçekli metrik mimarisi kurmak isteyen yazılım mimarları; SLO/Error Budget çerçevesini kurumda uygulamak ve DORA metriklerini Grafana dashboard'unda görünür kılmak isteyen engineering managers; ELK Stack'ten Grafana Stack'e migrasyon planlaması yapacak teknik liderler.

BULUT VE KUBERNETES MÜHENDİSLERİ

• GKE, EKS veya AKS üzerinde çalışan cluster'ların node, workload ve network metriklerini Prometheus ile tam kapsayan bir izleme altyapısı kurmak isteyen bulut mühendisleri; Kubernetes Audit Log'unu Loki ile merkezi olarak toplayarak DevSecOps izleme pipeline'ı oluşturmak isteyen güvenlik odaklı mühendisler; Falco runtime security metriklerini Grafana dashboard'unda görselleştirmek isteyen cloud security uzmanları.

VERİ ANALİSTLERİ VE İZLEME UZMANLARI

• İş metriklerini (sipariş sayısı, ödeme başarı oranı, kullanıcı kaydı) Prometheus custom metric olarak toplayarak Grafana business dashboard oluşturmak isteyen veri analistleri; Log analizi için Elasticsearch'ten Loki'ye geçiş değerlendiren, LogQL ile log sorgulama yapabilmek isteyen izleme uzmanları; Grafana'yı karar destek aracı olarak kullanan, dinamik dashboard tasarımı ve annotation ile API anomali korelasyonu yapmak isteyen BI profesyonelleri.

KATILIMCILARDAN BEKLENTİLERİMİZ

• Linux ve Komut Satırı Yetkinliği: Temel Linux komutları: cat, grep, tail -f, ps, netstat; YAML formatını okuyup düzenleyebilmek; curl ile HTTP endpoint'e istek atabilmek; bash betik: döngü, koşul, pipe. Prometheus scrape konfigürasyonu ve Loki Promtail konfigürasyonu YAML tabanlıdır; bu formata aşinalık eğitim verimliliğini doğrudan etkiler.
• Temel Kubernetes Bilgisi: Pod, Deployment, Service, ConfigMap, Namespace kavramlarına aşinalık; kubectl get pods, describe, logs komutlarını kullanabilmek; Helm chart kavramını bilmek (kullanmak yeterli, yazmak zorunlu değil); DaemonSet ve ServiceAccount temel işleyişini anlamak. Eğitim Kubernetes ortamında yürütülür; bu temel olmadan lab'larda verim düşer.
• Temel Ağ ve HTTP Bilgisi: HTTP status kodları: 2xx başarı, 4xx istemci hatası, 5xx sunucu hatası; TCP port, DNS çözümleme ve firewall kavramları; REST API çağrısı: endpoint, header, body; Prometheus pull-based scrape mimarisini anlamak için network erişilebilirlik kavramı kritiktir. Temel Docker bilgisi — container, image, port mapping — faydalıdır.
• Temel Programlama veya Betik Deneyimi: Python, Go, Java, .NET veya benzeri herhangi bir dilde basit program okuyabilmek; kod değişikliği yapmak zorunda kalınmasa da Prometheus client kütüphanesi örneğini ve OTel SDK enstrümantasyonunu anlamak için temel kodlama okuryazarlığı gerekir. Eğitimdeki kod örnekleri Python ve Go ile verilir; her iki dili okuyabilmek yeterlidir.
• Öğrenme Motivasyonu ve Aktif Katılım: Hands-on lab'ları atlamadan tamamlamak; grup tartışmalarına ve peer review'a aktif katılmak; kendi kurumunun gözlemlenebilirlik sorunlarını eğitime taşımak. Grafana Stack; okuyarak değil, yaparak öğrenilen bir platformdur — lab ortamında deney yapma isteği eğitimden alınan değeri doğrudan belirler.