Gozlemlenebilirlik (Observability) ve Monitoring Strateji Rehberi

Modern yazilim sistemleri dagitik mimariler, mikroservisler ve bulut altyapilari uzerinde calisiyor. Bu karmasiklik, sistemlerin nasil davrandigini anlamayi giderek zorlastiriyor. Geleneksel monitoring yaklasimi artik yeterli degil; daha derinlemesine bir anlayis sunan gozlemlenebilirlik (observability) stratejisine ihtiyac var. Bu rehberde, kurumsal duzeyde bir gozlemlenebilirlik mimarisi olusturmanin temel prensiplerini, araclarini ve en iyi uygulamalarini ele aliyoruz.

Monitoring ve Observability Arasindaki Fark

Monitoring ve observability kavramlari siklikla birbirinin yerine kullanilsa da temel bir fark tasirlar. Bu farki anlamak, dogru stratejiyi belirlemek icin kritiktir.

Monitoring, onceden tanimlanmis metrikleri ve esik degerlerini izleyerek bilinen sorunlari tespit eder. "CPU kullanimi yuzde 90'i asti" gibi onceden belirlenmis kosullara dayali uyarilar uretir. Monitoring reaktif bir yaklasimdir; neyin yanlis gittigini soyler ancak neden yanlis gittigini aciklamakta sinirli kalir.

Observability ise sisteminizin ic durumunu dis ciktilarindan (loglar, metrikler, izler) anlayabilme yetenegidir. Onceden tanimlanmamis sorunlari bile teshis etmenizi saglar. "Neden bu istek 3 saniye surdu?" veya "Bu hata neden sadece belirli kullanicilarda olusuyor?" gibi sorulara yanit bulmanizi mumkun kilar.

Kriter	Monitoring	Observability
Yaklasim	Reaktif	Proaktif ve reaktif
Kapsam	Bilinen sorunlar	Bilinen ve bilinmeyen sorunlar
Veri modeli	Onceden tanimli metrikler	Yuksek kardinaliteli, esnek veri
Soru tipi	"Ne oldu?"	"Neden oldu?"
Arac ornekleri	Nagios, Zabbix	OpenTelemetry, Jaeger, Grafana
Kurulum karmasikligi	Dusuk-orta	Orta-yuksek

Etkili bir strateji her iki yaklasimi da icerir. Monitoring, temel altyapi sagligini izlemek icin vazgecilmezdir; observability ise karmasik sorunlarin kok nedenini bulmak icin gereklidir.

Gozlemlenebilirligin Uc Sutunu

Gozlemlenebilirlik uc temel veri tipine dayanir. Bu sutunlar birlikte kullanildiginda sisteminizin tam bir resmini ortaya koyar.

1. Loglar (Logs)

Loglar, sistemde meydana gelen olaylarin zaman damgali kayitlaridir. Bir istegi islerken olusan her adim, hata mesaji veya uyari logu olarak kaydedilir.

Yapilandirilmis loglama (structured logging), log verilerinin JSON gibi makine tarafindan okunabilir formatlarda uretilmesini ifade eder. Bu yaklasim, log verilerini sorgulanabilir ve analiz edilebilir hale getirir.

{
  "timestamp": "2026-03-05T14:23:01.234Z",
  "level": "ERROR",
  "service": "payment-service",
  "trace_id": "abc123def456",
  "user_id": "usr_7890",
  "message": "Odeme islemi basarisiz",
  "error_code": "GATEWAY_TIMEOUT",
  "duration_ms": 30000
}

2. Metrikler (Metrics)

Metrikler, belirli zaman araliklarinda toplanan sayisal olcumlerdir. CPU kullanimi, istek sayisi, hata orani ve yanit suresi gibi degerler metrik olarak toplanir. Metriklerin en buyuk avantaji, depolama maliyetinin dusuk olmasi ve hizli sorgulanabilmesidir.

Dort temel metrik tipi vardir:

• Counter: Surekli artan degerler (toplam istek sayisi)
• Gauge: Anlik degisen degerler (bellek kullanimi)
• Histogram: Degerlerin dagilimi (yanit suresi dagilimlari)
• Summary: Yuzdelik dilim hesaplamalari (p95 yanit suresi)

3. Izler (Traces)

Dagitik izleme, bir istegin farkli servisler arasindaki yolculugunu takip eder. Her istek benzersiz bir trace ID alir ve servisler arasinda gecerken bu kimlik tasinir. Boylece tek bir istegin hangi servislerden gectigini, her serviste ne kadar sure harcadigini ve nerede hata olustu gunu gorebilirsiniz.

