- 01Observability, bir sistemin iç durumunu ürettiği telemetry verilerinden anlayabilme yeteneğidir; temel sinyaller metrics, logs ve traces'tir.
- 02Monitoring önceden tanımlanmış durumları izlemeye odaklanırken observability özellikle öngörülmemiş problemlerde neden sorusunu araştırmayı kolaylaştırır.
- 03Metrics trend ve alarm için, logs olay ayrıntısı için, traces ise dağıtık request'in uçtan uca yolunu anlamak için kullanılır.
- 04OpenTelemetry traces, metrics ve logs için vendor-neutral instrumentation ve collection framework'üdür; kendi başına observability storage/dashboard backend'i değildir.
- 05Küçük ekiplerde başarılı observability daha fazla veri toplamaktan değil, kritik kullanıcı akışları için yüksek sinyalli telemetry, aksiyon alınabilir alerting ve kontrollü retention kurmaktan geçer.
Kısaca
Observability, bir sistemin iç durumunu ürettiği telemetry verilerinden anlayabilme yeteneğidir. Yazılım sistemlerinde bunun temel sinyalleri metrics, logs ve traces'tir. Monitoring bilinen durumları izlemeye odaklanırken observability, özellikle öngörülmemiş problemlerde sistemin neden böyle davrandığını araştırmayı kolaylaştırır. Dynamis Teknoloji, observability'yi dashboard kurmak değil; production sistemine anlamlı telemetry, korelasyon ve aksiyon alınabilir alerting eklemek olarak ele alır.
Observability nedir?
Observability veya gözlemlenebilirlik, bir sistemin dışarı verdiği sinyallerden içeride neler olduğunu anlayabilme kapasitesidir.
Modern application ortamlarında bu sinyaller çoğunlukla şunlardır:
- Metrics
- Logs
- Traces
OpenTelemetry bu üç sinyali vendor-neutral biçimde üretmek, toplamak, işlemek ve farklı backend'lere aktarmak için ortak standartlar ve araçlar sağlar.
Observability'nin amacı daha fazla veri toplamak değildir.
Amaç şu sorulara daha hızlı cevap verebilmektir:
- Sistem yavaşladı mı?
- Hangi servis etkilendi?
- Hata hangi request'te başladı?
- Database mi, network mü, uygulama mı sorunlu?
- Yeni release sonrası ne değişti?
- Sorun tüm kullanıcıları mı etkiliyor?
- Hangi dependency failure yarattı?
Monitoring ile observability arasındaki fark
Monitoring genellikle önceden tanımlanmış sorulara cevap verir.
Örnek:
- CPU %80'i geçti mi?
- Disk doldu mu?
- HTTP 5xx arttı mı?
- Servis down mı?
Observability ise daha geniş bir soru sorar:
Sistem neden böyle davranıyor?
Örneğin p95 latency arttığında monitoring alarm verebilir.
Observability sistemi ise şu yolu takip etmenizi sağlar:
- hangi endpoint yavaşladı
- hangi trace etkilendi
- hangi downstream service gecikti
- hangi database query sürenin çoğunu aldı
- hangi deployment sonrası değişiklik başladı
İki kavram rakip değildir.
Monitoring, observability'nin operasyonel kullanım biçimlerinden biridir.
Metrics nedir?
Metrics, zaman içinde ölçülen sayısal değerlerdir.
Örnek:
- CPU usage
- memory usage
- request rate
- error rate
- latency
- queue depth
- database connection count
Metrics büyük sistemlerde trend ve alarm üretmek için etkilidir.
Ancak tek başına "neden" sorusunu her zaman cevaplamaz.
Örneğin error rate %5 olduysa bunun hangi müşteri akışında, hangi serviste ve hangi request zincirinde oluştuğunu log veya trace ile ilişkilendirmek gerekebilir.
Logs nedir?
Logs, sistem içinde gerçekleşen belirli olayların kayıtlarıdır.
Örnek:
- Kullanıcı login başarısız
- Database connection timeout
- Payment request rejected
- Background job completed
- Application exception
İyi log:
- timestamp
- severity
- service name
- environment
- request/correlation ID
- structured fields
içermelidir.
Serbest metin logları insan tarafından okunabilir olsa da büyük sistemlerde sorgulama ve korelasyon için structured logging daha kullanışlıdır.
Traces nedir?
Trace, tek bir request'in dağıtık sistem içindeki uçtan uca yolunu gösterir.
Örnek:
Kullanıcı API çağrısı yapıyor.
Request şu zinciri izliyor:
API Gateway → User Service → Payment Service → PostgreSQL
Trace bu akıştaki her adımı span olarak gösterebilir.
Böylece toplam latency'nin hangi servis veya dependency üzerinde oluştuğu görülebilir.
Distributed tracing özellikle mikroservis ortamlarında önemlidir.
Span nedir?
Span, trace içindeki tek bir operasyonu temsil eder.
Örneğin:
- HTTP request
- database query
- queue publish
- external API call
bir span olabilir.
Her span tipik olarak:
- başlangıç zamanı
- duration
- status
- attributes
- parent/child ilişkisi
taşır.
Span'lar birbirine bağlandığında request'in uçtan uca trace'i oluşur.
Metrics, logs ve traces nasıl birlikte kullanılır?
En güçlü observability modeli telemetry sinyallerini ayrı dashboard'lar olarak değil, ilişkili veri olarak kullanır.
Örnek incident:
- Metric: p95 latency arttı
- Trace: yavaş request'ler Payment Service'te yoğunlaşıyor
- Span: database query 1.8 saniye sürüyor
- Log: connection pool timeout mesajları var
Bu korelasyon troubleshooting süresini ciddi ölçüde azaltabilir.
Correlation ID neden önemlidir?
Correlation ID, aynı request veya iş akışına ait farklı log kayıtlarını ilişkilendirmek için kullanılabilir.
Örneğin müşteri destek ekibi şu ID'yi paylaşabilir:
req-8f2a91
Bu ID:
- API logunda
- worker logunda
- payment logunda
aynı request zincirini bulmayı kolaylaştırabilir.
Distributed tracing kullanıldığında trace ID benzer korelasyon sağlar.
OpenTelemetry nedir?
OpenTelemetry, Cloud Native Computing Foundation ekosistemindeki açık kaynaklı observability framework'üdür.
Amaç:
- traces
- metrics
- logs
telemetry verisini vendor-neutral biçimde instrument etmek, toplamak ve dışa aktarmaktır.
OpenTelemetry kendi başına:
- dashboard
- long-term storage
- alerting backend
değildir.
Telemetry verisini farklı backend'lere gönderebilir.
Bu sayede uygulama instrumentation'ını tek vendor'a sıkı bağlamamak mümkün olabilir.
OpenTelemetry Collector ne işe yarar?
Collector telemetry verisini almak, işlemek ve farklı backend'lere aktarmak için kullanılabilir.
Basit akış:
Application → OpenTelemetry Collector → Observability backend
Collector üzerinde:
- filtering
- batching
- sampling
- attribute processing
- export
gibi işlemler yapılabilir.
Bu yapı uygulamaların doğrudan her observability vendor'ına ayrı entegrasyon yapma ihtiyacını azaltabilir.
Sampling nedir?
Distributed tracing yüksek trafikli sistemlerde çok fazla veri üretebilir.
Sampling, tüm trace'leri saklamak yerine belirli bir bölümünü seçme yöntemidir.
Örnek:
- normal başarılı request'lerin %5'i
- hata alan request'lerin %100'ü
- çok yavaş request'lerin %100'ü
saklanabilir.
Sampling stratejisi maliyet ile troubleshooting kabiliyeti arasında denge kurar.
Observability maliyeti neden hızla büyür?
Telemetry hacmi doğrudan maliyet oluşturabilir.
Özellikle:
- yüksek log volume
- high-cardinality metrics
- tüm trace'leri saklamak
- uzun retention
maliyeti büyütebilir.
Bu nedenle "her şeyi topla" yaklaşımı sürdürülebilir değildir.
Önce:
- hangi sinyal gerekli
- retention ne kadar
- hangi environment production
- hangi log alanı gerçekten değerli
belirlenmelidir.
High cardinality nedir?
Metric label veya attribute çok fazla benzersiz değer üretiyorsa cardinality yükselir.
Örnek kötü metric label:
- user_id
- request_id
Milyonlarca farklı değer metric sisteminin maliyetini ve performans yükünü artırabilir.
Bu tür yüksek cardinality alanlar genellikle log veya trace için daha uygundur.
SLI nedir?
Service Level Indicator, servisin kullanıcı açısından performansını ölçen göstergedir.
Örnek:
- başarılı request oranı
- p95 latency
- availability
- job success rate
SLI, altyapı metriğinden farklı olabilir.
CPU %40 olması kullanıcı deneyiminin iyi olduğunu garanti etmez.
SLO nedir?
Service Level Objective, belirli SLI için hedef seviyedir.
Örnek:
30 günlük pencerede başarılı request oranı %99,9 veya üzeri
Bu hedef alerting ve engineering priority için kullanılabilir.
SLO'lar iş ve kullanıcı beklentileriyle bağlantılı olmalıdır.
Error budget nedir?
Error budget, SLO hedefi içinde tolere edilebilen başarısızlık miktarını ifade eder.
Örneğin %99,9 availability hedefi yaklaşık %0,1 hata bütçesi bırakır.
Error budget:
- release hızı
- reliability yatırımı
- riskli değişiklikler
arasında karar vermeyi destekleyebilir.
Amaç "downtime hakkını kullanmak" değil, güvenilirlik ile delivery hızını aynı çerçevede yönetmektir.
Alerting nasıl tasarlanmalı?
Her metric için alarm oluşturmayın.
İyi alert:
- kullanıcı etkisi yaratır
- aksiyon alınabilir
- net owner'a sahiptir
- gereksiz tekrar üretmez
Örnek:
Disk %70 oldu
her zaman acil alarm olmayabilir.
Ama:
Disk doluluk 2 saat içinde %100'e ulaşacak
daha aksiyon alınabilir olabilir.
Alert fatigue nedir?
Çok fazla ve düşük kaliteli alarm, ekiplerin gerçek kritik alarmı kaçırmasına neden olabilir.
Alert fatigue belirtileri:
- alarmlar sürekli mute ediliyor
- gece gelen alarm aksiyon gerektirmiyor
- aynı incident için onlarca alarm geliyor
- owner belli değil
Çözüm:
- alert deduplication
- severity standardı
- SLO tabanlı alerting
- doğru threshold
- runbook
olabilir.
Dashboard ne için kullanılmalı?
Dashboard sistemin durumunu hızlı anlamayı sağlamalıdır.
İyi dashboard:
- kullanıcı etkisi
- servis health
- error rate
- latency
- throughput
- saturation
gibi yüksek sinyalli metrikleri gösterir.
Her metric'i tek ekrana koymak görünürlüğü artırmak yerine azaltabilir.
Golden signals nedir?
Google SRE yaklaşımında yaygın kullanılan dört sinyal:
- latency
- traffic
- errors
- saturation
olarak ele alınır.
Bu model başlangıç dashboard'u için yararlı olabilir.
Ancak her workload aynı metrikleri kullanmak zorunda değildir.
Queue sisteminde queue depth, batch sisteminde job completion rate daha anlamlı olabilir.
Application monitoring ile infrastructure monitoring farkı
Infrastructure monitoring şunlara bakabilir:
- CPU
- RAM
- disk
- network
- node health
Application monitoring ise:
- request rate
- endpoint latency
- error
- transaction
- dependency
gibi application behavior'a odaklanır.
Production observability için ikisi de gereklidir.
Yalnız CPU dashboard'ı uygulamanın sağlıklı olduğunu göstermez.
Kubernetes observability nasıl farklıdır?
Kubernetes ortamında observability katman sayısı artar.
İzlenmesi gereken alanlar:
- control plane
- node
- pod
- container
- deployment
- ingress/gateway
- application
- storage
- network
Örneğin bir pod restart problemi:
- application crash
- OOMKilled
- liveness probe
- node pressure
kaynaklı olabilir.
Bu nedenle cluster metric'i ile application telemetry birlikte değerlendirilmelidir.
CI/CD ile observability ilişkisi
Observability deployment sonrası feedback sağlar.
CI/CD nedir? rehberindeki pipeline şu noktada observability'ye bağlanır:
- Deployment yapılır
- Yeni version etiketi telemetry'ye eklenir
- Error/latency değişimi izlenir
- Problem varsa rollback tetiklenir
Bu sayede release ile production behavior arasında doğrudan ilişki kurulabilir.
DevOps için observability neden önemlidir?
DevOps hızlı feedback üzerine kuruludur.
DevOps nedir? yaklaşımında production'dan gelen bilgi tekrar development sürecine dönmelidir.
Observability bu feedback loop'un teknik veri katmanıdır.
Production verisi olmadan ekip:
- release etkisini
- kullanıcı problemini
- dependency failure'ı
- recovery süresini
ölçmekte zorlanır.
Küçük ekip için minimum observability modeli
5-20 kişilik yazılım şirketinde ilk günden karmaşık observability platformu kurmak gerekmeyebilir.
Başlangıç:
1. Infrastructure metrics
- CPU
- RAM
- disk
- network
2. Application metrics
- request rate
- error rate
- latency
3. Structured logs
- timestamp
- level
- service
- request ID
4. Temel alerting
- servis down
- error spike
- latency
- disk exhaustion
5. Kritik akışlarda tracing
Mikroservis veya karmaşık dependency varsa distributed tracing eklenebilir.
Observability stack nasıl seçilir?
Araç seçiminde önce requirement belirleyin.
Sorular:
- Cloud mu self-hosted mı?
- Log volume ne kadar?
- Trace gerekli mi?
- Retention ne kadar?
- SaaS mı tercih ediliyor?
- Data location şartı var mı?
- OpenTelemetry desteği var mı?
- On-call entegrasyonu gerekiyor mu?
Araç seçimi ancak bu sorulardan sonra yapılmalıdır.
Vendor lock-in nasıl azaltılır?
Telemetry instrumentation'ını vendor-specific SDK'lara sıkı bağlamak ileride migration maliyeti yaratabilir.
OpenTelemetry kullanımı:
- ortak instrumentation
- collector tabanlı routing
- backend değişikliği
konusunda esneklik sağlayabilir.
Ancak backend query language, dashboard ve alert tanımları yine vendor-specific olabilir.
Tam vendor bağımsızlığı varsayılmamalıdır.
Log retention nasıl belirlenmeli?
Tüm logları süresiz tutmak doğru değildir.
Retention kararı:
- troubleshooting ihtiyacı
- security
- KVKK
- maliyet
- audit
ile birlikte verilmelidir.
Kişisel veri içeren loglarda masking ve retention ayrıca değerlendirilmelidir.
Production observability kurulum sırası
Adım 1: Kritik kullanıcı akışlarını belirleyin
Önce sistemin hangi davranışının iş açısından kritik olduğunu yazın.
Adım 2: SLI seçin
Availability, error rate veya latency gibi kullanıcı etkisine yakın göstergeler seçin.
Adım 3: Metrics ekleyin
Infrastructure ve application baseline oluşturun.
Adım 4: Structured logging kurun
Request/service correlation sağlayın.
Adım 5: Alerting ekleyin
Yalnız aksiyon alınabilir durumlara alarm üretin.
Adım 6: Tracing ekleyin
Dağıtık sistemlerde dependency latency ve failure araştırmasını kolaylaştırın.
Adım 7: Telemetry maliyetini ölçün
Volume, retention ve sampling'i optimize edin.
Adım 8: Incident sonrası instrumentation'ı iyileştirin
Her incident yeni visibility gap gösterebilir.
Dynamis'te observability yaklaşımı
Dynamis'in DevOps hizmeti kapsamında observability çalışmasına "hangi monitoring aracını kuralım?" sorusuyla başlamıyoruz.
Önce:
- kritik servisler
- kullanıcı akışları
- mevcut metrics
- log kalitesi
- alert noise
- deployment metadata
- incident geçmişi
- telemetry maliyeti
incelenir.
Sonra ihtiyaç halinde:
- infrastructure monitoring
- application metrics
- centralized logging
- OpenTelemetry
- distributed tracing
- SLI/SLO
- alerting
- dashboard
katmanları oluşturulur.
Amaç daha fazla dashboard değil, incident sırasında daha kısa teşhis ve recovery süresidir.
Sık yapılan hatalar
Monitoring ile observability'yi aynı sanmak: Monitoring observability'nin bir kullanım biçimidir.
Her şeyi loglamak: Maliyet ve gürültü hızla büyür.
Request ID kullanmamak: Dağıtık log korelasyonu zorlaşır.
Her metrik için alarm oluşturmak: Alert fatigue yaratır.
Yalnız infrastructure metric izlemek: Application failure kullanıcıyı etkilerken CPU normal olabilir.
OpenTelemetry'yi observability backend sanmak: OpenTelemetry telemetry üretim ve taşıma framework'üdür.
Sırada ne var
- DevOps nedir?: observability'nin DevOps feedback loop içindeki yerini görün.
- Infrastructure as Code nedir? Cloud altyapısı kodla nasıl yönetilir?: infrastructure değişikliklerini version control'e alıp production telemetry ile birlikte izleyin.
- CI/CD nedir?: deployment sonrasında telemetry ve rollback sürecini bağlayın.
- Sistem yöneticisi işe almak mı, dış kaynak kullanmak mı?: monitoring ve incident ownership için iç headcount ile managed service modelini karşılaştırın.
- Bulut sunucu mu, yönetilen altyapı mı?: production monitoring ve incident ownership'ın kimde kalacağını değerlendirin.
- DevOps hizmeti: monitoring, logging ve tracing yapınızı değerlendirin.
Kaynaklar
Kaynaklar
- 1.Observability primerOpenTelemetry · 2026-09-21
- 2.OpenTelemetry signalsOpenTelemetry · 2026-09-21
- 3.OpenTelemetry CollectorOpenTelemetry · 2026-09-21
- 4.Google Cloud ObservabilityGoogle Cloud · 2026-09-21
- 5.Monitoring and observability capabilityDORA · 2026-09-21
Sık sorulan sorular
Observability nedir?
Observability, bir sistemin iç durumunu ürettiği telemetry verilerinden anlayabilme yeteneğidir. Yazılım sistemlerinde bu genellikle metrics, logs ve traces sinyallerinin birlikte analiz edilmesiyle sağlanır.
Monitoring ile observability arasındaki fark nedir?
Monitoring önceden tanımlanmış metrik ve eşiklerle bilinen durumları izlemeye odaklanır. Observability ise metrics, logs ve traces gibi telemetry verilerini ilişkilendirerek öngörülmemiş problemlerde sistemin neden böyle davrandığını araştırmayı kolaylaştırır.
Logging, metrics ve tracing arasındaki fark nedir?
Logs belirli olayların kayıtlarını, metrics zaman içinde ölçülen sayısal değerleri, traces ise bir isteğin dağıtık sistem içindeki uçtan uca yolunu gösterir. Birlikte kullanıldıklarında aynı olayın ne olduğunu, ne kadar yaygın olduğunu ve nerede gerçekleştiğini anlamayı kolaylaştırırlar.
OpenTelemetry nedir?
OpenTelemetry, traces, metrics ve logs gibi telemetry verilerini üretmek, toplamak, işlemek ve dışa aktarmak için kullanılan açık kaynaklı ve vendor-neutral bir observability framework'üdür. OpenTelemetry kendi başına veri saklama veya dashboard backend'i değildir.
Küçük ekip için observability nasıl kurulmalı?
Önce kritik kullanıcı akışları ve servis hedefleri belirlenmeli; ardından temel metrics, structured logs, alerting ve gerektiğinde distributed tracing eklenmelidir. Küçük ekipte tüm telemetry'yi sınırsız toplamak yerine yüksek sinyalli ve aksiyon alınabilir verilerle başlamak daha sürdürülebilirdir.