OpenTelemetry rehberi: herhangi bir backend'e telemetry verisi gönderebilen ürünler geliştirme

Satıcıdan bağımsız telemetry için bir playbook

Hacker News'te öne çıkan, OpenTelemetry blogunda yayımlanan bir rehber, self-hosted yazılım ve SaaS ürünü sağlayıcılarının sistemlerini nasıl tasarlamaları gerektiğini açıklıyor; böylece müşteriler log, trace ve metric verilerini istedikleri observability backend'ine gönderebiliyor. New Relic'ten Dan Gomez Blanco'nun da katkıda bulunduğu yazıya göre kullanıcıları yerleşik panellerle sınırlamak ya da dışa aktarımı birkaç sağlayıcıya kısıtlamak, önlenebilir bir sürtünme yaratıyor. Yazıya göre müşteriler telemetry verilerini başka bir yere yönlendirmek için tekrar eden nedenlerle talepte bulunuyor: uyumluluk (compliance), maliyet kontrolü ve tüm observability verilerini tek bir yerde tutma.

Dört sinyal, tek protokol

OpenTelemetry dört sinyal türü tanımlar ve tümü OpenTelemetry Protocol (OTLP) üzerinden taşınır. Log'lar; zaman damgalı ve metadata'lı olay kayıtlarını, erişim log'larını ve uygulama log'larını kapsar; trace'ler, servisler arasındaki istek akışlarının görünür kalmasını ve log'larla ilişkilendirilebilmesini sağlayan dağıtık span'lar sunar; metric'ler; istek oranları, gecikme ve hata oranları gibi sayaç (counter), gösterge (gauge) ve histogramlardır; profile'lar ise bir uygulamanın çalışma sırasında kaynakları nerede tükettiğini gösteren örneklerdir.

Dışa aktarım deseni log, trace ve metric için aynıdır: kullanıcı bir OTLP endpoint'i yapılandırır ve telemetry verileri oraya gönderilir. Sağlayıcılar sinyallerin bir alt kümesini destekleyebilir, ancak yazı çoğu platformun zaten trace ve log'ları ele aldığına, metric desteğinin yaygınlaştığına ve baştan üçünü birlikte planlamanın sonradan ekleme maliyetinden kaçındığına dikkat çekiyor.

İyi bir dışa aktarım tasarımı nasıl görünür?

Rehber, iyi tasarlanmış bir telemetry sisteminin yaydığı her sinyal için dört özellik listeliyor:

• Satıcıdan bağımsızlık: kullanıcılar, sağlayıcıya özel entegrasyonlar geliştirmeye gerek kalmadan, ister bir OpenTelemetry Collector örneği ister protokolü doğrudan konuşan bir backend olsun, OTLP uyumlu herhangi bir hedefe yönlendirme yapabilir.
• Standart entegrasyon: harici platformlar ve kullanıcı araçları, tescilli API'ler yerine sıradan OTel SDK'ları ve OTLP üzerinden bağlanır.
• Bağlamın korunması: dışa aktarılan veri; metadata, zaman damgaları ve trace/span ilişkisini korur, böylece log kayıtları trace ID'lerine bağlı kalır ve kullanıcının kendi backend'inde faydalı olur.
• Semantic Conventions: projenin convention'larına uymak, öznitelik adlarını standartlaştırır ve uyumlu herhangi bir backend tarafından yorumlanabilir hale getirir; kullanıcıları sağlayıcıya özel şemalar öğrenmekten kurtarır.

İki dağıtım bağlamı yaklaşımı belirliyor

Doğru mimari, telemetry'yi üreten sistemi kimin işlettiğine bağlıdır.

Self-hosted yazılım için — müşterilerin kendi veri merkezine, cloud hesabına veya Kubernetes cluster'ına kurduğu bir kimlik sunucusu, service mesh veya veritabanı — sağlayıcı ürünü OpenTelemetry ile instrumente eder ve genellikle environment variable'lar veya bir config dosyası üzerinden bir OTLP endpoint yapılandırması sunar. Dışa aktarım müşterinin süreci içinde çalışır. OpenTelemetry standart yapılandırma seçenekleri tanımladığı için kurulum deneyimi, müşterinin zaten çalıştırdığı diğer instrumente edilmiş sistemlerle aynıdır. Yazının örnekleri Kuma ve Keycloak.

Workload'ların sağlayıcının altyapısında çalıştığı cloud platformlarda ise öneri, müşterilerin verilerinin nereye gideceğini bildirdiği, yapılandırılabilir telemetry hedeflerine benzer platform düzeyinde bir özellik. Platform, müşteri workload'larından ve router'lar gibi kendi servislerinden gelen telemetry'yi toplar ve müşterinin endpoint'ine iletir. Heroku ve Cloudflare bu deseni örnekliyor.

Dört ürün bunu nasıl yapıyor

Kuma; log, trace ve metric yaymaya hazır gelir ve müşteriler dışa aktarımı ayrı mesh policy'leri üzerinden yapılandırır: MeshAccessLog erişim log'larını mesh adı gibi özniteliklerle birlikte bir Collector'a yönlendirir, MeshTrace dağıtık trace'leri yapılandırılabilir örnekleme ve etiketleme ile yönetir, MeshMetric ise control ve data plane metric'lerini açığa çıkarır ve OpenTelemetry ile Prometheus ile entegre olur.

Keycloak dışa aktarımı süreç kendisi halleder; sidecar gerekmez. Kullanıcılar --telemetry-endpoint gibi bir başlangıç bayrağıyla Collector'larını gösterir, isteğe bağlı olarak header'lar ve gRPC ya da HTTP protokol seçeneği ekler ve sinyalleri tek tek açar. Tracing; HTTP isteklerini, veritabanı çağrılarını, LDAP ile giden HTTP ve kimlik sağlayıcı trafiğini kapsar; metric'ler aynı entegrasyonu kullanır; log dışa aktarımı ise önizlemede ve feature flag'lerin arkasında varsayılan olarak kapalıdır.

Platform tarafında yazının karşılaştırma tablosu Cloudflare Workers'ın log ve trace dışa aktardığını ama henüz metric dışa aktarmadığını, Heroku'nun ise üç sinyali de desteklediğini ve kullanıcıların --signals seçeneğiyle aralarından seçim yaptığını gösteriyor. Daha fazla örnek için yazı, yerel instrumentation veya birinci sınıf plugin sunan kütüphane ve servisleri listeleyen OpenTelemetry Integrations sayfasına işaret ediyor.

Neden önemli

Telemetry taşınabilirliği, altyapı yazılımı için sessizce vazgeçilmez bir gereklilik haline geliyor. Halihazırda bir izleme stack'i işleten alıcılar, observability verisindeki kilitlenmeyi bir kusur olarak görüyor ve yıllarca süren tescilli panellerin ardından OTLP desteği eklemek, erken aşamada instrumente etmekten çok daha pahalıya mal oluyor. Rehberin temel dersi şu: bu çoğunlukla mimari bir disiplin meselesi — standart sinyaller, standart yapılandırma, standart convention'lar — özgün entegrasyon mühendisliği değil; ve aynı disiplin hem indirilebilir bir binary hem de yönetilen bir platform için işe yarar.