Bir trace, birden fazla span icerir. Her span, istegin belirli bir servis veya islem icindeki yasam dongusunu temsil eder.

OpenTelemetry Standardi ve Enstrumantasyon

OpenTelemetry (OTel), Cloud Native Computing Foundation (CNCF) tarafindan desteklenen ve gozlemlenebilirlik verilerinin toplanmasi, islenmesi ve aktarilmasi icin acik bir standarttir. Vendor-agnostik yapisi sayesinde, tek bir enstrumantasyonla birden fazla backend aracina veri gonderebilirsiniz.

OpenTelemetry'nin temel bilesenleri sunlardir:

• API: Enstrumantasyon icin standart arayuzler
• SDK: Veri toplama, ornekleme ve aktarim islevleri
• Collector: Veriyi alan, isleyen ve farkli hedeflere yonlendiren bagisiz bir bilesen
• Otomatik enstrumantasyon: Kod degisikligi gerektirmeden veri toplayan kutuphaneler

OpenTelemetry Collector mimarisi ozellikle gucludur. Receiver, processor ve exporter katmanlarindan olusan pipeline yapisi sayesinde veri akisini esnek bir sekilde yonetebilirsiniz. Ornegin, ayni veriyi hem Prometheus'a hem Jaeger'a hem de bulut tabanli bir servise ayni anda gonderebilirsiniz.

Enstrumantasyon stratejisi olarak oncelikle otomatik enstrumantasyonu uygulayin, ardindan is mantigi icin onemli noktalara manuel enstrumantasyon ekleyin. Bu yaklasim, minimum eforla maksimum gozlemlenebilirlik saglar.

Log Yonetimi Stratejisi

Kurumsal ortamlarda gunluk milyonlarca satir log uretilir. Bu verilerin etkili bir sekilde toplanmasi, depolanmasi ve sorgulanmasi icin kapsamli bir log yonetimi stratejisi gereklidir.

ELK Stack (Elasticsearch, Logstash, Kibana)

ELK Stack, en yaygin log yonetimi cozumlerinden biridir. Elasticsearch tam metin arama ve analitik motoru olarak calisir, Logstash log verilerini toplar ve donusturur, Kibana ise gorsellestirme ve analiz arayuzu saglar. Genis ekosistem destegi ve olgun toplulugu en buyuk avantajlardir. Ancak yuksek veri hacimlerinde kaynak tuketimi ve operasyonel karmasiklik artabilir.

Grafana Loki

Loki, Grafana Labs tarafindan gelistirilen ve "Prometheus'un loglar icin karsiligi" olarak konumlanan bir cozumdur. Loki, log iceriklerini indekslemek yerine yalnizca etiketleri (label) indeksler. Bu yaklasim depolama maliyetini onemli olcude dusurur. Kubernetes ortamlariyla muhtesem entegrasyonu ve Grafana ile dogal uyumu Loki'yi populer bir secim haline getirir.

Kriter	ELK Stack	Grafana Loki
Indeksleme	Tam metin	Yalnizca etiketler
Depolama maliyeti	Yuksek	Dusuk
Sorgu dili	KQL / Lucene	LogQL
Kurulum karmasikligi	Yuksek	Orta
Tam metin arama	Cok guclu	Sinirli
Kubernetes entegrasyonu	Iyi	Mukemmel

Metrik Toplama ve Gorsellestirme

Prometheus ve Grafana

Prometheus, pull tabanli metrik toplama modeli ile calisir. Hedef servislerin /metrics endpointlerini belirli araliklarla cekerek metrikleri toplar. PromQL sorgu dili ile guclu analiz yapilabilir. Grafana ile birlikte kullanildiginda kapsamli dashboard ve alarm yetenekleri kazanir.

Prometheus kullanirken dikkat edilmesi gereken noktalar:

• Kardinalite kontrolu: Yuksek kardinaliteli etiketlerden (ornegin user_id) kacinin
• Uzun sureli depolama: Prometheus yerel depolamasi sinirlidir; Thanos veya Cortex ile genisletin
• Federasyon: Birden fazla Prometheus ornegini hiyerarsik olarak yapilandirin

Datadog ve Bulut Tabanli Cozumler

