Forem: Sıla Sarı

Performans Ve Güvenilirlik Ölçekleri

Sıla Sarı — Wed, 31 Jul 2024 13:52:01 +0000

Bu yazıda, uygulamaların izlenebilmesi için kullanılabilecek TPM, gecikme ölçütleri (P90, P99), başarısızlık oranı (failure rate), kullanıcı memnuniyetsizliği (user misery), Apdex, özel eşik (custom thresholds) metriklerin her birini ayrıntılı bir şekilde ele alarak, bunların nasıl hesaplandığını, ne anlama geldiğini ve sistem performansını nasıl iyileştirebileceğinizi inceleyeceğim.

TPM (Transactions Per Minute, Dakika Başına İstek Sayısı)

TPM, dakikada gerçekleştirilen işlem sayısını ifade eden bir performans metriğidir. Bu metrik, bir sistemin veya uygulamanın ne kadar yoğun bir şekilde kullanıldığını ve sistemin yük altında nasıl performans gösterdiğini anlamak için kullanılır. TPM metriği, sistem kapasitesini değerlendirmek ve gelecekteki yük artışlarını öngörmek için kritik bir araçtır.

TPM = Toplam İstek Sayısı / Süre (Dakika Cinsinden)

Gecikme ölçütleri

Gecikme, bilgisayar sistemleri, ağlar ve gerçek zamanlı işlem gerektiren uygulamaların performansını ölçmek için önemli bir metriktir. Bir isteğin gönderilmesi ile ilgili yanıtın alınması arasındaki zaman gecikmesini ifade eder.

Gecikme ölçümü: P90, P99 ve Ortalama Yanıt Süreleri

P90, yanıt sürelerinin %90'ının bu süre içinde tamamlandığını ifade ederken; P99, yanıt sürelerinin %99'unun bu süre içinde tamamlandığını gösterir. Bu yüzdelikler, yanıt sürelerinin dağılımının "uç kısmını" tanımlamak için kullanılır. Farklı yüzdelik dilimlere bakmak, uygulamanızın yavaş performans gösterdiği noktaları anlamanıza yardımcı olabilir. P50, P90 ve P99 gibi metrikler, API çağrılarının ne kadar hızlı işlendiğini gösterir. Örneğin, P90 gecikmesi 10 ms olan bir uç nokta, %90'lık kısmın 10 ms içinde tamamlandığını belirtir. Ancak, P99 gecikmesi 500 ms ise, %99'luk kısmın 500 ms içinde tamamlandığını gösterir. Bu, %1'lik dilimdeki en yavaş çağrıları da dikkate almanızı sağlar. Eğer P99.9 gecikmesi analiz edilirse, çağrıların %99.9'unun çok daha düşük bir süre içinde işlendiğini görerek en uç yavaşlığı inceleyebilirsiniz. Bu metrikler, performans sorunlarını belirlemenize ve iyileştirme yapmanıza olanak tanır.

Ortalama yanıt süresi, tüm yanıt sürelerinin aritmetik ortalamasıdır ve sistemin veya uygulamanın tipik yanıt süresi hakkında genel bir fikir verir. Ancak, uç değerler veya uzun kuyruk nedeniyle sapma gösterebilir. Bu nedenle, P90 ve P99 gibi yüzdelikler, gecikme dağılımı hakkında daha detaylı bilgi sağlar.

Başarısızlık Oranı (Failure Rate)

Başarısızlık oranı, bir sistemin veya uygulamanın belirli bir süre içindeki başarısızlıklarının yüzdesini ifade eder. Bu oran, sistemin güvenilirliği ve kullanıcı memnuniyeti açısından kritik bir göstergedir. Yüksek başarısızlık oranı, kullanıcı deneyimini olumsuz etkileyebilir ve hizmet kalitesinde düşüşe neden olabilir. Başarısızlık oranı, aşağıdaki formülle hesaplanır.

Başarısızlık Oranı = Başarısız İstek Sayısı / Toplam İstek Sayısı

Kullanıcı Memnuniyetsizliği (User Misery)

Kullanıcı memnuniyetsizliği, uygulamanızın performansını kullanıcı ağırlıklı olarak değerlendiren bir metriktir. Bu metrik, kullanıcıların uygulamanın performansından ne kadar etkilendiğini ölçer. Belirli bir yanıt süresi eşik değerinin (ms) dört katı gecikme yaşayan benzersiz kullanıcıların sayısını sayar. Bu metrik, kullanıcılar üzerinde en yüksek etkiye sahip işlemleri vurgular.

Her proje için memnun edici eşik değerlerini özel olarak ayarlayabilirsiniz. Kullanıcı memnuniyetsizliği, olasılık dağılımı kullanılarak hesaplanır. Bu, yanlış pozitif sonuçları önler ve düşük etkinlik hacmine sahip veri setleri için makul değerler sağlar.

Kullanıcı Memnuniyetsizliği Skoru = Memnuniyetsiz Kullanıcı Sayısı /Toplam Kullanıcı Sayısı

