Backend & Yazılım Mimarisi 6 dk okuma

ASP.NET Core’da OpenTelemetry ile Gözlemlenebilirlik: 7 Adımda Üretim Telemetrisi

6 dk okuma

Giriş: ASP.NET Core OpenTelemetry neden önemli?

ASP.NET Core OpenTelemetry, modern .NET uygulamalarında dağıtık izleri (trace), metrikleri ve logları ortak bir gözlemlenebilirlik standardında toplamak için kullanılan en güçlü yaklaşımlardan biridir. Mikroservis sayısı arttıkça “hangi servis yavaşladı?”, “gecikme veritabanından mı geliyor?”, “hata hangi dış API çağrısında oluştu?” gibi sorular klasik log dosyalarıyla zorlaşır. OpenTelemetry, bu sinyalleri aynı istek bağlamında birleştirerek teşhisi sistematik hale getirir.

OpenTelemetry belirli bir APM ürününe bağımlı değildir. Uygulama telemetrisini üretir, OTLP gibi standart protokoller üzerinden Collector’a veya doğrudan bir gözlemleme arka ucuna gönderir. Böylece bugün Jaeger veya Grafana tabanlı bir yapı kullanırken yarın farklı bir gözlemleme platformuna geçmek daha kolay olur.

İçindekiler

  • OpenTelemetry nedir?
  • ASP.NET Core’da temel kurulum
  • Trace: isteğin yolculuğunu izlemek
  • Metric: sistem davranışını sayısallaştırmak
  • Log: trace bağlamıyla olayları anlamlandırmak
  • OTLP ve OpenTelemetry Collector
  • Production için iyi pratikler
  • Sonuç
  • SEO Yayın Ayarları
  • Araştırma Kaynakları

1. OpenTelemetry nedir?

OpenTelemetry (OTel), uygulamalardan telemetry verisi üretmek, işlemek ve dışa aktarmak için API, SDK, semantic convention ve araçlar sağlayan açık bir standarttır. .NET tarafında System.Diagnostics altyapısı ve OpenTelemetry SDK birlikte kullanılarak izleme sinyalleri oluşturulur. ASP.NET Core, modern .NET sürümlerinde dağıtık trace ve metrik üretimi için yerleşik System.Diagnostics mekanizmalarından yararlanır; ek instrumentation paketleri ise HTTP, runtime ve veri erişimi gibi alanlarda otomatik veri toplar.

Üç temel sinyal vardır: traces bir isteğin servisler arasındaki yolculuğunu, metrics zaman içindeki sayısal davranışı, logs ise ayrıntılı olay kayıtlarını temsil eder. En yüksek değer, bu sinyallerin aynı service name, environment, trace id ve ortak resource metadata ile ilişkilendirilmesinden gelir.

2. ASP.NET Core’da temel kurulum

Manuel instrumentation yaklaşımında OpenTelemetry SDK uygulama başlangıcında yapılandırılır. ASP.NET Core instrumentation gelen HTTP isteklerini, HttpClient instrumentation giden HTTP çağrılarını izleyebilir. Runtime ve process instrumentation paketleri de GC, thread pool, CPU ve süreç davranışı gibi metrikleri ekleyebilir.

builder.Services.AddOpenTelemetry()
.WithTracing(t => t
.AddAspNetCoreInstrumentation()
.AddHttpClientInstrumentation()
.AddOtlpExporter())
.WithMetrics(m => m
.AddAspNetCoreInstrumentation()
.AddHttpClientInstrumentation()
.AddRuntimeInstrumentation()
.AddOtlpExporter());

Paket ve API ayrıntıları sürüme göre değişebileceği için uygulama sırasında güncel OpenTelemetry .NET dokümantasyonu esas alınmalıdır. Temel mimari değişmez: instrumentation → SDK/provider → exporter → Collector veya backend.

3. Trace: isteğin yolculuğunu izlemek

Trace, bir kullanıcı isteğinin API gateway’den başlayıp ASP.NET Core servisine, oradan HttpClient ile başka bir servise ve SQL çağrısına kadar nasıl ilerlediğini gösterir. Her önemli operasyon bir span olarak temsil edilir. Span süreleri, hata durumu, endpoint, servis adı ve ilişkili metadata sayesinde gecikmenin kaynağı görülebilir.

