> tpl_arc_013
Gözlemlenebilirlik Mimarisi ve Telemetri Stratejisi
Birleşik dağıtık izlemeyi (W3C Trace Context, OpenTelemetry), metrik kardinalite kontrollerini, yapılandırılmış JSON günlük şemalarını, örnekleme oranı stratejilerini ve mikroservisler genelinde alarm gürültüsünü azaltmayı tanımlayan kapsamlı kurumsal gözlemlenebilirlik mimarisi ve telemetri standardı.
OpenTelemetry dağıtık izleme, metrik kardinalite sınırları, yapılandırılmış JSON günlükleme ve baş/kuyruk örnekleme stratejilerini yapılandıran birleşik gözlemlenebilirlik standardı.
Önemli Teknik Doküman Şablonu ve Hukuki Uyarı
TinyCTO.tv Teknik Doküman Şablon Bildirimi: Bu şablon genel eğitim ve operasyon amaçlı bir başlangıç materyalidir. Hukuki, vergisel, muhasebesel, yatırım, satın alma, mevzuat, güvenlik veya sertifikasyon danışmanlığı değildir. Gereklilikler ülkeye, kuruma, sözleşmeye ve riske göre değişir. Kullanmadan önce yetkin uzmanlarla gözden geçirip uyarlayın.
Çözülen Üretim Problemi
Mühendislik ekipleri dağıtık izleme olmaksızın pahalı izleme araçlarına yapılandırılmamış serbest metin loglar basar; bu da fırlayan bulut izleme faturalarına ve kritik kesintilerde kör noktalara yol açar.
Ne Zaman Kullanılmalı?
- •Çok dilli mikroservisler, Kubernetes kümeleri ve sunucusuz fonksiyonlar genelinde kurumsal gözlemlenebilirlik standartları kurarken
- •Dağıtık izler, metrikler ve günlükler için tedarikçiden bağımsız OpenTelemetry (OTel) araçlandırması uygularken
- •Metrik kardinalite patlamalarını kontrol altına alıp yüksek hacimli telemetri besleme maliyetlerini optimize ederken
Ne Zaman Kullanılmamalı?
- •Temel proje görev takibi ve sprint kalan iş (burndown) grafiklerinde (TPL-DEL-002 kullanın)
- •Müşteri anket NPS geri bildirim analitiğinde (TPL-PDS-003 kullanın)
5 Şablon Bölümü ve Yapısal İskelet
OpenTelemetry aracılığıyla Metriklerin (sayaçlar), Günlüklerin (yapılandırılmış JSON) ve İzlerin (dağıtık span'lar) entegrasyonu.
İz kimliği yayılımı (propagation), ebeveyn-çocuk span hiyerarşisi, veritabanı sorgu yakalama ve HTTP/Kafka üzerinden bağlam aktarımı.
Etiket/boyut bütçelemesi, yüksek kardinalite hataları (metriklerde user_id, email, UUID kullanımı), Prometheus kuralları ve hız sınırlandırma.
Standart şema alanları (timestamp, level, service, trace_id, span_id, message), log düzeyleri ve otomatik regex PII karartma.
Baş tabanlı olasılıksal örnekleme vs kuyruk tabanlı anomali örnekleme (hataların ve p99 izlerin %100'ü), SLO hata bütçesi tüketim alarmları.
Doldurma ve Uygulama Yönergeleri
Bağımsız İnceleme ve Onay Kontrol Listesi
- Tüm zorunlu bölümler dolduruldu
- Gizli anahtar veya parola içermiyor
- Yönetici sponsor onayı alındı
Gözlemlenebilirlik Mimarisi ve Telemetri Stratejisi - Örnek Vaka Analizi
Örnek Organizasyon: Sovereign Fintek Birleşik Gözlemlenebilirlik Mimarisi ve Telemetri Boru Hattı
Sovereign Fintek Birleşik Gözlemlenebilirlik Mimarisi ve Telemetri Boru Hattı için eksiksiz operasyonel uygulamayı gösteren gerçek dünya vaka analizi.
- •Kuyruk tabanlı örnekleme ve metrik kardinalite bütçelemesiyle yıllık Datadog maliyetleri %52 (380.000 $) azaltıldı
- •80 Kubernetes mikroservisi ve Kafka olay işleyicisi genelinde %100 uçtan uca dağıtık iz yayılımı sağlandı
- •OpenTelemetry Collector katmanında otomatik PII temizleme kurularak log depolarına müşteri kartı sızıntısı tamamen sıfırlandı
Sıkça Sorulan Sorular
Metrik kardinalitesi nedir ve kardinalite patlaması neden astronomik bulut faturalarına yol açar?
Metrik kardinalitesi, bir metriğin tüm etiket değerlerinin çarpımıyla oluşan toplam benzersiz zaman serisi sayısıdır. "status" (3 değer) ve "service" (10 değer) etiketleri 30 seri üretir. Ancak bir mühendis yanlışlıkla "user_id" (1.000.000 değer) eklerse, kardinalite 30 milyon seriye patlar; bu da bellekleri tüketir ve on binlerce dolar ek maliyet çıkarır.
Dağıtık izlemede baş tabanlı (head-based) ile kuyruk tabanlı (tail-based) örnekleme arasındaki fark nedir?
Baş tabanlı örnekleme, bir izin saklanıp saklanmayacağına istek başlarken rastgele karar verir (%5 örnekleme gibi). Bu da kalan %95'te gerçekleşen kritik üretim hatalarının kaçırılmasına yol açar. Kuyruk tabanlı örnekleme ise isteğin tüm adımlarını OpenTelemetry Collector'da tamponlar; istek bittiğinde inceleyerek hata veya yüksek gecikme içeren izlerin %100'ünü saklar.
Ekipler neden tekil sistem eşikleri yerine SLO hata bütçesi tüketim hızına göre alarm kurmalıdır?
Eşik tabanlı alarmlar (CPU > %80 veya hata > 10) aşırı alarm yorgunluğu üretir çünkü geçici dalgalanmalar kullanıcıyı etkilemeden düzelir. SLO hata bütçesi tüketim hızına göre alarm kurmak ise yalnızca müşteriye yansıyan güvenilirlik aylık bütçeyi saatler içinde tüketecek hızda bozulduğunda bildirim gönderir; böylece her alarm eyleme dönüştürülebilir olur.
Teknik Doküman Şablon Paketi
Giriş GerekliTüm boş şablonları, işlenmiş senaryoları ve doğrulama manifestolarını tek bir arşivde indirin.
Yetkili Standartlar ve Kaynaklar
- OpenTelemetry Architecture & SpecificationCloud Native Computing Foundation (CNCF) • OFFICIAL REQUIREMENT
- Google Site Reliability Engineering (SRE) Book: Monitoring Distributed SystemsGoogle SRE • OFFICIAL REQUIREMENT