Observability Nedir? #

(Sistem Gözlemlenebilirliği)

All truths are easy to understand once they are discovered; the point is to discover them.
— Galileo Galilei

• Tanım: Observability, uygulamaların canlı ortamda bile iç durumlarını dışa vuran veriler üreterek izlenebilmesini sağlayan bir yaklaşımdır. Aynı zamanda bir sistemin iç durumunu dış gözlemlerle anlama yeteneğini ifade eder ve dağıtık sistemlerde sistemin performansını izlemek ve hataları tespit etmek için kullanılır.

• Neden Önemli?: IDE’de lokal olarak debug yapmak kolay. Ancak canlıda bir sorun yaşandığında sistemi gözlemleyebilmek için bazı verileri aktif olarak toplamamız gerekir.

Observability’nin 3 Temel Veri Tipi #

1. Log:

   • Sistemde meydana gelen olayların kaydıdır ve detaylı analiz yapma imkanı sunar.

   • Uygulamanın zaman bilgisini (timestamp), mesajı, sınıf/metot bilgilerini ve formatlanmış metinleri içerir.

   • Her yere log atmak sakıncalı olabilir, çünkü sistemde yük oluşturabilir.

2. Metrics:

   • Yükü en hafif olan, sistem performansını gösteren sayısal veriler sağlar. (ör. CPU kullanımı, kuyruktaki istek sayısı, hata sayısı).

   • Uygulamadan veya container/servis mesh gibi katmanlardan toplanabilir.

3. Tracing:

   • İşlemlerin dağıtık sistemlerde nasıl ilerlediğini izler. Özellikle mikroservisler arası isteklerin nasıl geçtiğini takip eder.

   • Trace Data: Başlangıçtan bitişine kadar bir operasyonu (transaction) uçtan uca izlemek için oluşturulur (Bu veride hangi işlemle devam etti, işlem ne kadar sürdü gibi veriler vardır.).

   • Geniş çaplı (ör. bir HTTP request’in veritabanı işlemlerine kadar takibi) süreçlerde gereklidir.

   • Her yerde trace tutmak da kaynak tüketimini artırır; ihtiyaca göre konumlandırılmalıdır.

OpenTelemetry Nedir? #

• Open açık kaynak olmasını, Tele uzaktan yapabilmesini ve Metry (Metron) ölçümü temsil eder. Bir gözlemlenebilirlik (observability) framework’üdür

• Log, trace ve metrics verilerini platform bağımsız, standart bir formatta üreterek istenilen hedefe aktarabilmeyi sağlar.

• Her dilin kütüphanesi farklı veri formatları oluşturabilirken, OpenTelemetry bu verileri tek bir standarda oturtur.

OpenTelemetry Nedir? #

• CNCF (Cloud Native Computing Foundation) tarafından desteklenir ve APM araçlarından bağımsız çalışır.

• OTLP protokolü sayesinde endüstri standartlarında veri toplayabilir.

• Jaeger ve Zipkin gibi araçlarla uyumlu çalışarak kapsamlı bir gözlemlenebilirlik çözümü sunar.

APM (Application Performance Monitoring) Araçları #

• Jaeger ve Zipkin: Özellikle tracing için kullanılan açık kaynaklı platformlardır. OpenTelemetry’le uyumludurlar.

• Jaeger: Cassandra ve Elasticsearch gibi veri depolarını destekler.

• Zipkin: Tracing tarafında yine popüler açık kaynak bir çözümdür.

• Özellikle bu iki araç log verisi istemezler; daha çok trace odaklı çalışırlar.

APM (Application Performance Monitoring) Araçları #

• Elastic APM: Elastic tarafından geliştirilen bir Application Performance Monitoring çözümüdür. Uygulamaların performansını, hatalarını ve işlemler arasındaki gecikmeleri izleyebilmek için distribute tracing, log analizi ve metrik toplama özelliklerini bir arada sunar.

APM (Application Performance Monitoring) Araçları #

• New Relic: SaaS tabanlı bir Application Performance Monitoring platformudur. Anlık performans metrikleri, hata takibi ve gelişmiş analiz araçları sunarak uygulamanızın uçtan uca izlenmesini sağlar. Kod seviyesinde detaylı tracing, kullanılabilirlik ölçümleri, gecikme analizleri gibi özelliklerle performans sorunlarını hızlıca tespit etmeye yardımcı olur.

