Biz loyihalarimizda mikroservis arxitekturasidan foydalanamiz. Ishlashda qiyinchiliklar yuzaga kelganda, jurnallarni kuzatish va tahlil qilish uchun ko'p vaqt sarflanadi. Jurnal faylida alohida operatsiyalarning vaqtlarini qayd qilishda, odatda, ushbu operatsiyalarni chaqirishga nima sabab bo'lganini tushunish, turli xizmatlarda harakatlar ketma-ketligini yoki bir operatsiyaning boshqasiga nisbatan vaqt o'zgarishini kuzatish qiyin.
Qo'l mehnatini minimallashtirish uchun biz kuzatuv vositalaridan birini ishlatishga qaror qildik. Qanday qilib va ββnima uchun kuzatuvdan foydalanishingiz mumkinligi va biz buni qanday qilganimiz haqida va ushbu maqolada muhokama qilinadi.
Kuzatish bilan qanday muammolarni hal qilish mumkin
- Bitta xizmat ichida ham, barcha ishtirokchi xizmatlar oβrtasidagi butun ijro daraxtida ham unumdorlik muammolarini toping. Masalan:
- Xizmatlar o'rtasida ko'plab qisqa ketma-ket qo'ng'iroqlar, masalan, geokodlash yoki ma'lumotlar bazasiga.
- Tarmoq o'tkazmalari yoki diskni o'qish kabi uzoq I/U kutish.
- Uzoq ma'lumotlarni tahlil qilish.
- CPU talab qiladigan uzoq operatsiyalar.
- Yakuniy natijani olish uchun kerak bo'lmagan va olib tashlanishi yoki kechiktirilishi mumkin bo'lgan kod bo'limlari.
- Qanday ketma-ketlikda nima deyilganini va operatsiyani bajarishda nima sodir bo'lishini aniq tushuning.
Ko'rinib turibdiki, masalan, so'rov WS xizmatiga keldi -> WS xizmati R xizmati orqali ma'lumotlarni to'ldirdi -> keyin V xizmatiga so'rov yubordi -> V xizmati ko'plab ma'lumotlarni yukladi. R xizmati -> P xizmatiga o'tdi -> P xizmati yana R xizmatiga o'tdi -> xizmat V natijani e'tiborsiz qoldirdi va J -> xizmatiga o'tdi va shundan keyingina WS xizmatiga javob qaytardi va shu bilan birga boshqa narsani hisoblashda davom etdi. fon.
Butun jarayon uchun bunday iz yoki batafsil hujjatlarsiz, kodni birinchi marta ko'rib chiqishda nima sodir bo'layotganini tushunish juda qiyin va kod turli xizmatlar bo'ylab tarqalib ketgan va bir qator qutilar va interfeyslar orqasida yashiringan. - Keyingi kechiktirilgan tahlil uchun ijro daraxti haqida ma'lumot to'plash. Bajarilishning har bir bosqichida siz ushbu bosqichda mavjud bo'lgan izga ma'lumot qo'shishingiz va keyin qanday kiritilgan ma'lumotlar shunga o'xshash stsenariyga olib kelganligini aniqlashingiz mumkin. Masalan:
- Foydalanuvchi IDsi
- Huquqlar
- Tanlangan usul turi
- Jurnal yoki ijro xatosi
- Izlarni ko'rsatkichlar to'plamiga aylantirish va ko'rsatkichlar shaklida keyingi tahlil qilish.
Qaysi iz jurnalga kirishi mumkin. Oraliq
Kuzatuvda oraliq tushunchasi mavjud, bu bitta logning konsolga o'xshashi. Spada quyidagilar mavjud:
- Ism, odatda bajarilgan usulning nomi
- Oraliq yaratilgan xizmat nomi
- O'ziga xos identifikator
- Unga kirgan kalit/qiymat ko'rinishidagi meta-ma'lumotlarning bir turi. Masalan, usul parametrlari yoki usul xato bilan tugadi yoki yo'q
- Ushbu oraliq uchun boshlanish va tugash vaqtlari
- Ota-ona oraliq identifikatori
Har bir span o'z bajarilishini tugatgandan so'ng, keyinchalik ko'rib chiqish uchun ma'lumotlar bazasida saqlash uchun span kollektoriga yuboriladi. Kelajakda siz ota-ona identifikatori orqali ulanib, barcha oraliqlarning daraxtini qurishingiz mumkin. Tahlil qilayotganda, masalan, ba'zi bir xizmatning bir muncha vaqtdan ko'proq vaqt talab qilgan barcha oraliqlarini topishingiz mumkin. Bundan tashqari, ma'lum bir oraliqga o'tish orqali, bu oraliqning ustidagi va ostidagi butun daraxtni ko'ring.
Opentrace, Jagger va uni loyihalarimiz uchun qanday amalga oshirganimiz
Umumiy standart mavjud , qanday qilib va ββqanday to'planishi kerakligini tasvirlaydi, hech qanday tilda ma'lum bir amalga oshirish bilan bog'lanmasdan. Masalan, Java-da izlar bilan barcha ishlar umumiy Opentrace API orqali amalga oshiriladi va uning ostida, masalan, Jaeger yoki hech narsa qilmaydigan bo'sh standart dasturni yashirish mumkin emas.
Biz foydalanamiz Opentrace dasturini amalga oshirish sifatida. U bir nechta tarkibiy qismlardan iborat:
- Jaeger-agent mahalliy agent bo'lib, odatda har bir mashinaga o'rnatiladi va xizmatlar unga mahalliy standart portda kiradi. Agar agent bo'lmasa, ushbu mashinadagi barcha xizmatlarning izlari odatda o'chiriladi
- Jaeger-kollektor - barcha agentlar unga to'plangan izlarni yuboradilar va u ularni tanlangan ma'lumotlar bazasiga joylashtiradi.
- Ma'lumotlar bazasi ularning afzal ko'rgan kassandrasidir, ammo biz elasticsearch-dan foydalanamiz, bir nechta boshqa ma'lumotlar bazalari uchun ilovalar va diskda hech narsa saqlamaydigan xotirada amalga oshirish mavjud.
- Jaeger-query - bu ma'lumotlar bazasiga boradigan va tahlil qilish uchun allaqachon to'plangan izlarni qaytaradigan xizmat
- Jaeger-ui - izlarni qidirish va ko'rish uchun veb-interfeys, u jaeger-query-ga o'tadi.
Alohida komponentni ma'lum tillar uchun opentrace jaegerni amalga oshirish deb atash mumkin, bu orqali spanlar jaeger-agentga yuboriladi.
io.opentracing.Tracer interfeysini amalga oshirishga tushadi, shundan so'ng u orqali barcha izlar haqiqiy agentga uchib ketadi.
Shuningdek, bahor komponenti uchun siz ulanishingiz mumkin va Jaeger tomonidan amalga oshirish bu komponentlar orqali o'tadigan hamma narsa uchun kuzatuvni avtomatik ravishda sozlaydi, masalan, kontrollerlarga http so'rovlari, jdbc orqali ma'lumotlar bazasiga so'rovlar va boshqalar.
Java-da tizimga kirish izlari
Yuqori darajadagi biror joyda, birinchi Span yaratilishi kerak, bu avtomatik ravishda amalga oshirilishi mumkin, masalan, so'rov qabul qilinganda bahor boshqaruvchisi tomonidan yoki agar yo'q bo'lsa, qo'lda amalga oshirilishi mumkin. Keyin u quyidagi Scope orqali uzatiladi. Agar quyidagi usullardan birortasi Span qo'shmoqchi bo'lsa, u Scope'dan joriy activeSpanni oladi, yangi Span yaratadi va uning ota-onasi natijada activeSpan ekanligini aytadi va yangi Spanni faol qiladi. Tashqi xizmatlarga qo'ng'iroq qilganda, joriy faol oraliq ularga uzatiladi va bu xizmatlar ushbu oraliqga mos ravishda yangi oraliqlarni yaratadi.
Barcha ishlar Tracer misolidan o'tadi, siz uni DI mexanizmi orqali yoki DI mexanizmi ishlamasa global o'zgaruvchi sifatida GlobalTracer.get () orqali olishingiz mumkin. Odatiy bo'lib, agar kuzatuvchi ishga tushirilmagan bo'lsa, NoopTracer qaytib keladi, bu hech narsa qilmaydi.
Bundan tashqari, joriy qamrov ScopeManager orqali kuzatuvchidan olinadi, joriydan yangi oraliq bog'langan holda yangi qamrov yaratiladi va keyin yaratilgan Scope yopiladi, bu yaratilgan oraliqni yopadi va oldingi Scopeni qaytaradi. faol holat. Qo'llanish doirasi ip bilan bog'langan, shuning uchun ko'p tarmoqli dasturlashda, ushbu oraliqga murojaat qilgan holda boshqa ipning doirasini faollashtirish uchun faol oraliqni boshqa ipga o'tkazishni unutmaslik kerak.
io.opentracing.Tracer tracer = ...; // GlobalTracer.get()
void DoSmth () {
try (Scope scope = tracer.buildSpan("DoSmth").startActive(true)) {
...
}
}
void DoOther () {
Span span = tracer.buildSpan("someWork").start();
try (Scope scope = tracer.scopeManager().activate(span, false)) {
// Do things.
} catch(Exception ex) {
Tags.ERROR.set(span, true);
span.log(Map.of(Fields.EVENT, "error", Fields.ERROR_OBJECT, ex, Fields.MESSAGE, ex.getMessage()));
} finally {
span.finish();
}
}
void DoAsync () {
try (Scope scope = tracer.buildSpan("ServiceHandlerSpan").startActive(false)) {
...
final Span span = scope.span();
doAsyncWork(() -> {
// STEP 2 ABOVE: reactivate the Span in the callback, passing true to
// startActive() if/when the Span must be finished.
try (Scope scope = tracer.scopeManager().activate(span, false)) {
...
}
});
}
}Ko'p oqimli dasturlash uchun TracedExecutorService va shunga o'xshash o'ramlar ham mavjud bo'lib, ular asinxron vazifalar ishga tushirilganda joriy oraliqni avtomatik ravishda ipga yo'naltiradi:
private ExecutorService executor = new TracedExecutorService(
Executors.newFixedThreadPool(10), GlobalTracer.get()
);Tashqi http so'rovlari uchun mavjud
HttpClient httpClient = new TracingHttpClientBuilder().build();Biz duch kelgan muammolar
- Fasol va DI har doim ham ishlamaydi, agar kuzatuvchi xizmat yoki komponentda ishlatilmasa, keyin Tracer ishlamasligi mumkin va siz GlobalTracer.get() dan foydalanishingiz kerak bo'ladi.
- Izohlar, agar u komponent yoki xizmat bo'lmasa yoki usul bir xil sinfning qo'shni usulidan chaqirilsa, ishlamaydi. Nima ishlayotganini tekshirish uchun ehtiyot bo'lishingiz kerak va agar @Traced ishlamasa, qo'lda iz yaratishdan foydalaning. Bundan tashqari, java izohlari uchun qo'shimcha kompilyatorni biriktirishingiz mumkin, keyin ular hamma joyda ishlashi kerak.
- Qadimgi bahor va bahor yuklashda, DI-dagi xatolar tufayli ochiq-oydin bahor bulutli avtokonfiguratsiyasi ishlamaydi, agar siz bahor komponentlaridagi izlarning avtomatik ishlashini istasangiz, buni shunga o'xshash tarzda qilishingiz mumkin.
- Resurslar bilan sinab ko'rish juda yaxshi ishlamaydi, siz nihoyat sinab ko'rishingiz kerak.
- Har bir xizmatning o'z spring.application.name bo'lishi kerak, uning ostida izlar qayd etiladi. Savdo va sinov uchun alohida nom nima qiladi, ular bilan birga aralashmaslik uchun.
- Agar siz GlobalTracer va Tomcat-dan foydalansangiz, ushbu tomcatda ishlaydigan barcha xizmatlar bitta GlobalTracerga ega, shuning uchun ularning barchasi bir xil xizmat nomiga ega bo'ladi.
- Usulga izlar qo'shganda, u tsiklda ko'p marta chaqirilmasligiga ishonch hosil qilishingiz kerak. Barcha qo'ng'iroqlar uchun umumiy ish vaqtini kafolatlaydigan bitta umumiy iz qo'shish kerak. Aks holda, ortiqcha yuk hosil bo'ladi.
- Bir marta jaeger-ui-da juda ko'p miqdordagi izlar uchun juda katta so'rovlar qilingan va ular javobni kutmagani uchun ular yana buni qilishdi. Natijada, jaeger-query juda ko'p xotira iste'mol qila boshladi va elastiklikni sekinlashtirdi. Jaeger-query-ni qayta ishga tushirish orqali yordam berdi
Namuna olish, saqlash va izlarni ko'rish
Uchta turi mavjud :
- Barcha izlarni yuboradigan va saqlaydigan Const.
- Ba'zi berilgan ehtimollik bilan izlarni filtrlaydigan probabilistik.
- Ratelimiting, bu soniyada izlar sonini cheklaydi. Siz ushbu sozlamalarni mijozda yoki jaeger-agentda yoki kollektorda sozlashingiz mumkin. Endi biz baholovchilar to'plamida const 1 dan foydalanamiz, chunki so'rovlar unchalik ko'p emas, lekin ular uzoq vaqt talab etadi. Kelajakda, agar bu tizimga ortiqcha yuk olib keladigan bo'lsa, uni cheklashingiz mumkin.
Agar siz kassandradan foydalansangiz, sukut bo'yicha u faqat ikki kun davomida izlarni saqlaydi. Biz foydalanamiz va izlar barcha vaqt davomida saqlanadi va o'chirilmaydi. Har bir kun uchun alohida indeks yaratiladi, masalan jaeger-service-2019-03-04. Kelajakda siz eski izlarni avtomatik tozalashni sozlashingiz kerak.
Izlarni ko'rish uchun sizga kerak bo'ladi:
- Izlarni filtrlamoqchi bo'lgan xizmatni tanlang, masalan, tomcat-da ishlayotgan va o'z nomiga ega bo'lmagan xizmat uchun tomcat7-default.
- Keyin operatsiyani, vaqt oralig'ini va minimal ishlash vaqtini, masalan, 10 soniyadan boshlab, faqat uzoq bajarilishlarni tanlang.
- Izlardan biriga boring va u erda nima sekinlashayotganini ko'ring.
Bundan tashqari, agar ba'zi so'rov identifikatori ma'lum bo'lsa, bu identifikator kuzatuv oralig'ida qayd etilgan bo'lsa, teg qidirish orqali ushbu identifikator bo'yicha izni topishingiz mumkin.
hujjatlar
- Opentracing hujjatlari
- jaeger hujjatlari
- Jaeger java ulanish
- bahor ochiq kuzatuv aloqasi
Maqolalar
- Haqiqiy PHP va Golang loyihasida Jaeger Opentracing va Microservices
- Uber Engineering-da rivojlanayotgan taqsimlangan kuzatuv
- Yalang'och metallda Jaeger agentini ishga tushirish
ΠΠΈΠ΄Π΅ΠΎ
- Qanday qilib biz Jaeger va Prometeydan foydalanuvchi so'rovlarini tez yetkazib berish uchun ishlatganmiz - Bryan Boreham
- Kirish: Jaeger - Yuriy Shkuro, Uber va Pavol Loffay, Red Hat
- Sergey Iakovlev, "Katta g'alabaning kichik hikoyasi: OpenTracing, AWS va Jaeger"
Manba: www.habr.com