Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
Observability, “hata var mı?” sorusundan “hangi kullanıcı akışında, hangi sürüm ve bağımlılık bağlamında, ne değişti?” sorularına geçmeyi destekler.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
İyi instrumentation ve ilişkilendirilebilir telemetry, etkiyi ölçmek, hipotezi daraltmak ve bir mitigation'ın işe yarayıp yaramadığını görmek için kanıt sağlar. Sistem otomatik olarak açıklama üretmez; ekip bu kanıtı doğru bağlamda yorumlar.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-005'te yeni release sonrasında “checkout error rate” metriği yükselir. Bu sinyal etkinin başladığını ve kapsamını gösterir, fakat nedeni tek başına açıklamaz.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Junior değişiklik zamanını ve sürümü karşılaştırır; ilgili trace ile isteğin hangi serviste bozulduğunu, logs ile o adımın ayrıntısını inceler. Rollback sonrası aynı kullanıcı akışı, hata oranı ve bağımlılık sinyalleri toparlanmayı doğrulamak için yeniden izlenir.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Temsili ekip konuşması: “Dashboard etkiyi gösteriyor ama nedeni göstermiyor. Hatalı checkout örneklerinin trace'ini release sürümüyle ilişkilendirip hangi dependency adımında ayrıştığını kontrol edelim.”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: Observability, instrumentation, telemetry, signal, metric, log, trace, correlation, dashboard ve alert terimlerinin farklı rollerini fark edebilmelisin.
- Açıkla: Observability'nin neden yalnız veri toplamak veya dashboard sahibi olmak olmadığını; beklenmeyen sorulara bağlamlı kanıtla yaklaşmayı hedeflediğini anlatabilmelisin.
- Uygula: Bir production sorununda kullanıcı etkisini gösteren sinyalden ayrıntılı kanıta ilerlemeli, zaman/sürüm/request bağlamını korumalı ve mitigation sonucunu aynı ölçütlerle doğrulamalısın.
- Şimdilik bilmesi gerekmeyen: Telemetry mimarisi seçmek, Collector pipeline kurmak, sampling/cardinality politikası tasarlamak ve kurumsal SLO sistemi oluşturmak.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Dağıtık bir production sisteminde bir kullanıcının isteği birden fazla servis ve bağımlılıktan geçebilir. Önceden hazırlanmış bir health check yalnız “çalışıyor” derken kullanıcı işlemi yine başarısız olabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Ekipler yeni ve beklenmeyen sorular sorduğunda kod ekleyip yeniden deploy etmeyi beklemeden davranışı yeterli bağlamla araştırmak ister.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
Ekipler release etkisini izlemek, Incident sırasında kullanıcı etkisini belirlemek, bağımlılık ve sürüm değişikliklerini karşılaştırmak ve kapasite/debug sorularını yanıtlamak için observability yatırımı yapabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
OpenTelemetry vendor bağımsız instrumentation ve telemetry taşıma araçları sunar. Google SRE örnekleri metrics ve logs'ın farklı hız/ayrıntı özelliklerini gösterir. Sinyal seçimi, saklama süresi, dashboard ve alert politikası servisin hedeflerine göre değişir.
Karar alanı · Bölüm 07
Trade-off ve bağlam
Instrumentation ve telemetry depolama, sorgulama ve bakım işi oluşturur. Her şeyi ayrıntısız biçimde toplamak gürültüyü artırabilir; çok az veri ise olay sırasında kritik bağlamı eksik bırakabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Metrics hızlı ve toplu bir görünüm sunarken logs veya traces daha ayrıntılı fakat farklı maliyet ve gecikme özelliklerine sahip olabilir. Doğru denge kullanıcı açısından önemli sorulara, sistem mimarisine ve veri hassasiyetine bağlıdır.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- “Observability bir dashboard'dur.” Yanlış; dashboard önceden seçilmiş bir görünüm ve arayüzdür.
- “Monitoring ile Observability tamamen aynı terimdir.” Eksik; pratikler kesişir, ancak Observability beklenmeyen soruları araştırma yeteneğini vurgular.
- “Logs, metrics ve traces varsa sistem observable'dır.” Yanlış; sinyallerin doğru bağlam, ilişki ve sorgulanabilirlik taşıması gerekir.
- “OpenTelemetry bir observability backend'idir.” Yanlış; telemetry üretme, toplama ve aktarma toolkit'idir.
- “Daha çok telemetry her zaman daha iyidir.” Yanlış; amaçsız veri gürültü, maliyet ve hassas veri riski yaratabilir.
- “Observability kök nedeni otomatik bulur.” Yanlış; kanıt sağlar, yorum ve karar yine ekip çalışmasıdır.
Gerilim ve çözüm1. bölüm