Süper Pratik Büyük Ölçekli Dağıtılmış Bir Sistem olan Nokta Tespit Teknolojisine Giriş
Genel Bakış
Pinpoint, büyük ölçekli dağıtılmış sistemleri analiz eden ve büyük miktarda izleme verisini işlemek için çözümler sunan bir platformdur. Geliştirme Temmuz 2012'de başladı ve 9 Ocak 2015'te açık kaynaklı bir proje olarak başlatıldı.
Bugün esas olarak Pinpoint ile ilgili kavramları tanıtıyoruz ve ardından özel yapım sürecini tanıtacağız.
Nokta özellikleri
Geçmişte İnternet kullanıcılarının sayısı nispeten azdı ve İnternet hizmetlerinin mimarisi o kadar karmaşık değildi. Web hizmetleri genellikle iki katmanlı (web sunucusu ve veritabanı) veya üç katmanlı (web sunucusu, uygulama sunucusu ve veritabanı) mimari kullanır. Ancak günümüzde, İnternet'in büyümesiyle birlikte çok sayıda eşzamanlı bağlantının desteklenmesi ve işlevlerin ve hizmetlerin organik olarak birleştirilmesi gerekmekte, bu da daha karmaşık yazılım yığını kombinasyonları ile sonuçlanmaktadır. Daha doğrusu, üçten fazla katmana sahip n katmanlı mimariler daha yaygın hale geliyor. SOA veya mikro hizmet mimarisi gerçek oluyor.
Bu nedenle sistemin karmaşıklığı artar. Sistem ne kadar karmaşıksa, sistem hataları veya performans sorunları gibi sorunları çözmek o kadar zor olur. Üç katmanlı mimaride çözüm bulmak çok zor değil, sadece web sunucusu, uygulama sunucusu ve veritabanı gibi üç bileşeni analiz etmesi gerekiyor ve sunucu sayısı fazla değil. Bununla birlikte, sorun bir n katmanlı mimaride ortaya çıkarsa, çok sayıda bileşen ve sunucunun araştırılması gerekir. Diğer bir sorun, büyük resmi yalnızca tek bir bileşeni analiz ederek görmenin zor olmasıdır; düşük görünürlük sorunu ortaya çıktığında, sistem karmaşıklığı ne kadar yüksek olursa, nedeni bulmak o kadar uzun sürer. Hepsinden kötüsü, bazı durumlarda onu bulamayabiliriz bile.
Bu tür sorunlar NAVER'ın sisteminde de ortaya çıkar. Uygulama Performans Yönetimi (APM) gibi bir çok araç kullanılmaktadır, ancak bunlar sorunu etkili bir şekilde çözmek için yeterli değildir. Bu nedenle, nihayet n katmanlı mimari için yeni bir izleme platformu geliştirmeye ve n katmanlı mimari sistemi için çözümler sağlamaya karar verdik.
Temmuz 2012'de geliştirilen ve Ocak 2015'te açık kaynaklı bir proje olarak başlayan Pinpoint, büyük ölçekli dağıtılmış sistemlere hizmet veren n katmanlı bir mimari izleme platformudur. Pinpoint'in özellikleri aşağıdaki gibidir:
- Dağıtılmış işlem izleme, dağıtılmış uygulamalarda mesajları izleme
- Uygulama mimarisini anlamanıza yardımcı olmak için uygulama topolojisini otomatik olarak tespit edin
- Büyük ölçekli sunucu kümelerini desteklemek için yatay olarak ölçeklendirin
- Arıza noktalarını ve darboğazları kolayca bulmak için kod düzeyinde görünürlük sağlayın
- Kodu değiştirmeden yeni özellikler eklemek için bayt kodu geliştirme teknolojisini kullanın
Google Dapper'da dağıtılmış işlem izleme nasıl çalışır?
Google Dapper'a dayalı olarak tek bir işlemde dağıtılmış istekleri tam olarak tespit eder.
Düğüm1'den Düğüm2'ye bir mesaj gönderildiğinde, dağıtılmış izleme sisteminin özü, dağıtılmış sistemde Düğüm1'de işlenen mesajlar ile Düğüm2'de gönderilen mesajlar arasındaki ilişkiyi tanımlamaktır.
Şekil 1. Dağıtılmış bir sistemdeki mesaj ilişkileri
Sorun, mesajlar arasındaki ilişkinin tanımlanamamasıdır. Örneğin, Düğüm1'den gönderilen N. mesaj ile Düğüm2 tarafından alınan N'message arasındaki ilişkiyi belirleyemiyoruz. Diğer bir deyişle, Düğüm1 X'inci mesajı göndermeyi bitirdiğinde, Düğüm2 tarafından alınan N mesaj arasında X'inci mesajı tanımlamak imkansızdır. İletileri TCP veya işletim sistemi düzeyinde izlemeye çalışmanın bir yolu vardır. Ancak, uygulama karmaşık ve düşük performanslıdır ve her protokol için ayrı ayrı uygulanması gerekir. Ek olarak, mesajı doğru bir şekilde izlemek zordur.
Ancak, Google dapper bu sorunu çözmek için basit bir çözüm uyguladı. Bu çözüm, mesaj gönderirken mesajlar arasındaki ilişki olarak uygulama düzeyinde etiketleri kullanır. Örneğin, HTTP isteğindeki HTTP başlığındaki mesaja bir etiket bilgisi ekleyin ve mesajı izlemek için bu etiketi kullanın.
Nokta tespiti, google dapper'in izleme teknolojisine dayanır, ancak uzak çağrılarda dağıtılmış işlemleri izlemek için çağrılan başlığa uygulama düzeyinde etiket verileri eklemek üzere değiştirilmiştir. Etiket verileri, TraceId olarak tanımlanan birden çok anahtardan oluşur.
Pinpoint'te veri yapısı
Pinpoint'te temel veri yapısı şunlardan oluşur: Aralık, İzleme ve İzleme Kimliği kompozisyon.
- Aralık: RPC (uzaktan yordam çağrısı) izlemesinin temel birimi; bir RPC çağrısı geldiğinde, işin işlendiğini ve izleme verilerini içerdiğini gösterir. Kod düzeyinde görünürlüğü sağlamak için Span, veri yapısı olarak SpanEvent etiketleri içeren bir alt yapıya sahiptir. Her Aralık bir TraceId içerir.
- İzleme: İlgili RPC'lerden (Aralıklar) oluşan birden çok Aralıktan oluşan bir koleksiyon Aynı izlemedeki aralıklar aynı İşlem Kimliğini paylaşır. İzleme, SpanId ve ParentSpanId aracılığıyla bir miras ağacı yapısı halinde düzenlenir.
- TraceId: TransactionId, SpanId ve ParentSpanId'den oluşan bir anahtar kümesi. TransactionId, ileti kimliğini, SpanId ve ParentSpanId ise RPC'nin üst-alt ilişkisini belirtir.
- İşlem Kimliği (TxId): Dağıtılmış sistemler arasındaki tek bir işlemle gönderilen / alınan mesajın kimliği; tüm sunucu kümesinde küresel olarak benzersiz olmalıdır.
- SpanId: RPC mesajı alındığında işlenen işin kimliği; RPC isteği düğüme ulaştığında oluşturulur.
- ParentSpanId (pSpanId): RPC çağrısını başlatan üst aralığın SpanId'si Eğer düğüm, işlemin başlangıç noktasıysa, üst aralık olmayacaktır - bu durumda, bu aralığın işlemin kök aralığı olduğunu belirtmek için -1 değerini kullanın.
TraceId nasıl çalışır?
Aşağıdaki şekil, 4 düğüm arasında 3 RPC çağrısının gerçekleştirildiği TraceId davranışını açıklar:
Şekil 2: TraceId davranışı örneği
Yukarıdaki şekilde, TransactionId (TxId), üç farklı RPC'nin tek bir işlem olarak birbiriyle ilişkili olduğunu göstermektedir. Ancak TransactionId, PRC arasındaki ilişkiyi doğru bir şekilde tanımlayamaz. PRC, SpanId ve ParentSpanId (pSpanId) arasındaki ilişkiyi tanımlamak için gereklidir.Bir düğümün Tomcat olduğu varsayılırsa, SpanId HTTP isteklerini işleyen bir iş parçacığı olarak düşünülebilir, ParentSpanId bu RPC çağrısını başlatan SpanId'yi temsil eder.
TransactionId kullanarak, Pinpoint ilişkili n Spans'ı keşfedebilir ve SpanId ve ParentSpanId'i bu n aralıkları bir miras ağacı yapısında düzenlemek için kullanabilir.
SpanId ve ParentSpanId 64 bitlik tam sayılardır. Bu numara isteğe bağlı olarak oluşturulduğu için çatışmalar meydana gelebilir, ancak değer aralığının -9223372036854775808 ile 9223372036854775807 arasında olabileceği düşünüldüğünde, çakışma olasılığı düşüktür. Anahtarlar arasında bir çakışma varsa Pinpoint ve Google Dapper sistemleri, geliştiricilere bunun olduğunu bildirir Çatışmayı çözmek yerine ne oldu.
TransactionId; AgentIds, JVM (java sanal makine) başlatma zamanı ve Sıra Numaraları / sıra numarasından oluşur.
- AgentId: Jvm başlatıldığında kullanıcı tarafından oluşturulan kimlik; pinpoinit tarafından yüklenen tüm sunucu kümelerinde global olarak benzersiz olmalıdır. Onu benzersiz tutmanın en kolay yolu, ana bilgisayar adını ($ HOSTNAME) kullanmaktır, çünkü ana bilgisayar adları genellikle tekrarlanmaz. Sunucu kümesinde çalışan birden çok JVM var. Yinelemeyi önlemek için lütfen ana bilgisayar adından önce bir önek ekleyin.
- JVM başlatma zamanı: Sıra Numarasının 0'dan başlayarak benzersiz olmasını sağlamak gerekir. Bu değer, kullanıcılar yanlışlıkla Ajan Kimliği yinelediğinde kimlik çakışmalarını önlemek için kullanılabilir.
- SıraNumarası: Pinpoint aracısı tarafından oluşturulan ve 0'dan sürekli artan ve her mesaj için bir tane oluşturulan kimlik.
Twitter'ın dağıtılmış bir sistem izleme platformu olan Dapper ve Zipkin, rastgele TraceIds (Pinpoint is TransactionIds) oluşturur ve çakışmaları normal olarak ele alır. Bununla birlikte, Pinpiont'ta çakışma olasılığından kaçınmak istiyorsanız, iki seçenek vardır: Birincisi, veri miktarının az olması, ancak çatışma olasılığının yüksek olması; diğeri, veri miktarının büyük ancak çatışma olasılığının düşük olmasıdır. Pinpiont ikinciyi seçti.
Bayt kodu geliştirme, kod değişikliği gerekmez
Daha önce dağıtılmış işlem takibini açıklamıştık. Bunu başarmanın bir yolu, geliştiricilerin kodu kendilerinin değiştirmesidir. Geliştiricilerin bir RPC çağrısı gerçekleştiğinde etiket bilgisi eklemesine izin verin. Bununla birlikte, bu tür özellikler geliştiriciler için çok yararlı olsa bile, kodu değiştirmek bir yük haline gelecektir.
Twitter'ın Zipkin'i, dağıtılmış işlem takibi sağlamak için değiştirilmiş bir sınıf kitaplığı ve kendi kabını (Finagle) kullanır. Ancak gerektiğinde kod değişikliği gerektirir. Özelliklerin kodu değiştirmeden çalışmasını bekliyoruz ve kod düzeyinde görünürlük elde etmeyi umuyoruz. Bu sorunu çözmek için, pinpoint, bayt kodu geliştirme teknolojisini kullanır. Pinpoint aracı, etiket bilgilerini otomatik olarak işlemek için RPC'yi başlatan koda müdahale eder.
Bayt kodu geliştirmenin dezavantajlarının üstesinden gelin
Bayt kodu geliştirme, manuel yöntem ile otomatik yöntem arasındaki otomatik yönteme aittir.
- Manuel yöntem: Geliştiriciler, verileri kilit noktalarda kaydetmek için kod geliştirmek için ponpoint tarafından sağlanan API'yi kullanır
- Otomatik yöntem: Geliştiricilerin kod değişikliklerine ihtiyacı yoktur çünkü nokta tespiti hangi API'lerin ayarlanması ve geliştirilmesi gerektiğini belirler
Her yöntemin avantajları ve dezavantajları şunlardır:
Tablo 1 Her yöntemin avantajları ve dezavantajları
Bayt kodu nasıl çalışır?
Bayt kodu geliştirme teknolojisi java bayt kodunu işlerken, geliştirme riskini artırma ve verimliliği azaltma eğilimi vardır. Ek olarak, geliştiricilerin hata yapma olasılığı daha yüksektir. Nokta tespiti, önleyiciyi soyutlayarak verimlilik ve erişilebilirlik geliştirildi. Yer tespiti, sınıf yüklemesi sırasında uygulama koduna müdahale ederek dağıtılmış işlem ve performans bilgileri için gerekli izleme kodunu enjekte eder. Bu, performansı artırır çünkü kod enjeksiyonu doğrudan uygulama kodunda gerçekleştirilir.
Şekil 3: Bayt kodu geliştirme davranışı
Nokta tespiti olarak, engelleyici API, performans verilerinin kaydedildiği yerde ayrılır (ayrılır). İzleme için, before () yöntemi ve after () yönteminin çağrılması ve before () yöntemi ve after () yöntemindeki bazı performans verilerinin kaydedilmesi için hedef yönteme bir engelleyici ekliyoruz. Bayt kodu geliştirmesiyle, nokta belirleme aracısı yönteme ihtiyaç duyan verileri kaydedebilir, ancak bu şekilde örneklenen verilerin boyutu küçülebilir.
sonuç olarak
Pinpoint, uygulama ile birlikte çalışan başka bir uygulamadır. Bayt kodu geliştirmelerinin kullanılması, nokta işaretinin kod değişikliği gerekmiyormuş gibi görünmesini sağlar. Genel olarak, bayt kodu geliştirme teknikleri, uygulamaları riske açık hale getirir. Sorun tam olarak ortaya çıkarsa, uygulamayı etkileyecektir. Daha sonra daha fazla devop ve DBA içeriği paylaşacağım ve ilgilenen arkadaşlar buna dikkat edebilir ~
