Observability Nedir? Gözlemlenebilirlik Rehberi

Observability, yani gözlemlenebilirlik, bir sistemin ürettiği telemetriyi kullanarak davranışını, performansını ve sorunlarını açıklayabilme yeteneğidir. Loglar olayların ayrıntısını, metrikler ölçülebilir değişimleri, dağıtık izler ise bir isteğin servisler arasındaki yolculuğunu gösterir. Değer, bu verileri ayrı ekranlarda biriktirmekten değil, aynı iş hizmeti ve işlem bağlamında ilişkilendirmekten doğar.

Sunucular erişilebilir, işlemci kullanımı normal ve ağ cihazlarında kritik alarm yok. Buna rağmen müşteri siparişini tamamlayamıyor. Böyle bir durumda “altyapı çalışıyor” cevabı, iş birimi için yeterli değildir. Hangi kullanıcı işleminin etkilendiğini, gecikmenin nerede oluştuğunu ve müdahale sorumluluğunun kimde olduğunu açıklamak gerekir.

Bu rehber; CIO, BT direktörü, altyapı yöneticisi, kurumsal mimar ve platform ekipleri için gözlemlenebilirliği bir araç satın alma projesinden çıkarıp ölçüm, mimari ve işletim modeli olarak ele alır. Sanal makineler, özel bulut, Kubernetes ve hibrit ortamlar birlikte değerlendirilir. Sayısal hedefler ve olay senaryoları açıklama amaçlıdır.

Observability ile monitoring arasındaki fark nedir?

Monitoring, belirlenmiş göstergeler üzerinden sistemin durumunu takip eder; gözlemlenebilirlik ise bu ölçümleri kullanarak beklenen ve beklenmeyen davranışları araştırmayı destekler. İkisi birbirinin alternatifi değildir. İyi tasarlanmış izleme, gözlemlenebilirliğin önemli bir parçasıdır. Ürünün adında “observability” bulunması, uygulamanın otomatik olarak anlaşılabilir hale geldiğini göstermez.

Örneğin “disk doluluk oranı yükseldi” alarmı belirli bir riski haber verir. Bunun hangi veri tabanını, hangi uygulamayı ve hangi müşteriye sunulan işlemi etkilediğini göstermek ek bağlam ister. İzleme ekranını kaldırıp yerine daha büyük bir ekran koymak bu ilişkiyi tek başına kurmaz.

İlk değerlendirmede araç sayısını değil, kritik bir hizmet hakkında cevaplanabilen soruları sayın. Hangi sürüm çalışıyor, hangi bağımlılıklar çağrılıyor, normal davranış nasıl değişiyor ve son değişikliği kim yaptı? Bu soruların cevapları farklı ekiplerin belleğinde kalıyorsa görünürlük teknik olduğu kadar organizasyonel bir sorundur.

Log, metrik ve trace hangi soruları cevaplar?

Telemetri, sistemlerin çalışma sırasında ürettiği ölçüm ve olay verilerinin genel adıdır. Log, metrik ve trace birbirini tamamlayan sinyallerdir; biri diğer ikisinin eksiksiz yerine geçmez. İhtiyaca göre profilleme, olay kayıtları ve kullanıcı deneyimi ölçümleri de araştırmaya eklenebilir.

Loglama ve log yönetimi rehberi, kayıtların temel işlevini ayrıca ele alır. Buradaki amaç daha fazla log üretmek değil, gerekli logu doğru işlemle ilişkilendirmektir. Metriklerde görülen hata artışından ilgili trace’e, oradan aynı bağlamdaki loglara geçebilmek araştırmanın kapsamını daraltır.

Profilleme ise “hangi fonksiyon işlemci zamanını tüketiyor?” gibi kod düzeyindeki sorulara yardımcı olabilir. Ancak profilleme verisi eklemek, eksik hizmet sahipliği veya belirsiz iş hedeflerini çözmez. Önce araştırmak istediğiniz soruyu belirleyin; sinyal seçimini bu soruya göre yapın.

Üç sinyalin birlikte kullanılması neden önemlidir?

Bir metrik, sipariş işlemlerindeki hata oranının yükseldiğini gösterebilir. Trace, bu işlemlerin hangi servis çağrısında beklediğini ortaya koyabilir; log ise aynı çağrının hangi hata mesajıyla sonlandığını açıklayabilir. Bu üç veri türü aynı olayın farklı ölçeklerdeki görünümüdür. Ortak kimlik ve zaman bilgisi bulunmadığında aynı platformda saklanmaları bile aralarındaki ilişkiyi kendiliğinden kurmaz.

Bu nedenle "log, metrik ve trace topluyoruz" demek başlangıçtır, sonuç değildir. Kabul testinde belirli bir işlemden başlayarak ilgili metriklere, izlere ve kayıtlara gerçekten geçilebildiği gösterilmelidir. Eksik enstrümantasyon, yanlış hizmet adı veya kaybolan bağlam bu geçişi engelliyorsa yeni bir dashboard eklemek yerine veri üretimindeki sorun giderilmelidir.

Güvenilir telemetri için ortak bağlam nasıl tanımlanır?

Telemetri sözleşmesi, ekiplerin aynı hizmeti aynı adlarla ve aynı anlamlarla tanımlamasıdır. OpenTelemetry kaynak bilgileri, telemetriyi üreten varlığı tanımlamak için kullanılır. Hizmet adı, sürüm, çalışma ortamı ve altyapı kimliği gibi alanlar, farklı veri kümelerinin ilişkilendirilmesini kolaylaştırır.