Apdex (Application Performance Index)

Apdex, uygulama yanıt sürelerine dayanarak kullanıcı memnuniyetini izlemek ve ölçmek için kullanılan bir metriktir.Apdex skoru 0 ile 1 arasında değişir. Skorun 1 olduğu durum, kullanıcıların %100'ünün memnun olduğu anlamına gelir. Apdex skoru, belirli bir işlem veya uç noktadaki memnun, tolere edilebilir ve hayal kırıklığına uğramış isteklerin oranını sağlar. Bu metrik, işlem performansını karşılaştırmak, hangi işlemlerin ek optimizasyon veya araştırma gerektirdiğini anlamak ve performans için hedefler belirlemek için bir standart sunar.

Apdex'in bileşenleri ve formülü aşağıdadır:

T: Hedef yanıt süresi eşiği.
Memnun (Satisfactory): Kullanıcılar, sayfa yükleme süreleri T'ye eşit veya T'den küçük olduğunda memnun olurlar.
Tolere Edilebilir (Tolerable): Kullanıcılar, sayfa yükleme süreleri T'den büyük ve 4T'ye eşit veya 4T'den küçük olduğunda uygulamayı tolere edilebilir bulurlar.
Hayal Kırıklığına Uğramış (Frustrated): Kullanıcılar, sayfa yükleme süreleri 4T'den büyük olduğunda hayal kırıklığına uğrarlar.

Apdex Formülü:
Apdex = (Memnun İstek Sayısı + (Tolere Edilebilir İstek Sayısı/2)) /Toplam İstek Sayısı

Özel Eşik (Custom Thresholds)

Özel eşik, Apdex ve diğer performans metrikleri için belirli bir işlem veya uç nokta için kullanıcı memnuniyeti seviyelerini tanımlamak üzere kullanılan bir özelliktir. Bu eşikler, kullanıcıların uygulamanızdaki deneyimlerini daha hassas bir şekilde ölçmek ve iyileştirmek için yapılandırılabilir.

Özel Eşiklerin Bileşenleri ve Kullanımı:

T (Hedef Yanıt Süresi): Kullanıcıların memnun kalacağı yanıt süresi eşiği. Bu eşik, kullanıcıların uygulamanın performansını tatmin edici bulacakları süredir.
4T (Tolere Edilebilir Yanıt Süresi): Kullanıcıların uygulamayı tolere edilebilir bulacakları maksimum yanıt süresidir. Bu eşik, memnuniyet eşiğinden dört kat daha fazladır.

Her proje için özel yanıt süresi eşiklerini yapılandırabilirsiniz. Bu, çeşitli işlemler veya uç noktalar için farklı memnuniyet ve tolere edilebilirlik seviyeleri belirlemenize olanak tanır. Bu özellik, uygulamanızın çeşitli bölümleri için daha uygun ve anlamlı performans hedefleri belirlemenize yardımcı olur. Örneğin, bazı işlemler daha hızlı yanıt süreleri gerektirebilirken, diğerleri daha uzun süreler tolere edilebilir.

Örnek Konfigürasyon:

Bir uygulama için memnuniyet eşiği 200 ms olarak belirlenebilir.
Tolere edilebilir eşik, memnuniyet eşiklerinin dört katı olan 800 ms olarak ayarlanabilir.

Bu özelleştirilebilir eşikler, uygulamanızın farklı bölümleri veya işlemleri için performans hedeflerinizi daha doğru bir şekilde yansıtmak ve kullanıcı deneyimini iyileştirmek için kullanılır.

Özet

Bu yazıda, uygulama performansını izlemek ve değerlendirmek için kullanılan çeşitli metrikler ele alınmıştır. Her bir metrik, sistemin performansını ve kullanıcı memnuniyetini anlamak için farklı bir perspektif sunar ve performans analizleri ile iyileştirme stratejileri geliştirmek için önemlidir. Özellikle; TPM uygulamanın kullanım yoğunluğunu, gecikme ölçütleri performans değerlerini, başarısızlık oranı sorun yaşanma oranını, Apdex işlemlerin performanslarını karşılaştırmak, özel eşikler belirli işlemler için performans hedeflerini hassas bir şekilde ayarlamak için kullanılır.

Jaeger ile Response Body İzleme: OpenTelemetry ve .NET Entegrasyonu

Sıla Sarı — Mon, 22 Jul 2024 15:01:42 +0000

Giriş

Bu dokümantasyonda, .NET uygulamanızda OpenTelemetry kullanarak Jaeger üzerinde response body'nin nasıl görselleştirileceğini maddeler halinde açıklayacağım. Amacımız, iki güçlü gözlemleme aracını kullanarak uygulamanızdaki işlemleri izlemek ve detaylı bir şekilde analiz etmek.

Adımlar

1) Gerekli paketleri yükleyin

İlk olarak, OpenTelemetry ve Newtonsoft.Json paketlerini projenize ekleyin:

dotnet add package OpenTelemetry
dotnet add package Newtonsoft.Json

