Not. tercüme: Bu materyalin yazarı, imgix'te API geliştirme ve özellikle mikro hizmet testi konusunda uzmanlaşmış bir mühendis olan Cindy Sridharan'dır. Bu materyalde, acil sorunları çözmek için gerçekten etkili araçların bulunmadığını düşündüğü dağıtılmış izleme alanındaki mevcut sorunlara ilişkin ayrıntılı vizyonunu paylaşıyor.
[İllüstrasyon şu kaynaktan alınmıştır: dağıtılmış izleme hakkında.]
Bu inanılır uygulanması zor ve geri dönüşü . İzlemenin sorunlu olmasının birçok nedeni vardır; bunlar genellikle her sistem bileşeninin, her istekle birlikte uygun başlıkları iletecek şekilde yapılandırılmasında harcanan emekten kaynaklanır. Bu sorun mevcut olsa da hiçbir şekilde aşılamaz değildir. Bu arada, geliştiricilerin izlemeyi neden gerçekten sevmediklerini açıklamıyor (zaten çalışıyor olsa bile).
Dağıtılmış izlemeyle ilgili temel zorluk, veri toplamak, sonuçları dağıtmak ve sunmak için formatları standartlaştırmak veya ne zaman, nerede ve nasıl numune alınacağını belirlemek değildir. Hayal etmeye çalışmıyorum önemsiz bu "anlaşılabilirlik sorunları" aslında oldukça önemli teknik sorunlardır ve (eğer gerçekten Açık Kaynak düşünüyorsak) ) bu sorunların çözülmüş sayılması için aşılması gereken siyasi zorluklar.
Ancak tüm bu sorunların çözüldüğünü hayal edersek, durum açısından önemli bir şeyin değişmeme ihtimali yüksek. son kullanıcı deneyimi. İzleme, dağıtıldıktan sonra bile en yaygın hata ayıklama senaryolarında hala pratik kullanımda olmayabilir.
Çok farklı bir iz
Dağıtılmış izleme birkaç farklı bileşen içerir:
- uygulamaları ve ara yazılımları kontrol araçlarıyla donatmak;
- dağıtılmış içerik aktarımı;
- izlerin toplanması;
- iz depolama;
- bunların çıkarılması ve görselleştirilmesi.
Dağıtılmış izlemeyle ilgili birçok konuşmada, bunun tek amacı sistemi tam olarak teşhis etmeye yardımcı olan bir tür tekli işlem olarak ele alınma eğilimi vardır. Bu büyük ölçüde dağıtılmış izleme hakkındaki fikirlerin tarihsel olarak nasıl oluştuğundan kaynaklanmaktadır. İÇİNDE Zipkin kaynakları açıldığında yapılan açıklamada şu ifadelere yer verildi: o [Zipkin] Twitter'ı daha hızlı hale getiriyor. İzlemeye yönelik ilk ticari teklifler de şu şekilde tanıtıldı: .
Not. tercüme: Daha fazla metnin anlaşılmasını kolaylaştırmak için iki temel terimi şu şekilde tanımlayalım: :
- Açıklık — Dağıtılmış izlemenin temel unsuru. Belirli bir iş akışının (örneğin bir veritabanı sorgusu) bir ad, başlangıç ve bitiş saatleri, etiketler, günlükler ve bağlamla birlikte açıklamasıdır.
- Kapsama alanları genellikle diğer kapsamlara bağlantılar içerir ve birden fazla yayılma alanının birleştirilmesine olanak tanır. Iz — dağıtılmış bir sistem boyunca hareket ederken bir isteğin ömrünün görselleştirilmesi.
İzler, üretim testi, olağanüstü durum kurtarma testi, hata ekleme testi vb. görevlerde yardımcı olabilecek inanılmaz derecede değerli veriler içerir. Aslında bazı şirketler izlemeyi benzer amaçlarla zaten kullanıyor. Şununla başlayalım: Açıklıkları depolama sistemine taşımanın yanı sıra başka kullanımları da vardır:
- Örneğin, Uber Test trafiği ile üretim trafiğini birbirinden ayırmak için sonuçların izlenmesi.
- Facebook Kritik yol analizi ve düzenli olağanüstü durum kurtarma testleri sırasında trafik geçişi için izleme verileri.
- Ayrıca sosyal ağ Geliştiricilerin izleme sonuçları üzerinde rastgele sorgular çalıştırmasına olanak tanıyan Jupyter not defterleri.
- Taraftarlar (Soyuna Dayalı Arıza Enjeksiyonu) Hata enjeksiyonu ile test için dağıtılmış izler.
Yukarıda listelenen seçeneklerin hiçbiri tamamen senaryoya uygulanmaz hata ayıklamaBu sırada mühendis ize bakarak sorunu çözmeye çalışır.
Ne zaman geliyor henüz hata ayıklama komut dosyasına ulaştığında birincil arayüz diyagram olarak kalır izleme görünümü (her ne kadar bazıları buna da diyorsa da) "Gantt şeması" veya "şelale diyagramı"). Altında izleme görünümü я izlemeyi oluşturan tüm kapsamlar ve bunlara eşlik eden meta veriler. Her açık kaynaklı izleme sistemi ve her ticari izleme çözümü, izleme görünümü İzleri görselleştirmek, detaylandırmak ve filtrelemek için kullanıcı arayüzü.
Şu ana kadar gördüğüm tüm izleme sistemlerindeki sorun şu ki, ortaya çıkan sonuç görselleştirme (iz izleme) iz oluşturma sürecinin özelliklerini neredeyse tamamen yansıtır. Alternatif görselleştirmeler önerildiğinde bile: ısı haritaları, hizmet topolojileri, gecikme histogramları, sonuçta bunlar izleme görünümü.
Geçmişte ben UI/UX izlemedeki çoğu "yeniliğin" aşağıdakilerle sınırlı olduğu görülüyor: izlemede ek meta veriler, bunlara yüksek önem derecesine sahip bilgiler yatırılır (yüksek kardinalite) veya belirli aralıklara ayrıntılı inceleme veya sorgu çalıştırma yeteneği sağlama izlemeler arası ve izleme içi. Bu durumda, izleme görünümü birincil görselleştirme aracı olmaya devam ediyor. Bu durum devam ettiği sürece, dağıtılmış izleme (en iyi ihtimalle) bir hata ayıklama aracı olarak metrikler, günlükler ve yığın izlemelerden sonra 4. sırada yer alacak ve en kötü ihtimalle para ve zaman kaybı haline gelecektir.
İzleme görünümüyle ilgili sorun
kader izleme görünümü - Tek bir isteğin ilgili olduğu dağıtılmış sistemin tüm bileşenleri arasındaki hareketinin tam bir resmini sağlar. Bazı daha gelişmiş izleme sistemleri, bireysel aralıkları ayrıntılı olarak incelemenize ve zaman içindeki dökümü görüntülemenize olanak tanır içinde bir süreç (yayılmaların işlevsel sınırları olduğunda).
Mikro hizmet mimarisinin temel dayanağı, organizasyon yapısının şirketin ihtiyaçları ile birlikte büyüdüğü düşüncesidir. Mikro hizmetlerin savunucuları, çeşitli iş görevlerini bireysel hizmetlere dağıtmanın, küçük, özerk geliştirme ekiplerinin bu tür hizmetlerin tüm yaşam döngüsünü kontrol etmesine olanak sağladığını ve onlara bu hizmetleri bağımsız olarak oluşturma, test etme ve dağıtma yeteneği verdiğini savunuyor. Ancak bu dağıtımın dezavantajı, her hizmetin diğerleriyle nasıl etkileşime girdiğine ilişkin bilgi kaybıdır. Bu gibi durumlarda, dağıtılmış izlemenin vazgeçilmez bir araç olduğu iddia edilir. hata ayıklama hizmetler arasındaki karmaşık etkileşimler.
Eğer gerçekten o zaman tek bir kişi bile bunu aklında tutamaz полную resim. Aslına bakılırsa, bunun mümkün olduğu varsayımına dayalı bir araç geliştirmek, bir çeşit anti-modeldir (etkisiz ve verimsiz bir yaklaşım). İdeal olarak hata ayıklama, yardımcı olan bir araç gerektirir. arama alanınızı daraltınBöylece mühendisler, dikkate alınan sorun senaryosuyla ilgili boyutların bir alt kümesine (hizmetler/kullanıcılar/ana bilgisayarlar vb.) odaklanabilirler. Bir arızanın nedenini belirlerken mühendislerin arıza sırasında ne olduğunu anlamalarına gerek yoktur. tüm hizmetler aynı andaçünkü böyle bir gereklilik mikro hizmet mimarisi fikriyle çelişecektir.
Ancak traceview tam Bu. Evet, bazı izleme sistemleri, izdeki yayılma sayısı tek bir görselleştirmede görüntülenemeyecek kadar büyük olduğunda sıkıştırılmış izleme görünümleri sunar. Bununla birlikte, bu kadar basitleştirilmiş bir görselleştirmenin bile içerdiği büyük miktarda bilgi nedeniyle, mühendisler hala zorla Seçimi, sorunların kaynağı olan bir dizi hizmetle manuel olarak daraltarak "eleyin". Ne yazık ki bu alanda makineler insanlardan çok daha hızlı, hata yapma olasılığı daha az ve sonuçları daha tekrarlanabilir.
Traceview'in yanlış olduğunu düşünmemin bir diğer nedeni de hipoteze dayalı hata ayıklama için iyi olmamasıdır. Özünde, hata ayıklama yinelemeli Bir hipotezle başlayan, sistemden elde edilen çeşitli gözlemlerin ve gerçeklerin farklı vektörler, sonuçlar/genellemeler doğrultusunda doğrulanması ve hipotezin doğruluğunun daha ileri değerlendirilmesi ile devam eden bir süreç.
Fırsat hızlı ve ucuz hipotezleri test etmek ve buna göre zihinsel modeli geliştirmek köşetaşı hata ayıklama Herhangi bir hata ayıklama aracı olmalıdır etkileşimli ve arama alanını daraltın veya yanlış yönlendirme durumunda kullanıcının geri dönüp sistemin farklı bir alanına odaklanmasına izin verin. Mükemmel araç bunu yapacak proaktif olarak, kullanıcının dikkatini potansiyel sorunlu alanlara anında çeker.
ne yazık ki izleme görünümü etkileşimli arayüze sahip bir araç denemez. Bunu kullanırken umabileceğiniz en iyi şey, artan gecikmenin bir kaynağını bulmak ve onunla ilişkili tüm olası etiketlere ve günlüklere bakmaktır. Bu, mühendisin tanımlamasına yardımcı olmaz. desenler trafikte gecikme dağılımının özellikleri gibi veya farklı ölçümler arasındaki korelasyonları tespit etmek. bu sorunlardan bazılarını çözmeye yardımcı olabilir. Gerçekten mi, Anormal kapsamları belirlemek ve anormal davranışlarla ilişkilendirilebilecek bir etiket alt kümesini belirlemek için makine öğrenimini kullanan başarılı bir analiz. Ancak, izleme görünümünden veya DAG'den (yönlendirilmiş döngüsel olmayan grafik) önemli ölçüde farklı olan aralıklara uygulanan makine öğrenimi veya veri madenciliği bulgularının ilgi çekici görselleştirmelerini henüz görmedim.
Açıklıklar çok düşük seviyede
Traceview ile ilgili temel sorun şudur: açıklıklar hem gecikme analizi hem de kök neden analizi için çok düşük seviyeli ilkellerdir. Bu, bir istisnayı çözmeye çalışmak için tek tek işlemci komutlarını ayrıştırmaya benzer; geri izleme gibi birlikte çalışmanın çok daha kolay olduğu çok daha üst düzey araçların olduğunu bilmek.
Ayrıca şunu belirtme özgürlüğünü kullanacağım: ideal olarak, Tam resim Modern izleme araçlarıyla temsil edilen istek yaşam döngüsü sırasında meydana geldi. Bunun yerine, neyin ne olduğu hakkında bilgi içeren daha yüksek düzeyde bir soyutlama gereklidir. yanlış gitti (geri izlemeye benzer), bazı bağlamlarla birlikte. İzin tamamını izlemek yerine görmeyi tercih ederim частьilginç veya olağandışı bir şeyin gerçekleştiği yer. Şu anda arama manuel olarak gerçekleştiriliyor: mühendis izi alıyor ve ilginç bir şey bulmak için aralıkları bağımsız olarak analiz ediyor. Şüpheli etkinliği tespit etme umuduyla bireysel izlerdeki aralıklara bakan kişilerin yaklaşımı hiç ölçeklenmiyor (özellikle de yayılma kimliği, RPC yöntem adı, yayılma süresi gibi farklı aralıklarda kodlanmış tüm meta verileri anlamaları gerektiğinde) 'a, günlükler, etiketler vb.).
Traceview'e alternatifler
İzleme sonuçları, sistemin birbirine bağlı kısımlarında neler olup bittiğine dair önemsiz olmayan bir içgörü sağlayacak şekilde görselleştirilebildiğinde en kullanışlıdır. Bu gerçekleşene kadar hata ayıklama işlemi büyük ölçüde devam eder hareketsiz ve kullanıcının doğru korelasyonları fark etme, sistemin doğru kısımlarını kontrol etme veya bulmacanın parçalarını bir araya getirme becerisine bağlıdır. araçkullanıcının bu hipotezleri formüle etmesine yardımcı olur.
Görsel tasarımcı veya kullanıcı deneyimi uzmanı değilim ancak bir sonraki bölümde bu görselleştirmelerin nasıl görünebileceğine dair birkaç fikir paylaşmak istiyorum.
Belirli hizmetlere odaklanın
Sektörün fikirler etrafında birleştiği bir dönemde , bireysel ekiplerin hizmetlerinin bu hedeflerle uyumlu olmasını sağlamaya öncelik vermesi makul görünüyor. Şunu takip ediyor hizmet odaklı görselleştirme bu tür ekipler için en uygunudur.
İzler, özellikle örnekleme olmadan, dağıtılmış bir sistemin her bileşeni hakkında bir bilgi hazinesidir. Bu bilgi, kullanıcılara bilgi sağlayacak kurnaz bir işlemciye aktarılabilir. hizmet odaklı Bunlar, kullanıcı izlere bakmadan önce bile önceden belirlenebilir:
- Yalnızca oldukça belirgin istekler için gecikme dağıtım diyagramları (aykırı istekler);
- Hizmet SLO hedeflerine ulaşılamadığı durumlar için gecikme dağılımı diyagramları;
- Sorgularda en sık kullanılan, “ilginç” ve “tuhaf” etiketler tekrarlanır;
- Aşağıdaki durumlar için gecikme dökümü: bağlı hizmetler SLO hedeflerine ulaşamıyor;
- Çeşitli aşağı yönlü hizmetler için gecikme dökümü.
Bu sorulardan bazılarının yerleşik ölçümler tarafından yanıtlanmaması, kullanıcıları aralıkları incelemeye zorluyor. Sonuç olarak, son derece kullanıcı düşmanı bir mekanizmaya sahibiz.
Bu durum şu soruyu gündeme getiriyor: Peki ya farklı ekipler tarafından kontrol edilen çeşitli hizmetler arasındaki karmaşık etkileşimler? değil mi izleme görünümü böyle bir durumu vurgulamak için en uygun araç olarak görülmüyor mu?
Mobil geliştiriciler, durum bilgisi olmayan hizmetlerin sahipleri, yönetilen durum bilgisi olan hizmetlerin sahipleri (veritabanları gibi) ve platform sahipleri başka bir şeyle ilgilenebilir sunum dağıtımlı sistem; izleme görünümü temelde farklı olan bu ihtiyaçlar için fazla genel bir çözümdür. Çok karmaşık bir mikro hizmet mimarisinde bile, hizmet sahiplerinin iki veya üçten fazla yukarı ve aşağı yönde hizmet hakkında derin bilgiye ihtiyacı yoktur. Esasen çoğu senaryoda kullanıcıların yalnızca aşağıdakilerle ilgili soruları yanıtlaması gerekir: sınırlı hizmet seti.
Bu, küçük bir hizmet alt kümesini incelemek amacıyla büyüteçle bakmak gibidir. Bu, kullanıcının bu hizmetler arasındaki karmaşık etkileşimler ve bunların acil bağımlılıkları hakkında daha acil sorular sormasına olanak tanıyacaktır. Bu, mühendisin bildiği hizmetler dünyasındaki geriye dönük izlemeye benzer. o Yanlıştır ve ayrıca çevredeki hizmetlerde olup bitenleri anlamak için bir miktar anlayışa sahiptir. neden.
Benim desteklediğim yaklaşım, analizin tüm izlemeyle başladığı ve daha sonra yavaş yavaş bireysel aralıklara doğru ilerlediği yukarıdan aşağıya, izleme tabanlı yaklaşımın tam tersidir. Buna karşılık, aşağıdan yukarıya yaklaşım, olayın potansiyel nedenine yakın küçük bir alanı analiz ederek başlar ve ardından arama alanını gerektiği gibi genişletir (daha geniş bir hizmet yelpazesini analiz etmek için diğer ekipleri getirme potansiyeli ile). İkinci yaklaşım, ilk hipotezlerin hızlı bir şekilde test edilmesi için daha uygundur. Somut sonuçlar elde edildikten sonra daha odaklı ve detaylı bir analize geçilmesi mümkün olacaktır.
Topoloji oluşturma
Kullanıcı bilirse hizmete özel görünümler inanılmaz derecede yararlı olabilir ne Gecikmenin artmasından veya hatalara neden olmasından bir hizmet veya hizmet grubu sorumludur. Ancak karmaşık bir sistemde, arızaya neden olan hizmeti tanımlamak, özellikle hizmetlerden herhangi bir hata mesajı bildirilmediyse, bir arıza sırasında önemsiz olmayan bir görev olabilir.
Bir hizmet topolojisi oluşturmak, hangi hizmetin hata oranlarında ani bir artış veya hizmetin gözle görülür şekilde bozulmasına neden olan gecikme artışı yaşadığını belirlemede büyük bir yardımcı olabilir. Bir topoloji oluşturmaktan bahsettiğimde bunu kastetmiyorum hizmetler haritasıSistemde mevcut olan ve bilinen her hizmeti gösteren . Bu görünüm, yönlendirilmiş döngüsel olmayan bir grafiğe dayalı izleme görünümünden daha iyi değildir. Bunun yerine görmek isterim dinamik olarak oluşturulmuş hizmet topolojisi, hata oranı, yanıt süresi gibi belirli niteliklere veya belirli şüpheli hizmetlerle ilgili durumu açıklığa kavuşturmaya yardımcı olan kullanıcı tanımlı herhangi bir parametreye dayalıdır.
Bir örnek verelim. Varsayımsal bir haber sitesi düşünelim. Ana sayfa hizmeti (ön Sayfa) Redis ile tavsiye hizmeti, reklam hizmeti ve video hizmeti aracılığıyla veri alışverişinde bulunur. Video hizmeti, videoları S3'ten ve meta verileri DynamoDB'den alır. Öneri hizmeti, meta verileri DynamoDB'den alır, Redis ve MySQL'den veri yükler ve mesajları Kafka'ya yazar. Reklam hizmeti MySQL'den veri alır ve Kafka'ya mesaj yazar.
Aşağıda bu topolojinin şematik bir temsili bulunmaktadır (birçok ticari yönlendirme programı topolojiyi oluşturur). Hizmet bağımlılıklarını anlamanız gerekiyorsa yararlı olabilir. Ancak sırasında hata ayıklamaBelirli bir hizmet (örneğin bir video hizmeti) artan yanıt süresi gösterdiğinde, böyle bir topoloji pek kullanışlı değildir.
Varsayımsal bir haber sitesinin hizmet şeması
Aşağıdaki şema daha uygun olacaktır. Hizmette sorun var (Video) tam ortada tasvir edilmiştir. Kullanıcı bunu hemen fark eder. Bu görselleştirmeden, ana sayfanın bir kısmının yükleme hızını etkileyen S3 yanıt süresindeki artış nedeniyle video hizmetinin anormal şekilde çalıştığı anlaşılıyor.
Yalnızca “ilginç” hizmetleri görüntüleyen dinamik topoloji
Dinamik olarak oluşturulan topolojiler, özellikle elastik, otomatik ölçeklendirmeli altyapılarda statik hizmet haritalarından daha verimli olabilir. Hizmet topolojilerini karşılaştırma ve karşılaştırma yeteneği, kullanıcının daha alakalı sorular sormasına olanak tanır. Sistem hakkında daha kesin sorular, sistemin nasıl çalıştığının daha iyi anlaşılmasına yol açacaktır.
Karşılaştırmalı ekran
Başka bir yararlı görselleştirme karşılaştırmalı bir gösterim olacaktır. Şu anda izler yan yana karşılaştırmalar için pek uygun değildir, bu nedenle karşılaştırmalar genellikle açıklıklar. Ve bu makalenin ana fikri tam olarak yayılmaların, izleme sonuçlarından en değerli bilgileri çıkarmak için çok düşük düzeyde olmasıdır.
İki izi karşılaştırmak temelde yeni görselleştirmeler gerektirmez. Aslında, izleme görünümüyle aynı bilgiyi temsil eden histogram gibi bir şey yeterlidir. Şaşırtıcı bir şekilde, bu basit yöntem bile iki izi ayrı ayrı incelemekten çok daha fazla sonuç getirebilir. Bu olasılık daha da güçlü olabilir görselleştirmek izlerin karşılaştırılması Toplamda. GC'yi (çöp toplama) etkinleştirmek için yakın zamanda dağıtılan bir veritabanı yapılandırma değişikliğinin, bir aşağı akış hizmetinin yanıt süresini birkaç saat ölçeğinde nasıl etkilediğini görmek son derece yararlı olacaktır. Burada tanımladığım şey altyapı değişikliklerinin etkisine ilişkin bir A/B analizi gibi görünüyorsa birçok hizmette izleme sonuçlarını kullanarak gerçeklerden çok da uzak değilsiniz.
Sonuç
İzlemenin yararlılığını sorgulamıyorum. Bir izdeki veri kadar zengin, nedensel ve bağlamsal veri toplamanın başka bir yöntemi olmadığına yürekten inanıyorum. Ancak tüm takip çözümlerinin bu verileri son derece verimsiz kullandığını da düşünüyorum. İzleme araçları, izleme görünümü temsilinde takılı kaldığı sürece, izlemelerin içerdiği verilerden elde edilebilecek değerli bilgilerden en iyi şekilde yararlanma yetenekleri sınırlı olacaktır. Ayrıca, kullanıcının uygulamadaki hataları giderme becerisini ciddi şekilde sınırlayacak, tamamen düşmanca ve sezgisel olmayan bir görsel arayüzün daha da geliştirilmesi riski de bulunmaktadır.
En son araçlarla bile karmaşık sistemlerde hata ayıklamak inanılmaz derecede zordur. Araçlar geliştiricinin bir hipotezi formüle etmesine ve test etmesine yardımcı olmalıdır. aktif olarak sağlamak ilgili bilgiler, aykırı değerlerin belirlenmesi ve gecikmelerin dağılımındaki özelliklerin not edilmesi. Üretim hatalarını giderirken veya birden fazla hizmete yayılan sorunları çözerken izlemenin geliştiricilerin tercih ettiği araç haline gelmesi için, bu hizmetleri oluşturan ve işleten geliştiricilerin zihinsel modelleriyle daha tutarlı olan orijinal kullanıcı arayüzleri ve görselleştirmelere ihtiyaç vardır.
İzleme sonuçlarında mevcut olan çeşitli sinyalleri, analiz ve çıkarımı kolaylaştıracak şekilde optimize edilmiş bir şekilde temsil edecek bir sistem tasarlamak, önemli miktarda zihinsel çaba gerektirecektir. Kullanıcının bireysel izlere veya aralıklara bakmadan kör noktaları aşmasına yardımcı olacak şekilde hata ayıklama sırasında sistem topolojisini nasıl soyutlayacağınızı düşünmeniz gerekir.
İyi soyutlama ve katmanlama yeteneklerine ihtiyacımız var (özellikle kullanıcı arayüzünde). Tekrar tekrar sorular sorabileceğiniz ve hipotezleri test edebileceğiniz hipoteze dayalı hata ayıklama sürecine iyi uyum sağlayacak olanlar. Tüm gözlemlenebilirlik sorunlarını otomatik olarak çözmeyecekler ancak kullanıcıların sezgilerini keskinleştirmelerine ve daha akıllı sorular oluşturmalarına yardımcı olacaklar. Görselleştirmeye daha düşünceli ve yenilikçi bir yaklaşım çağrısında bulunuyorum. Burada ufukları genişletmek için gerçek bir fırsat var.
çevirmenden PS
Blogumuzda da okuyun:
- «";
- «";
- «'.
Kaynak: habr.com