Önerilen başlangıç sözleşmesi; hizmet adı, üretim/test ayrımı, sürüm, sahip ekip, lokasyon veya cluster bilgisi, zaman standardı ve uygun işlemlerde trace kimliğini kapsamalıdır. Her alanın kim tarafından üretildiği, zorunlu olup olmadığı ve hangi değerleri kabul ettiği de tanımlanmalıdır.

Aşağıdaki kayıt, kavramı göstermek için hazırlanmış üründen bağımsız bir JSON örneğidir; doğrudan bir OpenTelemetry yapılandırması değildir:

{
  "service": "order-service",
  "environment": "production",
  "version": "release-42",
  "owner": "commerce-platform",
  "operation": "create_order",
  "outcome": "timeout",
  "trace_id": "example-trace-identifier"
}

“Order”, “orders-prod” ve “siparis-servisi” aynı hizmeti tanımlıyorsa isimleri sorgu sırasında elle birleştirmek yerine kaynakta standardize edin. Geçici instance kimliklerini kalıcı hizmet adlarıyla karıştırmayın. Saat senkronizasyonunu ve zaman dilimi dönüşümlerini doğrulayın; eşzamanlı görünen iki olayın gerçekten aynı zaman aralığına ait olması gerekir.

Trace kimliği de bir yetkilendirme kanıtı değildir. Dışarıdan gelen bir bağlam alanını, güvenilir kullanıcı kimliği veya erişim hakkı gibi kullanmayın. Telemetri etiketlerinin yönetimi ile güvenlik kimliklerinin yönetimini ayrı tasarlayın.

OpenTelemetry nedir, mimarinin neresinde bulunur?

OpenTelemetry, telemetri üretmek, toplamak, işlemek ve dışa aktarmak için kullanılan açık kaynaklı ve sağlayıcıdan bağımsız bir çerçevedir. Tek başına uzun süreli depolama, analiz arayüzü veya dashboard ürünü değildir. Bu işlevler için uygun arka uç sistemleri ve işletim modeli gerekir.

Veri akışı, uygulama ve altyapının gerekli sinyalleri üretmesiyle başlar. Ajanlar veya Collector bileşenleri bu verileri toplar; gerektiğinde filtreler, zenginleştirir ve örnekler. Ardından veriler depolama ve analiz sistemlerine gönderilir. Sorgu ve hizmet görünümleri araştırmayı desteklerken alarm, olay yönetimi ve değişiklik süreçleri bulguyu aksiyona dönüştürür.

Collector yerleşimi doğrudan uygulamadan dışa aktarım, ajan, merkezi gateway veya birleşik modellerle tasarlanabilir. Buradaki “gateway”, telemetri toplama katmanıdır; uygulamanın API Gateway’iyle aynı görevde değildir. Yerel toplama ile merkezi yönetim arasında gecikme, kaynak tüketimi ve arıza bağımlılıkları değerlendirilmelidir.

Otomatik enstrümantasyon, desteklenen dil ve kütüphanelerde kod değişikliğini azaltabilir; ancak iş sürecine özgü olayları ve tüm uygulama içi ayrıntıları kendiliğinden anlamaz. Ödeme reddinin teknik arıza mı yoksa beklenen iş sonucu mu olduğunu tanımlamak uygulama ekibinin katkısını gerektirir.

Açık telemetri standartları kullanmak, veri üretim katmanındaki taşınabilirliği destekler. Buna rağmen özel sorgular, dashboard’lar, saklama modelleri ve alarm kuralları ayrı bağımlılıklar oluşturabilir. Satın alma sırasında yalnızca verinin dışa aktarılmasını değil, bu operasyonel varlıkların nasıl taşınacağını da değerlendirin.

OTLP ve Collector bileşenleri ne işe yarar?

OTLP - OpenTelemetry Protocol, telemetri verisinin uygulama, Collector ve analiz sistemleri arasında aktarılmasını tanımlayan protokoldür. OpenTelemetry ile aynı kavram değildir; daha geniş çerçevenin veri taşıma katmanıdır. Desteklenen sistemler arasında ortak bir aktarım biçimi sunar.

Collector içinde alıcılar veriyi kabul eder, işlemciler filtreleme ve zenginleştirme gibi işlemleri yürütür, dışa aktarıcılar ise veriyi hedefe gönderir. Bu bileşenler log, metrik ve trace akışları için ayrı veri hatlarında tanımlanabilir. Bir bileşenin yapılandırma dosyasında bulunması, ilgili veri hattında etkin olduğu anlamına gelmez; bağlantıların ve hedeflerin de doğru tanımlanması gerekir.

OpenTelemetry tedarikçi bağımlılığını tamamen kaldırır mı?

Hayır. Ortak veri üretim ve aktarım katmanı sağlayıcı değişimini kolaylaştırabilir; ancak sorgu dili, hazır paneller, alarm politikaları ve geçmiş verinin taşınması ayrı konulardır. Telemetriyi başka bir hedefe gönderebilmek ile yıllar içinde oluşmuş operasyon bilgisini taşımak aynı şey değildir. Bu ayrımı Vendor Lock-in ve tedarikçi bağımlılığı rehberinde daha geniş çerçevede ele alıyoruz.

Dağıtık izleme nasıl çalışır ve nerede yanıltabilir?