Datadog gibi SaaS cozumleri, altyapi yonetimi yukunu ortadan kaldirir ve hizli baslangicci mumkun kilar. Ancak veri hacmi arttikca maliyet onemli bir faktore donusur. Karar verirken ekip buyuklugu, operasyonel kapasite ve uzun vadeli maliyet projeksiyonlarini degerlendirin.

Dagitik Izleme (Distributed Tracing)

Dagitik izleme, mikroservis mimarilerinde sorun teshisi icin vazgecilmez bir yetenektir. Bir kullanici isteginin onlarca servis arasindaki yolculugunu gorsellestirir.

Arac Secenekleri

• Jaeger: Uber tarafindan gelistirilen, olgun ve yaygin kullanilan bir cozum. Kubernetes ortamlari icin hazir operatorleri mevcuttur.
• Grafana Tempo: Loki benzeri bir yaklasimla yalnizca trace ID'leri indeksler. Maliyet etkin depolama saglar ve Grafana ekosistemiyle dogal entegrasyon sunar.
• Zipkin: Twitter tarafindan gelistirilen, basit ve hafif bir dagitik izleme araci.

Dagitik izlemede ornekleme (sampling) stratejisi kritiktir. Tum izleri saklamak maliyet acisindan surdurulebilir degildir. Head-based sampling isteklerin basinda karar verir; tail-based sampling ise tum spanlari topladiktan sonra hata iceren veya yavas izleri secici olarak saklar. Tail-based sampling daha akilli sonuclar verir ancak daha fazla kaynak gerektirir.

SLI, SLO ve SLA Tanimlari

Gozlemlenebilirlik stratejisinin is degeri uretebilmesi icin, olcumlerin somut hedeflere baglanmasi gerekir. Bu noktada SLI, SLO ve SLA kavramlari devreye girer.

SLI (Service Level Indicator): Servis kalitesini olcen spesifik metriklerdir. Ornek: basarili istek orani, p99 yanit suresi, hata orani.

SLO (Service Level Objective): SLI metrikleri icin belirlenen hedef degerlerdir. Ornek: "Basarili istek orani 30 gunluk pencerede yuzde 99.9 olmalidir."

SLA (Service Level Agreement): Musterilerle yapilan resmi anlasmalardir. SLO'larin ihlal edilmesi durumunda tazminat veya ceza kosullarini icerir.

Uygulama adimlari:

1. Kritik kullanici yolculuklarini belirleyin
2. Her yolculuk icin anlamli SLI'lar tanimlayin
3. Gercekci SLO hedefleri belirleyin (yuzde 100 hedeflemekten kacinin)
4. Hata butcesi (error budget) kavrami ile gelistirme ve guvenilirlik arasinda denge kurun
5. SLO ihlallerine yaklasildikca otomatik uyarilar olusturun

Alert Stratejisi ve Alert Fatigue Onleme

Etkisiz bir alarm stratejisi, alarm yorgunluguna (alert fatigue) yol acar. Ekipler surekli gereksiz alarmlarla boguldugunda, gercekten kritik olan alarmlari da gormezden gelmeye baslar.

Alert fatigue onlemek icin uygulanmasi gereken prensipler:

• Semptom bazli alarmlar: Neden yerine sonuca odaklanin. "Disk IO yuksek" yerine "Kullanici istekleri basarisiz" alarmi daha anlamlidir.
• Katmanli alarm yapisi: Bilgilendirme (info), uyari (warning) ve kritik (critical) seviyelerini net olarak ayirin.
• Aksiyona dayali alarmlar: Her alarm bir aksiyon gerektirmelidir. Aksiyon gerektirmeyen alarmlar dashboard'a tasinmalidir.
• Gruplama ve korelasyon: Ayni kok nedenden kaynaklanan birden fazla alarmi gruplandirin.
• Duzeltme runbook'lari: Her alarm icin ne yapilmasi gerektigini anlatan belgeler hazirlayip alarma baglantilarin.

Maliyet Yonetimi

Gozlemlenebilirlik verileri hizla buyur ve depolama maliyetleri kontrolden cikabilir. Maliyet yonetimi stratejisi, gozlemlenebilirlik mimarisinin surdurulebilirligi icin kritiktir.

Strateji	Aciklama	Tasarruf Etkisi
Ornekleme (Sampling)	Tum verileri degil, temsili bir alt kumeyi saklayin	Yuksek
Katmanli depolama	Sicak/ilik/soguk depolama katmanlari kullanin	Orta-yuksek
Log seviyeleri	Produksiyon ortaminda yalnizca WARN ve ustu	Orta
Metrik kardinalitesi	Yuksek kardinaliteli etiketleri sinirlandin	Orta
Veri saklama suresi	Veri tipine gore farkli saklama politikalari	Yuksek
Toplulastirma	Eski verileri dakikalik/saatlik ortalamalar haline getirin	Orta

