Observability, modern yazılım sistemlerinin nasıl çalıştığını anlamak ve karşılaşılan sorunların temel nedenini belirlemek için kullanılan kapsamlı bir gözlemlenebilirlik yaklaşımıdır. Uygulamaların, sunucuların ve mikroservislerin ürettiği log, metrik ve iz verilerini bir araya getirerek sistemin iç durumu hakkında bilgi sağlar.
Günümüzde uygulamalar artık tek bir sunucu üzerinde çalışan basit yapılardan oluşmuyor. Bulut sistemleri, konteynerler, API ağ geçitleri, mikroservisler ve üçüncü taraf hizmetler aynı işlem içerisinde birlikte görev alabiliyor. Böyle bir ortamda yalnızca “Sistem çalışıyor mu?” sorusunu cevaplamak yeterli değildir. Sorunun nerede başladığını, kullanıcıları nasıl etkilediğini ve neden ortaya çıktığını da anlamak gerekir.
Observability yaklaşımının asıl gücü tam olarak burada ortaya çıkar.
Observability Nedir?
Observability kelimesi Türkçede “gözlemlenebilirlik” anlamına gelir. Bir sistemin dışarıya verdiği sinyaller incelenerek içeride neler yaşandığının anlaşılabilmesini ifade eder.
Örneğin bir e-ticaret sitesinde ödeme işlemleri yavaşladıysa observability sayesinde şu soruların cevapları aranabilir:
- Yavaşlama hangi serviste başladı?
- Sorun bütün kullanıcıları mı etkiliyor?
- Veritabanı sorguları normalden uzun mu sürüyor?
- Ödeme sağlayıcısına gönderilen istekler zaman aşımına mı uğruyor?
- Son yazılım güncellemesinden sonra hata oranı arttı mı?
OpenTelemetry’nin observability rehberine göre sistemin doğru biçimde gözlemlenebilmesi için uygulamanın log, metrik ve trace gibi telemetri sinyalleri üretmesi gerekir.
Monitoring ile Observability Arasındaki Fark Nedir?
Monitoring ve observability birbirine yakın kavramlar olsa da aynı anlama gelmez.
Monitoring, daha önceden belirlenmiş metrikleri ve eşikleri takip eder. CPU kullanımının yüzde 90’a çıkması, hata sayısının artması veya sunucunun yanıt vermemesi gibi bilinen durumlar için uyarı oluşturur.
Observability ise yalnızca mevcut uyarıları göstermez. Daha önce tanımlanmamış veya beklenmeyen problemlerin araştırılmasına yardımcı olur. Monitoring çoğunlukla “Ne oldu?” sorusuna cevap verirken observability “Neden oldu ve hangi kullanıcılar etkilendi?” sorularına odaklanır.
Bu nedenle monitoring, observability sisteminin önemli bir parçasıdır. İki yaklaşım birlikte kullanıldığında çok daha güçlü sonuçlar elde edilir.
Observability Sisteminin Temel Sinyalleri
Bir observability altyapısı genellikle üç temel telemetri sinyalinden yararlanır.
Loglar
Loglar, uygulama içerisinde gerçekleşen olayların zaman bilgisiyle kaydedilmesidir. Hata mesajları, kullanıcı işlemleri, bağlantı problemleri ve servis cevapları log kayıtlarında bulunabilir.
Üretim ortamlarında yapılandırılmış log formatlarının kullanılması önemlidir. JSON gibi düzenli formatlar, milyonlarca kayıt arasında arama ve filtreleme yapılmasını kolaylaştırır.
Metrikler
Metrikler, belirli zaman aralıklarında ölçülen sayısal değerlerdir. İşlemci kullanımı, bellek tüketimi, istek sayısı, hata oranı ve yanıt süresi metriklere örnek gösterilebilir.
Metrikler sistemde genel bir problem olup olmadığını hızlı biçimde gösterir. Ancak problemin nedenini anlamak için log ve trace verileriyle birlikte değerlendirilmelidir.
Dağıtık İzler
Dağıtık iz veya distributed tracing, tek bir isteğin sistemde izlediği yolu gösterir. Kullanıcıdan gelen bir isteğin API Gateway, sipariş servisi, ödeme servisi ve veritabanı arasında nasıl hareket ettiği takip edilebilir.
Her işlem parçası “span”, işlemin tamamı ise “trace” olarak adlandırılır. Bu yapı sayesinde gecikmenin hangi serviste meydana geldiği belirlenebilir. OpenTelemetry belgeleri de bir trace’in, isteğin dağıtık sistemde izlediği uçtan uca yolu gösterdiğini belirtmektedir.
Sistemleri Güçlendiren 7 Kritik Observability Uygulaması
1. Kullanıcı Odaklı SLI ve SLO Değerleri Belirleyin
Observability çalışmasına yalnızca sunucu metrikleriyle başlamak yeterli değildir. Öncelikle kullanıcı deneyimini temsil eden göstergeler belirlenmelidir.
SLI, hizmet davranışını ölçen göstergedir. SLO ise bu gösterge için hedeflenen hizmet seviyesini tanımlar.
Takip edilebilecek temel değerler şunlardır:
- İsteklerin yanıtlanma süresi
- Başarılı işlem oranı
- Hata oranı
- Hizmet kullanılabilirliği
- Sipariş veya ödeme tamamlama oranı
CPU kullanımının düşük olması sistemin kullanıcı açısından sorunsuz olduğu anlamına gelmeyebilir. Bu nedenle teknik metrikler, kullanıcı deneyimini gösteren verilerle desteklenmelidir.
2. Yapılandırılmış ve Merkezi Loglama Kullanın
Her servisin loglarını farklı bir konumda saklamak sorun araştırmasını zorlaştırır. Logların merkezi bir platformda toplanması, aranması ve ilişkilendirilmesi gerekir.
Her log kaydında mümkün olduğunca şu bilgiler bulunmalıdır:
- Zaman bilgisi
- Servis adı
- Ortam bilgisi
- Hata seviyesi
- İstek veya trace kimliği
- Sürüm ve dağıtım bilgisi
Parola, erişim anahtarı, ödeme bilgisi ve kişisel veri gibi hassas bilgiler loglara yazılmamalıdır. Gerekli alanlarda maskeleme uygulanmalıdır.
3. Doğru Metrikleri ve Etiketleri Seçin
Çok fazla metrik toplamak observability kalitesini otomatik olarak artırmaz. Önemli olan, sistemin ve kullanıcının durumunu gösteren doğru metrikleri seçmektir.
Özellikle şu dört gösterge takip edilebilir:
- Gecikme
- Trafik
- Hatalar
- Kaynak doygunluğu
Metrik etiketleri dikkatli kullanılmalıdır. Kullanıcı kimliği veya benzersiz sipariş numarası gibi sürekli değişen değerlerin etiket yapılması yüksek kardinalite oluşturabilir. Bu durum depolama maliyetini ve sorgu yükünü artırabilir.
4. Mikroservislerde Distributed Tracing Uygulayın
Bir kullanıcı isteği çok sayıda servisten geçiyorsa yalnızca log kayıtlarını incelemek yeterli olmayabilir. Dağıtık izleme sayesinde isteğin bütün yolculuğu görüntülenebilir.
Örneğin ödeme sayfasındaki gecikmenin kaynağı ana uygulama değil, dışarıdaki ödeme hizmeti olabilir. Trace verileri her servisin işlem süresini ayrı ayrı göstererek darboğazı ortaya çıkarabilir.
Bu yöntem özellikle mikroservis, serverless ve bulut tabanlı mimarilerde önemlidir.
5. Log, Metrik ve Trace Verilerini İlişkilendirin
Observability sisteminin en büyük avantajı farklı telemetri sinyallerinin birlikte kullanılabilmesidir.
Bir metrik hata oranının arttığını gösterebilir. İlgili trace hangi servisin yavaşladığını belirleyebilir. Aynı trace kimliğine sahip log kaydı ise hatanın ayrıntılı mesajını gösterebilir.
Dağıtım zamanı, yazılım sürümü ve yapılandırma değişiklikleri de bu verilere eklenmelidir. Böylece problemin yeni bir sürümden sonra başlayıp başlamadığı hızlı biçimde anlaşılabilir.
Çok miktarda telemetri verisiyle çalışan kurumlar, büyük veri analizi yöntemlerinden de yararlanabilir.
6. Etki Odaklı Uyarılar Oluşturun
Her metrik değişiminde bildirim göndermek zamanla alarm yorgunluğuna neden olur. Ekipler çok fazla uyarı aldığında gerçekten önemli bildirimleri gözden kaçırabilir.
Uyarılar kullanıcı etkisine ve hizmet seviyesine göre önceliklendirilmelidir. Örneğin kısa süreli küçük bir CPU artışı yerine ödeme başarısızlık oranındaki sürekli yükseliş daha önemli olabilir.
Her kritik alarm için aşağıdaki bilgiler hazırlanmalıdır:
- Alarmın olası nedeni
- Etkilenen sistemler
- Kontrol edilecek ekranlar
- Uygulanabilecek ilk müdahale
- Sorumlu ekip
- Geri alma veya kurtarma adımları
Bu bilgiler bir runbook içerisinde saklanabilir.
7. OpenTelemetry ile Standart Bir Yapı Kurun
Farklı servislerin birbirinden tamamen farklı telemetri formatları üretmesi yönetimi zorlaştırır. Açık ve standart bir gözlemlenebilirlik altyapısı kurmak için OpenTelemetry kullanılabilir.
OpenTelemetry; uygulamalardan trace, metrik ve log verilerinin üretilmesi, toplanması ve farklı gözlemlenebilirlik platformlarına aktarılması için kullanılan açık kaynaklı ve sağlayıcıdan bağımsız bir çerçevedir.
Kod tabanlı enstrümantasyon daha ayrıntılı veriler sağlarken otomatik enstrümantasyon hızlı başlangıç imkânı sunar. Kurumlar kritik işlemler için özel ölçümler ekleyerek iki yöntemi birlikte kullanabilir.
Observability Nasıl Çalışır?
Tipik bir observability mimarisinde süreç şu şekilde ilerler:
- Uygulamalar telemetri verisi üretir.
- Ajanlar veya SDK’lar bu verileri toplar.
- Veriler ortak bağlam ve servis bilgileriyle zenginleştirilir.
- Bir collector üzerinden merkezi sisteme aktarılır.
- Log, metrik ve trace verileri depolanır.
- Panolar, sorgular ve uyarılar üzerinden analiz edilir.
- Ekipler problemi tespit ederek gerekli müdahaleyi gerçekleştirir.
AWS observability rehberi, ilişkili log, metrik ve trace verilerinin performans darboğazlarını belirlemeyi ve sorun giderme süresini azaltmayı kolaylaştırdığını ifade etmektedir.
E-Ticaret Sisteminde Observability Örneği
Bir e-ticaret sitesinde ödeme ekranının yavaşladığını düşünelim. Observability sistemi öncelikle ödeme isteklerinin gecikme metriğindeki artışı gösterebilir.
İlgili trace incelendiğinde isteğin şu yolu izlediği görülebilir:
Kullanıcı → API Gateway → Sipariş Servisi → Ödeme Servisi → Banka API’si
Trace üzerindeki span süreleri, gecikmenin banka API’sinde oluştuğunu gösterebilir. Aynı trace kimliğiyle açılan log kaydında zaman aşımı hatası bulunabilir. Dağıtım verileri kontrol edildiğinde problemin yeni bir sürümle ilişkili olmadığı anlaşılabilir.
Böylece ekipler uygulamanın tamamını incelemek yerine doğrudan sorunlu bağımlılığa odaklanabilir.
Observability Kurarken Yapılan Hatalar
Observability projelerinde karşılaşılan yaygın hatalar şunlardır:
- Amaç belirlemeden bütün verileri toplamak
- Yapılandırılmamış loglar kullanmak
- Loglara hassas kullanıcı bilgileri yazmak
- Yüksek kardinaliteli metrik etiketleri oluşturmak
- Trace kimliklerini servisler arasında taşımamak
- Her metrik için ayrı alarm oluşturmak
- Yalnızca altyapıyı takip edip kullanıcı deneyimini ölçmemek
- Panoları hazırlayıp düzenli olarak güncellememek
- Telemetri maliyetlerini kontrol etmemek
Toplanan verilerin saklama süresi ve örnekleme oranı sistemin önemine göre belirlenmelidir. Her isteğin sürekli kaydedilmesi büyük sistemlerde gereksiz maliyet oluşturabilir.
30 Günde Observability Sistemine Nasıl Başlanır?
İlk hafta en kritik kullanıcı işlemi belirlenebilir. Bu işlem için başarı oranı, hata oranı ve yanıt süresi ölçümleri hazırlanabilir.
İkinci hafta loglar yapılandırılmış formata dönüştürülerek merkezi sisteme aktarılabilir. Servis adı, ortam, sürüm ve trace kimliği gibi ortak alanlar eklenebilir.
Üçüncü hafta kritik işlem yolu için dağıtık izleme uygulanabilir. Servisler arasındaki bağlam aktarımı kontrol edilebilir.
Dördüncü hafta kullanıcı etkisine dayalı alarmlar, panolar ve müdahale dokümanları hazırlanabilir. Kurulan yapı gerçek bir hata senaryosuyla test edilmelidir.
Sıkça Sorulan Sorular
Observability Türkçede ne anlama gelir?
Observability, Türkçede gözlemlenebilirlik anlamına gelir. Bir sistemin dışarıya verdiği veriler üzerinden içerideki durumun anlaşılmasını sağlar.
Observability ile monitoring aynı şey mi?
Hayır. Monitoring önceden belirlenmiş metrikleri takip eder. Observability ise bu verileri ilişkilendirerek problemlerin nedenini araştırmaya yardımcı olur.
OpenTelemetry nedir?
OpenTelemetry, telemetri verilerinin üretilmesi, toplanması ve dışarı aktarılması için kullanılan açık kaynaklı bir gözlemlenebilirlik çerçevesidir.
Observability yalnızca mikroservisler için mi kullanılır?
Hayır. Tek parça uygulamalar, mobil uygulamalar, web siteleri, sunucular ve bulut sistemleri de observability yaklaşımından yararlanabilir.
Yalnızca log toplamak yeterli midir?
Küçük sistemlerde loglar önemli bilgiler sağlayabilir. Ancak dağıtık yapılarda metrik ve trace verileri olmadan problemin bütün etkisini ve izlediği yolu anlamak zorlaşabilir.
Sonuç
Observability, modern yazılım sistemlerinin güvenilirliğini artırmak ve karmaşık problemlerin temel nedenini daha hızlı bulmak için kullanılan güçlü bir yaklaşımdır. Log, metrik ve dağıtık iz verileri birlikte değerlendirildiğinde sistemin yalnızca çalışıp çalışmadığı değil, kullanıcı deneyiminin neden bozulduğu da anlaşılabilir.
Başarılı bir observability sistemi mümkün olan bütün verileri toplamak yerine doğru sinyalleri üretmeli, bu sinyalleri ilişkilendirmeli ve ekiplerin harekete geçebileceği bilgiler sunmalıdır.
