CloudWatch, OpenTelemetry trace’leri için API key desteği ekledi
CloudWatch bearer token desteğiyle SigV4 imzalayamayan on-premises, çoklu bulut ve CI/CD iş yükleri OpenTelemetry trace'lerini X-Ray'e gönderebiliyor.
Bu haberde
AWS, OpenTelemetry trace’lerini X-Ray OTLP traces endpoint’ine göndermek için CloudWatch bearer token desteğini açtı; authentication artık API key ile yapılabiliyor. Authorization header’ı ayarlayabilen her OTLP/HTTP client, OpenTelemetry Collector ve SDK exporter’ları dahil, SigV4 imzası yerine bu token’ı kullanabiliyor. Özellik, X-Ray OTLP traces endpoint’inin bulunduğu tüm ticari AWS Region’larında kullanılabiliyor.
OpenTelemetry nedir, ne işe yarar?
OpenTelemetry, uygulamalardan trace, metrik ve log toplamak için kullanılan açık kaynak bir telemetri standardı ve araç setidir. SDK’lar, Collector ve OTLP protokolünden oluşur. Toplanan veri tek bir üreticiye bağlı kalmadan Jaeger, Prometheus, CloudWatch veya ticari izleme ürünlerine gönderilebilir. Cloud Native Computing Foundation çatısı altında geliştirilir.
SigV4 yazamayan iş yükleri için
CloudWatch’a trace göndermek şimdiye kadar SigV4 imzası istiyordu. Bunun için AWS SDK veya kısa ömürlü credential gerekiyordu. On-premises sunucu, başka bir buluttaki cluster veya yalnızca sabit header destekleyen bir üçüncü taraf araç bu şartı karşılayamıyordu.
CloudWatch bearer token desteğiyle Authorization header’ı yazabilen her OTLP/HTTP client doğrudan X-Ray OTLP endpoint’ine bağlanıyor. Araya imza atan bir proxy koymanız gerekmiyor.
Collector tarafında tek değişiklik
OpenTelemetry Collector kullanıyorsanız değişiklik exporter yapılandırmasında kalıyor. Token’ı dosyaya gömmeyin, ortam değişkeninden okuyun:
exporters:
otlphttp:
traces_endpoint: <X-Ray OTLP traces endpoint>
headers:
Authorization: "Bearer ${env:CW_API_KEY}"Endpoint adresini ve token oluşturma adımlarını AWS X-Ray Developer Guide’daki bearer token sayfasından alın.
ADOT kullanıyorsanız dokunmayın
AWS içinde ADOT SDK’larıyla çalışıyorsanız yapacak bir şey yok. ADOT varsayılan olarak SigV4 ile imzalamaya devam ediyor ve AWS hâlâ SigV4’ü öneriyor. İki yoldan gelen trace’ler de Transaction Search, Application Signals ve CloudWatch Omni’de aynı şekilde görünüyor. Yöntem değiştirdiğinizde dashboard veya sorgu güncellemeniz gerekmiyor.
Statik token, statik risk
SigV4’te credential kısa ömürlü, bearer token ise her istekte aynen gidiyor. Sızan bir CloudWatch bearer token en azından sizin adınıza trace göndermeye yetiyor. AWS duyurusu token’ın ömrünü ve yetki kapsamını anlatmıyor; açmadan önce bu ayrıntıları Developer Guide’da kontrol edin.
Uygulama sırası şöyle olabilir:
- AWS içindeki iş yüklerini SigV4’te bırakın.
- Bearer token’ı yalnızca SigV4 kullanamayan kaynaklarda açın: on-premises, diğer bulutlar ve CI/CD pipeline’ları.
- Token’ı pipeline’da secret olarak saklayın ve log çıktısına düşmediğini doğrulayın.
- Mümkünse her ortama ayrı token verin; sızıntıda yalnızca o ortamı kapatırsınız.



