Bir uygulama yavaşladığında teknik ekiplerin yaptığı ilk şey genellikle kendi tarafını kontrol etmektir. Uygulama ekibi loglara bakar, veritabanı ekibi sorguları inceler, altyapı ekibi CPU ve bellek kullanımını açar.

Sonuçlar gelir: Sunucular normal, veritabanında belirgin bir problem yok, servisler ayakta.

Müşteri ise hâlâ ödeme ekranında bekliyordur.

Bir süre sonra toplantıya yeni kişiler katılır. Ekranlar paylaşılır. “Saat kaçta olmuştu?” sorusu birkaç kez sorulur. Birisi ağ ekibini de çağırmayı önerir.

Bu tabloyu yaşadıysanız OpenTelemetry’nin çözmeye çalıştığı problemi zaten biliyorsunuz.

OpenTelemetry nedir?

OpenTelemetry, kısaca OTel; uygulamaların nasıl çalıştığını anlamamıza yardımcı olan trace, metrik ve log verilerini üretmek, toplamak ve izleme platformlarına göndermek için kullanılan açık kaynaklı bir araç ve standart bütünüdür.

Belirli bir üreticiye bağlı değildir. Uygulamanızın ürettiği telemetri verisini farklı uyumlu platformlarda kullanabilmeniz için ortak bir yapı sunar.

Kendi başına bir dashboard veya APM ürünü değildir. Veriyi saklamak, görselleştirmek ve analiz etmek için ayrıca bir gözlemlenebilirlik platformu kullanırsınız. (opentelemetry.io)

Her parçayı görüyoruz. İşlemin tamamını görebiliyor muyuz?

Müşterinin tek bir butona basması, arka tarafta oldukça fazla iş başlatabilir. Sepet kontrol edilir, kampanya hesaplanır, stok sorgulanır, ödeme sağlayıcısına gidilir, sipariş kaydedilir.

Bu adımlar farklı uygulamalarda çalışabilir. Bazıları bulutta, bazıları kurum içindedir. Bir kısmını başka ekipler yönetiyordur.

Her uygulamanın kendi kayıtları vardır. Ama aynı işlemin bu uygulamalardan nasıl geçtiğini takip etmek her zaman kolay olmaz. Özellikle kayıtlar farklı araçlarda tutuluyorsa, araştırmanın bir kısmı saatleri ve işlem numaralarını elle eşleştirmeye dönüşür.

OpenTelemetry, trace, log ve metriklerin ortak bağlam üzerinden ilişkilendirilmesini destekler. Gerekli enstrümantasyon ve bağlam aktarımı sağlandığında, tek bir isteğin farklı servislerdeki adımlarını birlikte araştırabilirsiniz. (opentelemetry.io)

Ödeme ekranında bekleyen müşterinin işlemini bulup hangi çağrıda zaman kaybettiğini görmek, toplantıda on ayrı ekran görüntüsünü karşılaştırmaktan daha iyi bir başlangıçtır.

Trace, log, metrik… Zaten bunları toplamıyor muyduk?

Topluyorduk. OpenTelemetry bunları icat etmedi.

Metrikler, sistemdeki değişimleri görmemize yardımcı olur. İstek süreleri yükselmiş mi, hata oranı artmış mı, bellek tüketimi değişmiş mi?

Loglar, belirli bir anda yaşananların ayrıntısını verir. Hata mesajları ve uygulamanın kaydettiği olaylar burada bulunur.

Trace, bir isteğin geçtiği adımları ve bu adımlarda harcanan süreyi gösterir. İşlem birkaç servise dağıldığında, gecikmenin hangi bölümde oluştuğunu araştırmak için kullanışlıdır. (opentelemetry.io)

Bu veriler ilişkilendirildiğinde, yükselen hata oranından ilgili isteğe, isteğin içindeki başarısız çağrıya ve o çağrının loglarına geçebilirsiniz.

Aynı ekrana üç grafik koymakla bu ilişki kurulmuş olmaz. Topladığınız verinin aynı işlemi işaret edebilmesi gerekir.

Google, Microsoft ve AWS de bu işin içinde

OpenTelemetry yalnızca açık kaynak topluluğunun takip ettiği bir proje değil. Büyük bulut sağlayıcılarının resmî ürünlerinde ve kurulum önerilerinde de yer alıyor.

Google Cloud, Cloud Trace için uygulamaların enstrümante edilmesinde OpenTelemetry kullanımını öneriyor. Dokümanlarında verinin OpenTelemetry Protocol, yani OTLP üzerinden doğrudan veya Collector aracılığıyla Google Cloud’a gönderildiği kurulumları anlatıyor. (docs.cloud.google.com)

