Dağıtılmış İzleme: Geçmiş, Bugün ve Gelecek

Dağıtılmış İzleme bölücü bir konudur. Bir zamanlar her KubeCon'un duayeni olan teknolojinin gözlemlenebilirlikte devrim yaratması bekleniyordu.

Hızlı bir şekilde 5 yıl ileri sardığımızda, bu heyecan bir miktar azaldı, acı hakkında daha fazla konuşuluyor ve evlat edinme orta düzeyde. Bu arada, teknolojinin genişletilmesi ve standartlaştırılması konusunda istikrarlı faaliyetler devam ediyor - Açık Telemetri (OpenTracing'e dayalı), Kubernetes'ten sonra en büyük 2. CNCF projesidir . Peki Dağıtılmış İzlemenin sorunu nedir? Hemen uygulamaya mı geçilmeli, yoksa bekleyip izlenmeli mi?

Bu makalede Dağıtılmış İzlemeyi derinlemesine inceleyelim

1. Dağıtılmış İzlemenin özelliği nedir ve buna neden ihtiyacımız var?
2. Günümüzde dağıtılmış izlemeyle ilgili sorunlar nelerdir?
3. Yaklaşan gelişmeler nelerdir ve bunlar mevcut zorlukları nasıl çözüyor?

Giriş - Dağıtılmış İzleme Nasıl Çalışır?

Deneyimsiz olanlar için, Dağıtılmış İzleme, dağıtılmış bir ortamın birkaç farklı bileşenini/mikro hizmetini geçerken tek bir isteği izlememize olanak tanıyan bir teknolojidir. İsteğin yolunda yapılan her ağ çağrısı yakalanır ve bir aralık olarak temsil edilir.

Bunu mümkün kılmak için, dağıtılmış izleme araçları her isteğin başlığına benzersiz bir izleme bağlamı (izleme kimliği) ekler ve izleme bağlamının istek yolu boyunca yayılmasını sağlamak için mekanizmalar uygular.

Dağıtılmış izlemenin istek yolunu nasıl temsil ettiği

İlk etapta neden Dağıtılmış İzlemeye ihtiyacımız var?

Dağıtılmış izleme benzersizdir çünkü gözlemlenebilirlik birimi olarak bir talebe odaklanır. Bir izleme/ölçüm platformunda, bir bileşen (örneğin bir hizmet, ana bilgisayar) gözlemlenen temel birimdir. Bu platformlara, bu birimin bir bütün olarak zaman içindeki davranışı hakkında sorular sorulabilir. Örneğin, belirli bir zaman diliminde bu hizmetin durumu/verimliliği/hata oranı nedir?

Günlüklerde gözlemlenen temel birim bir olaydır ; örneğin, kod yürütme sırasında bir olay meydana geldiğinde bazı bilgileri yazdırın. Bu "olaylar" geliştiriciler tarafından kod yazarken öznel olarak tanımlanır. Günlüklerle ilgili zorluk, hepsinin birbirinden kopuk olması, her bileşenin kendi günlük iletisi biçimini ayrı ayrı yazdırması ve anlamlı olması için bunları birbirine bağlamanın kolay bir yolunun olmamasıdır.

Bunun aksine, dağıtılmış izlemede gözlemlenen şey, birden fazla bileşenden geçen tek bir istektir. Bu, bir bütün olarak dağıtılmış sistem hakkında sorular sormamıza ve karmaşık, birbirine bağlı bir sistemin neresinde ne olduğunu anlamamıza olanak tanır.

Dağıtılmış izlemenin temel durumu, istekler etrafındaki bu yönelimin son kullanıcının deneyimine en yakın olduğu argümanında yatmaktadır. Sonuç olarak, dağıtılmış mimarileri nasıl incelemek ve sorunlarını gidermek istediğimiz konusunda da en sezgisel olanıdır.

Dağıtılmış İzlemenin Evrimi

Son on yılda dağıtılmış yazılım mimarilerinin yaygın olarak benimsenmesi nedeniyle Dağıtılmış İzlemenin önemi arttı.

Modern mikro hizmet tabanlı mimari, istek-yanıt sistemlerinin kullanımının yaygınlaştığı 90'ların sonundaki internet büyüme öyküsünün bir evrimidir.

"90'ların sonları ve internetin hızlı büyümesiyle birlikte, bir web sunucusu ön ucu ve bir veritabanı arka ucuna sahip iki katmanlı web siteleri gibi istek-yanıt sistemlerinin büyük ölçüde çoğalması geldi... İstekler, sistemler hakkında akıl yürütmenin yeni bir boyutuydu. , toplu olarak herhangi bir makineye veya sürece dik."

- Uygulamada Dağıtılmış İzleme, O'Reilly Media

Bu mikro hizmet mimarilerinde, her bir istek çok sayıda (10'larca, hatta 100'lerce mikro hizmet) karşılanır ve arada birkaç ağ çağrısı yapılır. Uber'in 3000'den fazla hizmete sahip mikro hizmet mimarisi için aşağıya bakın.

Uber'in 2018 mikro hizmet mimarisi. Kaynak: https://www.uber.com/en-IN/blog/microservice-architecture/

Bu tür karmaşık sistemlerde, dağıtılmış izleme her türlü sorun giderme için kritik hale gelir. Sonuç olarak Dağıtılmış İzleme, büyük, karmaşık, dağıtılmış ortamları kullanan ve ilk benimseyen büyük şirketler tarafından öncülük edildi.

• Google'ın 2010'da yayınladığı Dapper makalesi dağıtılmış izlemenin başlangıcıydı

  
  

• Önümüzdeki birkaç yıl içinde iki şirket daha kendi dağıtılmış izleme sistemlerini açık kaynaklı hale getirdi (2012'de Twitter açık kaynaklı Zipkin ve 2017'de Uber açık kaynaklı Jaeger). Zipkin ve Jaeger bugün bile en popüler dağıtılmış izleme araçları arasında yer almaya devam ediyor

  
  

• 2016 yılından bu yana, OpenTracing projesi aracılığıyla bileşenler arasında dağıtılmış izlemeyi standartlaştırmaya yönelik önemli bir çaba sarf ediliyor. OpenTracing, sonunda 2019'da OpenTelemetry oldu. OpenTelemetry oldukça popülerdir ve dünya çapında binlerce katkıda bulunanı vardır.

  
  

• Artık Dağıtılmış İzleme, ölçümler ve günlüklerin yanı sıra gözlemlenebilirliğin üçüncü "direği" olarak kabul ediliyor. Çoğu büyük izleme ve gözlemlenebilirlik oyuncusu, ürünlerinin bir parçası olarak dağıtılmış izleme araçları sağlar.

Dağıtılmış İzlemenin Durumu: Teori ve Gerçeklik

Ancak vaatlere, heyecana ve topluluk çabalarına rağmen bugün dağıtılmış izlemenin benimsenmesi ~%25 civarındadır. Açıkça dağıtılmış izlemeye ihtiyaç duymalarına rağmen, mikro hizmet mimarilerinde günlükler ve ölçümlerle idare eden şirketler bulmak alışılmadık bir durum değildir.

Aynı zamanda, bugün dünyada üretim hatalarının Ortalama Çözülme Süresi de artıyor. Şirketlerin %73'ü bugün üretim sorunlarını çözmenin bir saatten fazla sürdüğünü bildiriyor .

Herhangi bir geliştiriciye hayatındaki en acı anların neler olduğunu sorduğunuzda, üretimde bir Sev-1 hatasının hatalarını ayıklamak için harcanan zamandan ve sanki birkaç yüz kişinin nefes nefese kaldığından bahsedeceklerdir.

Öyle görünüyor ki, MTTR'sini önemseyen herhangi bir şirket (ki bu hemen hemen her şirket için geçerlidir) dağıtılmış izlemeyi kullanıyor olmalı ve bu ortamda benimsenme hızla artmış olmalı. Ancak gerçek rakamlar bunu desteklemiyor; peki ne veriyor?

Dağıtılmış İzlemenin Günümüzde Karşılaştığı Zorluklar

Günümüzde şirketlerin değer elde etmek için üstesinden gelmeleri gereken dağıtılmış izlemeyle ilgili çeşitli sorunlar var ve bunların hepsi ana akım anlatıda geniş çapta tartışılmıyor.

1. Uygulama zordur!

Dağıtılmış izlemeyi bugün bir hizmette uygulamak için bir kod değişikliği ve sürüm yapmamız gerekiyor. Kod değişiklikleri yapmak yeterince yaygın bir gözlemlenebilirlik isteği olsa da, özellikle dağıtılmış izlemeyle ilgili zorluk şudur: Dağıtılmış bir izleme elde etmek için hizmetin veya bileşenin tamamının ayarlanması gerekir, aksi takdirde iz kesilir.

İzleme veya kayıt tutmada olduğu gibi tek bir hizmetle başlayıp değer elde etmek mümkün değildir. Dağıtılmış izleme, kullanılabilir izlemeler oluşturmak için kolektif bir hizmet kümesi genelinde enstrümantasyon gerektirir.

Bu, hizmetlerinde değişiklik yapmak için çeşitli ekipler ve hizmet sahipleri arasında koordinasyon gerektirir. Yani bu bir organizasyonel sorun haline geliyor; siz değerin farkına varmadan önce, birkaç ay boyunca 100'lerce ekibin hizmetlerini araçlandırdığını hayal edin.

Günümüzde dağıtılmış izlemenin en büyük zorluğu budur.

2. Karmaşık örnekleme kararlarına duyulan ihtiyaç

Ayrıca, Dağıtılmış İzleme tarafından oluşturulan izleme verilerinin hacmi çok büyük olabilir. Her bir istek için her birinin az miktarda izleme verisi yaydığı yüzlerce hizmetin olduğunu hayal edin. Bu, saniyede milyonlarca istek anlamına gelecektir ve dağıtılmış izlemeyi hem depolama hem de ağ bant genişliği açısından pahalı hale getirecektir.

Günlük kaydı da aynı şeyi yapsa da (ve istek başına daha fazla veri yayar, bu daha sonra büyük günlük toplama araçları tarafından yönetilir), aradaki fark, günümüzde çoğu şirketin zaten günlük kaydına sahip olmasıdır . Neredeyse günlük kaydı kadar hacimli olacak bir veri türünün daha tanıtılması göz korkutucu bir iştir ve muhtemelen harcamayı iki katına çıkaracaktır.

Bu maliyet sorununun üstesinden gelmek için günümüzde tüm dağıtılmış izleme sistemleri örneklemeyi kullanıyor ve izlerin yalnızca bir alt kümesini kaydediyor. Günümüzde pratikte yaygın olarak kullanılan örnekleme oranları %0,1 ila %2 arasındadır. Bunun mantığı, örneklerin %1'inin bile performans darboğazlarının nerede olduğuna dair iyi bir toplu resim vermeye yeterli olmasıdır.

Günümüzde çoğu platform, müşterilerin örnekleme stratejilerini seçmelerine ve maliyet görünürlüğü konusunda kendi ödünlerini vermelerine olanak tanıyor. Ancak bu karar süreci, dağıtılmış bir izleme sisteminin enstrümantasyon ve yönetimine ilişkin zaten karmaşık olan ek yüke katkıda bulunur.

3. Ancak örnekleme değeri anlamlı bir şekilde azaltır

Bir şirketin her hizmeti/bileşeni ölçme çabasından geçtiğini ve ardından bütçeyi zorlamamalarını sağlamak için örnekleme stratejisine karar verdiğini varsayalım.

Şimdi ne olacak; MTTR'nin dramatik bir şekilde düşmesini mi beklemeliyiz? Hayır, çünkü geliştiriciler örnekleme nedeniyle sorunları gerçekten gidermek için dağıtılmış izlemeyi kullanamazlar.

Bir geliştiricinin deneyimini hayal edin: "Orada olduğunu bildiğim sorunu bulamıyorum. Hatayı oluşturdum ancak karşılık gelen izi bulamıyorum".

Peki ne olur? Geliştiriciler dağıtılmış izleme verilerinin kalitesine güvenmeyi bırakır ve hata ayıklama/sorun giderme için normal yöntemlerine (ör. günlükleri kullanma) geri dönerler.

4. Geliştirici kullanımı düşük sıklıkta

Bu kısıtlamalar göz önüne alındığında, günümüzde Dağıtılmış İzleme öncelikle performans sorunlarını gidermenin bir yolu olarak satılmaktadır.

Temel bir dağıtılmış izlemenin bize gerçekte kimin kimi aradığını ve her bir aralığın ne kadar sürdüğünü söylediğini unutmayın. Dağıtılmış izler, hizmet içinde hataya/yüksek gecikmeye neden olan şeyin ne olduğunu bize söylemez. Bunun için geliştiricilerin yine de günlük mesajına bakmaları ve/veya hata ayıklamak için sorunu yerel olarak yeniden oluşturmaları gerekir.

Tipik bir şirkette performans sorunları muhtemelen toplamın %10'undan azdır. Dolayısıyla gerçekte dağıtılmış izleme, sorunların yalnızca bu küçük bölümü için faydalıdır.

Bir hizmeti sunan ve sahibi olan ortalama bir geliştirici, dağıtılmış bir izleme aracını belki yılda 2-3 kez kullanıyor.

Tüm bu zorlukların etkisi

Özetle:

1. Dağıtılmış izlemenin uygulanması zordur
2. Dağıtılmış İzleme, maliyetleri kontrol etmek için kapsamlı örnekleme gerektirir
3. Ancak örnekleme değeri önemli ölçüde azaltır
4. Sonuç olarak, geliştiriciler izlemeyi yalnızca tek seferlik performans kullanım durumu için kullanır

Bütün bunlar, dağıtılmış izleme için ROI durumunu oldukça bulanık hale getiriyor.

Tipik bir heyecan döngüsünde, şişirilmiş beklentiler aşamasını artık geride bıraktığımızı ve hayal kırıklığının yerleşmeye başladığını söyleyebiliriz.

Ancak son durum açısından düşünürsek, bilgi işlem sistemlerinin geleceği dağıtılmışsa, o zaman dağıtılmış izleme doğal olarak gözlemlenebilirlik için en temel vektör olacaktır. Bu dünyada, dağıtılmış bir mimariye sahip herhangi bir şirket, bugün sahip olduğumuz sistemlerin pasif izlenmesine karşı, üretimde meydana gelen herhangi bir şeyi gidermek için birincil mekanizma olarak izlemeyi (gerçek "gözlenebilirlik") kullanır.

Ancak bu son duruma ulaşmadan önce mevcut durum üzerinde bazı iyileştirmelere ihtiyacımız olacak. İyi haber şu ki, bunların çoğu zaten devam ediyor. Her birine bakalım. Peki gelecekte ne görmeyi bekleyebiliriz?

Dağıtılmış izlemenin geleceği

Kod değişikliği olmadan anında enstrümantasyon

Bir aracıyı bıraktığınızı ve dağıtılmış bir sistemin tamamını (tüm hizmetler, bileşenler) kod değişikliği olmadan tek seferde kapsayabildiğinizi hayal edin.

Önümüzdeki 2-3 yıl içinde bu gerçekçi bir şekilde mümkün görünüyor.

OpenTelemetry'nin otomatik enstrümantasyon kütüphaneleri bunu bazı programlama dilleri için zaten mümkün kılmaktadır (ancak Go gibi derlenmiş dillerde yetersiz kalmaktadır). Buna paralel olarak eBPF gibi teknolojiler , kod değişikliği olmadan sistem çapında enstrümantasyonu mümkün kılacak şekilde gelişiyor. İkisi arasında, enstrümantasyon sorununun birkaç yıl içinde çözülmesini rahatlıkla bekleyebiliriz.

Örnekleme, ilgi taleplerinin yapay zeka tabanlı seçimine yol açıyor

Yüksek Lisans dünyasında, rastgele örnekleme karanlık çağlardan kalma bir kalıntı gibi görünmeye başlar. İdeal olarak izlerin %100'üne bakabilmemiz, anormal görünen her şeyi tespit edebilmemiz ve bunu gelecekte incelemek üzere saklayabilmemiz gerekir. Artık rastgele örnekleme yok.

Düşünürsek ~%95'lik "mutlu istekler"i pek de umursamıyoruz. Anormal izlerin yalnızca ~%5'ini (hatalar, istisnalar, yüksek gecikme veya bazı geçici hatalar) önemsiyoruz. Bu yüzden sadece %100'e bakmanın ve ilginç %5'i seçmenin bir yoluna ihtiyacımız var.

Bugün bunu yapmayı amaçlayan kuyruk bazlı örnekleme gibi mekanizmalar var. Kuyruk tabanlı örneklemede sistem, bir istekteki tüm aralıklar tamamlanana kadar bekler ve ardından tam izlemeye dayanarak bunun saklanıp saklanmayacağına karar verir.

Kuyruk tabanlı örneklemenin ana zorluğu, tüm istek tamamlanana kadar bir izin tüm aralıklarını saklamanız ve ardından izi saklamaya/atmaya karar vermenizdir. Bu, her isteği tüm aralıklarıyla birlikte belirli bir süre boyunca (istek tamamlanana kadar) sakladığımız anlamına gelir; bu, son derece karmaşık ve pahalı olan yük dengeleme, depolama ve işleme bileşenlerine sahip ayrı bir veri mimarisi gerektirir.

OpenTelemetry'nin kuyruk tabanlı bir örnekleme toplayıcısı vardır, ancak henüz olgunlaşmamıştır ve çeşitli ölçeklenebilirlik zorlukları vardır (yukarıda bahsedilen sorun nedeniyle). Bu arada ZeroK.ai'nin de aralarında bulunduğu birçok şirket, anormallik tespitini verimli ve ölçeklenebilir hale getirmek için yapay zekayı kullanmaya çalışıyor.

Bu alandaki hızlı gelişmeyle birlikte, bu sorunun da önümüzdeki 3-5 yıl içinde çözülmesini makul bir şekilde bekleyebiliriz.

Tüm hata ayıklamayı mümkün kılan "zengin" dağıtılmış izlerin ortaya çıkışı

İzlemenin "yalnızca performans sorunları" alanından "tüm sorunlar" alanına doğru gelişmesi, yeni nesil izlemede gerçek bir sıçrama olacaktır. İşte o zaman dağıtılmış izlemenin gerçek gücü ortaya çıkar.

Bunun mümkün olabilmesi için her izin zengin bir içeriğe sahip olması gerekir.

Her izdeki her yayılmanın aşağıdakilere sahip olduğu bir senaryo hayal edin:

• İstek ve yanıt verileri (PII maskelemeyle)

• İstisnalar için yığın izleri

• Kütükler

• Kubernetes etkinlikleri

• Kapsül durumları

• Ve bu aralıkta meydana gelen diğer her şey

  
  

Hepsi bir arada entegre, kesintisiz akış.

Ve kişinin aradığı izi bulmanın son derece kolay olduğunu hayal edin; örneklemeyle ilgili veri boşlukları yoktur, sorunlar tekilleştirilir ve gruplandırılır ve çeşitli boyutlara göre filtrelenebilir.

O halde, bir geliştiricinin herhangi bir yazılım sorununda hata ayıklaması için ihtiyaç duyduğu tek şey budur. Ve potansiyel olarak, bir yapay zeka modelinin tümünün, geliştiriciyi neyin yanlış gittiğini teşhis etmesi ve yönlendirmesi gerekir.

Bu dünyada, izleme, günlüğe kaydetmenin yerini alarak gözlemlenebilirliğin birincil ekseni haline gelir. Dağıtılmış izlemenin son durumu böyle görünebilir; henüz burada olmasa da, bugün bulunduğumuz yerden görülebilir.

Bunu mümkün kılmanın önündeki temel engel, tüm bu bağlam verilerinin depolanmasının neden olacağı veri hacmindeki patlamadır. Bunu mümkün kılmak için veri işleme ve depolama mimarilerinde derin yeniliklere ihtiyacımız olacak. Henüz erken günler ve burada neler olacağını bekleyip görmemiz gerekiyor.

Özet

Özetle Dağıtılmış İzleme, üretimdeki dağıtılmış uygulama mimarilerini gözlemleyebilmek için gereken gerekli ve sezgisel bir görünümdür.

İlk nesil dağıtılmış izleme, umut verici olsa da, şirketlerin izlemeden değer elde etmesini zorlaştıran çeşitli zorluklarla kuşatılmıştır ve bu da benimsenmeyi bir şekilde engellemiştir.

Bununla birlikte, uzayda, izlemeyi bugün sahip olduğumuzdan daha kolay, daha basit ve daha güçlü hale getirmesi ve gelecekte gözlemlenebilirliği daha kusursuz hale getirmesi beklenen birçok heyecan verici gelişme meydana geliyor.