Zipkin Proje Lideri ile Röportaj: Zipkin ile dağıtılmış izleme nasıl yapılır?
Modern mikro hizmet mimarileri, iş sistemi modellerinde giderek daha karmaşık hale geldi ve sistem davranışını anlamamıza ve hizmetler arasındaki çağrıları netleştirmemize yardımcı olmak için dağıtılmış sistemlerde bir dizi bağlantı izleme sistemine ihtiyaç duyulmaktadır. Son zamanlarda yazar, Zipkin projesinin ana geliştiricisi ve sürdürücüsü Adrian Cole'u Zipkin projesinin ayrıntılarını tanıtması için davet etti, böylece herkes Zipkin'i dağıtılmış izleme sisteminde nasıl kullanacağını anlayabilir.
Adrian, bulut bilişimle ilgili açık kaynak projelerinin geliştirilmesinde yer almıştır ve Apache jclouds ve OpenFeign açık kaynak projelerinin kurucusudur. Son yıllarda, dağıtık izleme alanına odaklandı ve OpenZipkin projesinin ana geliştiricisi ve sürdürücüsüdür. Adrian şu anda Pivotal Spring Cloud OSS ekibinde çalışıyor. Pivotal'a katılmadan önce Twitter, Square ve Netflix'te çalıştı.
Hepimizin bildiği gibi Zipkin projesi Twitter'da ortaya çıktı, bize projenin arka planından bahseder misiniz?
Adrian : Zipkin, Twitter tarafından dahili olarak oluşturulan ve 2012'de açık kaynaklı bir dağıtılmış izleme projesidir. Başlangıçta BigBrotherBird olarak adlandırılıyordu, bu nedenle bugün bile http başlığı "B3" olarak adlandırılıyor. Twitter'ın ilk günlerinde, hızlı iş gelişimi nedeniyle, sıklıkla sistem aşırı yükleri meydana geliyordu. Bu ne zaman olursa, kullanıcı sayfada karaya oturmuş bir balina görecektir. Zipkin adı balinalarla da ilgilidir, çünkü Zipkin zıpkın anlamına gelir ve başlangıçta "karaya oturmuş balinalar" ile ilgili sistem gecikmelerini izlemek için yapılmıştır. Zipkin'in Twitter'ın marka kutsamasına ilişkin başarısının yanı sıra diğer faktörler de önemli bir rol oynamaktadır: Birincisi, Zipkin, istemci, sunucu ve kullanıcı arayüzü gibi ihtiyacınız olan tüm parçaları içerir; ayrıca Twitter Mühendisliği ile ilgili bir önceki makale Zipkin'i tanıttı. Blog ayrıca bir sansasyon yarattı. Zipkin zamanla onlarca gözlemlenebilirlik aracından biri haline geldi.
Dağıtılmış çağrı izlemenin mikro hizmet izleme için değeri nedir ve mikro hizmetler için neden böyle bir izleme sistemi oluşturmak istiyorsunuz?
Adrian : Burada, dağıtılmış izleme sisteminin değerini özetlemek için Netflix site belgesindeki (Zipkin kullanıcı kullanım raporu) açıklamadan alıntı yapmak istiyorum:
Ticari değeri, geliştiricilerin üretkenliğini artırırken, sistem için işletim seviyesinde görsel bir arayüz sağlamasında yatmaktadır.Bir mikro hizmet sistemi için, dağıtılmış izleme araçlarının yardımı olmadan, çeşitli hizmetler arasındaki çağrı ilişkisini anlamak oldukça zordur. Çok kıdemli mühendisler için bile, sistem izleme bilgilerini analiz etmek için yalnızca izleme günlüklerine güveniyorlarsa, mikro hizmet sistemi sorunlarını hızla bulmak ve keşfetmek zordur. Dağıtılmış çağrı izleme sistemi, geliştiricilerin veya sistem işletim ve bakım personelinin, performans sorunlarını belirlemek ve çözmek veya hataların temel nedenini bulmak için uygulamaların ve bunların temelindeki hizmetlerin zamanında yürütülmesini anlamalarına yardımcı olabilir. Dağıtılmış izleme sistemi, istek uygulama sisteminden geçtiğinde uçtan uca bir görünüm sağlayabilir ve uygulamanın temel bileşenlerinin ilgili çağrı ilişkilerini görüntüleyebilir, böylece geliştiricilerin üretim ortamında dağıtılmış uygulamayı analiz etmesine ve hatalarını ayıklamasına yardımcı olabilir.
Sektörün çok sayıda mikro hizmet mimarisini benimsediği günümüzde Zipkin, sektördeki mikro hizmet sistemlerinin problem takibinde çok önemli bir rol oynamaktadır.Sektörün Zipkin projesini nasıl kullandığını bize anlatır mısınız?
Adrian : Bu soruyu cevaplamadan önce Zipkin'in sistem mimarisini kısaca tanıtalım. Zipkin iki bölümden oluşur: ön uç koleksiyonu ve arka uç depolama ekranı. Uygulamanın çağrısını takip edebilmek için, uygulamanın içinde çağrı yürütme zamanını ve çağrı işlemiyle ilgili meta veri bilgilerini kaydetmek için ilgili bir izleyici kurmamız gerekir. Genel olarak konuşursak, bu izleyiciler uygulama çerçevesine yerleştirilmiştir ve kullanıcı uygulama programı temelde varlığını algılamaz. Aşağıdaki şekilde gösterildiği gibi, izlenen istemci izlenen sunucuya bir mesaj gönderdiğinde, izlenen istemcinin izleyicisi ve izlenen sunucunun sırasıyla Span adında bir mesaj oluşturacak ve bunu Raporlayıcı aracılığıyla Zipkin arka ucuna gönderecektir. Birden fazla hizmette yapılan bir çağrı, istemci ile sunucu arasında iletilen mesaj başlığıyla ilişkilendirilen birden çok Span bilgisini içerecektir. Arka uç, toplayıcı aracılığıyla Span mesajlarını alacak, ilgili analiz ve ilişkilendirme gerçekleştirecek ve ardından verileri, UI ekranı için depolama modülü aracılığıyla depolayacaktır.
Zipkin, herkesin başlaması için projenin açık kaynağının başında eksiksiz bir izleme çözümü içeriyordu.Aynı zamanda, aktarım protokolü ve ilgili mesaj başlıkları aracılığıyla açık kaynak, Zipkin'in kullanıcının izleme sistemine entegre edilmesine yardımcı oldu. Bu, Zipkin'in birçok izleme sistemi arasında öne çıkmasını ve sektörde en yaygın kullanılan izleme aracı olmasını sağlar.
2015 yılında, herkesin dağıtılmış arama izleme sistemlerini kullanma konusunda tecrübesi olmadığını ve dağıtılmış bir izleme sistemini nasıl başarılı bir şekilde kuracaklarını bilmediklerini gördük. Bu nedenle, sektörde Zipkin kullanımıyla ilgili birçok ilgili materyali derledik ve bu materyalleri depolamak için Google Drive'da ilgili bir doküman dizini oluşturduk. Herkesin Google Drive'a erişmesinin sakıncalı olabileceğini göz önünde bulundurarak, daha sonra Zipkin'in nasıl kullanılacağını paylaşmak için bir wiki oluşturduk, böylece daha fazla insan, izleme sistemindeki sorunları çözmek için diğer insanların Zipkin'i nasıl kullandığını anlayabilir.
Burada, Netflix gibi büyük şirketlerin günde 5 TB'a kadar izleme verisi işlemek için Zipkin ve Elasticsearch'ü nasıl kullandığını, Ascend Money'nin Zipkin'i kullanmak için genel ve özel bulutları nasıl birleştirdiğini ve Line'ın Zipkin ile armeria'yı nasıl birleştirdiğini görebilirsiniz. Eşzamansız çağrı izleme ve Sound Cloud'un Zipkin izlemeyi iyileştirmek için Kubernetes Pod meta veri bilgilerini nasıl birleştirdiği. Burada ayrıca daha fazla Çinli kullanıcıyı Zipkin kullanma deneyiminizi paylaşmaya davet ediyoruz.
Bu arada, Zipkin kullanıcısıysanız, kod depomuza yıldız eklemeyi unutmayın, bu bizim en büyük teşvikimizdir.
Zipkin projesinin şu anda üretim ortamında yaygın olarak kullanıldığını biliyoruz, bu projeleri doğrudan mı kullandılar yoksa ihtiyaçları doğrultusunda projeleri mi değiştirdiler?
Adrian : Zipkin projesinin işleyişi, kullanıcıların kendi köpek mamalarını yemelerine dayandığından (kendi geliştirdikleri yazılımı kullanarak), birçok yeni araç önce kullanıcılar tarafından dahili olarak kullanılıyor ve daha sonra genel projelere açık kaynaklı. Örneğin, zipkin-forwarder projesi, Ascend'in verileri kendi iş ihtiyaçlarıyla birlikte birden çok veri merkezine iletmesi için deneysel bir projedir. Yelp, birden çok Zipkin kümesinden veri okumak için bir Zipkin proxy uyguladı. LINE, Zipkin kullanıcı arayüzünü değiştirmek için dahili olarak "proje merceği" adlı bir proje kodu geliştirdi.
Zipkin için pek çok kullanım durumu vardır ve farklı kullanım durumları için ilgili mimariler farklıdır. Bu, kullanıcıların OpenZipkin organizasyonu altındaki projeleri doğrudan benimsemedikleri anlamına gelmez. Örneğin Mediata, site belgelerinde herhangi bir değişiklik yapmadan doğrudan Zipkin sürümünü kullandıklarını açıkladı.
Zipkin projesi varsayılan olarak orta ölçekli kullanım senaryolarını destekler. Daha büyük ölçekli kullanım senaryolarını desteklemek için ne yapmamız gerekiyor?
Adrian : Büyük ölçekli kullanım senaryoları daha fazla veri hacmi anlamına gelir. Büyük ölçekli kullanıcılar bu sorunu genellikle maliyetten ve verileri işleme veya temizleme becerisinden alır. Örneğin SoundCloud, verileri kubernetes meta verilerine dayalı olarak temizlemek için bir araç uygular. Geçmişte, neredeyse tüm büyük Zipkin siteleri izleme verilerini Cassandra'da saklıyordu. Artık Netflix gibi büyük siteler de Elasticsearch'ü başarıyla kullanabilir. Hemen hemen tüm büyük siteler daha büyük veri aktarımları için Kafka'yı kullanır. Verimlilik nedenleriyle, daha küçük siteler farklı iletim yöntemleri kullanır. Örneğin, Infostellar veri aktarmak için Armeria'yı (gRPC'ye benzer asenkron ve verimli bir RPC kitaplığı) kullanır.
Çoğu olgun site, veri boyutu konusunda da endişelenir ve sorunu çözmek için örnekleme kullanır. Farklı site türleri için ortak bir araç tasarlamak bizim için zor olduğundan, Zipkin size http istek ifadelerine dayalı yapılandırma ve yeni bir geliştirme istemci oranı sınırlayıcı örnekleyici dahil olmak üzere çeşitli örnekleme seçenekleri sunar. Örneğin, Spring kullanan siteler bazen örnekleme oranını gerçek zamanlı olarak iletmek için yapılandırma sunucusunu kullanır. Bu, olağan düşük örnekleme oranını bozmadan ilginç izler yakalayabilir.
Çoğu site, gereksiz izlemeye başlamamak için istemci tarafı örneklemeyi kullanır. Örneğin, spring cloud sleuth'un varsayılan politikası, sağlık kontrolleri gibi yönetim trafiği için izler oluşturmaz. Bunlar http yol ifadeleri aracılığıyla yapılır. Bazı yüzdeye dayalı örnekleme (örneğin,% 1 veya daha az trafik), veri dalgalanmaları olduğunda hala sorun yaşar. Örnekleme oranı% 1 olsa bile debi% 1000'e ulaştığında problemler ortaya çıkabilir. Bu nedenle, sistemin yedekli yapılandırmasını her zaman öneriyoruz, bu da normal trafik için yalnızca bant genişliği ve depolama alanı tahsis edilmesinin yanı sıra belirli bir marjın da sağlanması gerektiği anlamına gelir. Ama bu en iyi çözüm değil. Şaka yollu OPP (aşırı tedarik ve dua, bir Amerikan popüler şarkısının adı) diyoruz, bu da gereksiz garantiler ve dualar yoluyla veri artışıyla başa çıkmamıza yardımcı oluyor.
Birçok sitenin uyarlamalı (otomatik) örneklemeye "evrimleşme" niyetinde olmadığını belirtmek gerekir. Örneğin Yelp, verilerinin% 100'ünü özel, indekslenmemiş, ucuz depolamada kullanır. Bu şekilde, ilginç izler olağan düşük örnekleme oranını bozmadan doğrudan yakalanabilir. Zipkin topluluğunda, temel örnekleme oranının karmaşıklığını artırmadan sorunlu alanları vurgulamak için uyarlanabilir örnekleme konfigürasyonları hakkında tasarım tartışmaları vardır. Kendi kendine adaptasyon ilginç bir seçimdir, veri artışı sorunuyla kesinlikle başa çıkabilir, ancak insanlar genellikle kendi kendine adaptasyonu sağlamak için farklı yöntemler kullanırlar.
Zipkin çevrimiçi sitelerinde günlük aralık işlemenin yaklaşık veri akışı nedir? Zipkin verileri varsayılan olarak bir ay boyunca saklayabilir mi? Zipkin depolaması için iyi bir öneriniz var mı?
Adrian : Yelp, verilerin% 100'ünü özel bir depolama kümesinde toplayacaklarından en Yayılma verilerini işleyebilir. Ancak rakamları açıklamadılar. Netflix'in sistemi arka plana 240 MB / sn aralıklı veri gönderecektir (kaç aralıklı mesaj olduğunu hesaplayabilirsiniz) Genel olarak konuşursak, bir aralık verileri genellikle 1KiB'yi geçmez, hatta 1KiB'nin çok altındadır.
Veri depolamayla ilgili olarak, çoğu web sitesi, maliyet hususları nedeniyle verileri yalnızca birkaç gün saklamaktadır. Ancak, bazı kullanıcılar izleme verilerini uzun süre saklamak için bir "favori izleme" işlevi sağlar. Yayılma boyutu ile ilgili olarak, cesur veya zipkin-go gibi araçlarla birlikte gelen varsayılan değeri kullanmanızı ve ardından kaynak kullanımını iyileştirmek için özel ihtiyaçlarınıza göre bazı veri etiketleri (verileri saklayıp saklamayacağınıza karar vererek) eklemenizi öneririz.
Ayrıca, span'ı bir logger olarak kullanmanızı önermiyoruz. OpenTracing bu kötü kafayı yarattı. Günlük aracını dağıtılmış izleme API'si ile karıştırdılar ve hatta API'de Span'da "microlog" u tanımladılar. Bildiğim kadarıyla, sisteme düzenli giriş yapmak için iyi bir iş çıkarabilecek bir izleme sistemi yok, çünkü izleme sistemi ve düzenli kayıt sistemi tamamen farklı iki sistemdir ve bunu yapmak sadece izleme sisteminin verimliliğine zarar verecektir.
İhtiyaçlarınıza göre en iyi depolama yöntemini seçmenizi tavsiye ederiz. Örneğin, Infostellar, depolama için izleme verilerini doğrudan Google Stackdriver'a iletir. Elasticsearch'e Cassandra'dan daha aşina iseniz, lütfen Elasticsearch'ü kullanın ve tersini yapın. Ancak MySQL kullanmamanızı tavsiye ederiz çünkü MySQL mimarimiz yüksek performans için yazılmamıştır.
Zipkin, analiz sistemlerine (Amazon X-Ray, Apache SkyWalking ve Expedia HayStack gibi) nasıl bağlanır? Bunun için iyi bir öneriniz var mı?
Adrian : Bahsettiğiniz tüm projeler Zipkin verileri alınarak entegre edilmiştir Infostellar bu konuda referans için iyi web sitesi belgelerine sahiptir.
Skywalking ayrıca Zipkin verilerine erişmek için entegre bir yol sağlar. Skywalking, Zipkin formatındaki verileri kabul edebilir, bu nedenle ister Zipkin probu ister Jaeger gibi diğer araçlar, aynı formattaki araçlar kullanıldığı sürece, Skywalking'e bağlanabilirler. Unutulmamalıdır ki birçok izleme aracı artık Zipkin formatını desteklemektedir.Zipkin formatını destekleyerek diğer izleme sistemlerinin entegrasyonunu tamamlamak kolaydır.
Haystack ve Zipkin entegrasyon çalışmaları hakkında belirli bir anlayışa sahibim. Verileri sırasıyla Zipkin ve Haystack'e göndermek için Hotels.com tarafından sağlanan Pitchfork aracını kullandılar. Haystack'in sistemi, Zipkin verileri üzerinde hizmet grafiği toplama ve diğer işlemleri gerçekleştirebilir, bu nedenle verileri işlemek için Zipkin'in kullanıcı arayüzünü kullanmaya gerek yoktur.
OpenZipkin nedir? Zipkin topluluğu yıllar içinde nasıl gelişti? Zipkin topluluğuna nasıl katılabilirsiniz?
Adrian : 2015 yılında topluluktaki bazı kişiler, projenin daha hızlı geliştirilmesi için projenin daha açık bir yere taşınması çağrısında bulundu. Üç aylık sıkı çalışmanın ardından, Temmuz 2015'te Github'da "OpenZipkin" grubunu kurduk. Topluluk bundan sonra hızla gelişti ve çok sayıda kullanıcı toplulukta dağıtılmış bir izleme sistemi oluştururken karşılaştıkları sorunları ve zorlukları paylaştı. Topluluk, tercih edilen dilin Scala yerine Java olduğuna karar verdiğinde, sunucuyu yeniden yazdık. Başlamanıza yardımcı olacak birçok örnek projemiz var ve başkalarıyla iletişim kurmanın öğrenmenin en iyi yolu olduğunu düşünüyoruz. İzlemeye aşina değilseniz, katılmanın en kolay yolu gitter tartışmamıza katılmaktır.
Zipkin kısa süre önce ASF inkübatörüne katıldı. Bu Zipkin için ne anlama geliyor?
Adrian: Zipkin bir süredir geliştirme aşamasındayken, CNCF katılmak için bizimle iletişime geçti ve Apache Software Foundation'a (ASF) katılmayı veya hiçbir şeye katılmamayı düşündük. Cemaat o dönemde vakfa katılmanın faydalarını görmedi, biz vakfa katılmamayı seçtik. Bununla birlikte, topluluk büyümeye ve gelişmeye devam ettikçe, büyümek için de sorumluluğumuz var. Özellikle SkyWalking'in ASF'deki inkübasyonu aracılığıyla ASF hakkında daha derin bir anlayışa sahip olduğumuzda. Vakıf, projelerinin sorunları satıcıdan bağımsız bir bakış açısıyla değerlendirmesini gerektirdiğinden, bu Zipkin'in topluluk perspektifinden bağımsız olarak nasıl geliştirileceğini düşünmesine yardımcı olabilir. ASF kültürü bizimkine daha çok uyuyor, bu yüzden Zipkin bu yılın Ağustos ayında bir Apache kuluçka projesi oldu.
Yazar hakkında Jiang Ning, Huawei Açık Kaynak Yetkinlik Merkezi teknik uzmanı, eski Red Hat Yazılım Baş Yazılım Mühendisi, Apache Software Foundation Üyesi, on yıldan fazla kurumsal düzeyde açık kaynak ara yazılım geliştirme deneyimine, Java geliştirme ve kullanımında zengin deneyime, işlevsel programlama Aşıklar. 2006 yılından bu yana, Apache Soft Foundation açık kaynak ara yazılım projesinin geliştirilmesiyle uğraşmaktadır ve Apache CXF, Apache Camel, Apache ServiceMix ve Apache ServiceComb'un geliştirilmesine art arda katılmıştır. Mikro hizmet mimarisi, Web Hizmetleri, Kurumsal Entegrasyon Modeli, SOA, OSGi hakkında derinlemesine araştırma. Weibo Kimliği: https://weibo.com/willemjiang Kişisel blog adresi: https://willemjiang.github.io/
