Yeni paket, Dagster pipeline'larına sıfır kodla OpenTelemetry tracing getiriyor

opentelemetry-instrumentation-dagster adlı yeni bir açık kaynak Python paketi, pipeline kodunda hiçbir değişiklik yapmadan Dagster pipeline'larına distributed tracing ekliyor. dev.to'da yazan yazarı Hirofumi Tsuda'ya göre paketi kurup Dagster'ı standart opentelemetry-instrument komutuyla başlatmak yeterli: bir definitions dosyasındaki her op, asset, multi-asset, asset check ve dbt asset, kullanıcı kodunda decorator veya import gerektirmeden otomatik olarak bir trace span üretiyor.

İki paket, iki ödünleşim

Yeni kütüphane, Tsuda'nın önceki projesi olan ve @op veya @asset altına yerleştirilen açık bir @traced() decorator sağlayan dagster-otel'in yol arkadaşısı. Bu yaklaşım opt-in'dir ve framework'ün iç işlerine dokunmaz, ancak izlenecek her fonksiyonun düzenlenmesini gerektirir. Auto-instrumentation paketi ters yöne gider: sıfır kod değişikliği karşılığında runtime patching. Tsuda bu ayrımı bilinçli olarak yapıyor; tıpkı OpenTelemetry Python ekosisteminin framework instrumentation paketlerini (Flask veya Django için olanlar gibi) manuel API ve SDK'dan ayrı tutması ve onları anahtar olarak sunmaması gibi.

Patching nasıl çalışıyor

Paket, hazır definition nesnelerine uzanıp compute fonksiyonlarını sonradan değiştirmek yerine, decorator fabrikalarının kendisini — dagster.op, dagster.asset, dagster.multi_asset ve dagster.asset_check — patch'liyor; Tsuda bunları kamuya açık ve kararlı API olarak tanımlıyor. Her fabrika, gelen compute fonksiyonunu önce dagster_otel.traced() ile sarıyor, sonra gerçek decorator'a teslim ediyor; böylece sarma işlemi Dagster bir op veya asset definition oluşturmadan önce gerçekleşiyor.

Sıralama önemli: patch, kullanıcı modülü from dagster import asset satırını çalıştırmadan önce aktif olmalı, aksi halde patch'lenmiş isim hiç referans alınmaz. opentelemetry-instrument launcher bunu genel bir şekilde çözer: opentelemetry_instrumentor entry point'i altında kayıtlı her paketi keşfeder ve kullanıcının kodu herhangi bir şey import etmeden önce instrument() metodunu çağırır.

Multiprocess ve Kubernetes execution

Dagster'ın multiprocess executor'ı her adım için taze bir interpreter başlatır ve definitions modülünü baştan import eder; bu yüzden yalnızca orijinal süreçte uygulanan bir patch hayatta kalmaz. Launcher bunu dolaylı olarak çözer: iki satırlık bir sitecustomize.py içeren bir dizini PYTHONPATH'in başına yerleştirir ve hedef komuta exec ile geçer. Python, başlangıçta sys.path üzerinde bulduğu sitecustomize adlı her modülü import eder; türetilen alt süreçler PYTHONPATH'i varsayılan olarak devralır, böylece her çocuk instrumentation'ı kendi başına yeniden uygular.

k8s_job_executor bu zinciri kırar, çünkü her adım ayrı bir Kubernetes pod'unda çalışır ve PYTHONPATH, Dagster'ın pod'lara aktardığı ortam değişkenleri arasında değildir. Çözüm statiktir: sitecustomize.py dosyasını container imajına gömün, böylece her pod onu interpreter başlangıcında yükler. Tsuda her iki yolun da Postgres destekli run storage ve bir Jaeger instance'ı bulunan gerçek bir kind kümesinde doğrulandığını, span'ların gerçekten ayrı pod'larda doğru şekilde ebeveynlendirildiğini ve depoda tekrarlanabilir bir kurulumun yer aldığını söylüyor.

Asset check desteği ve kapsam

En son sürüm, şimdiye dek izlemeden kaçan tek decorator olan @asset_check'ı ekliyor. Keyword-only olduğu ve @multi_asset ile aynı biçimde bulunduğu için dördüncü bir wrapper kaydetmek yeni bir dispatch mantığı gerektirmemiş. Zorluk context'teydi: AssetCheckExecutionContext, op ve asset context'lerinin sunduğu job_name ve selected_asset_keys gibi alanlardan yoksundur; bu yüzden dagster_otel bu context türünü yalnızca 0.4.0 sürümünde ele almayı öğrenmiştir ve instrumentation paketi bağımlılığını buna göre güncellemiştir. Tsuda iki şekilde doğrulama yaptığını bildiriyor: test paketinde gerçek bir materialize() çalıştırması ve tamamen launcher üzerinden yürütülen sade bir script; bu, script Dagster'ı import etmeden patch'in aktif olduğunu doğruluyor.

Bugünkü kapsam; basit ve isimli biçimleriyle @op, iki biçimiyle de @asset, @multi_asset, @asset_check ve içeride multi_asset'ı çağırdığı için ek bedel ödemeden kapsanan @dbtAssets'i içeriyor. @graph_asset ise bilinçli olarak hariç tutuldu — fonksiyonu, definition anında bir kez çağrılan bir birleştirme rutinidir ve asla bir runtime context almaz; onu izlemek gereksiz olmaktan öte yanlış olur. Birleştirdiği op'lar yine de span alır.

Neden önemli

Distributed tracing web servisleri için standart bir uygulama olsa da veri pipeline'larında genellikle fonksiyon başına emek gerektirmiştir. Bu paket, Dagster kullanıcıları için bu maliyeti neredeyse sıfıra indiriyor; her op veya asset'in ne kadar sürdüğünü, adımların bir run içinde nasıl iç içe geçtiğini ve bir run'ın onu tetikleyen şeyle — bir sensor tick'i, bir CI job'ı veya upstream'daki OpenTelemetry ile instrument edilmiş bir servis — nasıl bağlantılı olduğunu görmeyi ucuzlatıyor. Uyarılar gerçek: proje alpha aşamasında ve MIT lisanslı, auto-instrumentation fonksiyon başına açık kontrolden vazgeçmek demek ve Kubernetes yolu imaj düzeyinde kurulum gerektiriyor. Ancak zaten bir OTel collector çalıştıran ekipler için mevcut trace'lere pipeline'larını eklemenin engeli artık esasen bir launcher bayrağı. Kod GitHub ve PyPI üzerinde mevcut ve yazar geri bildirim bekliyor.