Tam bağlantı izleme: çözüme genel bakış ve karşılaştırma | gerçekten kuru
Mikro hizmet mimarisinin popülaritesiyle, hizmetler farklı boyutlara göre bölünmüştür ve bir talep genellikle birden çok hizmeti içerir. İnternet uygulamaları, farklı yazılım modülleri setleri üzerine inşa edilmiştir.Bu yazılım modülleri farklı ekipler tarafından geliştirilebilir, farklı programlama dillerinde uygulanabilir, binlerce sunucuya dağıtılabilir ve birden fazla farklı veriyi kapsayabilir. merkez. Bu nedenle, sistem davranışını anlamaya ve performans sorunlarını analiz etmeye yardımcı olabilecek bazı araçlara ihtiyaç vardır, böylece bir hata oluştuğunda sorunun hızlı bir şekilde bulunup çözülebilir.
Tam bağlantı izleme bileşeni, bu sorunun arka planı altında oluşturulmuştur. En ünlüsü, Google'ın yayınlanan makalelerinde adı geçen Google Dapper'dır. Bu bağlamda dağıtılmış bir sistemin davranışını anlamak için, farklı uygulamalar ve farklı sunucular arasındaki ilgili eylemleri izlemek gerekir.
Bu nedenle, karmaşık bir mikro hizmet mimarisi sisteminde, hemen hemen her ön uç talebi, karmaşık bir dağıtılmış hizmet çağırma bağlantısı oluşturacaktır. Bir talebin tüm çağrı zinciri aşağıdaki şekilde gösterildiği gibi olabilir:
Daha sonra, iş ölçeğinin artması, artan hizmetler ve sık değişiklik olması durumunda, karmaşık çağrı bağlantılarının yüzü bir dizi sorunu beraberinde getirecektir:
- Sorunu hızlı bir şekilde nasıl bulabilirim?
- Arızanın kapsamı nasıl değerlendirilir?
- Hizmet bağımlılığı ve bağımlılığın rasyonelliği nasıl çözülür?
- Bağlantı performansı sorunları ve gerçek zamanlı kapasite planlaması nasıl analiz edilir?
Aynı zamanda, istek işleme sırasında her aramanın çeşitli performans göstergelerine, örneğin verim (TPS), yanıt süresi ve hata kayıtları gibi dikkat edeceğiz.
- Verimlilik, ilgili bileşenlerin, platformların ve fiziksel cihazların gerçek zamanlı verimi, topolojiye göre hesaplanabilir.
- Genel aramanın yanıt süresi ve her hizmetin yanıt süresi vb. Dahil olmak üzere yanıt süresi.
- Hata kaydı, servise göre istatistiksel birim zamanda anormal zamanların sayısını döndürür.
Tam bağlantı performans izleme, genel boyuttan yerel boyuta kadar çeşitli göstergeleri görüntüler ve uygulamalar genelinde tüm çağrı zincirlerinin performans bilgilerini merkezi olarak görüntüler, bu da genel ve yerel performansın ölçülmesini kolaylaştırır ve üretimde büyük ölçüde azaltılabilen arızaların kaynağını bulmayı kolaylaştırır Sorun giderme süresi.
Tam bağlantı izleme araçlarıyla şunları başarabiliriz:
- Bağlantı takibi isteme, hızlı arıza bulma: İş günlüğü ile birlikte çağrı zinciri aracılığıyla hata bilgilerini hızlı bir şekilde bulabilirsiniz.
- Görselleştirme: her aşama zaman alıcıdır ve performans analizi yapılır.
- Bağımlılık optimizasyonu: her bir arama bağlantısının kullanılabilirliği, hizmet bağımlılıklarını ayırma ve optimizasyon.
- Veri analizi ve bağlantı optimizasyonu: Kullanıcının davranış yolu elde edilebilir ve özet analiz birçok iş senaryosuna uygulanır.
Yukarıda belirtildiği gibi, tam bağlantılı izleme bileşenleri seçimimiz için hedef gereksinimler nelerdir? Ayrıca, Google Dapper'da da şu şekilde özetlenmiştir:
1. Probun performans tüketimi
APM bileşen hizmetlerinin etkisi yeterince küçük olmalıdır. Servis çağrısı gömme noktasının kendisi performans kaybına neden olur, bu da çağrı izleme kaybının düşük olmasını gerektirir Pratikte, örnekleme oranını yapılandırarak istek yolunu analiz etmek için talebin bir kısmı seçilir. Bazı yüksek düzeyde optimize edilmiş hizmetlerde, küçük bir kayıp bile kolayca fark edilebilir ve çevrimiçi hizmetlerin dağıtım ekibini izleme sistemini kapatmaya zorlayabilir.
2. Kodun müdahaleciliği
Yani, bir iş bileşeni olarak, diğer iş sistemlerine mümkün olduğunca az müdahale olmalı veya hiç girmemeli, kullanıcılara şeffaf olmalı ve geliştiricilerin üzerindeki yükü azaltmalıdır.
Uygulama programcıları için bir izleme sistemi olduğunu bilmeye gerek yoktur. Bir izleme sisteminin etkili olabilmesi için, uygulamaya güvenen geliştiriciler tarafından aktif olarak işbirliği yapılması gerekir.İzleme sistemi de çok kırılgandır.Çoğunlukla izleme sisteminde, uygulamada sorunlara neden olan hatalar veya ihmaller bulunur. İzleme sisteminin "her yerde dağıtılması" talebini karşılayın.
3. Ölçeklenebilirlik
Mükemmel bir çağrı izleme sistemi, dağıtılmış dağıtımı desteklemeli ve iyi bir ölçeklenebilirliğe sahip olmalıdır. Desteklenebilen bileşen sayısı ne kadar fazlaysa o kadar iyidir. Veya uygun bir eklenti geliştirme API'si sağlayın. İzlenmeyen bazı bileşenler için uygulama geliştiricileri de kendi bileşenlerini genişletebilir.
4. Veri analizi
Veri analizi hızlı olmalı ve analizin boyutları olabildiğince çok olmalıdır. İzleme sistemi, üretim ortamındaki anormal koşullara hızla yanıt vermek için yeterince hızlı bilgi geri bildirimi sağlayabilir. Kapsamlı analiz, ikincil gelişmeyi engelleyebilir.
Genel tam bağlantılı izleme sistemi kabaca dört işlevsel modüle ayrılabilir:
1. Noktaları gömmek ve günlükleri oluşturmak
Gömme noktası, istemci katıştırma noktası, sunucu katıştırma noktası ve istemci ile sunucunun iki yönlü katıştırma noktasına bölünebilen mevcut düğümdeki sistemin bağlam bilgisidir. Gömülü nokta günlüğü genellikle şu içeriği içerir: traceId, spanId, aramanın başlangıç zamanı, protokol türü, arayan ip ve portu, istenen hizmet adı, arama zamanı, arama sonucu, istisna bilgileri, vb. Aynı zamanda, genişletilebilir alanlar ayrılmıştır. Bir sonraki genişletmeye hazırlanın;
- Performans yüküne neden olamaz: Değeri doğrulanmamış ancak performansı etkileyecek bir şeyi şirkette tanıtmak zordur!
- Günlüğün yazılması gerektiğinden, işletme QPS'si ne kadar yüksekse, performans etkisi o kadar ağırdır. Örnekleme ve eşzamansız günlük ile çözüldü.
2. Günlükleri toplayın ve saklayın
MQ'yu arabellek olarak eklerken, temelde dağıtılmış günlük toplama çözümünü destekler;
- Günlük toplama için her makinede bir deamon vardır, iş süreci kendi izini daemon'a gönderir ve arka plan programı toplanan izi üst seviyeye gönderir;
- Pub / sub mimarisine benzer çok seviyeli toplayıcı denge yükleyebilir;
- Gerçek zamanlı analiz ve birleştirilmiş verilerin çevrimdışı depolanması;
- Çevrimdışı analizin aynı çağrı zincirinin günlüklerini özetlemesi gerekir;
3. Analiz ve istatistikler, bağlantı verilerini ve zamanlılığı çağırır
Çağrı zinciri izleme analizi: Aynı TraceID'nin Aralıklarını toplayın ve zaman çizelgesi zamana göre sıralanır. Stringing ParentID çağrı yığınıdır.
Bir istisna veya zaman aşımı atın ve günlüğe TraceID yazdırın. Çağrı zincirini sorgulamak ve sorunu bulmak için TraceID'yi kullanın.
Bağımlı ölçüm:
- Güçlü bağımlılık: arama hatası, ana süreci doğrudan kesintiye uğratır
- Yüksek bağımlılık: bir bağlantıda belirli bir bağımlılığı çağırma olasılığı yüksektir
- Sık bağımlılık: Aynı bağımlılık tek bağlantıda daha sık çağrılır
Çevrimdışı analiz: TraceID ile özetleyin, Span ID ve ParentID aracılığıyla arama ilişkisini geri yükleyin ve bağlantı formunu analiz edin.
Gerçek zamanlı analiz: özet veya yeniden düzenleme olmadan doğrudan tek bir günlüğü analiz edin. Mevcut QPS'yi alın, gecikme.
4. Sunum ve karar desteği
3.1 Aralık
Temel çalışma birimi olan bir bağlantı çağrısı (belirli kısıtlamalar olmaksızın RPC, DB, vb. Olabilir) bir aralık oluşturur ve bunu 64 bitlik bir kimlikle tanımlar. Uuid daha kullanışlıdır. Aralıkta açıklama bilgileri ve zaman damgası gibi başka veriler vardır , Anahtar / değer çifti (Ek açıklama) etiket bilgisi, parent_id, vb., Burada ebeveyn-kimliği, çağrı yapan bağlantının kaynağını belirtebilir.
Yukarıdaki şekil, büyük bir izleme sürecinde sürenin nasıl göründüğünü göstermektedir. Dapper, bir izleme sürecindeki farklı aralıklar arasındaki ilişkiyi yeniden yapılandırmak için aralık adını ve her bir aralığın kimliğini ve üst kimliğini kaydeder. Bir yayılma alanı bir üst kimliğe sahip değilse, buna kök aralığı denir. Tüm aralıklar belirli bir izleme ile bağlantılıdır ve ayrıca bir izleme kimliği paylaşır.
Yayılma veri yapısı :
type Span struct { TraceID int64 // Tam bir istek kimliğini işaretlemek için kullanılır İsim dizesi ID int64 // bu sefer span_id çağrısı ParentID int64 // üst hizmet aralığı_kimliği çağrısı En üstteki hizmetin parent_id'si boş Ek Açıklama Ek Açıklama // işaretleme için kullanılan zaman damgası Hata ayıklama bool }3.2 İzleme
Benzer Ağaç yapısının yayılma kümesi , İstekten sunucuya kadar tam bir izlemeyi belirtir, sunucu yanıtı sonuna kadar döndürür ve her bir rpc çağrısında harcanan zamanı izler ve benzersiz bir trace_id vardır. Örneğin: Trace bir kez çalıştırdığınız dağıtılmış büyük veri depolama, sizden gelen bir talepten oluşur.
Her rengin notu bir aralıkla işaretlenir, bir bağlantı TraceId tarafından benzersiz şekilde tanımlanır ve aralık, başlatılan istek bilgilerini tanımlar. Ağaç düğümü, tüm mimarinin temel birimidir ve her düğüm, yayılma alanına bir referanstır. . Düğümler arasındaki bağlantı, yayılma alanı ile üst aralığı arasındaki doğrudan ilişkiyi temsil eder. Aralıklar, günlük dosyasındaki aralıkların başlangıç ve bitiş zamanlarını temsil etseler de, ağaç yapısının tamamında görece bağımsızdırlar.
3.3 Ek Açıklama
Belirli bir olayla (zaman gibi) ilgili bilgileri kaydetmek için kullanılan ek açıklama, bir aralıkta birden çok ek açıklama açıklaması olacaktır. . Genellikle dört ek açıklama bilgisi içerir:
(1) cs : Client Start, yani müşterinin bir talep başlattığı anlamına gelir (2) sr : Sunucu Alımı, yani sunucunun isteği aldığı anlamına gelir (3) ss : Sunucu Gönderimi, yani sunucunun işlemi tamamladığı ve sonucu istemciye gönderdiği anlamına gelir (4) cr : İstemci Alındı; bu, istemcinin sunucu tarafından döndürülen bilgileri aldığı anlamına gelirEk açıklama veri yapısı :
type Annotation struct { Zaman damgası int64 Değer dizesi Host Endpoint Süre int32 }3.4 Çağrı örneği
1. Çağrı örneği isteyin
2. Çağrı süreci izleme
Tüm çağrı sürecini takip etmek:
- İstek geldiğinde, global bir TraceID üretilir ve tüm çağrı zinciri TraceID aracılığıyla bağlanabilir Bir TraceID bir isteği temsil eder.
- TraceID'ye ek olarak, SpanID, çağıran üst-çocuk ilişkisini kaydetmek için de gereklidir. Her hizmet, tam bir çağrı zincirinin ebeveyn-çocuk ilişkisinin organize edilebildiği üst kimlik ve kapsam kimliğini kaydeder.
- Üst kimliği olmayan bir aralık, çağrı zinciri girişi olarak kabul edilebilecek bir kök aralık haline gelir.
- Tüm bu kimlikler, küresel olarak benzersiz bir 64 bitlik tamsayı ile temsil edilebilir;
- TraceID ve SpanID, tüm çağrı sırasında her istek için şeffaf bir şekilde iletilmelidir.
- Her hizmet, isteğe bağlı TraceID ve SpanID'yi üst kimlik olarak kaydeder ve ürettiği SpanID'yi kaydeder.
- Tam bir aramayı görüntülemek için, yalnızca TraceID'ye göre tüm arama kayıtlarını bulmanız ve ardından tüm arama ebeveyn-çocuk ilişkisini ebeveyn kimliği ve aralık kimliği aracılığıyla düzenlemeniz gerekir.
5. AGENT non-invaziv dağıtım
AGENT aracısının müdahaleci olmayan kullanımı, performans ölçümünü iş mantığından tamamen ayırır ve her türden herhangi bir yöntemin uygulama süresini ölçebilir.Bu yöntem, toplama verimliliğini büyük ölçüde artırır ve işletme ve bakım maliyetlerini azaltır. Hizmet süresine göre, esas olarak iki kategoriye ayrılır :
Piyasadaki tam bağlantı izleme teorik modellerinin çoğu Google Dapper belgelerine dayanmaktadır. Bu makale aşağıdaki üç APM bileşenine odaklanmaktadır:
- Zipkin: Veri toplama, depolama, arama ve görüntüleme dahil olmak üzere mikro hizmet mimarisindeki gecikme sorununu çözmek için hizmet zamanlama verilerini toplamak için kullanılan Twitter tarafından açık kaynaklı, açık kaynaklı dağıtılmış bir izleme sistemi.
- Tam yerini saptama: Koreliler tarafından açık kaynaklı bir dağıtılmış izleme bileşeni olan Java ile yazılmış büyük ölçekli dağıtılmış sistemler için bir APM aracı.
- Skywalking: Yurt içinde üretilen mükemmel APM bileşeni, JAVA dağıtılmış uygulama kümesinin iş operasyonunu izlemek, uyarmak ve analiz etmek için bir sistemdir.
Yukarıdaki üç tam bağlantılı izleme çözümünün, çıkarılan öğelerle karşılaştırılması gerekir:
4.1 Prob performansı
Sondanın performansına daha fazla dikkat edin Sonuçta, APM konumlandırma hala bir araçtır.Bağlantı izleme kurulumu etkinleştirilirse, verim yarıdan fazla azalacaktır ve bu da kabul edilemez. Skywalking, zipkin ve nokta tespiti üzerinde basınç testleri gerçekleştirildi ve taban çizgisi ile karşılaştırıldı (prob kullanılmadı).
Spring Boot, Spring MVC, redis client ve mysql içeren yaygın bir Spring tabanlı uygulama seçtim. Bu uygulamayı izlemek için, her izleme için prob 5 aralık (1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql) alacaktır. Buradaki test uygulaması temelde skywalkingtest ile aynıdır.
Üç eşzamanlı kullanıcı simüle edilir: 500, 750 ve 1000. Test etmek için jmetre kullanın, her iş parçacığı 30 istek gönderir, düşünme süresini 10 ms'ye ayarlayın. Kullanılan örnekleme oranı, üretimden farklı olabilen% 1 veya% 100'dür. Nokta tespiti için varsayılan örnekleme oranı, aracı yapılandırma dosyası ayarlanarak% 100 olarak değiştirilen 20 veya% 50'dir. Zipkin ayrıca varsayılan olarak 1'dir. Toplamda 12 çeşit bulunmaktadır. Aşağıdaki özet tabloya bakın:
Yukarıdaki tablodan da görülebileceği gibi, üç bağlantı izleme bileşeni arasında, gökyüzü yürüyüş sondası iş hacmi üzerinde en az etkiye sahiptir ve zipkin verimi ortadadır. Nokta tespiti sondasının verim üzerinde daha belirgin bir etkisi vardır. 500 eşzamanlı kullanıcı kullanıldığında, test hizmetinin verimi 1385'ten 774'e düşürülür ve bu da büyük bir etkiye sahiptir. O halde CPU ve belleğin etkisine bakalım Dahili sunucu üzerinde yapılan basınç testi, CPU ve bellek üzerindeki etkinin neredeyse% 10 civarında olduğunu gösteriyor.
4.2 Toplayıcının ölçeklenebilirliği
Toplayıcının ölçeklenebilirliği, büyük ölçekli sunucu kümelerini desteklemek için yatay genişletmeye olanak tanır.
4.3 Kapsamlı arama bağlantısı veri analizi
Kapsamlı arama bağlantısı veri analizi, arıza noktalarını ve darboğazları kolayca bulmak için kod düzeyinde görünürlük sağlar.
4.4 Geliştirmeye şeffaf, geçişi kolay
Geliştirmeye şeffaf, geçişi kolay, kodu değiştirmeden yeni özellikler ekleyin ve etkinleştirmesi veya devre dışı bırakması kolaydır. Özelliklerin kodu değiştirmeden çalışmasını bekliyoruz ve kod düzeyinde görünürlük elde etmeyi umuyoruz.
Bunun için Zipkin, dağıtılmış işlem takibi sağlamak için değiştirilmiş bir kitaplık ve kendi kabını (Finagle) kullanır. Ancak gerektiğinde kod değişikliği gerektirir. Hem gökyüzü yürüyüşü hem de nokta tespiti bayt kodu geliştirmeye dayalıdır, geliştiricilerin kodu değiştirmesine gerek yoktur ve bayt kodunda daha fazla bilgi olduğu için daha doğru veriler toplayabilir.
4.5 Tam çağrı zinciri uygulama topolojisi
Uygulama mimarisini anlamanıza yardımcı olmak için uygulama topolojisini otomatik olarak tespit edin.
Yukarıdaki üç şekil, sırasıyla, eksiksiz bir çağrı zinciri uygulama topolojisi elde edebilen APM bileşenlerinin ilgili çağrı topolojilerini göstermektedir. Nispeten konuşursak, nokta belirleme arayüzü, adı verilen DB adına özel olarak daha bol görüntüler, zipkin topolojisi hizmetler arasında hizmet vermekle sınırlıdır.
4.6 Pinpoint ve Zipkin arasında hassas karşılaştırma
4.6.1 Nokta Tespiti ve Zipkin arasındaki farklar
4.6.2 Pinpoint ve Zipkin arasındaki benzerlik
Hem Pinpoint hem de Zipkin, Google Dapper'ın makalesine dayanmaktadır, bu nedenle teorik temel kabaca aynıdır. Her ikisi de hizmet çağrısını bir dizi basamaklı Aralıklara böler ve çağrı ilişkilerini basamaklamak için SpanId ve ParentSpanId'i kullanır; Son olarak, tüm çağrı zincirinde akan tüm Aralıklar bir izde toplanır ve hizmete bildirilir Sonunda toplayıcı toplar ve depolar.
Bu noktada bile, Pinpoint tarafından kullanılan kavram, bu makale ile tamamen tutarlı değildir. Örneğin, TraceId yerine TransactionId kullanır ve gerçek TraceId, TransactionId, SpanId ve ParentSpanId içeren bir yapıdır. Ve Pinpoint, Span'ın altına bir Span'ın dahili çağrı ayrıntılarını (belirli yöntem çağrıları vb.) Kaydetmek için kullanılan bir SpanEvent yapısı ekler, böylece Pinpoint varsayılan olarak Zipkin'den daha fazla izleme verisi kaydeder.
Ancak teorik olarak, Span öğesinin ayrıntı düzeyi için bir sınır yoktur, bu nedenle bir hizmet çağrısı bir Span olabilir, o zaman her hizmetteki yöntem çağrısı da bir Span olabilir. Bu durumda, Brave aslında yöntem çağrı düzeyini izleyebilir, ancak belirli uygulama ve Bunu yapmadım.
4.6.3 Bayt kodu enjeksiyonu ve API çağrısı
Pinpoint, bayt kodu enjeksiyonuna dayalı bir Java Aracısı araştırması uygularken, Zipkin'in Brave çerçevesi yalnızca uygulama düzeyinde API'ler sağlar, ancak sorunu düşünmek basit değildir. Bayt kodu enjeksiyonu basit ve kaba bir çözümdür Teorik olarak hangi yöntem denilirse adlandırılsın kod enjekte edilerek durdurulabilir yani elde edilemeyen hiçbir şey yoktur, sadece ulaşılamayanlar vardır. Ancak Brave farklıdır. Sağladığı uygulama düzeyinde API, engellemeyi başarmak için çerçevenin temelindeki sürücünün desteğini gerektirir.
Örneğin, MySQL'in JDBC sürücüsü, önleyiciyi enjekte etmek için bir yöntem sağlar. Bu nedenle, ilgili durdurmayı kolayca uygulamak için yalnızca StatementInterceptor arabirimini uygulamanız ve Bağlantı Dizesinde yapılandırmanız gerekir. Tersine, MongoDB'nin daha düşük sürümü Spring Data MongoDB'nin sürücüleri veya uygulamaları böyle bir arayüze sahip değildir.Sorgu ifadelerini yakalama işlevini uygulamak daha zordur.
Bu nedenle, bu noktada Brave bir kusurdur.Bytecode enjeksiyonunu kullanmak ne kadar zor olursa olsun, en azından ulaşılabilirdir, ancak Brave'in başlatılması imkansızdır ve enjekte edilip edilemeyeceği, ne ölçüde enjekte edilebileceği ve daha fazlası Kendi yeteneklerinden ziyade çerçevenin API'sine bağlıdır.
4.6.4 Zorluk ve maliyet
Pinpoint ve Brave eklenti kodunu basit bir şekilde okuduktan sonra, ikisinin zorluğunun dünyalar kadar farklı olduğunu görebilirsiniz. Herhangi bir geliştirme belgesinin desteği olmadan, Brave'i öğrenmek Pinpoint'ten daha kolaydır. Brave az miktarda koda sahiptir ve temel işlevler cesur çekirdek modülünde yoğunlaşmıştır Orta düzey bir geliştirici içeriğini bir günde okuyabilir ve API'nin yapısını çok net bir şekilde anlar.
Pinpoint'in kod kapsüllemesi de çok iyidir, özellikle bayt kodu enjeksiyonu için üst düzey API kapsülleme mükemmeldir, ancak bu yine de okuyucuların, kodu enjekte etmek için kullanılan çekirdek API'nin bunu yapmamasına rağmen, ne kadar bayt kodu enjeksiyonu olduğunu anlamalarını gerektirir. Fazla değil, ama iyice anlamak istiyorsanız, Korkarım Ajanın ilgili kodunun derinliklerine inmeniz gerekiyor.Örneğin, addInterceptor ile addScopedInterceptor arasındaki farkı bir bakışta anlamak zordur ve bu iki yöntem ilgili Ajan türlerinde yer alır.
Brave'in enjeksiyonu, ilgili arayüzleri sağlamak için temel çerçeveye güvenmek zorunda olduğundan, çerçeve hakkında kapsamlı bir anlayışa sahip olmaya gerek yoktur.Sadece enjeksiyon sırasında nereye enjekte edilebileceğini ve hangi verilerin elde edilebileceğini bilmeniz gerekir. Yukarıdaki örnekte olduğu gibi, MySQL'in JDBC Sürücüsünün SQL'i engelleme becerisini elde etmek için nasıl uygulandığını bilmemize gerek yok.
Ancak Pinpoint, hemen hemen her yere herhangi bir kodu enjekte edebildiğinden, Pinpoint, geliştiricilerin enjekte edilecek kitaplığın kod uygulamasını çok derinlemesine anlamalarını gerektirdiğinden, MySQL ve Http İstemci eklentilerinin uygulanmasına bakarak bir fikir edinilebilir. Tabii ki, bu aynı zamanda başka bir seviyeden, Pinpoint'in yeteneklerinin gerçekten çok güçlü olabileceğini ve varsayılan olarak uygulanan birçok eklentinin çok ince taneli durdurma elde ettiğini gösteriyor.
Temel çerçeve API'yi açığa çıkarmadığında, Brave tamamen beyhude değildir.Ayrıca belirtilen koda ilgili müdahaleyi de enjekte edebilen AOP yaklaşımını kullanabiliriz ve açıkçası AOP'nin uygulanması bayt kodu enjeksiyonundan çok daha basittir.
Yukarıdakiler doğrudan bir izleme uygulama maliyeti ile ilgilidir .. Pinpoint'in resmi teknik dokümanında bir referans veri verilmiştir. Bir sisteme entegre edilmişse, Pinpoint eklentisi geliştirme maliyeti 100'dür ve bu eklentiyi sisteme entegre etmenin maliyeti 0'dır; ancak Brave için eklenti geliştirme maliyeti sadece 20'dir ve entegrasyon maliyeti 10'dur. Bu noktadan resmi maliyet referans verisinin 5: 1 olduğu görülebilmektedir.
Ancak yetkili, entegre edilmesi gereken 10 sistem varsa, toplam maliyetin 10 * 10 + 20 = 120 olduğunu vurguladı, bu da Pinpoint'in geliştirme maliyeti olan 100'ü aşıyor ve ne kadar çok hizmet entegre edilmesi gerekiyorsa, boşluk o kadar büyük oluyor.
4.6.5 Çok yönlülük ve ölçeklenebilirlik
Açıkçası, Pinpoint, topluluk tarafından geliştirilen entegre arayüzden de görülebileceği gibi, bu noktada tamamen dezavantajlı durumda.
Pinpoint'in veri arayüzü dokümantasyondan yoksundur ve çok standart değildir (forum tartışma gönderilerine bakın) Kendi probunuzu (Node veya PHP gibi) uygulamak için çok sayıda kod okumanız gerekir. Ekip, HTTP ve JSON'dan çok daha zor olan performans değerlendirmeleri için veri aktarım protokol standardı olarak Thrift'i kullandı.
4.6.6 Topluluk Desteği
Söylemeye gerek yok, Zipkin Twitter tarafından geliştirildi ve bir yıldız ekip olarak kabul edilebilirken, Naver'in ekibi sadece bilinmeyen küçük bir ekip (# 1759'daki tartışmadan görülebileceği gibi). Bu projenin kısa vadede kaybolması veya güncellenmesini durdurması muhtemel olmasa da, eskisi kadar güvenli değil.
Ve topluluk tarafından geliştirilen daha fazla eklenti yok Pinpoint'in birçok çerçevenin entegrasyonunu yalnızca ekibin kendi gücüyle tamamlaması zordur ve şu anki odak noktaları hala performansı ve kararlılığı artırmaktır.
4.6.7 Diğer
Uygulamanın başlangıcında dikkate alınan performans sorunlarını kesin olarak belirleyin. Www.naver.com web sitesinin bazı arka uç hizmetleri her gün 20 milyardan fazla isteği işler, böylece Thrift'in ikili değişken uzunluklu kodlama biçimini seçecek ve iletim olarak UDP'yi kullanacaklardır. Aynı zamanda, sabitleri iletirken veri referans sözlüğünü kullanmayı deneyin, doğrudan bir dizeyi iletmek yerine bir sayı iletin, vb. Bu optimizasyonlar aynı zamanda sistemin karmaşıklığını da artırır: Thrift arayüzünü kullanmanın zorluğu, UDP veri aktarımı sorunu ve veri sabiti sözlüğünün kaydı vb.
Bunun aksine, Zipkin bilinen Restful arayüzü artı JSON kullanır ve neredeyse hiç öğrenme maliyeti ve entegrasyon zorluğu yoktur.Veri aktarım yapısını bildiğiniz sürece, yeni bir çerçeve için karşılık gelen bir arayüzü kolayca geliştirebilirsiniz.
Ek olarak, Pinpoint istekleri örnekleme yeteneğinden yoksundur Açıkçası, yüksek trafikli bir üretim ortamında tüm istekleri kaydetmek imkansızdır.Bu, hangi istekleri kaydetmem gerektiğini belirlemek için isteklerin örneklenmesini gerektirir. Hem Nokta Tespiti hem de Cesur örnekleme yüzdelerini, yani isteklerin yüzde kaçının kaydedileceğini destekler. Bununla birlikte, buna ek olarak, Brave, özellikle A / B testi yaparken, örnekleme stratejisini özelleştirmenize izin veren Örnekleyici arayüzünü de sağlar, bu işlev çok anlamlıdır.
4.6.8 Özet
Kısa vadeli hedefler açısından, Pinpoint'in çok büyük bir avantajı vardır: problar proje kodunda herhangi bir değişiklik yapılmadan dağıtılabilir, izleme verileri yöntem çağrı düzeyine göre ince detaylandırılabilir, güçlü kullanıcı arayüzü ve neredeyse kapsamlı Java çerçeve desteği . Ancak uzun vadede, Pinpoint'in geliştirme arayüzünü öğrenmek ve gelecekte farklı çerçeveler için arayüz uygulama maliyeti hala bilinmemektedir.
Aksine, Brave'de ustalaşmak nispeten kolaydır ve Zipkin'in topluluğu daha güçlüdür ve gelecekte daha fazla arayüz geliştirme olasılığı daha yüksektir. En kötü durumda, çok fazla yeni teknoloji ve kavram getirmeden AOP aracılığıyla kendimize uygun izleme kodunu da ekleyebiliriz. Ve gelecekte işler değiştiğinde, Pinpoint tarafından resmi olarak sağlanan raporların gereksinimleri karşılayıp karşılayamayacağını söylemek zordur.Yeni raporların eklenmesi de öngörülemeyen iş zorluğu ve iş yükü getirecektir.
Monitör, sistem izleme ve uygulama izleme olarak ikiye ayrılabilir. Sistem CPU, bellek, ağ, disk vb. Gibi genel sistem yük verilerini izler ve her işlemin ilgili verilerine göre detaylandırılabilir. Bu tür bilgiler doğrudan sistemden elde edilebilir. Uygulama izleme, uygulamanın destek sağlamasını ve ilgili verileri ifşa etmesini gerektirir.
Örneğin, uygulama tarafından talep edilen QPS, talep işlemenin gecikmesi, işlenmesi istenen hata sayısı, mesaj kuyruğunun sıra uzunluğu, kilitlenme durumu, işlem çöp toplama bilgileri vb. Monitor'un temel amacı anormallikleri tespit etmek ve zamanında polisi aramaktır.
Tracing'in temeli ve özü çağrı zincirleridir. İlgili ölçümlerin çoğu, çağrı zinciri analiz edilerek elde edilir. Tracing'in temel amacı sistem analizidir. Sorunu, oluştuktan sonra çözmek yerine önceden bulmak daha iyidir.
İzleme ve uygulama düzeyindeki İzleme teknolojisi yığınının pek çok ortak noktası vardır. Hepsinde veri toplama, analiz, depolama ve geliştirme var. Sadece toplanan verilerin boyutları farklıdır ve analiz süreci farklıdır.