Bir trace, ilişkili işlemleri; span ise bu yolculuktaki belirli bir işi temsil eder. Servisler arasında aktarılan bağlam, farklı bileşenlerin aynı isteğe ait işlemlerini ilişkilendirmeyi sağlar. Bağlam aktarımı kaybolduğunda tek bir iş akışı, birbirinden kopuk izler olarak görünebilir.

Örneğin mobil uygulama isteği gateway’den sipariş servisine, oradan veri tabanına ve bir mesaj kuyruğuna geçebilir. Kuyruktaki iş daha sonra başka bir tüketici tarafından işleniyorsa, yalnızca HTTP çağrılarını izlemek işin tamamlandığını kanıtlamaz. Üretici ve tüketici arasındaki bağlamın taşınması ve asenkron işin bitiş ölçütünün tanımlanması gerekir.

Span sürelerini körlemesine toplamayın. İç içe veya paralel çalışan işlemlerde süreler çakışabilir. Bir veri tabanı span’ının uzun olması da her zaman sorgunun veri tabanı içinde yavaş çalıştığını göstermez; bağlantı bekleme, ağ veya istemci davranışı ayrı ölçümlerle araştırılmalıdır.

Trace’in göstermediği alanları ayrıca kaydedin. Üçüncü taraf API’nin yalnızca dış yanıt süresini görebiliyorsanız sağlayıcının içindeki bileşeni kesin kök neden olarak adlandırmayın. Aynı şekilde yalnızca örneklenmiş izlerden tüm kullanıcıların etkilenme oranını doğrudan hesaplamayın. İz, araştırma kanıtıdır; kapsamı ve sınırlamalarıyla birlikte yorumlanmalıdır.

İstek bağlamının servisler arasında korunması için istemci, ara katman ve backend entegrasyonları birlikte test edilmelidir. OpenTelemetry, HTTP iletişiminde W3C Trace Context başlıklarını kullanarak bu ilişkiyi taşıyabilir. Bununla birlikte dışarıdan gelen trace bağlamı kullanıcı kimliği veya erişim yetkisi değildir; güven sınırları ayrıca korunmalıdır.

Uptime yüksekken kullanıcı deneyimi neden kötü olabilir?

Sunucu erişilebilirliği, kullanıcı işleminin başarıyla tamamlandığı anlamına gelmez. Gecikme, trafik, hata ve doygunluk gibi göstergeler hizmet davranışının farklı yönlerini açığa çıkarır. Google SRE yaklaşımı bu dört sinyali temel izleme boyutları olarak ele alır.

İşlemci kullanımı düşükken uygulama, sınırlı bir bağlantı havuzunda bekliyor olabilir. Hata oranı değişmezken istekler zaman aşımı sınırına yaklaşabilir. Bir endpoint HTTP 200 döndürdüğü halde cevap içinde iş işleminin başarısız olduğu bilgisi bulunabilir. Bu nedenle başarı tanımı yalnızca altyapı veya HTTP durum kodundan türetilmemelidir.

p95 gecikme, gözlemlerin yüzde 95’inin altında kaldığı gecikme değeridir; ortalama değildir. Dağılımı izlemek, ortalamanın gizlediği yavaş kullanıcı grubunu görmeye yardımcı olur. Farklı instance’ların p95 değerlerini ortalamak, birleşik p95 sonucunu vermez. Toplulaştırılabilir histogramlar ve doğru sorgu modeli değerlendirilmelidir.

Gerçek kullanıcı ölçümü, tarayıcı veya uygulama tarafındaki deneyimi; sentetik kontrol ise belirli bir senaryonun seçilen noktadan çalışıp çalışmadığını inceleyebilir. Bunları aynı gösterge gibi yorumlamayın. Sentetik sipariş başarılıyken belirli bir müşteri grubunun oturum veya ödeme problemi yaşaması mümkündür. Ölçüm konumunu, örnek kapsamını ve veri güvenliği gereksinimlerini açıklayın.

RED ve USE yöntemleri hangi ölçümleri seçmeye yardımcı olur?

RED, servislerin istek hızı, hata ve işlem süresine; USE ise altyapı kaynaklarının kullanım, doygunluk ve hata durumuna odaklanır. RED, Rate - Errors - Duration; USE ise Utilization - Saturation - Errors ifadelerinin kısaltmasıdır. İlki kullanıcıya sunulan hizmeti, ikincisi o hizmeti taşıyan kaynakları incelemek için bir başlangıç çerçevesi sunar.

Bu yöntemler zorunlu ürün özellikleri veya hazır başarı ölçütleri değildir. Aynı CPU kullanım oranı iki uygulamada farklı sonuç doğurabilir. Ölçümün değeri, iş işlemindeki bozulmayla kaynak üzerindeki beklemeyi birlikte açıklayabildiğinde ortaya çıkar.

SLI, SLO ve SLA nasıl ayrılır?

SLI ölçülen gösterge, SLO bu gösterge için belirlenen hedef, SLA ise taraflar arasındaki hizmet seviyesi anlaşmasıdır. Aynı uygulamaya ait olsalar da kapsamları ve ölçüm yöntemleri aynı olmak zorunda değildir. Altyapı sağlayıcısının erişilebilirlik taahhüdünü, uçtan uca sipariş başarısı hedefiyle eşitlemeyin.

Örnek hesap: 30 günlük dönemde 1.000.000 uygun deneme ve yüzde 99,9 başarı hedefi varsayılırsa, hedefe göre başarısızlık bütçesi 1.000 denemedir. 400 başarısız deneme gerçekleştiğinde aynı sabit dönem ve tanım altında bütçenin yüzde 40’ı tüketilmiştir. Bu hesap bir örnektir; önerilen evrensel eşik değildir.