Özel iş adımlarında ActivitySource kullanarak uygulama seviyesinde span eklemek mümkündür. Ancak her metoda span eklemek iyi fikir değildir. Checkout, ödeme doğrulama, sipariş oluşturma veya model inference gibi gerçekten teşhis değeri olan iş operasyonları seçilmelidir.

4. Metric: sistem davranışını sayısallaştırmak

Metrikler, tek bir isteği değil sistemin zaman içindeki davranışını anlamaya yarar. Request rate, hata oranı, latency histogramları, active request sayısı, GC pause, allocation ve thread pool göstergeleri üretim sağlığının temel göstergeleridir. Dashboard ve alarm kuralları çoğunlukla metriklerden beslenir.

Özel metriklerde düşük cardinality kritik önemdedir. UserId, OrderId veya benzersiz URL gibi çok fazla farklı değer üreten etiketler metric backend maliyetini ve sorgu yükünü büyütür. Boyutlar; environment, region, endpoint group veya result type gibi kontrollü kümelerden seçilmelidir.

5. Log: trace bağlamıyla olayları anlamlandırmak

Loglar hâlâ ayrıntılı hata teşhisinin vazgeçilmezidir; ancak dağıtık sistemlerde tek başına yeterli değildir. İdeal durumda log kaydı TraceId ve SpanId içerir. Böylece bir hata logundan ilgili trace’e, trace’den yavaş span’e geçilebilir. Structured logging kullanmak ve kritik alanları ayrı property olarak tutmak aramayı kolaylaştırır.

Kişisel veri, access token, connection string veya hassas payload gibi bilgilerin telemetry içine sızmaması gerekir. Logging ve span enrichment politikaları veri minimizasyonu prensibiyle tasarlanmalıdır.

6. OTLP ve OpenTelemetry Collector

OTLP, OpenTelemetry verisini taşımak için kullanılan standart protokoldür. Uygulamaların her gözlemleme ürününe özel exporter bağımlılığı taşımaması için Collector iyi bir ara katmandır. Collector telemetry kabul edebilir, batch işlemi yapabilir, attribute filtreleyebilir, örnekleme uygulayabilir ve veriyi bir veya birden fazla hedefe yönlendirebilir.

Bu yaklaşım özellikle Kubernetes ve mikroservis ortamlarında değerlidir. Backend adresi veya kimlik bilgisi değiştiğinde onlarca uygulamayı yeniden dağıtmak yerine Collector yapılandırması güncellenebilir. Ayrıca sampling ve redaction gibi ortak politikalar merkezileştirilebilir.

7. Production için 7 iyi pratik

  1. Service name, deployment.environment.name ve service.version gibi resource alanlarını standartlaştırın.
  2. Trace sampling oranını trafik hacmine göre belirleyin; yüksek trafikte her trace’i saklamak maliyetli olabilir.
  3. Health-check ve gürültülü endpoint’leri filtreleyerek gereksiz telemetry miktarını azaltın.
  4. Yüksek cardinality metric tag’lerinden kaçının.
  5. PII, token ve hassas verileri span/log attribute’larına yazmayın.
  6. Collector’ı merkezi policy noktası olarak kullanın ve OTLP akışını TLS ile koruyun.
  7. Dashboardları yalnız teknik metriklere değil SLI/SLO hedeflerine bağlayın: availability, latency ve error rate.

Sonuç

ASP.NET Core OpenTelemetry kullanmak, log toplamaktan daha kapsamlı bir adımdır: amaç trace, metric ve logları ortak bir bağlamda birleştirerek sistem davranışını uçtan uca görünür hale getirmektir. Küçük bir API’de bile doğru service metadata, ASP.NET Core + HttpClient instrumentation ve OTLP export ile başlanabilir. Sistem büyüdükçe Collector, sampling, metric cardinality ve veri güvenliği politikaları eklenerek üretim seviyesinde sürdürülebilir bir observability mimarisi kurulabilir.

En önemli kazanım araç seçimi değil, standartlaştırılmış telemetry akışıdır. Bu sayede sorun çözme süresi kısalır, servis bağımlılıkları görünür olur ve performans iyileştirmeleri ölçülebilir hale gelir.

Araştırma Kaynakları

Paylaş