Pratik bir kural olarak: detayli verileri 7 ila 14 gun, toplulastirilmis verileri 90 gun, kritik metrikleri ise 1 yil saklamak cogu kurumsal senaryo icin yeterli bir baslangiç noktasidir.

Mikroservis Ortaminda Observability Zorluklari

Mikroservis mimarileri, gozlemlenebilirlik acisindan monolitik sistemlere kiyasla cok daha karmasik zorluklar ortaya koyar.

Servis kesfetme ve bagimliliklarin haritalanmasi: Onlarca veya yuzlerce servisin birbirleriyle nasil etkilestigini otomatik olarak kesfetmek ve gorsellestiremek gerekir. Servis mesh cozumleri (Istio, Linkerd) bu konuda dogal gozlemlenebilirlik yetenekleri sunar.

Baglam yayilimi (context propagation): Trace ID, baggage header ve korelasyon bilgilerinin tum servisler arasinda eksiksiz tasinmasi gerekir. Bir servisteki enstrumantasyon eksikligi, tum izleme zincirini kirar.

Poliglot ortamlar: Farkli programlama dilleriyle yazilmis servislerin tutarli enstrumantasyonu zorlayicidir. OpenTelemetry'nin coklu dil destegi bu sorunu onemli olcude hafifletir.

Efemeral altyapi: Konteynerlerin ve pod'larin surekli olusup yok olmasi, geleneksel host bazli izleme yaklasimlarini gecersiz kilar. Etiket tabanli (label-based) bir izleme stratejisi benimsemek gerekir.

Kurumsal Observability Olgunluk Modeli

Organizasyonlar gozlemlenebilirlik yolculugunda farkli olgunluk seviyelerinde bulunur. Bu modeli kullanarak mevcut durumunuzu degerlendirebilir ve gelisim yol haritanizi belirleyebilirsiniz.

Seviye 1 - Temel Monitoring: Altyapi metrikleri izlenir (CPU, bellek, disk). Loglar dosya sisteminde saklanir. Manuel sorun giderme yapilir.

Seviye 2 - Merkezi Log Yonetimi: Loglar merkezi bir platformda toplanir. Temel dashboardlar olusturulur. Basit alarm kurallari tanimlanir.

Seviye 3 - Dagitik Izleme: Trace verileri toplanir ve servisler arasi akislar gorsellestirilir. SLI ve SLO tanimlari yapilir. Yapilandirilmis loglama standartlastirilir.

Seviye 4 - Proaktif Observability: Hata butcesi yonetimi uygulanir. Anomali tespiti ve tahmine dayali uyarilar etkinlestirilir. Maliyet optimizasyonu yapilir.

Seviye 5 - AIOps ve Otomasyon: Makine ogrenimi ile kok neden analizi otomatiklestirilir. Kendi kendini iyilestiren sistemler devreye alinir. Is metrikleri ile teknik metrikler korelasyona alinir.

Sonuc ve Oneriler

Etkili bir gozlemlenebilirlik stratejisi, yazilim sistemlerinin guvenilirligi ve operasyonel verimlilik icin temel bir yatirimdir. Basarili bir uygulama icin su adimlari onceliklendirmenizi oneriyoruz:

1. OpenTelemetry ile baslatin: Vendor bagimsiz enstrumantasyon, gelecekte arac degisikligini kolaylastirir.
2. SLO'lari is gereksinimleri ile hizalayin: Teknik metrikler is degeri uretmelidir.
3. Kademeli olgunlasmayi hedefleyin: Her seyi bir anda yapmaya calismak yerine, olgunluk modelinde kademeli ilerleme planlayin.
4. Maliyet kontrolunu bastan planlain: Veri hacmi ve saklama politikalarini erken asamada belirleyin.
5. Kulturel degisimi destekleyin: Gozlemlenebilirlik yalnizca bir arac meselesi degil, muhendislik kulturu meselesidir.

Smart Maple olarak, Ankara merkezli yazilim gelistirme sureclerimizde gozlemlenebilirlik prensiplerini en basindan itibaren projelerimize entegre ediyoruz. Dagitik sistemlerin karmasikligi arttikca, gozlemlenebilirlik stratejisine yapilan yatirim kendini hizla geri oduyor.