JetBrains, 15 Eylül 2026'da OpenTelemetry eklentisindeki Service Map özelliğinin nasıl çalıştığına ilişkin teknik bir açıklama yayımladı. Bu özellik, uygulama geliştirme ortamında çalışırken mikro hizmetler arasındaki gerçek ilişkileri haritalandırıyor. Açıklama, Rider Execution ekibi ile Software Engineering Research ekibi arasındaki iş birliği kapsamında Nikita Dukin ve Egor Klimov tarafından hazırlandı.
Fikir, bilinen pratik bir sorundan yola çıkıyor: Mimari şema düzenli görünebilir, ancak sistemin aylar önceki durumunu yansıtıyor ve yeni bir hizmeti veya belgeleri güncellenmemiş bir mesaj kuyruğunu göstermiyor olabilir. JetBrains, statik kod analizinin her zaman yeterli olmadığını düşünüyor; çünkü bu analiz kaynak kodunda nelerin gerçekleşebileceğini açıklıyor, çalışma sırasında hizmetler arasında gerçekte nelerin gerçekleştiğini değil.
İzler haritanın kaynağıdır
Eklenti, günlükleri, ölçümleri ve izleri toplayan OpenTelemetry verilerine dayanıyor. Günlükler neler olduğunu açıklarken ve ölçümler olayın boyutunu gösterirken, izler bir isteğin sistem içindeki yolunu ortaya çıkarıyor. Her izleme işlemi spans adı verilen çalışma birimlerinden oluşuyor ve OpenTelemetry bu birimler için HTTP Client ve HTTP Server izleri gibi standartlaştırılmış anlamsal kurallar sağlıyor.
Eklenti, algoritmayı belirli bir çerçeveye veya dile bağlamadan çalışma mimarisini anlamak için bu izleri kullanıyor. Uygulamalar ve kütüphaneler izleri OpenTelemetry beklentilerine uygun biçimde gönderiyorsa özellik, kullanılan teknolojiden bağımsız olarak iletişimleri görselleştirebiliyor. JetBrains, aynı mantığın JVM, .NET, Python ve Go uygulamalarıyla diğer uygulamalarda da çalışabileceğini; ayrıca IntelliJ IDEA, GoLand, PyCharm, WebStorm ve Rider'da kullanılabileceğini belirtiyor.
Harita geliştirme ortamında nasıl oluşturuluyor?
OpenTelemetry eklentisi etkinleştirilmiş geliştirme ortamı çalıştırıldığında eklenti, telemetri verilerini kabul eden hafif bir yerel sunucu başlatıyor. Uygulama çalıştırıldığında eklenti, standart OpenTelemetry ortam değişkenlerini ayarlayarak uygulamanın izlerini bu yerel sunucuya göndermesini sağlıyor.
Sunucu, gelen izleri eşzamansız biçimde işliyor, mimari için dahili bir model oluşturuyor ve bu modeli sürekli güncelliyor. Service Map sekmesi açıldığında eklenti en güncel yapısal modeli alarak görsel bir şema biçiminde gösteriyor. Böylece harita, elle oluşturulan sabit bir belge değil, sistem çalışırken gözlemlenen iletişimlerin doğrudan sonucu oluyor.
Zorluk çizim değil, verileri yorumlamaktır
İzler birbirinden bağımsız biçimde geliyor ve ulaşma sıralarının garantisi bulunmuyor. Alt hizmetin izi üst hizmetin izinden önce gelebiliyor; ayrıca izleme, gecikmiş bir izin ulaşmayacağını garanti eden kesin bir bitiş anı bildirmiyor. Bunun yanı sıra OpenTelemetry, her iz için ayrı ve katı bir tür sunmuyor; izler bunun yerine işlemin anlamını açıklayan anahtar-değer çiftlerinden oluşan bir harita taşıyor.
Bu nedenle JetBrains, mimarinin yeniden oluşturulmasını bir veri akışı işleme algoritması olarak sınıflandırdı. Eklenti izlemenin tamamlanmasını beklemiyor; her izi ulaşır ulaşmaz inceliyor. İşlemin bir HTTP iletişimi olup olmadığını belirlemek için http.request.method ve http.response.status_code gibi öznitelikleri kullanıyor; diğer öznitelikler ise veritabanı sorgusuna veya bir mesajlaşma sistemiyle etkileşime işaret ediyor.
İz sınıflandırıldıktan sonra algoritma, izi oluşturan hizmeti belirliyor. Hizmet yeniyse haritaya ekleniyor; mevcutsa yeni verilerle birleştiriliyor ve istatistikleri güncelleniyor. HTTP iletişimlerinde eklenti, çağrıyı yapan hizmetten çıkan CLIENT izi ile alıcı hizmette oluşan SERVER izi arasındaki ilişkiyi arıyor. İzleme bağlamı istekle birlikte taşınıyor; bu da SERVER izini CLIENT izinin alt öğesi haline getiriyor. Diğer uç mevcutsa ilişki hemen çiziliyor; mevcut değilse karşılık gelen veriler ulaşana kadar iz bellekte tutuluyor.
Diğer bağımlılıklar farklı kurallar kullanıyor. Veritabanı çağrısı genellikle tek bir CLIENT iziyle temsil ediliyor ve eklenti, anlamsal özniteliklere dayanarak bu izden veritabanı düğümünü çıkarıyor. Mesajlaşma sistemleri ise daha fazla esneklik gerektiriyor; çünkü üretici ile tüketici arasındaki ilişki, mesajlaşma sistemine ve kullanılan instrumention yöntemine bağlı olarak üst-alt ilişkisi aracılığıyla veya iz bağlantıları üzerinden ortaya çıkabiliyor.
Bu pratikte neden önemli?
Buradaki temel değer, haritanın yalnızca beklenen yapıyı değil, gözlemlenen davranışı ortaya çıkarmasıdır. Sistem geliştirme sırasında beklenenden tek bir bağlantı yerine birden fazla HTTP bağlantısı veya veritabanına yönelik sorgular gösteriyorsa bu durum sürümden önce keşfedilebilir. Harita ayrıca belgelenmemiş veya zaman içinde değişmiş bağımlılıkların anlaşılmasına yardımcı oluyor.
Ancak sonucun doğruluğu telemetrinin kalitesiyle bağlantılı kalıyor. Algoritmanın doğru izlere, hizmetler arasında izleme bağlamının aktarılmasına ve beklenen anlamsal özniteliklerin kullanılmasına ihtiyacı var. Bu nedenle Service Map, yalnızca eklentinin kurulmasıyla her sistemin eksiksiz bir görüntüsünü otomatik olarak sunmuyor; ölçüm araçlarının göndermediği veya bağlam olmadan ulaşan veriler çıkarılan ilişkilerde görünmeyebilir. Metin ayrıca modelin yeni kanıtlar geldikçe geliştiğini ve bunun haritayı mimari tasarıma ilişkin nihai bir hüküm değil, sürekli yenilenen operasyonel bir temsil haline getirdiğini açıklıyor.