APM (Application Performance Monitoring) Araçları #

• Application Insights: Microsoft Azure ekosisteminin bir parçası olan Application Insights, canlı uygulamaların performans ve kullanım verilerini izlemek için kullanılan bir APM hizmetidir. Kullanıcı davranışlarını, istek performansını ve hataları gerçek zamanlı olarak takip etmeyi sağlar. Ayrıca, Azure’un diğer hizmetleriyle entegre çalışarak merkezi izleme, uyarı mekanizmaları ve veri analizi imkanları sunar.

APM (Application Performance Monitoring) Araçları #

• Bu tüm araçlarg genellikle önce gelen veri paketlerini kaydeder, sonrasında da indexleyerek sorgulanabilir ve görselleştirilebilir hale getirir.

Trace Data Nedir? #

• Tracing, logların daha özelleşmiş bir formudur ve uygulamada meydana gelen olayları daha detaylı biçimde gösterir.
• Bu sayede performansla ilgili problemleri, hangi adımda gecikme yaşandığını ve işlemlerin genel gidişatını inceleyebilirsiniz.
• .NET 5 öncesindeki projelerde, System.Diagnostic.DiagnosticSource paketine ihtiyaç duyulur.

Trace Data İçeriği #

Bir trace, uygulamanın farklı katmanları veya bileşenleri arasındaki etkileşimleri ayrıntılı bir şekilde gösterir. Örneğin:

• HTTP Request: İsteğin gönderilme ve alınma süresi.
• HTTP Response: Dönen cevabın içeriği ve genel yanıt süresi.

Trace Data İçeriği #

• Veritabanı İşlemleri (DB): Komutların (query, insert, update vb.) ne kadar sürdüğü ve hangi tabloların etkilendiği.
• Başka Bir API’ye Çağrı (Another API): Harici servis veya mikroservis iletişimi.
• Metot Çağrıları (Method): Metot içerisinde gerçekleşen adımlar, parametreler ve süre bilgisi.
• Queue İşlemleri (Queue): Sıralarda bekleyen mesajlar, gönderim ve tüketim süreleri.

Trace Data İçeriği #

Bu veriler, tek bir zincir (trace) üzerinde segmentler (span) şeklinde toplanır ve böylelikle uçtan uca bir görünürlük elde etmenizi sağlar.

Kurulum #

Console Demo #

Console Demo #

Resource Nedir ve Nasıl Yapılandırılır? #

OpenTelemetry’de Resource, hangi servis veya uygulamanın veri ürettiğini tanımlayan ve telemetri (Trace, Metrics, Logs) verilerine bağlam kazandıran meta bilgileri içerir. Bu sayede, ürettiğiniz verilerin hangi servis tarafından, hangi sürümde, hangi ortamda (örn. dev, preprod, prod) veya hangi instance (kopya) üzerinden geldiğini anlayabilirsiniz.

Resource Üzerinde Tanımlanabilen Bilgiler #

1. Service Name

   • Uygulama veya servisin adı. (Örneğin: PaymentService)

2. Service Version

   • Uygulamanın hangi sürümünün çalıştığını belirtir. (Örneğin: 1.0.0)

Resource Üzerinde Tanımlanabilen Bilgiler #

3. Namespace

   • Bir uygulama veya servis ailesinin/alanının adı olarak düşünebilirsiniz. (Örneğin: MyCompanyName.PaymentSystem)

4. Instance

   • Servisin belirli bir kopyası. (Örneğin: payment-service-instance-2)

Resource Üzerinde Tanımlanabilen Bilgiler #

5. Deployment Environment (örn. dev, preprod, prod)
   • Static property olarak veya değişken üzerinden tanımlayabilirsiniz. Böylece telemetri verilerinin hangi ortamdan geldiği kolayca anlaşılır.

Örnek Resource Tanımı #

var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .SetResourceBuilder(
        ResourceBuilder.CreateDefault()
            .AddService(
              serviceName: "PaymentService",
              serviceVersion: "1.0.0")
            .AddAttributes(new Dictionary<string, object>
            {
                ["deployment.environment"] = "dev", // Ortam bilgisi
                ["service.instance.id"] = "instance-001" // Instance
            })
    )
    // Exporter vb. diğer ayarlar
    .AddConsoleExporter()
    .Build();

AgentSource (TraceProvider) #

