# Observability nedir? Monitoring'den farkı ve nasıl başlanır URL: https://upstreamapi.com/tr/journal/observability-nedir Type: blog Locale: tr Published: 2026-11-14 Updated: 2026-11-14 --- > Observability, bilinmeyen arızaların nedenini üretimde yeni kod yazmadan açıklama yeteneğidir. Monitoring ile farkı, üç sinyali ve maliyeti. Observability nedir sorusunun kısa cevabı şu: sisteminizin zaten yaydığı telemetriyi kullanarak, öngörmediğiniz arızalar dahil, sistemin neden yanlış davrandığını açıklayabilme yeteneği. Monitoring, checkout gecikmesinin 800 ms eşiğini geçtiğini söyler. Observability ise hangi müşterinin, hangi bağımlılığın ya da hangi deploy'un bunu yarattığını, gece üçte yeni kod yazmadan sorabilmenizi sağlar. Bir sahneyle somutlaştıralım. Alarm çalıyor: ödeme API'sinde p99 gecikmesi 180 ms'den 1,4 saniyeye çıkmış. Panelde CPU, bellek ve hata oranı yeşil. Hazır grafiklerin hepsi servisin sağlıklı olduğunu söylüyor, müşterilerin hepsi ise aksini söylüyor. Bundan sonraki on dakikada ne yaptığınız, bu yazının asıl konusu. ## Tanım neden araçtan önce gelir? Terim kontrol teorisinden geliyor: bir sistemin iç durumu dış çıktılarından çıkarılabiliyorsa, o sistem gözlemlenebilirdir. Yazılım dünyası bu kavramı ödünç aldı, sonra satıcılar kavramı "bir dashboard ürünü" anlamına gelene kadar genişletti. Bu genişletmeyi bir kenara bırakın. Mühendislik ekibi için daha dar ve daha faydalı bir tanım yeter. Bir sistem, üretimde yeni bir instrumentation eklemeden davranışı hakkında yeni bir soruyu yanıtlayabiliyorsa gözlemlenebilirdir. Asıl kelime "yeni". Eşik alarmı, geçen çeyrek birinin yazdığı bir soruyu yanıtlar. Gözlemlenebilir bir sistem ise şu an sorduğunuz soruyu yanıtlar. Bu bir saflık testi değil. Kimsenin mükemmel gözlemlenebilir bir sistemi yok ve hedef bir puan değil. Hedef, "bir şeyler yanlış" ile "bu değişiklik buna neden oldu" arasındaki yolu kısaltmak. Tespit için geçen süre ile anlama için geçen süre farklı sayılar ve çoğu ekip yalnızca birincisini takip ediyor. ![Whiteboard sketch of services connected by arrows](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/3a5d62-i1.webp) ## Observability monitoring'den nasıl ayrılır? Monitoring, bildiğiniz hata modlarına karşı yapılan kontrollerden oluşur. CPU beş dakika boyunca yüzde 90'ın üzerinde, hata oranı yüzde 1'in üzerinde, kuyruk derinliği 10.000'in üzerinde. Ucuz, güvenilir ve hâlâ ihtiyacınız olan bir şey. Observability onun yerini almaz. Fark, arıza yeni olduğunda ortaya çıkar. Monitoring geçmiş olaylarınızdan kurulur. Observability ise bir sonraki olay için kurulur ve o olayı tanımı gereği henüz görmemişsinizdir. Basit bir test var: son üç olayınıza bakın ve kök nedenin nasıl bulunduğunu sorun. - Biri hazır bir dashboard'a baktıysa ve cevap oradaysa, monitoring işini yapmış demektir. - Biri altı sunucuda log taramış, bir hipotez kurmuş, log satırı ekleyip yeniden deploy ederek doğrulamışsa, bu bir observability açığıdır. - Gerçek cevap bir müşterinin ekran görüntüsünden geldiyse, iki sorunuz birden var demektir. İkisinin rakip olup olmadığı tartışmasına girmeyin. Bunlar katman. Monitoring duman dedektörü gibidir. Observability ise yangının hangi devreden başladığını bulmak için binayı sonradan dolaşabilme yeteneğidir. ## Üç sinyal nedir ve her biri nerede yetersiz kalır? Log, metrik ve trace standart üçlü. Her biri farklı bir soruyu yanıtlıyor ve satıcı rehberlerinin çoğunun atladığı bir hata moduna sahip. **Metrikler**, zaman içinde toplanmış sayısal ölçümlerdir: istek oranı, hata oranı, gecikme yüzdelikleri, doygunluk. Saklaması ucuz, sorgulaması hızlı. Alarmlar bu yüzden metriklerin üzerine kurulur. Hata modu toplulaştırmadır. 1,4 saniyelik bir p99 bir şeyin yavaş olduğunu söyler, ama yavaş isteklerin hepsinin tek bir müşteriye ait tek bir shard'dan geldiğini söyleyemez. **Loglar**, ayrık olayların zaman damgalı kayıtlarıdır. En fazla ayrıntıyı taşırlar, yapıyı zorla vermediğiniz sürece en az yapıya sahip olurlar. Hata modu hacim ve maliyettir. Yapılandırılmamış loglar yalnızca hangi metni aradığını bilen insanlar tarafından aranabilir. Bu da onları hata ayıklama kılığına girmiş bir monitoring aracı yapar. **Trace'ler**, tek bir isteği servis sınırları boyunca izler. Her adım için bir span ve zamanlaması vardır. Bir isteğin şeklini gösteren tek sinyal budur: bu çağrı, alt bağımlılıkta üç kez yeniden denenen 900 ms'lik bir bekleme yaşamış. Hata modu kapsamdır. Trace bağlamını düşüren tek bir servis zinciri koparır, ve delikli bir trace, yetkili göründüğü için hiç olmamasından daha kötüdür. Üçüne birden sahip olmak, gözlemlenebilir olmakla aynı şey değil. Asıl mesele korelasyon. Metrik sıçramasından ona katkı yapan trace'lere, oradan da o isteğin loglarına geçebilmeniz gerekir. Üçü ortak bir tanımlayıcı olmadan ayrı araçlarda duruyorsa, elinizde üç ayrı monitoring sistemi ve birleştiriciyi oynayan bir mühendis var demektir. ## Kardinalite neden hata ayıklamayı belirler? Kardinalite, bir alanın alabileceği farklı değerlerin sayısıdır. status_code yaklaşık yirmi değer alır. customer_id yüz binlerce değer alır. request_id ise her istek için bir tanedir. Bir olay sırasında en çok ihtiyaç duyduğunuz alanlar yüksek kardinaliteli olanlardır. "Hangi müşteri etkilendi?" bir customer_id sorusudur. "Yavaş istekleri hangi build sunuyor?" bir deploy_version sorusudur. Depolama modeliniz yüksek kardinaliteli alanları, seri başına fiyatlandırarak ya da sessizce düşürerek cezalandırıyorsa, olayı çözecek soruyu soramazsınız. Metrik odaklı kurulum ile gözlemlenebilir kurulum arasındaki gerçek mimari çizgi budur. Önceden toplanmış metrikler, daha sonra ihtiyaç duyacağınız boyutları atar. Geniş ve yapılandırılmış olaylar bu boyutları saklar ve sonradan dilimlersiniz. Bir servisin kenarında faydalı bir olay şöyle görünür: istek başına tek bir yapılandırılmış kayıt, ileride dilimlemek isteyeceğiniz her şeye göre yeterli bağlamla. `logger.info("request.completed", { trace_id: span.traceId, route: "/v1/payments", customer_id: ctx.customerId, deploy_version: process.env.BUILD_SHA, flag_variant: flags.get("new-ledger-path"), db_ms: timings.db, upstream_ms: timings.upstream, status: res.statusCode, duration_ms: elapsed, });`Olaydaki feature flag varyantına dikkat edin. Yayınlanmış post-mortem'lerin yarısı bir değişiklikle başlar, ve bir flag değerlendirmesi de bir değişikliktir. Varyant olayda yoksa, yavaş isteklerin yeni yolda olup olmadığını soramazsınız. ![Desk with a laptop showing a latency dashboard](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/c95a59-i2.webp) ## Bir olay observability ile ve observability olmadan nasıl ilerler? Aynı ödeme senaryosunu alalım. Aynı alarm, aynı 1,4 saniyelik p99. Observability olmadan döngü şöyle işler: servis dashboard'una bakarsınız, bir şey bulamazsınız. Veritabanı dashboard'una bakarsınız, yine bir şey bulamazsınız. Olay kanalında bir deploy olup olmadığını sorarsınız. Biri bir konfigürasyon değişikliğini hatırlar, bir başkası buna katılmaz. Kırk dakika sonra, belki yardımcı olur diye son deploy'u geri alırsınız. Olmaz, çünkü neden bir flag'in bazı tenant'lara açılması. Observability ile döngü şöyle işler: yavaş istekleri flag_variant'a göre gruplarsınız ve hepsinin new-ledger-path üzerinde olduğunu görürsünüz. customer_id'ye göre gruplarsınız ve üç büyük tenant'ın hacmin çoğunu oluşturduğunu görürsünüz. Bir trace açarsınız ve ledger çağrısının 40 sıralı sorguya yayıldığını görürsünüz. Toplam süre birkaç dakika. Deploy'u değil, flag'i kapatırsınız. İkinci döngünün neye ihtiyaç duymadığına dikkat edin. Hazır bir dashboard gerekmedi. Birinin "flag variant"ı önceden ilginç bir boyut olarak öngörmesi gerekmedi. Gereken tek şey, verinin geniş ve sorgulanabilir biçimde orada bulunmasıydı. Bu, Honeycomb'ın argümanının tek paragrafta özeti ve bu argüman geçerli. Ama bunun bedava olduğunu söylemiyor. ## Maliyeti ne, ve pahalı sürümü kimler atlamalı? Telemetri önce bir veri hacmi problemi, sonra bir araç problemi. [Grafana Labs'in 1.255 uygulayıcı üzerinde yaptığı 2025 observability anketine](https://grafana.com/blog/2025/03/25/observability-survey-takeaways) göre bir organizasyon ortalama sekiz farklı observability aracı kullanıyor ve yeni araç seçerken en çok söylenen kriter maliyet. Bu iki gerçek birbirine bağlı. Her araç bir parçayı çözdüğü için ekipler araç biriktiriyor, sonra hepsinde üst üste binen veri alımının bedelini ödüyor. Çoğu ekip büyüklüğünde geçerli pratik kurallar şunlar: - **Özel bir agent yerine OpenTelemetry ile enstrümante edin.** Collector, örnekleme, filtreleme ve yönlendirme için tek bir yer verir. Backend değiştirmek, yeniden enstrümantasyon projesi değil bir konfigürasyon değişikliği olur. - **Trace örneklemesini bilinçli yapın.** Her hatayı ve her yavaş isteği tutun, sağlıklı ve hızlı olanları örnekleyin. Sabit yüzde 1 head-based örnekleme, ihtiyacınız olan tam trace'i atabilir. - **Logları yazma anında yapılandırın.** Sorgu anında serbest metni ayrıştırmak, alanları elde etmenin pahalı yoludur. - **Sinyal başına saklama politikası belirleyin.** Metrikler bir yıl, geniş olaylar iki hafta, debug logları üç gün. Geçen çeyreğin debug loglarına kimse ihtiyaç duymadı. Birkaç servisiniz ve tek bir on-call rotasyonunuz varsa tam platform yaklaşımını atlayın. Küçük bir ekip, yapılandırılmış loglar, RED metrikleri ve iki üç sıcak yol üzerindeki trace'lerle faydanın büyük kısmını alır. Pahalı, her şeyi yapan sözleşme, hiçbir kişinin topolojinin tamamını kafasında tutamadığı kadar çok servisiniz olduğunda karşılığını verir. Bizim deneyimimize göre bu nokta 30 ila 40 servisin üzerinde. ## Hangi araçlara bakmaya değer? Araç seçimi, ne kadarını kendiniz işletmek istediğinize, kardinalite profilinize ve faturanızın neyi kaldırabileceğine bağlı. Kısa ve görüşlü bir tur: Datadog, en geniş ticari seçenek: metrik, log, trace ve profilleme tek çatı altında, aralarında güçlü korelasyonla. Bu entegrasyonun bedeli, faturanın host sayısı, özel metrikler ve alınan log hacmiyle ölçeklenmesi. Tek bir satıcı istediğinizde ve bütçeniz buna uygunsa değer katar. Taahhütten önce özel metrik kalemine bakın. Grafana, açık bileşenleri kendiniz barındırmak ya da yönetilen bir yığın olarak satın almak istediğinizde varsayılan seçim. Prometheus tarzı metriklerle ve OpenTelemetry pipeline'larıyla iyi çalışır. Bedeli operasyonel: montajın daha fazlasına siz sahip olursunuz ve yukarıdaki anketin yaydığı araç dağınıklığı sizin için de geçerli. SigNoz, OpenTelemetry'ye yerel, açık kaynaklı bir seçenek. Logları, metrikleri ve trace'leri tek bir veri deposunda tutuyor. Bu önemli, çünkü korelasyon noktası için ortak bir depo, metrikten trace'e ve oradan loga geçişi bir sekme değiştirme değil bir sorgu yapar. Dört ayrı projeyi birbirine eklemeden kendi sunucunuzda barındırmak isteyen ekipler için uygun. Better Stack, uptime izleme, incident alarmları ve log yönetimini daha küçük ekipler için uygun bir fiyatla birleştiriyor. "Sorunu müşterilerden öğreniyoruz" aşamasından yapılandırılmış bir düzene geçerken sağlam bir ilk adım. Yoğun trace gereksinimleri olan büyük bir servis mesh'i için daha az uygun. ![Data center aisle with status lights](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/63d34b-i3.webp) ## Okyanusu kaynatmadan nasıl başlarsınız? Bir araç değerlendirmesiyle başlamayın. Son üç olayınızı ve tek bir dürüst soruyu ele alarak başlayın: keşke neyi sorabilseydik? Elli ila iki yüz mühendisi olan bir ekip için işe yarayan bir sıra var: - **Tek bir kritik istek yolu seçin** ve uçtan uca OpenTelemetry ile enstrümante edin. Checkout, giriş, sizi gece üçte uyandıran her şey. - **Servis kenarında istek başına tek bir geniş yapılandırılmış olay yayınlayın.** Müşteri, sürüm, flag varyantları ve alt bağımlılık süreleriyle. - **O yol için tek bir SLO tanımlayın** ve ham eşiklerde değil, burn rate üzerinde alarm kurun. Burn-rate alarmları kullanıcı etkisi için sizi uyandırır, adım 2'deki telemetri ise nedenini söyler. - **Bir game day yapın.** Henüz alarmı olmayan bir arıza enjekte edin ve kodu yazmamış birinin onu bulmasının ne kadar sürdüğüne bakın. Bu sayı başlangıç noktanız olur. - **Yalnızca ilk yol gerçek bir olayda kendini amorti ettikten sonra**, her seferinde bir yolu genişletin. Observability bir platform olarak satın alınır, ama bir alışkanlık olarak benimsenir. Alışkanlık, kod incelemesinde olaydan önce, olay sırasında değil, "bunu açıklamak için neyi bilmem gerekirdi?" sorusunu sormaktır. Son olay incelemenize bakın ve "doğrulamak için loglama ekledik" cümlesini bulun. Bu cümlelerin her biri, sistemin üretimde cevaplayamadığı bir sorudur. Elinizde kaç tane var ve bugün bunlardan hangileri hâlâ cevapsız? ## FAQ ### Observability ile monitoring aynı şey mi? Değil. Monitoring bildiğiniz hata modlarına karşı kontrol yapar. Observability ise daha önce görmediğiniz arızaları da açıklamanızı sağlar. İkisi birbirinin yerini almaz, birlikte kullanılır. ### Observability'nin üç sinyali nelerdir? Metrikler, loglar ve trace'lerdir. Metrikler eğilimleri gösterir, loglar olayların ayrıntısını verir, trace'ler ise bir isteğin servisler arasındaki yolculuğunu gösterir. Asıl değer, üçünün ortak bir tanımlayıcıyla birbirine bağlanmasından gelir. ### Kardinalite neden önemlidir? Kardinalite, bir alanın alabileceği farklı değer sayısıdır. Olay incelemesinde en çok ihtiyaç duyulan alanlar, yani müşteri kimliği ya da sürüm gibi yüksek kardinaliteli alanlardır. Depolama modeli bu alanları cezalandırıyorsa, kök nedeni bulamazsınız. ### OpenTelemetry kullanmak zorunlu mu? Zorunlu değil, ama önerilen yol. Enstrümantasyonu tek bir standarda bağlar ve backend değiştirmeyi bir konfigürasyon değişikliğine indirir. ### Küçük bir ekibin observability'ye ihtiyacı var mı? Birkaç servisiniz ve tek bir on-call rotasyonunuz varsa tam platform gerekmez. Yapılandırılmış loglar, RED metrikleri ve iki üç kritik yoldaki trace'ler çoğu zaman yeterlidir. ### Observability için hangi araç en iyisi? Tek bir en iyi araç yoktur. Ne kadarını kendiniz işletmek istediğinize, kardinalite profilinize ve bütçenize bağlıdır. Datadog, Grafana, SigNoz ve Better Stack farklı ihtiyaçlara göre değerlendirilebilir.