İstek bazlı bütçeyi doğrudan kesinti dakikasına çevirmeyin. Trafik gün içinde eşit dağılmayabilir. Zaman bazlı bir SLI kullanılacaksa ölçüm ayrıca tanımlanmalıdır. Teknik olarak sağlıklı bir ödeme reddini hizmet hatası saymak da her tekrarı bağımsız müşteri kaybı saymak da yanıltıcı olabilir. Ölçümü uygulama ve iş ekipleri birlikte onaylamalıdır.

Alarm yorgunluğu nasıl azaltılır?

İyi bir alarm, doğru kişiye zamanında ulaşan ve belirli bir karar gerektiren alarmdır. Her eşik aşımını nöbetçi ekibe göndermek yerine iş etkisine ve müdahale aciliyetine göre bildirim sınıfları tasarlayın. SLO tüketimine dayalı alarm yaklaşımı, hata bütçesinin ne kadar hızlı tüketildiğini değerlendirmek için kullanılabilir.

Örneğin yüzde 99,9 SLO’nun izin verdiği hata oranı yüzde 0,1’dir. Belirli bir ölçüm penceresinde gözlenen hata oranı yüzde 1 ise, bu pencere için bütçe tüketim hızı 10 kattır. Ancak düşük trafikli bir serviste az sayıda olay büyük oran değişimleri yaratabilir; pencere uzunluğu ve minimum trafik koşulları dikkate alınmalıdır.

Devam eden kritik hizmet etkisi nöbetçi ekibe acil bildirim ve olay yönetimi gerektirebilir. Önümüzdeki haftalarda oluşması beklenen kapasite riski ise sorumlusu ve hedef tarihi belirli bir iş kaydıyla yönetilebilir. Aksiyon gerektirmeyen değişimleri aynı acil kanala göndermek yerine bilgilendirme veya dönemsel değerlendirme kapsamında tutmak daha uygundur.

Her kritik alarmın sahibi, yedek sorumlusu, eskalasyon yolu ve runbook’u bulunmalıdır. Runbook; incelenecek kanıtları, güvenli ilk adımı, değişiklik yetkisini, geri dönüş koşulunu ve iletişim düzenini içermelidir. “Sunucuyu yeniden başlat” gibi bağlamsız bir talimat, hizmeti geçici olarak düzeltirken araştırma kanıtını ortadan kaldırabilir.

Tek bir ölçüm penceresine bağlı alarm, kısa süreli sıçramalarda gereksiz bildirim üretebilir veya yavaş gelişen bozulmaları geç yakalayabilir. Kısa ve uzun pencerelerdeki hata bütçesi tüketimini birlikte değerlendirmek bu ayrımı destekler. Eşikler başka bir kurumdan doğrudan kopyalanmamalı; trafik hacmi, hizmetin kritikliği ve nöbetçi ekibin müdahale modeliyle sınanmalıdır.

Kubernetes, sanal makineler ve hibrit bulut birlikte nasıl gözlemlenir?

Ortamları tek dashboard’a toplamak, ortak hizmet modeline sahip olmakla aynı şey değildir. Önce uygulama, çalışma platformu, veri katmanı ve bağlantıların hangi iş hizmetine ait olduğunu tanımlayın. Değişen kaynak kimliklerini sabit hizmet sahipliğiyle ilişkilendirin.

Uygulama katmanında işlem başarısı, gecikme, sürüm ve bağımlılık çağrıları; çalışma platformunda kaynak kullanımı, yeniden başlama ve bekleme durumları incelenir. Veri katmanında bağlantı havuzu, sorgu ve depolama gecikmesi araştırılırken ağ tarafında paket kaybı, bağlantı kurulumu ve yol değişimleri değerlendirilir. Sürüm ve yapılandırma değişiklikleri de aynı zaman çizelgesinde görünür olmalıdır.

Kubernetes ortamlarında bir Pod'un yeniden oluşturulması, hizmet kimliğinin de değiştiği anlamına gelmez. Araştırma, kısa ömürlü Pod adından başlayıp ilgili uygulama, sürüm ve sorumlu ekibe ulaşabilmelidir. Bekleyen Pod'lar, yeniden başlatmalar ve kaynak sınırları, kullanıcıya yansıyan gecikmeyle aynı bağlamda değerlendirilmelidir.

Kubernetes’te kaynakların geçici olması nedeniyle kısa ömürlü instance kayıtlarıyla yetinmeyin. Sanal makinelerde de tek bir işletim sistemi göstergesi uygulama sağlığını kanıtlamaz. Hibrit bulut yönetimi yaklaşımı, ortamlar arası sorumluluk ve bütünlük değerlendirmesini tamamlar.

Ortamlar arasında taşınan telemetrinin bant genişliği, erişim yolu ve veri konumu ayrıca tasarlanmalıdır. Özel bulut altyapısı seçimi, görünürlük ihtiyacını ortadan kaldırmaz; hangi veriyi kimin toplayıp hangi sisteme aktaracağını daha açık hale getirmeyi gerektirir.

Örnek olay: Sunucular normalken sipariş neden yavaşladı?

Aşağıdaki olay tamamen kurgusaldır. Bir kurumda yeni uygulama sürümünden sonra sipariş oluşturma gecikmesinin yükseldiğini varsayalım. Altyapı ekranında işlemci ve bellek kullanımında belirgin artış yoktur. İlk gözlem “daha fazla sunucu gerekiyor” sonucunu desteklememektedir.