• Tanım: Uygulamada trace verilerinin üretildiği ana sınıflardır.
• Amaç: Trace verilerini oluşturarak, hangi işlemlerin ne kadar sürdüğünü ve hangi bileşenler arasında gerçekleştiğini izlememizi sağlar.

AgentSource (TraceProvider) #

• Tasarım:
  • Static veya Singleton şeklinde tasarlanmalıdır, böylece uygulama içinde merkezi ve tutarlı bir yerden yönetilebilir.
  • Benzer şekilde, namespace yapısını kullanarak farklı traceleri mantıksal olarak ayırabilir veya gruplandırabilirsiniz.

AgentSource (TraceProvider) #

• Faydalar:
  • Uygulamanın belirli kısımlarından veya mikroservislerden üretilen verileri daha düzenli takip etme olanağı sunar.
  • Tek noktada konfigüre edildiğinden, kaynak yönetimi (örneğin, tek bir Tracer Provider üzerinden farklı bileşenlerin izlenmesi) kolaylaşır.
  • Şeffaf gözlemlenebilirlik elde etmeye yardımcı olur, çünkü tüm izleme (tracing) aktiviteleri ortak bir kayıt noktası üzerinden yönetilir.

Activity (Span) #

• Uygulamadaki her bir operasyon, bir span (örneğin: HTTP isteği, veritabanı çağrısı, dosya yazma) şeklinde temsil edilir.
• Bu span’lerin bir araya gelmesiyle bir trace (işlem bütünlüğü) oluşur.

Span İçeriği #

• Start-end time: Span’in başlama ve bitiş zamanı
• Success-failure: İşlemin başarılı mı yoksa hatalı mı sonuçlandığı
• Span kind: Span’in rolü (client, server, consumer, producer, internal)
• Attributes/Tags: Operasyona dair ek bilgiler (örn. kullanıcı kimliği, sürüm bilgisi vb.)
• Events: Span sürecindeki belirli olaylar veya kontrol noktaları (checkpoints)

Span ve Trace Arasındaki İlişki #

• Span: Tek bir operasyonu temsil eder.
• Trace: Birden fazla span’in birleşerek oluşturduğu, uçtan uca bütün bir işlemi ifade eder.

Activity (Span) Kind #

• Internal: Uygulama içindeki dahili bir işlemi ifade eder.
• Server: İstekleri sunucu tarafında karşılayan veya işleyen taraftır.
• Client: Dış bir kaynağa veya hizmete istek gönderen taraftır.
• Producer: Mesaj veya veri üreterek bir kuyruğa, topic’e veya başka bir yere yayımlayan taraftır.
• Consumer: Yayınlanmış mesajları veya event’leri alan ve işleyen taraftır.

Activity.Current #

• Tanım: .NET uygulamalarında halihazırda etkin (aktif) olan Activity nesnesine (span) erişim sağlar.
• Kullanım: Aşağıdaki örnek, Activity.Current üzerinden mevcut işlem (span) bilgisini elde etmeye yarar. Örneğin, etiket eklemek veya durum güncellemesi yapmak istediğinizde Activity.Current?.SetTag("key", "value") şeklinde çağrı yapabilirsiniz.

Activity.Current #

• Örnek Senaryo:
  1. Bir HTTP isteği geldiğinde, yeni bir Activity başlatılır (veya otomatik başlatılır).
  2. Bu süreçte, Activity.Current o anki isteği temsil eden span’i gösterir.
  3. Ek etiketler, event’ler veya hata durumlarıyla ilgili kayıtlar bu aktif Activity üzerinden yapılır.

Önemli Not: Activity.Current, her zaman aktif bir işlem (span) olmayabilir. Bu nedenle, kod yazarken null durumlarını dikkate almak gereklidir.

ActivityListener #

• Tanım: .NET uygulamalarında, oluşturulan veya bitirilen Activity (yani Span) nesnelerini dinlemek (listen) ve yönetmek için kullanılan bir mekanizmadır.
• Amaç: Uygulamada hangi Activity’lerin (işlemlerin) izlenmesi, örneğin hangilerinin kaydedilmesi veya kaydedilmemesi gerektiğine karar vermenizi sağlar.

ActivityListener #