Microsoft, Azure Monitor ve Application Insights için OpenTelemetry tabanlı dağıtımlar sunuyor. Yeni Application Insights projelerinde OpenTelemetry tabanlı yaklaşımı öneriyor. Bu yatırımın nedenleri arasında üreticiden bağımsızlığı ve farklı dillerde ortak API’lerle çalışabilmeyi sayıyor. (learn.microsoft.com)

AWS, AWS Distro for OpenTelemetry, yani ADOT dağıtımını sunuyor. ADOT ile toplanan metrik ve trace verileri AWS X-Ray, CloudWatch ve diğer desteklenen izleme çözümlerine gönderilebiliyor. (docs.aws.amazon.com)

Üçünün de aynı projeyi desteklemesi önemli. Uygulamaların telemetri üretimi için ortak bir yaklaşım benimsenirken, bu verinin hangi platformda analiz edileceği ayrı bir tercih olarak kalabiliyor.

Kubernetes’ten sonra ikinci sırada

OpenTelemetry için “Kubernetes’ten sonra en büyük topluluk” ifadesini duymuş olabilirsiniz. Burada neyin ölçüldüğünü belirtmek gerekiyor.

CNCF’nin Mayıs 2026 açıklamasına göre OpenTelemetry, proje geliştirme aktivitesinde Kubernetes’in ardından ikinci sırada. Projenin başlangıcından bu yana 2.800’den fazla şirketten 12.000’i aşkın katkıcı yer almış. Aynı açıklamada projenin CNCF’nin “Graduated” olgunluk seviyesine ulaştığı da duyuruldu. (cncf.io)

Bu ölçekte bir katılımın oluşması şaşırtıcı değil. Farklı teknolojiler kullansak da benzer sorularla uğraşıyoruz: Uygulama neden yavaşladı? Hata nerede başladı? Hangi işlemler etkilendi?

Her ekibin ve her araç üreticisinin bu sorular için ayrı bir veri toplama düzeni geliştirmesi yerine, ortak bir temel üzerinde çalışılması önemli bir kazanım.

İzleme aracını değiştirmek neden uygulama projesine dönüşsün?

Bugün kullandığınız izleme platformundan memnun olabilirsiniz. Birkaç yıl sonra ihtiyaçlarınız veya bütçeniz değişebilir. Başka bir platformu denemek isteyebilirsiniz.

Uygulamalardaki veri toplama yapısı tek bir ürüne sıkı biçimde bağlıysa, bu kararın ardından yeni agent’lar, SDK değişiklikleri ve uygulama testleri gündeme gelebilir.

OpenTelemetry, telemetri üretimini analiz platformundan ayırmaya yardımcı olur. Veriyi uyumlu başka bir platforma gönderirken uygulamaların tamamını yeniden enstrümante etme ihtiyacını azaltır. (opentelemetry.io)

Elbette panellerin, alarmların ve platforma özel sorguların taşınması için çalışma gerekebilir. Ama araç değiştirirken uygulamanın veri toplama altyapısını koruyabilmek ciddi bir avantajdır.

Kurduk, tamam mı?

Henüz değil.

Otomatik enstrümantasyon, desteklenen teknolojilerde hızlı bir başlangıç sağlayabilir. Kapsam ise kullanılan dile, kütüphaneye ve çalışma ortamına göre değişir. Uygulamaya özgü iş adımlarını izlemek için ek enstrümantasyon gerekebilir. (opentelemetry.io)

Bir veritabanı çağrısının üç saniye sürdüğünü görmek başka, siparişin hangi iş kuralı nedeniyle beklediğini anlamak başkadır. İkinci soruyu cevaplamak için uygulamanın ilgili bilgiyi de üretmesi gerekir.

Bu yüzden başlangıçta tek bir kritik işlem seçmek daha yönetilebilir olabilir. Örneğin sipariş oluşturmayı ele alın. İsteğin geçtiği servisleri takip edin, görünmeyen noktaları bulun, ilgili hata kayıtlarını ilişkilendirin. Ardından kapsamı genişletin.

İlk hedefiniz bütün sistem için yüzlerce dashboard hazırlamak olmak zorunda değil. Gerçek bir sorun yaşandığında, seçtiğiniz işlemin nerede takıldığını bulabiliyor musunuz? Önce buna bakın.

Bir sonraki performans sorununda yine toplantı yapmanız gerekebilir. Ama bu kez “Bizim tarafta sorun yok” diyen herkesle aynı isteği açıp inceleyebilirsiniz.

Ağ ekibini çağırmadan önce bakacak bir yeriniz olur.