Araştırma önce iş etkisini sınırlar: Bozulma bütün siparişlerde mi, belirli bir kanalda mı, yalnızca yeni sürümü kullanan instance'larda mı görülmektedir? Bu ayrım yapılmadan toplam sunucu sayısını artırmak, sorunun kaynağını değiştirmeden maliyeti yükseltebilir.

İlgili trace'ler, beklemenin veri tabanı erişimi çevresinde yoğunlaştığını göstermektedir. Ekip burada "veri tabanı yavaş" sonucuna atlamak yerine bağlantı havuzundaki bekleme süresini sorgunun çalışma süresinden ayırır. Metrikler bekleyen isteklerin arttığını, aynı trace kimliğine bağlı loglar ise bağlantı edinme zaman aşımını gösterir.

Yeni sürümün havuz ayarı veya bağlantı kullanım biçimi incelenir. Onaylı geri dönüş ya da düzeltme sonrasında yalnızca CPU ekranına değil, sipariş başarı oranına ve gecikme dağılımına bakılır. Kullanıcı işlemi normale dönmeden olayın giderildiği kabul edilmez.

Son değişiklik ile sorunun aynı anda görülmesi tek başına nedensellik kanıtı değildir. Bağımlı servis değişikliği, trafik bileşimi veya önceden var olan bir sınır da araştırılmalıdır. Geri dönüş sonrasında düzelme görülse bile bulgunun hangi gözlemlerle desteklendiği kayıt altına alınmalıdır.

Olay sonrası çıktı yalnızca “havuz ayarı düzeltildi” olmamalıdır. Enstrümantasyon boşluğu, eksik yük testi, yanlış alarm veya belirsiz değişiklik sorumluluğu varsa bunlar da iyileştirme kaydına dönüştürülmelidir. Aynı olayın bir sonraki sürümde daha erken anlaşılması, gözlemlenebilirliğin gerçek kazanımıdır.

Telemetri maliyeti: Hacim, kardinalite, saklama ve örnekleme

Telemetri maliyetini yalnızca depolama kapasitesi olarak değerlendirmeyin. Toplama, aktarım, indeksleme, sorgulama, replikasyon, lisanslama ve operasyon emeğini aynı modelde ele alın. Hangi hizmetin ne kadar veri ürettiği bilinmiyorsa maliyet optimizasyonu rastgele log kapatmaya dönüşebilir.

Örnek hacim hesabı: Saniyede 1.000 olay ve olay başına ortalama 1.000 bayt varsayımı, günde yaklaşık 86,4 GB ham veri üretir. Otuz günlük ham hacim yaklaşık 2,592 TB olur. Bu ondalık birimlerle yapılan matematiksel örnek; sıkıştırma, indeksler, replikalar, protokol yükü ve ücretlendirme modelini içermez.

Kardinalite, bir metrikte oluşabilecek farklı etiket kombinasyonlarıyla ilgilidir. Kullanıcı kimliği veya ham URL gibi sınırsız değişen değerler metrik etiketi olarak kullanıldığında zaman serisi sayısı büyüyebilir. Prometheus, yüksek kardinaliteli alanların etiket olarak kullanılmasına karşı uyarır.

Örneğin 20 endpoint, 5 durum sınıfı ve 10 instance, bütün kombinasyonlar oluşursa 1.000 benzersiz etiket kümesi yaratır. Tek bir skaler metrik için bu 1.000 zaman serisi olabilir; klasik histogramlarda bucket, toplam ve sayaç serileri ayrıca oluşur. Ham kullanıcı kimliği veya her istekte değişen URL eklemek serilerin sayısını daha da büyütebilir. Bu nedenle /orders/1234 yerine /orders/{id} gibi sınırlı rota kalıplarıyla toplulaştırma düşünülmelidir.

Head sampling, kararını isteğin başlangıcında; tail sampling ise iz hakkında daha fazla bilgi toplandıktan sonra verir. İkinci yaklaşım hata ve gecikme odaklı seçimleri destekleyebilir, ancak tamponlama, kaynak ve yönlendirme gereksinimleri getirir. Başlangıçta atılan bir iz, sonradan tail sampling ile geri oluşturulamaz.

İşlem başarısı SLI’sini mümkün olduğunda tüm uygun işlemleri temsil eden sayaçlardan üretin. Örneklenmiş trace verisini araştırma için kullanırken seçim yanlılığını açıklayın. Operasyon logu, güvenlik kaydı ve denetim kaydı için tek bir saklama süresi varsaymayın; her veri sınıfının amacı ve gereksinimi ayrı belirlenmelidir.

Cloud FinOps yaklaşımı bu maliyetleri hizmet ve ekip bazında görünür kılmak için kullanılabilir. Başlangıç lisans ücretinden önce hangi hizmetin ne kadar veri ürettiği, bunun ne kadarının sorgulandığı ve hangi verinin daha düşük maliyetli saklama katmanına taşınabileceği değerlendirilmelidir. Tasarruf, olay araştırmasını körleştirmeden elde edildiğinde anlamlıdır.

Telemetri verisinin güvenliği nasıl sağlanır?

Log ve trace içerikleri; token, çerez, sorgu parametresi, kimlik bilgisi veya kişisel veri taşıyabilir. Mümkün olduğunda hassas alanları hiç üretmeyin; ayrıca toplama katmanında filtreleme ve maskeleme uygulayın. Bir değeri hash’lemek, özellikle tahmin edilebilir bir giriş alanında, otomatik olarak anonim hale getirmez.