• Nasıl Çalışır:
  1. ActivityListener nesnesi oluşturulur.
  2. İlgili geribildirim (callback) yöntemleri tanımlanır, örneğin:
     • ShouldListenTo (hangi ActivitySource’ları dinlemek istediğimizi belirtir)
     • Sample (hangi Activity’lerin başlatılıp başlatılmayacağına karar verir)
     • ActivityStarted/ActivityStopped (bir Activity başladığında veya bittiğinde çalışacak event metodları)
  3. Bu listener, ActivitySource nesnesine veya genel ActivitySource.AddActivityListener(activityListener) gibi bir API üzerinden eklenir.

Örnek Kullanım #

using System;
using System.Diagnostics;

public class ActivityListenerExample
{
    public static void SetupListener()
    {
        var listener = new ActivityListener
        {
            // Hangi ActivitySource'ları dinleyeceğimize karar veriyoruz.
            ShouldListenTo = (activitySource) =>
            {
                // Örneğin, "MyCompany.MyApp" adındaki ActivitySource’lara izin ver
                return activitySource.Name.Contains("MyCompany.MyApp");
            },

            // Activity oluşturulmadan önce “örnekleme” kararı veriyoruz (ör. kaydetsin mi kaydetmesin mi).
            Sample = (ref ActivityCreationOptions<ActivityContext> options) =>
            {
                // Belli bir mantığa göre (ör. rastgele yüzdelik, environment bilgisi vb.) karar verebilirsiniz.
                // Örnekte tüm Activity'leri kaydediyoruz:
                return ActivitySamplingResult.AllDataAndRecorded;
            },

            // Activity başladığında çalışacak callback
            ActivityStarted = activity =>
            {
                Console.WriteLine($"Activity Started: {activity.DisplayName}");
            },

            // Activity bittiğinde çalışacak callback
            ActivityStopped = activity =>
            {
                Console.WriteLine($"Activity Stopped: {activity.DisplayName}");
            }
        };

        // Listener'ı default ActivitySource'a ekliyoruz.
        ActivitySource.AddActivityListener(listener);
    }
}

Bu Örnekte #

• ShouldListenTo: Hangi ActivitySource’ları dinlemek istediğimizi belirtiyoruz.
• Sample: Hangi Activity’lerin gerçekten oluşturulacağını veya kaydedileceğini kontrol edebiliyoruz.
• ActivityStarted ve ActivityStopped: Oluşturulan Activity’lerin başlangıç ve bitiş anlarında özel işlem yapabiliyoruz (örnek olarak konsola yazma).

Neden Önemli? #

• Filtreleme: Çok fazla Activity oluşturulduğunda, dinlemek istediklerimizi kısıtlayarak sistem yükünü azaltabilirsiniz.
• Merkezi Yönetim: Tracing mantığını uygulamanın çeşitli yerlerine serpmek yerine, tek bir noktadan (ActivityListener) yönetebilirsiniz.

Neden Önemli? #

• Esneklik: Gerçek zamanlı olarak hangi span’lerin kaydedilmesi gerektiğini değiştirerek (örneğin, hata modunda tüm tracing’i aktif hale getirerek) sistem davranışını dinamik olarak ayarlayabilirsiniz.
• İnce Ayar: Özel mantıklar (ör. belirli bir kullanıcıya veya siparişe ait Activity’leri kaydetme) tanımlayarak ince düzeyde kontrol sağlayabilirsiniz.

Instrumentations Nedir? #

Instrumentations, bir uygulamanın belirli bölümlerini (ör. ASP.NET Core, HttpClient, Entity Framework, Redis, RabbitMQ) otomatik olarak izlenebilir hâle getiren bileşenler veya kütüphanelerdir. Bu sayede, uygulamanızın farklı katmanlarında (ör. web istekleri, veri tabanı işlemleri, mesaj kuyruğu vb.) gerçekleşen olaylar ve performans metrikleri otomatik olarak toplanır ve kaydedilir.

• Neden Gerekli?
  • Uygulamanın kritik noktalarını (API çağrıları, veritabanı sorguları, mesaj kuyruğu işlemleri vb.) tek tek manuel kodlamadan izlemeye olanak tanır.
  • Performans sorunlarını veya hataları hızlı bir şekilde tespit edip kök neden analizi (root cause analysis) yapmak kolaylaşır.

• Nasıl Çalışır?
  • Geliştiriciler, ilgili instrumentation paketini projeye ekler (NuGet).
  • Uygulamaya, konfigürasyonla hangi bileşenlerin izleneceği belirtilir (AddAspNetCoreInstrumentation, AddHttpClientInstrumentation, vb.).
  • Toplanan veriler, tercihe göre Jaeger, Zipkin, Elastic APM gibi dış araçlara veya konsola gönderilir (export edilir).

