2019-yil va bizda Kubernetes-da jurnallarni yig‘ish uchun hali ham standart yechim yo‘q. Ushbu maqolada biz haqiqiy amaliyotdan misollar yordamida izlanishlarimiz, duch kelgan muammolar va ularning echimlari bilan bo'lishmoqchimiz.
Biroq, birinchi navbatda, men turli xil mijozlar jurnallarni yig'ish orqali juda boshqacha narsalarni tushunishlarini bron qilaman:
- kimdir xavfsizlik va audit jurnallarini ko'rishni xohlaydi;
- kimdir - butun infratuzilmani markazlashtirilgan tarzda qayd etish;
- va ba'zilar uchun, masalan, balanschilar bundan mustasno, faqat dastur jurnallarini yig'ish kifoya.
Quyida biz turli xil "istaklar ro'yxati" ni qanday amalga oshirganimiz va qanday qiyinchiliklarga duch kelganimiz haqida qisqacha ma'lumot berilgan.
Nazariya: jurnalga yozish vositalari haqida
Ro'yxatga olish tizimining tarkibiy qismlari haqida ma'lumot
Jurnallar uzoq yo'lni bosib o'tdi, buning natijasida jurnallarni yig'ish va tahlil qilish metodologiyalari ishlab chiqildi, biz bugungi kunda foydalanamiz. 1950-yillarda Fortran standart kirish/chiqish oqimlarining analogini taqdim etdi, bu dasturchiga o'z dasturini tuzatishga yordam berdi. Bu o'sha davrdagi dasturchilarning hayotini osonlashtirgan birinchi kompyuter jurnallari edi. Bugun biz ularda logging tizimining birinchi komponentini ko'ramiz - jurnallar manbai yoki "ishlab chiqaruvchisi".
Informatika bir joyda turmadi: kompyuter tarmoqlari paydo bo'ldi, birinchi klasterlar... Bir nechta kompyuterlardan iborat murakkab tizimlar ishlay boshladi. Endi tizim ma'murlari bir nechta mashinalardan jurnallarni yig'ishga majbur bo'lishdi va alohida holatlarda tizimdagi nosozlikni tekshirish kerak bo'lsa, ular OS yadrosi xabarlarini qo'shishlari mumkin edi. Markazlashtirilgan jurnallarni yig'ish tizimlarini tavsiflash uchun 2000-yillarning boshlarida nashr etilgan , bu masofaviy_syslogni standartlashtirgan. Yana bir muhim komponent shunday paydo bo'ldi: log yig'uvchi va ularni saqlash.
Jurnallar hajmining oshishi va veb-texnologiyalarning keng joriy etilishi bilan foydalanuvchilarga qanday jurnallarni qulay tarzda ko'rsatish kerakligi haqida savol tug'ildi. Oddiy konsol vositalari (awk/sed/grep) yanada rivojlanganlari bilan almashtirildi tomoshabinlar jurnali - uchinchi komponent.
Jurnallar hajmining oshishi tufayli yana bir narsa aniq bo'ldi: jurnallar kerak, lekin ularning hammasi emas. Va turli xil jurnallar turli darajadagi saqlashni talab qiladi: ba'zilari bir kunda yo'qolishi mumkin, boshqalari esa 5 yil davomida saqlanishi kerak. Shunday qilib, ro'yxatga olish tizimiga ma'lumotlar oqimlarini filtrlash va yo'naltirish komponenti qo'shildi - keling, uni chaqiraylik filtr.
Saqlash ham katta sakrashni amalga oshirdi: oddiy fayllardan relyatsion ma'lumotlar bazalariga, keyin esa hujjatlarga yo'naltirilgan saqlashga (masalan, Elasticsearch). Shunday qilib, ombor kollektordan ajratilgan.
Oxir oqibat, jurnal tushunchasi biz tarix uchun saqlamoqchi bo'lgan voqealarning mavhum oqimiga aylandi. Toʻgʻrirogʻi, agar siz tergov oʻtkazishingiz yoki tahliliy hisobot tuzishingiz kerak boʻlsa...
Natijada, nisbatan qisqa vaqt ichida jurnallar to'plami muhim quyi tizimga aylandi, uni haqli ravishda Big Dataning kichik bo'limlaridan biri deb atash mumkin.
Agar bir vaqtlar oddiy nashrlar "ro'yxatga olish tizimi" uchun etarli bo'lishi mumkin bo'lsa, endi vaziyat juda o'zgargan.
Kubernetes va jurnallar
Kubernetes infratuzilmaga kelganida, allaqachon mavjud bo'lgan jurnallarni yig'ish muammosi ham uni chetlab o'tmadi. Qaysidir ma'noda, bu yanada og'riqli bo'ldi: infratuzilma platformasini boshqarish nafaqat soddalashtirilgan, balki ayni paytda murakkablashdi. Ko'pgina eski xizmatlar mikroservislarga o'tishni boshladi. Jurnallar kontekstida bu log manbalarining ko'payishi, ularning maxsus hayot aylanishi va barcha tizim komponentlarining aloqalarini jurnallar orqali kuzatish zaruratida namoyon bo'ladi...
Oldinga qarab, shuni ta'kidlashim mumkinki, hozir, afsuski, Kubernetes uchun boshqalar bilan taqqoslanadigan standartlashtirilgan ro'yxatga olish varianti yo'q. Jamiyatdagi eng mashhur sxemalar quyidagilar:
- kimdir stekni ochadi EFK (Elasticsearch, Fluentd, Kibana);
- kimdir yaqinda chiqarilganni sinab ko'rmoqda yoki foydalanadi ;
- нас (va balki faqat biz emas? ..) Men o'zimning rivojlanishimdan ko'p mamnunman - ...
Qoida tariqasida, biz K8s klasterlarida quyidagi to'plamlardan foydalanamiz (o'z-o'zidan joylashtirilgan echimlar uchun):
- ;
- .
Biroq, men ularni o'rnatish va sozlash bo'yicha ko'rsatmalarga to'xtalmayman. Buning o'rniga, men ularning kamchiliklariga va umuman loglar bilan bog'liq vaziyat haqida ko'proq global xulosalarga e'tibor qarataman.
K8-larda jurnallar bilan mashq qiling
"Kundalik jurnallar", sizlardan nechtasi bor?..
Katta infratuzilmadan jurnallarni markazlashtirilgan yig'ish jurnallarni yig'ish, saqlash va qayta ishlashga sarflanadigan katta resurslarni talab qiladi. Turli loyihalarni amalga oshirish jarayonida biz turli talablar va ulardan kelib chiqadigan operatsion muammolarga duch keldik.
Keling, ClickHouse-ni sinab ko'raylik
Jurnallarni juda faol ishlab chiqaradigan ilovaga ega bo'lgan loyihadagi markazlashtirilgan xotirani ko'rib chiqaylik: soniyada 5000 dan ortiq satr. Keling, uning jurnallari bilan ishlashni boshlaymiz, ularni ClickHouse-ga qo'shamiz.
Maksimal real vaqt talab qilinishi bilan, ClickHouse bilan 4 yadroli server allaqachon disk quyi tizimiga haddan tashqari yuklangan bo'ladi:
Ushbu turdagi yuklash biz imkon qadar tezroq ClickHouse-da yozishga harakat qilayotganimiz bilan bog'liq. Va ma'lumotlar bazasi bunga qattiq disk yuklanishi bilan javob beradi, bu quyidagi xatolarga olib kelishi mumkin:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Gap shundaki ClickHouse-da (ular jurnal ma'lumotlarini o'z ichiga oladi) yozish operatsiyalari paytida o'z qiyinchiliklariga ega. Ularga kiritilgan ma'lumotlar vaqtinchalik bo'limni hosil qiladi, keyinchalik u asosiy jadval bilan birlashtiriladi. Natijada, yozuv diskda juda talabchan bo'lib chiqadi va biz yuqorida qayd etilgan ogohlantirishga ham bog'liq: 1 soniyada 300 dan ortiq bo'limlarni birlashtirish mumkin emas (aslida bu 300 ta qo'shimchalar). soniyada).
Bunday xatti-harakatdan qochish uchun, imkon qadar katta bo'laklarda va har 1 soniyada 2 martadan ko'p bo'lmagan. Biroq, katta portlashlarda yozish biz ClickHouse-da kamroq yozishni taklif qiladi. Bu, o'z navbatida, buferning to'lib ketishiga va jurnallarning yo'qolishiga olib kelishi mumkin. Yechim Fluentd buferini oshirishdir, lekin keyin xotira iste'moli ham ortadi.
nota: ClickHouse bilan bizning yechimimizning yana bir muammoli jihati bizning holatimizda (loghouse) bo'linish ulangan tashqi jadvallar orqali amalga oshirilishi bilan bog'liq edi. . Bu katta vaqt oralig'ida namuna olishda ortiqcha RAM talab qilinishiga olib keladi, chunki metatable barcha bo'limlar orqali takrorlanadi - hatto kerakli ma'lumotlarni o'z ichiga olmaydi. Biroq, endi bu yondashuv ClickHouse-ning joriy versiyalari uchun xavfsiz tarzda eskirgan deb e'lon qilinishi mumkin (c ).
Natijada, har bir loyihada ClickHouse-da real vaqt rejimida jurnallarni yig'ish uchun etarli resurslar mavjud emasligi aniq bo'ladi (aniqrog'i, ularni taqsimlash mos kelmaydi). Bundan tashqari, siz foydalanishingiz kerak bo'ladi akkumulyator, biz keyinroq qaytamiz. Yuqorida tavsiflangan holat haqiqatdir. Va o'sha paytda biz mijozga mos keladigan va minimal kechikish bilan jurnallarni yig'ish imkonini beradigan ishonchli va barqaror echimni taklif qila olmadik ...
Elasticsearch haqida nima deyish mumkin?
Elasticsearch og'ir ish yuklarini boshqarishi ma'lum. Keling, xuddi shu loyihada sinab ko'raylik. Endi yuk quyidagicha ko'rinadi:
Elasticsearch ma'lumotlar oqimini hazm qila oldi, ammo unga bunday hajmlarni yozish protsessordan katta foydalanadi. Bu klaster tashkil qilish orqali hal qilinadi. Texnik jihatdan, bu muammo emas, lekin ma'lum bo'lishicha, loglarni yig'ish tizimini ishlatish uchun biz allaqachon 8 ta yadrodan foydalanamiz va tizimda qo'shimcha yuklangan komponent mavjud...
Xulosa: bu variantni oqlash mumkin, lekin agar loyiha katta bo'lsa va uning boshqaruvi markazlashtirilgan logging tizimiga katta resurslarni sarflashga tayyor bo'lsa.
Shunda tabiiy savol tug'iladi:
Qanday jurnallar haqiqatan ham kerak?
Keling, yondashuvning o'zini o'zgartirishga harakat qilaylik: jurnallar bir vaqtning o'zida ma'lumotli bo'lishi kerak va qoplamaydi har biri tizimdagi hodisa.
Aytaylik, bizda muvaffaqiyatli onlayn do'kon bor. Qaysi jurnallar muhim? Iloji boricha ko'proq ma'lumot to'plash, masalan, to'lov shlyuzidan, ajoyib g'oya. Ammo mahsulot katalogidagi tasvirni kesish xizmatining barcha jurnallari biz uchun juda muhim emas: faqat xatolar va kengaytirilgan monitoring etarli (masalan, ushbu komponent yaratadigan 500 ta xatoning foizi).
Shunday qilib, biz shunday xulosaga keldik markazlashtirilgan jurnallar har doim ham oqlanmaydi. Ko'pincha mijoz barcha jurnallarni bir joyda to'plashni xohlaydi, garchi aslida butun jurnaldan biznes uchun muhim bo'lgan shartli 5% xabar talab qilinadi:
- Ba'zan, aytaylik, faqat konteyner jurnalining o'lchamini va xato kollektorini (masalan, Sentry) sozlash kifoya.
- Xatolik xabari va katta mahalliy jurnalning o'zi ko'pincha hodisalarni tekshirish uchun etarli bo'lishi mumkin.
- Bizda faqat funktsional testlar va xatolarni yig'ish tizimlari bilan amalga oshirilgan loyihalarimiz bor edi. Ishlab chiquvchiga jurnallar kerak emas edi - ular xato izlaridan tortib hamma narsani ko'rdilar.
Hayotdan olingan illyustratsiya
Yana bir hikoya yaxshi misol bo'la oladi. Biz Kubernetes joriy etilishidan ancha oldin ishlab chiqilgan tijorat yechimidan foydalangan mijozlarimizdan birining xavfsizlik guruhidan so'rov oldik.
QRadar korporativ muammolarni aniqlash sensori yordamida jurnallarni yig'ishning markazlashtirilgan tizimi bilan "do'stlashish" kerak edi. Ushbu tizim syslog protokoli orqali jurnallarni qabul qilishi va ularni FTP dan olishi mumkin. Biroq, uni fluentd uchun remote_syslog plaginiga integratsiya qilish darhol imkoni bo'lmadi (ma'lum bo'lishicha, ). QRadarni sozlash bilan bog'liq muammolar mijozning xavfsizlik guruhi tomonida bo'lib chiqdi.
Natijada, biznes uchun muhim jurnallarning bir qismi FTP QRadar-ga yuklandi, boshqa qismi esa masofaviy syslog orqali to'g'ridan-to'g'ri tugunlardan yo'naltirildi. Buning uchun biz hatto yozdik - ehtimol, bu kimgadir shunga o'xshash muammoni hal qilishga yordam beradi ... Natijada paydo bo'lgan sxema tufayli mijozning o'zi tanqidiy jurnallarni qabul qildi va tahlil qildi (o'zining sevimli vositalaridan foydalangan holda) va biz logging tizimining narxini kamaytirishga muvaffaq bo'ldik. o `tgan oy.
Yana bir misol nima qilmaslik kerakligini ko'rsatadi. Qayta ishlash uchun mijozlarimizdan biri har birining foydalanuvchidan kelgan hodisalar, ko'p qatorli qilingan tuzilmagan ishlab chiqarish jurnaldagi ma'lumotlar. Siz taxmin qilganingizdek, bunday jurnallar o'qish va saqlash uchun juda noqulay edi.
Jurnallar uchun mezonlar
Bunday misollar loglarni yig'ish tizimini tanlashdan tashqari, kerak degan xulosaga olib keladi shuningdek, jurnallarni o'zlari loyihalash! Bu erda qanday talablar bor?
- Jurnallar mashina oʻqiy oladigan formatda boʻlishi kerak (masalan, JSON).
- Jurnallar ixcham bo'lishi va yuzaga kelishi mumkin bo'lgan muammolarni bartaraf etish uchun jurnalga yozish darajasini o'zgartirish imkoniyatiga ega bo'lishi kerak. Shu bilan birga, ishlab chiqarish muhitida siz kabi jurnallar darajasiga ega tizimlarni ishga tushirishingiz kerak ogohlantirish yoki xato.
- Jurnallar normallashtirilishi kerak, ya'ni jurnal ob'ektida barcha qatorlar bir xil maydon turiga ega bo'lishi kerak.
Strukturaviy bo'lmagan jurnallar jurnallarni saqlashga yuklash va ularni qayta ishlashni to'liq to'xtatish bilan bog'liq muammolarga olib kelishi mumkin. Misol tariqasida, 400-xato bilan misol keltiramiz, bu ko'pchilik ravon jurnallarda aniq uchragan:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Xato siz turi beqaror bo'lgan maydonni tayyor xaritalash bilan indeksga yuborayotganingizni bildiradi. Eng oddiy misol - o'zgaruvchiga ega bo'lgan nginx jurnalidagi maydon $upstream_status. U raqam yoki qatorni o'z ichiga olishi mumkin. Masalan:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
Jurnallar shuni ko'rsatadiki, 10.100.0.10 serveri 404 xatosi bilan javob bergan va so'rov boshqa kontent xotirasiga yuborilgan. Natijada, jurnallardagi qiymat quyidagicha bo'ldi:
"upstream_response_time": "0.001, 0.007"
Bu holat shunchalik keng tarqalganki, u hatto alohida bo'lishga loyiqdir .
Ishonchlilik haqida nima deyish mumkin?
Ba'zida istisnosiz barcha jurnallar hayotiy ahamiyatga ega. Va bu bilan, yuqorida taklif qilingan/muhokama qilingan K8 uchun jurnallarni yig'ishning odatiy sxemalarida muammolar mavjud.
Misol uchun, fluentd qisqa muddatli konteynerlardan jurnallarni to'play olmaydi. Loyihalarimizdan birida ma'lumotlar bazasini ko'chirish konteyneri 4 soniyadan kamroq vaqt yashadi va keyin o'chirildi - tegishli izohga ko'ra:
"helm.sh/hook-delete-policy": hook-succeeded
Shu sababli, migratsiyani bajarish jurnali saqlashga kiritilmagan. Bu holatda siyosat yordam berishi mumkin. before-hook-creation.
Yana bir misol Docker jurnalining aylanishi. Aytaylik, jurnallarga faol yozadigan dastur mavjud. Oddiy sharoitlarda biz barcha jurnallarni qayta ishlashga muvaffaq bo'lamiz, lekin muammo paydo bo'lishi bilanoq - masalan, noto'g'ri format bilan yuqorida tavsiflanganidek - ishlov berish to'xtaydi va Docker faylni aylantiradi. Natijada biznes uchun muhim jurnallar yo'qolishi mumkin.
Shuning uchun ham log oqimlarini ajratish muhimdir, ularning xavfsizligini ta'minlash uchun eng qimmatlilarini to'g'ridan-to'g'ri ilovaga yuborish. Bundan tashqari, ba'zilarini yaratish ortiqcha bo'lmaydi jurnallarning "akkumulyatori", bu muhim xabarlarni saqlash vaqtida qisqa xotira mavjud bo'lmaganda omon qolishi mumkin.
Nihoyat, buni unutmasligimiz kerak Har qanday quyi tizimni to'g'ri kuzatish muhimdir. Aks holda, ravon bo'lgan vaziyatga tushib qolish oson CrashLoopBackOff va hech narsa yubormaydi va bu muhim ma'lumotlarning yo'qolishini va'da qiladi.
topilmalar
Ushbu maqolada biz Datadog kabi SaaS yechimlarini ko'rib chiqmayapmiz. Bu erda tasvirlangan ko'plab muammolar jurnallarni yig'ishga ixtisoslashgan tijorat kompaniyalari tomonidan u yoki bu tarzda hal qilingan, ammo hamma ham turli sabablarga ko'ra SaaS-dan foydalana olmaydi. (asosiylari xarajat va 152-FZ ga muvofiqligi).
Markazlashtirilgan jurnallarni yig'ish dastlab oddiy vazifaga o'xshaydi, lekin u umuman emas. Shuni esda tutish muhim:
- Faqat muhim komponentlar batafsil tizimga kirishi kerak, monitoring va xatolarni yig'ish boshqa tizimlar uchun sozlanishi mumkin.
- Keraksiz yukni qo'shmaslik uchun ishlab chiqarishdagi jurnallar minimal bo'lishi kerak.
- Jurnallar mashinada o'qilishi, normallashtirilgan va qat'iy formatga ega bo'lishi kerak.
- Haqiqatan ham tanqidiy jurnallar alohida oqimga yuborilishi kerak, ular asosiylaridan ajratilishi kerak.
- Kundalik akkumulyatorni ko'rib chiqishga arziydi, bu sizni yuqori yukning portlashlaridan qutqarishi va saqlashga yukni yanada bir xil qilish imkonini beradi.
Ushbu oddiy qoidalar, agar hamma joyda qo'llanilsa, yuqorida tavsiflangan sxemalarning ishlashiga imkon beradi - garchi ularda muhim komponentlar (batareya) yo'q bo'lsa ham. Agar siz bunday printsiplarga rioya qilmasangiz, vazifa sizni va infratuzilmani tizimning boshqa yuqori yuklangan (va ayni paytda samarasiz) komponentiga osongina olib boradi.
PS
Shuningdek, bizning blogimizda o'qing:
- «";
- «";
- «".
Manba: www.habr.com