Üretim verisini test ortamındaki serbest erişimli dashboard’a göndermeyin. Telemetri platformu için rol tabanlı erişim, güçlü kimlik doğrulama, şifreli aktarım, erişim kayıtları ve saklama politikası tanımlayın. Destek ekibinin tüm sorgu içeriklerini görmesi gerekmiyorsa yetkileri hizmet ve görev kapsamına göre daraltın.

Veri konumu değerlendirmesinde yalnızca ilk depolama bölgesini değil, yedekleri, dışa aktarımları ve destek erişimlerini de sorgulayın. Hukuki saklama veya veri aktarımı yükümlülükleri için hukuk ve uyum ekiplerinin değerlendirmesini alın; teknik bir maskeleme ayarını tek başına mevzuata uyum kanıtı olarak sunmayın.

Veri konumu ve erişim yetkilerinin altyapı seçimindeki rolü için Veri Egemenliği rehberi tamamlayıcıdır. Yalnızca ana veri tabanının nerede olduğunu bilmek yetmez; telemetri kopyaları da aynı değerlendirmeye dahil edilmelidir.

Telemetri altyapısı arızalandığında ne olur?

Gözlemlenebilirlik altyapısının kendisi de arızalanabilir. Collector kuyrukları, başarısız gönderimler ve veri kaybı göstergeleri izlenmelidir. Kalıcı kuyruk ve yeniden deneme tasarımı kesintilere dayanımı artırabilir; sınırsız veya garantili teslimat anlamına gelmez. Collector’ın kendi metrik ve logları, bu kontrol için ayrıca kullanılabilir.

Veri gelmemesi, hata olmadığı anlamına gelmez. Collector veya ağ bağlantısı kesildiğinde hata grafiğinin sıfıra düşmesi, uygulama iyileşmiş gibi yorumlanmamalıdır. Veri tazeliği, beklenen veri akışının kesilmesi ve kuyruk doluluk durumu ayrı kontrollerle ele alınmalıdır.

Kalıcı kuyruklar geçici kesintilerde faydalıdır; fakat disk kapasitesi, yeniden deneme sınırı ve kesinti süresi aşıldığında yine veri kaybı olabilir. İzleme altyapısının üretim uygulamasına ek yükü de pilotta ölçülmelidir. Normal ve tepe trafik altında telemetri açıkken ve kapalıyken gecikme, işlem hacmi, CPU ve bellek kullanımını karşılaştırmak bir kabul testi olarak kullanılabilir. Tek bir evrensel performans etkisi yüzdesi varsaymak yerine kendi uygulamanızdaki farkı ölçün.

Observability, APM, SIEM ve AIOps aynı şey midir?

Bu kavramlar ürün pazarında örtüşebilir; satın alma kararında isimlerden çok kullanım senaryosuna bakın. Aşağıdaki tablo, ürün sertifikasyonu değil, ihtiyaçları ayırmak için hazırlanmış bir değerlendirme çerçevesidir.

AIOps ve yapay zekâ destekli BT operasyonları, gözlemlenebilirlik verisinin analiz boyutunu tamamlar. Ancak modelin ürettiği olası neden, doğrulanmış kök nedenle aynı şey değildir. Kritik bir otomatik düzeltme için hangi kanıtın yeterli olduğu, kimin onay vereceği ve işlemin nasıl geri alınacağı önceden belirlenmelidir.

İç ekip ile hizmet sağlayıcının sorumlulukları nasıl paylaşılır?

7/24 altyapı izleme, bütün uygulama kodunun ve iş mantığının otomatik olarak sağlayıcının sorumluluğunda olduğu anlamına gelmez. Sözleşmede kapsam, erişim yetkisi, müdahale sınırı ve uygulama ekibinin yükümlülüğü açıkça ayrılmalıdır.

Bu tablo bir Ixpanse sözleşmesi değildir. Kendi organizasyonunuzdaki rollere ve satın alınan kapsama uyarlanmalıdır. Bildirime cevap süresi, hizmeti geri getirme süresi ve kalıcı kök neden analizinin teslim süresi de ayrı kavramlar olarak ele alınmalıdır.

Ortak çalışma modelinde kurumun uygulama bağlamı ile sağlayıcının altyapı görünürlüğü aynı olay kaydında buluşmalıdır. “Bizim katmanımız yeşil” yaklaşımı yerine, uçtan uca iş etkisinin kimin koordinasyonunda araştırılacağı belirlenmelidir.

İlk 90 gün için nasıl bir yol haritası izlenebilir?

Aşağıdaki plan önerilen bir çalışma sıralamasıdır; her kurum için tamamlanma süresi veya sonuç garantisi değildir. İlk pilotu iş açısından anlamlı, sahibi belli ve bağımlılıkları yönetilebilir bir hizmet üzerinde başlatın.

1-15. gün: Hizmeti ve sorumluluğu netleştirin

Kritik kullanıcı işlemi, mevcut araçlar, teknik bağımlılıklar ve sorumlu ekipler belirlenir. İlk çıktının satın alınacak ürün listesi değil, pilot hizmet için onaylanmış kapsam ve cevaplanacak sorular olması gerekir. Mevcut durumdaki tespit ve toparlanma süreleri de bu aşamada kaydedilir.

16-30. gün: Telemetri akışını kurun