Özetle: Instrumentations, uygulamanızdaki karmaşık işlemleri elle uğraşmadan otomatik olarak ölçümleyerek daha kolay gözlemleme (observability) sağlar.

1. ASP.NET Core Instrumentation #

• Amaç: ASP.NET Core uygulamanızın HTTP isteklerinin süresini, yanıt kodlarını ve performansını otomatik olarak ölçmek.
• Neler Ölçülür?
  • Giden/gelen HTTP istekleri
  • İstek başlama ve bitiş zamanı
  • Yanıt durum kodu (ör. 200, 404, 500)
  • İstek başlıkları ve yol (endpoint) bilgileri

1. ASP.NET Core Instrumentation #

• Fayda:
  • Uygulamanıza ek middleware eklemeden, out-of-the-box izleme alabilirsiniz.
  • Hangi endpoint’lerin ne kadar sıklıkla ve hangi sürelerde çalıştığını görebilirsiniz.

2. HttpClient Instrumentation #

• Amaç: Uygulamanız içindeki HttpClient çağrılarını izlemek ve performans sorunlarını tespit etmek.
• Neler Ölçülür?
  • Yapılan dış istek (URL), metot (GET, POST vb.)
  • Başlangıç ve bitiş zamanı
  • Yanıt kodu ve süresi (latency)

2. HttpClient Instrumentation #

• Fayda:
  • Mikroservisler veya harici API’lere yapılan çağrıları kolayca takip edersiniz.
  • Yanıt süresi uzun mu, hatalar hangi oranda gerçekleşiyor vb. sorulara yanıt bulabilirsiniz.

3. Entity Framework Instrumentation #

• Amaç: Entity Framework (EF Core) ile yapılan veritabanı işlemlerini (sorgu, ekleme, güncelleme) otomatik olarak izlemek.
• Neler Ölçülür?
  • Oluşturulan sorgular (SQL)
  • Her sorgunun çalışma süresi (latency)
  • Hata durumu (ör. time-out, bağlantı hatası)

3. Entity Framework Instrumentation #

• Fayda:
  • Veritabanı katmanındaki performans darboğazlarını (örneğin uzun süren sorgular) kolayca tespit edebilirsiniz.
  • Tracing üzerinden hangi üst işlem (HTTP istek, background job vb.) sırasında bu sorguların tetiklendiğini görebilirsiniz.

4. Redis Instrumentation #

• Amaç: Redis kullanımıyla ilgili performans ve hata gözlemlemek (GET, SET, Publish/Subscribe vb.).
• Neler Ölçülür?
  • Redis komutları (örn. GET, SET, MGET, PUBLISH)
  • Komutun başlangıç ve bitiş zamanı
  • Hata durumları (ör. bağlantı hataları, time-out)

4. Redis Instrumentation #

• Fayda:
  • Redis çağrılarının ne kadar sık yapıldığını ve ne kadar sürdüğünü tespit edebilirsiniz.
  • Uygulamanın nakit (cache) katmanında olup bitenleri tek bir trace altında izlemek mümkündür.

5. MassTransit Library Instrumentation #

• Amaç: RabbitMQ üzerinden mesajların kuyruklanması ve işlenmesi sürecini izlemek.
• MassTransit Kütüphanesi: .NET dünyasında RabbitMQ gibi mesajlaşma altyapılarına dair kolaylaştırıcı bir çerçeve (framework) sunar.

5. MassTransit Library Instrumentation #

• Neler Ölçülür?
  • Kuyruğa gönderilen mesajlar (Publish/Send)
  • Tüketici (Consumer) tarafından alınan mesajların işleme süresi
  • Hata durumları (ör. ileti zaman aşımı, işleyici (handler) hatası)

5. MassTransit Library Instrumentation #

• Fayda:
  • Dağıtık bir mimaride, mesajların uçtan uca (publish -> queue -> consumer) hangi aşamalardan geçtiğini görebilir, hangi aşamada gecikme ya da hata oluştuğunu tespit edebilirsiniz.
  • MassTransit ile entegre bir şekilde izleme sağlayarak, iş akışını (workflow) uçtan uca izleyebilirsiniz.