OpenTelemetry eBPF Instrumentation, OBI 1.0 ile stable sürüme geçti

OpenTelemetry eBPF Instrumentation projesi OBI 1.0 sürümüne, yani v1.0.0’a ulaştı. OBI, Linux üzerinde çalışan uygulamalardan kaynak koda dokunmadan OpenTelemetry observability (gözlemlenebilirlik) verisi topluyor. Yeni sürüm Config v2, deployment arayüzleri ve desteklenen ortamlar için belgelenmiş uyumluluk taahhütleri getiriyor.

OpenTelemetry nedir, ne işe yarar?

OpenTelemetry, uygulamalardan trace, metric ve log toplamak için açık kaynak bir standart ve araç setidir. Dil SDK’ları, otomatik instrumentation ve verileri işleyip farklı backend’lere ileten Collector bileşeninden oluşur. Satıcıdan bağımsız olduğu için ekipler toplama katmanını değiştirmeden backend değiştirebilir. CNCF bünyesinde geliştirilir.

eBPF nedir, ne işe yarar?

eBPF, Linux kernel’ı içinde güvenli biçimde küçük programlar çalıştırmaya yarayan bir teknolojidir. Programlar yüklenmeden önce bir verifier’dan geçer. Ağ izleme, güvenlik denetimi ve uygulama kodunu değiştirmeden performans verisi toplama gibi işlerde kullanılır; Cilium ve Falco gibi projeler eBPF üzerine kuruludur.

OBI 1.0 ile değişen asıl şey: öngörülebilirlik

Yeni protokol listesi uzun. Ama production’da en çok işe yarayacak kısım sözleşme. Bugüne kadar OBI’yı çalıştıran ekipler, her yükseltmede config’in ve metric adlarının değişip değişmeyeceğini tahmin etmek zorundaydı.

Artık Config v2, onun üretilmiş şeması, belgelenmiş deployment arayüzleri ve desteklenen ortamlar uyumluluk taahhüdü altında. Telemetry tarafında verilen söz farklı: stabilite değil, migration yolu. Verinin bir kısmı stable semantic convention’lara uyuyor, bir kısmı hâlâ gelişen convention’lara dayanıyor ve değişebilir. Stable olanlarda bile convention’a uymayan davranış bug sayılıp düzeltilecek.

Dashboard ve alert’ler nasıl etkilenir?

Asıl risk sessiz kırılma. Bir attribute adı değişirse alert hata vermez, hiç tetiklenmez. Bu yüzden şu sırayı izlemek mantıklı:

• Paging alert’lerini request rate, error ve latency gibi temel sinyallere bağlayın.
• Go, Java, .NET, Node.js ve Python runtime metric’lerini şimdilik dashboard’da tutun. Proje bunları açıkça experimental olarak işaretliyor; hangi metric’in geleceği runtime’a ve açık özelliklere göre değişiyor.
• Her yükseltmede release notes ve migration rehberini okuyun. Weaver uyumlu schema registry’deki dönüşümler her değişikliği kapsamıyor; ek işlem gerektirenler notlarda anlatılıyor.

Collector pipeline’ında attribute yeniden adlandıran kurallarınız varsa, yayımlanan telemetry schema’ları sürümler arası farkı çıkarmak için başlangıç noktası olur.

OBI 1.0’a geçmeden önce

Config v1 hâlâ çalışıyor ama dondu: fix yok, yeni özellik yok. Yani bugün v1 ile duran bir kurulum her sürümde biraz daha geride kalıyor. Config v2, v0.11.0’dan beri var ve 1.0’ın sözleşmesi bu.

Geçiş için önerilen sıra:

1. Elinizdeki yapılandırmayı obi config migrate ile dönüştürün, obi config validate ile doğrulayın. Argümanlar için resmî migration rehberine bakın.
2. Ortam değişkeniyle verilen ayarları ayrıca gözden geçirin. Helm values ya da DaemonSet manifest’inde env olarak duran bir ayar, dosya üzerinden yapılan migration’da gözden kaçabilir.
3. Telemetry’yi önce bir canary deployment’ta eski sürümle karşılaştırın, sonra genişletin.
4. OBI’yı Collector içine gömüyorsanız receiver’ın ayrı v0 sürüm hattını kontrol edin. OBI 1.0 olması receiver’ın da stable olduğu anlamına gelmiyor.

Proje doğrulamayı farklı kernel ve mimarilere genişletti. Yine de node havuzunuzu support matrix ile eşleştirmeden yaymayın:

uname -r
uname -m
kubectl get nodes -o wide

Route template’leri ve AI instrumentation

Yeni protokoller arasında MQTT, NATS, AMQP 1.0, MSSQL, Couchbase, Memcached ve Aerospike var. Trace propagation her protokolde aynı seviyede değil. Support matrix sınırları protokol bazında listeliyor; dağıtık trace bekliyorsanız oraya bakın.

Route template’leri Django, FastAPI, Flask, Rails, .NET ve bazı PHP framework’lerinde çalışıyor. Pratik faydası cardinality’de. Her benzersiz URL ayrı bir metric serisi açmıyor, yavaş endpoint’i şablon düzeyinde görüyorsunuz.

AI tarafında model provider’lar, embedding (vektör temsili), reranking, vector retrieval ve MCP etkileşimleri izleniyor. OpenAI uyumlu gateway’ler ve Ollama da listede. Ayrıntılı veri çıkarmak için payload capture’ı açıkça etkinleştirmek gerekiyor. Bu doğru bir varsayılan, çünkü prompt’lar ve model yanıtları kullanıcı verisi ya da secret taşıyabilir. Etkinleştirmeden önce bu verinin hangi backend’e gideceğini ve orada kimin okuyabileceğini netleştirin.

Tedarik zinciri ve ilk deneme

Release’ler artık imzalı artifact, checksum ve SBOM (Software Bill of Materials) ile geliyor. Image doğrulama politikası olan ortamlarda OBI’yı bu listeye eklemenin önündeki eksik kapandı.

OBI’yı ilk kez deneyecekseniz tek ve temsil edici bir servis seçin. Çıktıyı OpenTelemetry Collector’a ya da uyumlu bir backend’e gönderin, metric ve trace’leri inceleyin. eBPF programı yüklemek host üzerinde yükseltilmiş yetki ister; bunu güvenlik ekibinizle önceden konuşun.

Otomatik görünürlük iş mantığını anlatmaz. Go tarafında OpenTelemetry Go Trace API ve Auto SDK ile yazılan span’leri OBI yakalayabiliyor. Node.js’te kayıtlı SDK yoksa opt-in manual span capture var. Ödeme ya da sipariş gibi iş adımlarını görmek istiyorsanız dil agent’ları ve manual instrumentation yine gerekli; OBI bunların çevresindeki trafiği dolduruyor.