Hizmet adlandırması, veri güvenliği, enstrümantasyon ve Collector yerleşimi tanımlanır. Bir örnek işlem üzerinden log, metrik ve trace ilişkisi test edilir. Hassas alanların kontrolsüz aktarılmadığı ve eksik verinin fark edilebildiği doğrulanmadan kapsama yeni servisler eklenmemelidir.

31-60. gün: Ölçümü müdahaleye bağlayın

SLI ve SLO'lar, alarm politikaları ve runbook'lar uygulanır. Kontrollü bir test olayının doğru ekibe, gerekli bağlamla ulaşıp ulaşmadığı incelenir. Alarmın üretilmesi kadar, müdahale yetkisinin ve geri dönüş koşulunun belli olması da kabul ölçütüdür.

61-90. gün: Sonucu ve genişleme kararını değerlendirin

Görünürlük kapsamı, telemetri maliyeti, veri kaybı ve operasyon sonuçları değerlendirilir. Pilot sonunda genişleme planı, iyileştirme kayıtları ve sorumluluk kabulü oluşturulur. Kapsam büyümeden önce mevcut hizmette hangi soruların hâlâ cevapsız kaldığı açıkça yazılmalıdır.

Pilotta yalnızca normal davranışı göstermeyin. Kontrollü bağımlılık gecikmesi, Collector bağlantı kesintisi veya etiket eksikliği gibi durumların nasıl göründüğünü de test edin. Üretimde risk yaratacak testler için onay, etki sınırı ve geri dönüş koşulları bulunmalıdır.

Başarı ve çözüm seçimi nasıl ölçülmeli?

Başarı ölçütlerini başlangıçta kaydedin. Olay sayısı veya uygulama kapsamı değişirken tek bir ortalama süreye bakarak gelişme iddiasında bulunmayın. Tespit, ilk müdahale, hizmeti geri getirme ve kalıcı çözüm sürelerini ayrı tutun; MTTR gibi kısaltmalarda “R” harfinin neyi temsil ettiğini raporda açıklayın.

Olgunluk hedefi bütün verileri toplamak değil, kritik sorulara daha tutarlı cevap verebilmektir. Bir sonraki yatırım kararını da “hangi yeni ekranı alacağız?” yerine “hangi önemli soruyu hâlâ cevaplayamıyoruz?” üzerinden verin.

Tespit süresinin kısalması ile hizmetin daha hızlı geri gelmesi aynı kazanım değildir. Başarı raporunda bu süreleri ayrı ölçün; kritik işlemlerin ne kadarının ilişkilendirilebilir telemetri ürettiğini, alarmların ne kadarının gerçek aksiyon gerektirdiğini ve telemetri maliyetinin nasıl değiştiğini de gösterin. RPO ve RTO hedefleri ise veri kaybı toleransı ve kurtarma planlamasıyla ilgilidir; gözlemlenen olay çözüm süresinin yerine kullanılmamalıdır.

Ixpanse ile görünürlük ve işletim kapsamını değerlendirin

Gözlemlenebilirlik, altyapı ve uygulama ekiplerinin aynı hizmet hakkında ortak kanıta ulaşmasını gerektirir. Ixpanse'in Yönetilen Hizmetler kapsamında sunduğu 7/24 izleme, sanal sunucu ve replikasyon yönetimi ile bulut geçiş desteği, altyapı operasyonunun bu değerlendirmedeki başlangıç noktalarıdır. Özel Bulut hizmeti ise ayrılmış altyapı ihtiyaçlarıyla birlikte ele alınabilir.

Uygulama koduna müdahale, OpenTelemetry entegrasyonu, APM kapsamı, telemetri saklama ve olay müdahalesi yetkileri proje özelinde netleştirilmelidir. 7/24 altyapı izleme hizmetinin bütün uygulama katmanlarını kendiliğinden kapsadığı varsayılmamalıdır.

Kritik hizmetinizin hangi katmanlarda görünür olduğunu, hangi soruların cevapsız kaldığını ve operasyon sorumluluklarının nasıl paylaşılacağını değerlendirmek için Ixpanse ekibiyle iletişime geçebilirsiniz.

Sonuç: Daha fazla veri değil, daha açıklanabilir sistemler

Observability'nin kurumsal değeri, bir arızanın varlığını göstermekten öte hangi hizmetin neden etkilendiğini araştırılabilir hale getirmesidir. Log, metrik ve trace bu araştırmanın kanıtlarını oluşturur; ortak hizmet bağlamı, doğru ölçüm ve tanımlı sorumluluklar ise kanıtı müdahaleye dönüştürür.

Bu nedenle iyi bir başlangıç bütün altyapıya ajan kurmak değil, önemli bir kullanıcı işlemini seçmek ve onun sağlıklı tamamlandığını nasıl anlayacağınızı belirlemektir. Sonraki yatırım da daha fazla panel üretmeye değil, bu işlem hakkında hâlâ cevaplanamayan sorulara odaklanmalıdır.

Sık sorulan sorular

Observability nedir?

Gözlemlenebilirlik, sistemin ürettiği telemetriyi kullanarak davranışını ve sorunlarını araştırabilme yeteneğidir. Log, metrik ve trace gibi sinyallerin ortak hizmet ve işlem bağlamıyla ilişkilendirilmesi bu yeteneği destekler. Tek başına bir ürün veya dashboard sayısı değildir.

Monitoring ile observability aynı şey midir?

