CICS Hiçbir OpenTelemetry Trace'ini Başlatmaz: Span Hacmini Çağıranın Sampler'ı Belirler

CICS TS 6.3 her task için bir OpenTelemetry span'i yazabilir, ama hangi task'lar için yazacağına kendisi karar vermez. Kararı çağıranın W3C traceparent header'ındaki sampled biti verir; CICS bu biti değiştiremez ve OpenTelemetry SDK'sının varsayılan ayarı biti her istekte açar. Span hacminizi belirleyen ayar aslında başka bir ekibin elinde.

CICS bir trace'e ancak çağıran onu getirirse katılır

IBM'in yapılandırma rehberine göre CICS trace context başlatmaz; context'in web servisleri, Liberty uygulamaları ve z/OS middleware gibi istemcilerden gelen isteklerle ulaşması gerekir (CICS'te OTel yapılandırması). Transaction referansı bir adım daha ileri gidiyor: hiç OTel verisi gelmezse CICS hiçbir tracing bilgisi üretmez (yapılandırma seçenekleri).

Context bir task'a beş protokolden ulaşır: Db2 attachment facility, HTTP, IPIC, MRO ve IBM MQ (desteklenen protokoller). Sayfalar 6.3'ü ve CICS TS beta'yı kapsıyor; beta RETURN TRANSID ve DTP gibi senaryolar ekliyor, bu yazıdaki her şey 6.3 için geçerli. IBM'in planlama rehberi önce z/OS Connect, Db2, CICS Transaction Gateway ya da MQ gibi aradaki ürünlerde OTel'i açmanızı istiyor (planlama notları).

OTELTRACE=YES her transaction'ı span yazmaya aday yapar

Davranışı üç anahtar yönetir. OTELTRACE varsayılanı NO olan ve altındaki her şeyi ezen bir SIT parametresidir; her transaction ayrıca OTELPROP (PROPONLY ya da NOPROP) ve OTELEMIT (TASKEND ya da NOEMIT) taşır (yapılandırma seçenekleri). Span data record yalnızca PROPONLY ile TASKEND birlikteyken ve gelen context'te sampled bayrağı açıksa üretilir.

Asıl planlanması gereken nokta varsayılanlar. DFHCSDUP UPGRADE sonrasında her transaction tanımı OTELEMIT için TASKEND, OTELPROP için PROPONLY değerini taşıyor; IBM de bu yüzden OTELTRACE YES olduğu anda transaction'ların span data record üretecek şekilde otomatik ayarlı olduğunu belirtiyor (CICS'te OTel yapılandırması). Bu kayıtlar SMF tip 1159; bir IBM z/OS emitter onları doğrudan ya da bir OTel collector üzerinden observability backend'ine uygun biçime getiriyor.

Sampled biti W3C'de bir öneri, CICS'te bağlayıcı

W3C Trace Context Recommendation tek bir bayrak tanımlar: sampled, çağıranın trace verisini kaydetmiş olabileceğini gösterir (W3C Trace Context). Belge trace bayraklarını çağıranın verdiği öneriler olarak tanımlıyor; gösterdiği üç gerekçeden biri, çağıran ile çağrılan arasındaki yük farkının çağrılanı downsample yapmaya zorlayabilmesi. Bir bileşen parent-id alanını da güncellediği sürece sampled bayrağını değiştirebilir.

CICS her task'ta parent ID'yi günceller: trace ID aynı kalır, her task yeni bir span ID alır (desteklenen protokoller). Yani standart CICS'e downsample yapma alanı bırakıyor. CICS 6.3 bu alanı kullanmıyor: IBM, CICS'in sampling bayrağını dinamik olarak değiştirecek bir mekanizma sunmadığını ve CICS'ten diğer sistemlere giden context'in sampled bayrağını içerdiğini yazıyor (planlama notları). Yukarıda verilen karar, Db2 ve MQ'nun da gördüğü karar oluyor.

OpenTelemetry SDK varsayılanı her root span'i örnekler

O biti root span'i oluşturan taraf açar. W3C metnine göre kesin bir kayıt kararı veren bileşen bu kararı sampled bayrağına yansıtmalı (W3C Trace Context). OpenTelemetry SDK spesifikasyonunda varsayılan sampler ParentBased(root=AlwaysOn), AlwaysOn ise her zaman RECORD_AND_SAMPLE döndürüyor (OTel tracing SDK). OTEL_TRACES_SAMPLER ortam değişkeninin varsayılanı da aynı şey: parentbased_always_on (OTel ortam değişkenleri).

Üç belgeyi yan yana koyunca zincir kısa. Sampler'ı hiç yapılandırılmamış bir SDK ile çalışan front end, başlattığı her isteği örnekler ve her birini sampled olarak işaretler. Bu isteklerin beş protokol üzerinden ulaştığı ve varsayılan ayarlarda bırakılmış her CICS transaction'ı da task bitiminde bir SMF 1159 kaydı yazar, çünkü CICS bu akışı seyreltemez: transaction başına seçenek ya örneklenen tüm task'lar ya hiçbiri.

IBM'in planlama rehberi istek hacmini sınırlamak için head-based sampling düşünmenizi öneriyor (planlama notları). Bunu yapan ayar ise çağıranın ortamında duruyor ve sahibi büyük olasılıkla hiç SMF raporu okumayan bir ekip.

Task başına bir kayıt ve IBM'in adını koyduğu iki istisna

Span task başladığında açılır, task bittiğinde kapanır. İstisna CICS-MQ adapter: trigger monitor CKTI tarafından başlatılan task'larda CICS, her yeni unit of work başında MQ mesajından context'i alır ve UoW sonunda bir span yazar. Böylece trace context taşıyan birkaç mesaj alan tek bir task birkaç span üretir (desteklenen protokoller).

Diğer durum uzun süren task'lar. IBM, ağırlıklı olarak bunlar için kullanılan region'ların task sonunda span yazmaktan fayda görmeyebileceğini, yalnızca propagation'ın trace bütünlüğünü korumaya yettiğini söylüyor (planlama notları).

OTELTRACE'i YES yapmadan önce sampler'da anlaşın

Trace root'unun sahibi olan ekibe hangi OTEL_TRACES_SAMPLER ile çalıştığını sorun. Cevap varsayılansa birlikte bir oran belirleyin: parentbased_traceidratio, OTEL_TRACES_SAMPLER_ARG içinde 0 ile 1 arasında bir olasılık alır (OTel ortam değişkenleri). Span'e ihtiyaç duymadığınız yerde OTELEMIT değerini NOEMIT yapın ve PROPONLY'yi koruyun; IBM trace'in bütün kalması için propagation'ın tüm region'larda açık olması gerektiğini söylüyor (planlama notları).

SET TRANSACTION iki özelliği de region'ı yeniden başlatmadan değiştirir (CICS'te OTel yapılandırması). IBM'in önerdiği gibi birkaç region ile başlayın ve SMF 1159 kayıt sayısını trace root'undaki istek hızıyla karşılaştırın. İkisi birlikte artıp azalıyorsa çağıran her şeyi örnekliyor demektir.