1. Giriş: Gözlemlenebilirlik 1.0’dan 2.0’a Geçiş
Geleneksel izleme (monitoring) sistemleri, önceden tanımlanmış metrikler ve statik panolar üzerinden “bilinen bilinmeyenleri” takip etmek üzerine kurgulanmıştır. Ancak modern mikroservis mimarileri ve dağıtık sistemler, “Yüksek Kardinalite” (High Cardinality) problemiyle bu yapıyı işlemez hale getirmiştir. Gözlemlenebilirlik 1.0 dünyasında metrikler, her yeni boyut eklendiğinde “kardinalite patlamasına” yol açarak maliyetleri artırırken, sistemdeki karmaşık “bilinmeyen bilinmeyenleri” açıklamakta yetersiz kalmaktadır.
Observability 2.0, odağı metrik tabanlı kısıtlı yapılardan alıp, yapılandırılmış “Geniş Olaylar” (Wide Events) ve “Kanonik Loglar” (Canonical Logs) felsefesine taşımaktadır. Honeycomb verilerinin de ortaya koyduğu üzere, Observability 2.0’ın temel taşı metrikler değil, zengin bağlam içeren loglardır. Mühendislerin sadece önceden indekslenmiş verilerle kısıtlı kalmadığı, sistemin o anki durumunu tüm boyutlarıyla yansıtan tek bir geniş olay kaydı üzerinden analiz yapabildiği bu yaklaşım, modern altyapı yönetiminin stratejik zorunluluğudur.
2. Modern Loglama İlkeleri ve Teknik Altyapı
Log verisinin basit bir metin yığınından stratejik bir analiz varlığına dönüşmesi, teknik mimarinin standardizasyonu ile mümkündür. Serbest metin loglar (unstructured logs) sorgulama hızını düşürürken, JSON formatında yapılandırılmış loglama, verinin programatik olarak işlenmesini ve OpenTelemetry (OTel) gibi global standartlarla entegrasyonunu sağlar.
Teknik Mimari ve Güvenlik Standartları:
• Geniş Olay (Wide Event) Yapısı: Bir işlemin tüm yaşam döngüsünü (veritabanı sorgu sayısı, CPU kullanımı, kullanıcı segmenti, coğrafi konum vb.) içeren tek bir zengin kayıt tutulmalıdır.
• Standardizasyon (OpenTelemetry): Log field isimlerinin ve tiplerinin OTel modeline göre standartlaştırılması, servisler arası korelasyonu (Trace ID/Request ID) kusursuz hale getirir.
• Hassas Veri Yönetimi (PII): Kişisel veriler loglanmadan önce “Masking”, “Hashing” veya “Tokenization” teknikleriyle korunmalıdır. Bu, sadece bir tercih değil, KVKK uyumu için teknik bir zorunluluktur.
Örnek Stratejik Geniş Olay (Wide Event) Yapısı:
{
"timestamp": "2025-02-21T14:30:00.123Z",
"level": "INFO",
"trace_id": "5b8ea12e3d7a4c0a",
"span_id": "08e31242",
"service.name": "payment-gateway",
"service.version": "v2.4.1",
"http.method": "POST",
"http.status_code": 201,
"http.duration_ms": 450,
"db.query_count": 3,
"db.duration_ms": 120,
"user.id": "u-99821",
"user.tier": "premium",
"payment.amount": 1500.00,
"payment.currency": "TRY",
"payment.provider": "iyzico",
"resource.container.id": "c-4491",
"resource.host.name": "prod-k8s-node-01",
"resource.region": "tr-east-1",
"exception.type": null,
"app.feature_flag": "new_checkout_flow_enabled",
"app.internal_latency_ms": 30
}
3. Log Örnekleme (Sampling) ve Veri Optimizasyon Stratejileri
Modern sistemlerdeki devasa veri hacmi, depolama maliyetlerini sürdürülemez kılmaktadır. Ancak her logu silmek, adli bilişim (forensics) süreçlerinde ciddi zafiyetler yaratabilir. Bu dengenin kurulması için mimari düzeyde “Akıllı Örnekleme” ve “Kalıp Çıkarma” (Pattern Extraction) yöntemleri kullanılmalıdır.
Log Örnekleme Yöntemleri ve Mimari Katman Analizi:
| Yöntem | Mimari Uygulama Katmanı | Avantajı | Risk / Dezavantaj |
|---|---|---|---|
| Head-based Sampling | Agent / Ingress | Karar anında verilir; bant genişliğini korur. | Önemli/Hatalı işlemleri kaçırma riski yüksektir. |
| Tail-based Sampling | Collector / Backend | İşlem bitince karar verilir; tüm hatalar saklanır. | Geçici depolama ve CPU yükü gerektirir. |
| Adaptive (Dinamik) | Collector | Trafik yoğunluğuna göre oranı ayarlar. | Tahmin edilebilirliği düşüktür; karmaşıktır. |
| Logs-to-Metrics | Edge Delta / OTel | Logdan metrik çıkarıp ham logu atar. | Ham veriye dayalı adli inceleme yapılamaz. |
Stratejik Analiz: Edge Delta gibi modern yaklaşımlar, logları sadece ham veri olarak saklamak yerine onlardan anlamlı metrikler ve kalıplar çıkararak maliyetleri %90 oranında düşürebilmektedir. Örnekleme yaparken “adli bilişim zafiyeti” oluşmaması adına güvenlik ve denetim (audit) logları her zaman %100 oranında saklanmalıdır.
4. Analitik Katman: SIEM, Anomali Tespiti ve Korelasyon
Ham logların proaktif bir güvenlik aracına dönüşümü SIEM (Güvenlik Bilgisi ve Olay Yönetimi) katmanında gerçekleşir. Klasik eşik tabanlı (threshold-based) sistemlerin statik limitleri, dinamik bulut iş yüklerinde “Alarm Yorgunluğu” (Alert Fatigue) yaratarak gerçek tehditlerin gözden kaçmasına neden olmaktadır.
SIEM Proje Metodolojisi (7 Adım):
1. Gereksinim ve Kapsam: Kurumun iş hedefleri ve yasal (5651/KVKK) ihtiyaçlarının belirlenmesi.
2. Kaynak Envanteri: Log üreten tüm varlıkların (Sunucu, DB, Network, SaaS) tespiti.
3. Politika ve Detay: Hangi kaynaktan hangi log seviyesinde (Audit, Debug vb.) veri alınacağının seçimi.
4. Normalizasyon: Ham logların standart bir formata (Etiketleme ve Anlamlandırma) getirilmesi.
5. Gelişmiş Korelasyon: Farklı kaynaklar arası tehdit ağaçlarının (Cyber Kill Chain) kurgulanması.
6. Simülasyon ve Tatbikat: Yazılan kuralların Picus gibi araçlarla test edilerek “False Positive” (Hatalı Alarm) oranının düşürülmesi.
7. Security Dashboard: SOC ekipleri için anomali ve trend odaklı görselleştirme.
Dinamik sistemlerde “Hatalı Alarm” yönetimi stratejik bir içgörüdür. Klasik sistemlerin aksine modern AI/ML sistemleri, sistemin “normal” davranışını öğrenerek sadece sapmalarda (Noktasal, Bağlamsal veya Kolektif) alarm üretmelidir.
5. Yasal Çerçeve ve Uyumluluk: 5651, KVKK ve ISO 27001
Türkiye’deki veri sorumluları için log yönetimi teknik bir ihtiyaçtan ziyade hukuki bir zorunluluktur. 5651 Sayılı Kanun ve KVKK uyarınca logların doğruluğu, bütünlüğü ve gizliliği garanti altına alınmalıdır.
5651 Sayılı Kanun ve Cezai Yaptırım Tablosu:
| Rol | Yükümlülük | Saklama Süresi | Cezai Yaptırım (İdari) |
|---|---|---|---|
| Erişim Sağlayıcı | IP, Port, Kullanıcı trafik bilgisi. | 6 ay – 2 yıl | 10.000 TL – 100.000 TL |
| Yer Sağlayıcı | Barındırılan içeriğe erişim trafik logları. | 1 yıl – 2 yıl | 10.000 TL – 100.000 TL |
| İçerik Sağlayıcı | Kendi ürettiği içerikten sorumludur. | Zorunluluk Yok* | – |
*İstisna: İçerik sağlayıcı, yer sağlayıcı konumuna geçerse (örn: kendi sunucusunda içerik barındırırsa) 1-2 yıl saklama yükümlülüğü başlar.
ISO 27001 ve KVKK Teknik Tedbir Eşleşmesi:
| Teknik Tedbir (KVKK Rehberi) | ISO 27001 Kontrol Maddesi (Ek A) | Açıklama |
|---|---|---|
| Yetki Matrisi / Yetki Kontrol | A.9.2 Kullanıcı Erişim Yönetimi | Kimin hangi veriye eriştiği loglanmalıdır. |
| Erişim Logları / Olay Kayıtları | A.12.4.1 Olay Kaydetme | Sistem olayları değişmez şekilde saklanmalıdır. |
| Silme, Yok Etme, Anonimleştirme | A.8.3.2 Ortamın Yok Edilmesi | Veri yaşam döngüsü politikası uygulanmalıdır. |
| Zaman Damgası ve HASH | A.12.4.3 Günlük Kayıtlarının Korunması | Log bütünlüğü yasal kanıt için mühürlenmelidir. |
6. Log İzleme Araçları ve Seçim Matrisi (2025 Perspektifi)
Kurumsal araç seçiminde “Toplam Sahiplik Maliyeti” (TCO) en kritik metriktir. Geleneksel Splunk veya ELK mimarileri yüksek RAM tüketimi ve karmaşık indeks yönetimiyle maliyetli hale gelmektedir.
Modern Araç Analizi:
• OpenObserve: SQL tabanlı yapısı sayesinde öğrenme eğrisi düşüktür ve mevcut BI araçlarıyla tam uyumludur. S3 uyumlu depolama ve 140x sıkıştırma yeteneğiyle TCO’yu %90’a kadar düşürebilir.
• Datadog: SaaS rahatlığı sunar ancak “Billing Spikes” (beklenmedik fatura artışları) riski yüksektir. Maliyet öngörülebilirliği zayıftır.
• Grafana Loki: “Metadata indexing” felsefesiyle depolama dostudur ancak karmaşık tam metin (full-text) aramalarında performans kaybı yaşatabilir.
• Splunk: SIEM gücü yüksektir ancak lisanslama maliyetleri büyük veri hacimlerinde kısıtlayıcıdır.
Ajan Karşılaştırması: Bulut yerli (cloud-native) ortamlarda derinlemesine görünürlük için Agent-based (EDR/CWPP) yaklaşımlar, API kısıtlamalarından kaçınmak ve düşük gecikme için ise Agentless (API tabanlı) çözümler hibrit bir modelle kurgulanmalıdır.
7. Sonuç: Observability 2.0 İçin Yol Haritası
Log yönetimi artık pasif bir kayıt tutma işlemi değil, operasyonel mükemmelliğin ve hukuki korunmanın temelidir. Kurumlar, loglarını sadece “maliyet” olarak değil, sistemin genetiğini açıklayan “stratejik veri” olarak konumlandırmalıdır.
3 Maddelik Mimari Eylem Planı:
1. Collector Mimarisini Standartlaştırın: OpenTelemetry (OTel) tabanlı bir toplama yapısına geçerek vendor lock-in riskini bertaraf edin ve servisler arası Trace-Log korelasyonunu sağlayın.
2. Veri Yaşam Döngüsünü Tanımlayın: Logları önem derecesine göre Hot (SSD), Warm (Disk) ve Cold (S3/Archive) depolama katmanlarına ayırarak depolama maliyetlerini optimize edin.
3. Yasal Uyumu Otomatize Edin: 5651 ve KVKK gerekliliklerini, logların Collector seviyesinde otomatik olarak zaman damgasıyla imzalandığı ve PII verilerinin maskelendiği bir “otomasyon hattı” (pipeline) haline getirin.
Geleceğin dayanıklı sistemleri, bugünün zengin bağlamlı “geniş olay” stratejisi üzerine inşa edilecektir.