2) Controller sınıflarınıza kütüphaneleri ekleyin

İzleme yapmak istediğiniz controller sınıflarınıza aşağıdaki kütüphaneleri ekleyin. Bu, OpenTelemetry ve JSON işlemleri için gerekli olacaktır.

using OpenTelemetry;
using OpenTelemetry.Trace;
using Newtonsoft.Json;

3) İzleme yapmak istediğiniz methodlara span ekleyin

İzleme yapmak istediğiniz metotların içine girerek span tanımlaması yapın. Span, izlenmekte olan bir işlemi temsil eder ve bu işlemin ayrıntılarını kaydeder.

var currentSpan = Tracer.CurrentSpan;

Bu satır, şu anda yürütülen span'i alır ve izleme yapmaya hazır hale getirir.

4) Response body'nin Kaydedilmesi

var responseBody = new {
//izlemek istediğiniz özellikleri buraya ekleyin
        AccountId = account.AccountId, 
        NewBalance = account.Balance
};

5) Response body'yi JSON stringe dönüştürme

Tanımladığınız response body'yi JSON formatına dönüştürün. Bu, response body'yi Jaeger üzerinde daha kolay görselleştirmenizi sağlar.

var responseBodyJson = JsonConvert.SerializeObject(responseBody);

6) Response body'yi span attribute olarak ekleme

Son olarak, JSON formatındaki response body'yi span attribute olarak ekleyin.

currentSpan.SetAttribute("http.response.body", responseBodyJson);

Bu adım, response body'nin izleme verilerine eklenmesini sağlar ve Jaeger üzerinde kolayca görselleştirilebilir hale getirir.

Sonuç

Bu adımları takip ederek, .NET uygulamanızda OpenTelemetry ve Jaeger kullanarak response body'yi görselleştirebilirsiniz. Böylece, uygulamanızın izlenebilirliğini ve analiz edilebilirliğini artırabilirsiniz.

OpenTelemetry Uygulaması .NET'te Kod Yazmadan İzleme Ekleme

Sıla Sarı — Thu, 18 Jul 2024 05:01:56 +0000

Giriş

Bu doküman OpenTelemetry .NET otomatik enstrümasyonu kullanarak .NET uygulamalarından ve servislerinden kaynak kodlarını değiştirmeden izleme verilerini görebilmeyi maddelerle açıklamaktadır.

Gereksinimler

En düşük desteklenen .NET Framework sürümü 4.6.2'dir.

Adımlar

1. Bash script'i indirin

Bu script, otomatik kurulumu sağlayacak olan temel dosyaları içerir.

curl -sSfL https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/releases/latest/download/otel-dotnet-auto-install.sh -O

2. Çekirdek dosyaları yükleyin

İndirdiğimiz bash script'ini kullanarak, OpenTelemetry .NET için gerekli olan dosyaları yüklüyoruz. Bu adım, enstrümantasyonun çalışması için gerekli olan alt yapıyı hazırlar.

sh ./otel-dotnet-auto-install.sh

3.Enstrümantasyonun betiğinin çalıştırılabilir yapılmasını sağlayın

Bu adım betiğin başarıyla tamamlanabilmesi için gereklidir.

 . $HOME/.otel-dotnet-auto/instrument.sh

4. Geçerli kabuk oturumu için enstrümantasyonu ayarlama

Bu komut uygulamayı etkinleştirilmiş OpenTelemetry izleme işlemleriyle çalıştırmak için kullanılır.

OTEL_EXPORTER_OTLP_ENDPOINT=your-endpoint OTEL_SERVICE_NAME=your-app OTEL_RESOURCE_ATTRIBUTES=deployment.environment=staging,service.version=1.0.0 ./your-app

Projeniz .NET 8 ile derlendiğinde, çalıştırılabilir uygulamanız genellikle proje dizininizdeki bin/debug veya bin/Release klasörlerinde bulunur. Terminal veya Komut istemi üzerinden proje dizinine giderek bin/debug klasörüne erişin. Burada, .NET 8 tarafından derlenen ve çalıştırılabilir hale getirilen uygulamanızın adını (your-app) ve konumunu bulabilirsiniz.

OTEL_EXPORTER_OTLP_ENDPOINT ayarı, izleme verilerinin gönderileceği OpenTelemetry collector veya başka bir izleme backend'ini belirtir;
OTEL_SERVICE_NAME, izleme verilerinde kullanılacak servis adını tanımlar;
OTEL_RESOURCE_ATTRIBUTES ise uygulamanızın dağıtım ortamı (örneğin, staging) ve sürümü (1.0.0) gibi ek bilgiler sağlar.

Komut satırı seçenekleri veya ortam değişkenleri aracılığıyla uygulamanızı başlatırken ek parametreler (örneğin OTEL_LOG_LEVEL=debug) veya çevresel değişkenler kullanabilirsiniz.

Not:İzlemek istediğiniz servisin ismini görmenize rağmen verileri göremiyorsanız uygulamanızın saatini kontrol etmeniz faydalı olacaktır.