Tam olarak aynı değildir; ancak birbirini tamamlar. Monitoring, tanımlı göstergelerin izlenmesini sağlar. Gözlemlenebilirlik, bu göstergeler ve ek bağlam üzerinden sistemin neden belirli şekilde davrandığını araştırmaya odaklanır. İyi monitoring olmadan sağlıklı gözlemlenebilirlik kurmak da zorlaşır.

Yalnızca log toplamak yeterli midir?

Her ihtiyaç için yeterli değildir. Loglar olay ayrıntısı sunar; ancak oranları, gecikme dağılımlarını ve servisler arası işlem ilişkilerini tek başına verimli biçimde açıklamayabilir. Hangi ek sinyallerin gerektiği, araştırılan hizmet ve sorun türüne göre belirlenmelidir.

OpenTelemetry bir izleme ürünü müdür?

OpenTelemetry telemetri üretim, toplama, işleme ve dışa aktarma çerçevesidir. Kendi başına tam bir depolama ve görselleştirme platformu değildir. Uygulama enstrümantasyonu, analiz arka ucu ve operasyon süreçleri birlikte tasarlanmalıdır.

Kubernetes kullanmadan observability uygulanabilir mi?

Evet. Sanal makineler, fiziksel sunucular ve geleneksel uygulamalarda da uygulanabilir. Esas gereksinim konteyner kullanımı değil; anlamlı telemetri, ortak bağlam, uygun araştırma araçları ve tanımlı operasyon sorumluluğudur.

Kod değişmeden ne kadar görünürlük sağlanabilir?

Desteklenen otomatik enstrümantasyon ve altyapı entegrasyonları başlangıç görünürlüğü sağlayabilir. Ancak iş mantığı, özel protokoller ve uygulamaya özgü işlem adımları için ek geliştirme gerekebilir. Kapsamı kullanılan dil, kütüphane, sürüm ve yetkiler belirler.

p95 gecikme ne anlama gelir?

Ölçülen işlemlerin yüzde 95’inin altında kaldığı gecikme değeridir. Ortalama gecikmeyle aynı şey değildir. Farklı sunuculardaki p95 değerlerini ortalamak, bütün işlemlerin birleşik p95 değerini vermez; uygun dağılım verisi gerekir.

SLO ile SLA aynı hedefi mi ifade eder?

Zorunlu olarak hayır. SLO belirli bir gösterge için hedefi, SLA ise sözleşmesel hizmet anlaşmasını ifade eder. Ölçülen katman, zaman penceresi, istisnalar ve yükümlülükler farklı olabilir. Bir altyapı SLA’sı uçtan uca uygulama başarısını otomatik olarak kapsamaz.

Tüm trace’leri saklamak gerekir mi?

Evrensel bir zorunluluk yoktur. Hacim, araştırma ihtiyacı, saklama gereksinimi ve maliyet birlikte değerlendirilir. Örnekleme maliyeti azaltabilir; fakat bazı olayların görünmemesine yol açabileceği için yöntem ve kapsam açıkça belirtilmelidir.

Observability siber güvenliğin yerine geçer mi?

Hayır. Telemetri güvenlik araştırmasına katkı sağlayabilir; ancak kimlik, erişim kontrolü, güvenli yapılandırma, yama ve güvenlik operasyonlarının yerine geçmez. Üstelik telemetri sisteminin kendisi de hassas veri ve erişim açısından korunmalıdır.

Gözlemlenebilirlik maliyeti nasıl kontrol edilir?

Veri üretimini hizmet bazında ölçün; gereksiz ayrıntı, yüksek kardinalite, uygun olmayan saklama ve kontrolsüz kopyaları azaltın. Örnekleme kararını araştırma ihtiyacıyla birlikte verin. Depolama dışında aktarım, sorgu, lisans ve operasyon maliyetlerini de hesaplayın.

Yönetilen hizmet almak uygulama sorumluluğunu kaldırır mı?

Hayır. İş hedefleri, uygulama kodu, veri sınıflandırması ve değişiklik onayları için kurum tarafında sorumluluk gerekir. Hangi izleme ve müdahale işlerinin sağlayıcı tarafından yürütüleceği sözleşmede tanımlanmalı; uygulama ve altyapı ekipleri aynı olay sürecinde çalışmalıdır.

OTLP nedir?

OTLP, OpenTelemetry ekosisteminde telemetri verisinin uygulamalar, Collector bileşenleri ve analiz sistemleri arasında aktarılmasını tanımlayan protokoldür. Bir dashboard veya depolama ürünü değildir.

Hata bütçesi nedir?

Hata bütçesi, belirlenen SLO'nun izin verdiği başarısız işlem veya hizmet kaybı payıdır. İstek bazlı ve zaman bazlı bütçeler aynı değildir; ölçüm dönemi ve başarı tanımı açıkça belirlenmelidir.

Telemetri gelmemesi sistemin sağlıklı olduğunu gösterir mi?

Hayır. Veri akışının kesilmesi, uygulama düzelmeden hata grafiğinin sıfıra düşmesine neden olabilir. Collector sağlığı, veri tazeliği, kuyruk doluluğu ve başarısız gönderimler ayrıca izlenmelidir.

OpenTelemetry tedarikçi bağımlılığını tamamen ortadan kaldırır mı?

Hayır. Ortak telemetri üretimi ve aktarımı taşınabilirliği destekler; ancak sorgular, dashboard'lar, alarm kuralları ve geçmiş verinin taşınması ayrı bağımlılıklar oluşturabilir. Çıkış planı bu operasyonel varlıkları da kapsamalıdır.