Modern sistemlerde “log var, metric var” demek yeterli değil. Bir incident sırasında cevap aranan soru şudur: aynı isteğin servisler arasındaki hareketini, gecikmesini ve hata nedenini tek bir akış olarak görebiliyor muyuz? OpenTelemetry bu problemi çözmek için ortaya çıkan ortak standarttır.
Neden tek araç değil, ortak bir telemetry standardı?
Kurumsal ortamlarda telemetry verisi çoğu zaman parçalıdır:
- Uygulama ekipleri APM kullanır.
- Sistem ekipleri node exporter ve sistem metriklerini toplar.
- Güvenlik ekipleri ayrı log hatlarına sahiptir.
- Platform ekipleri Kubernetes olaylarını başka yerde izler.
Bu parçalı yapı, özellikle hibrit mimarilerde kök neden analizini yavaşlatır. OpenTelemetry’nin değeri, veriyi tek ürün altında toplamasında değil; üretim biçimini standartlaştırmasındadır.
Temel mimari
Pratik ve sürdürülebilir bir observability pipeline şu bileşenlerden oluşur:
- Instrumentation katmanı: Uygulama içine trace ve metric üretimi eklenir.
- Collector katmanı: Veriler uygulamalardan merkezi toplayıcıya akar.
- Processor katmanı: Örnekleme, etiket temizleme, zenginleştirme ve routing yapılır.
- Exporter katmanı: Veriler Prometheus, Tempo, Loki, Elastic veya başka hedeflere aktarılır.
Bu modelin avantajı, backend değişse bile uygulama kodunun büyük ölçüde sabit kalmasıdır.
Collector neden kritik?
Collector kullanmadan doğrudan backend’e veri göndermek küçük sistemlerde işe yarayabilir. Fakat kurumsal ölçekte collector şarttır çünkü:
- Servis keşfi ve çoklu backend yönlendirmesi yapabilir.
- Hassas alanları maskeleyebilir.
- Maliyet yönetimi için örnekleme uygulayabilir.
- Log, metric ve trace verisini farklı hedeflere ayırabilir.
Başlangıç için örnek pipeline
Aşağıdaki yaklaşım, orta ölçekli bir platform için iyi bir başlangıçtır:
- Uygulamalar OTLP üzerinden collector’a veri yollar.
- Collector trace verisini Tempo’ya, metric verisini Prometheus uyumlu hedefe, log verisini Loki’ye iletir.
- Tüm sinyallerde ortak etiket standardı kullanılır:
service.name,deployment.environment,team,region.
receivers:
otlp:
protocols:
grpc:
http:
processors:
batch:
resource:
attributes:
- key: deployment.environment
value: production
action: upsert
exporters:
debug:
otlp/tempo:
endpoint: tempo.internal:4317
service:
pipelines:
traces:
receivers: [otlp]
processors: [resource, batch]
exporters: [otlp/tempo, debug]Etiket standardı olmadan observability eksik kalır
Birçok ekip telemetry toplamaya odaklanır ama veri modelini ihmal eder. Oysa etiket standardı yoksa sorgulanabilirlik zayıf kalır. Özellikle şu alanlar kurumsal mimaride kritik önem taşır:
- Servis adı
- Ortam bilgisi
- Bölge veya veri merkezi
- Takım sahipliği
- Uygulama kritikliği
Bu alanlar hem dashboard tasarımını hem de alarm yönlendirmesini doğrudan etkiler.
Log, metric ve trace birlikte nasıl okunur?
Sağlam bir incident akışında ekip şu sırayla hareket eder:
- Alarm metric tabanlı tetiklenir.
- İlgili servis trace görünümünde hangi downstream çağrılarda bozulma olduğunu gösterir.
- Aynı trace veya request kimliği ile uygulama logları açılır.
- Gerekirse node ve container seviyesi metric’lerle kapasite baskısı doğrulanır.
Bu zincir kurulmadığında ekipler aynı sorunu üç farklı ekrandan ayrı ayrı çözmeye çalışır.
Güvenlik ve maliyet dengesi
Observability sistemi de bir veri platformudur; dolayısıyla maliyet ve veri koruma sınırları net olmalıdır:
- PII alanları collector üzerinde maskeleyin.
- Her ortam için farklı örnekleme politikası uygulayın.
- Yüksek hacimli debug loglarını varsayılan olarak merkezi sisteme taşımayın.
- Veri saklama sürelerini iş ve regülasyon gereksinimlerine göre ayırın.
Sonuç
OpenTelemetry, tek başına sihirli bir araç değil; telemetry disiplinini standartlaştıran bir kontrol noktasıdır. Doğru kurulduğunda platform ekiplerine bağımsızlık, uygulama ekiplerine tutarlılık ve operasyon ekiplerine daha hızlı teşhis imkânı verir. Özellikle dağıtık servisler, ERP entegrasyonları ve hibrit altyapılar için uçtan uca görünürlük artık lüks değil, işletme gereksinimidir.