Бүртгэлүүд нь системийн чухал хэсэг бөгөөд энэ нь хүлээгдэж буй шиг ажилладаг (эсвэл ажиллахгүй) гэдгийг ойлгох боломжийг олгодог. Микро үйлчилгээний архитектурын нөхцөлд логуудтай ажиллах нь тусгай олимпиадын тусдаа салбар болж хувирдаг. Шийдвэрлэх шаардлагатай маш олон асуудал байна:
- програмаас бүртгэлийг хэрхэн бичих;
- бүртгэлийг хаана бичих;
- логыг хадгалах, боловсруулахад хэрхэн хүргэх;
- бүртгэлийг хэрхэн боловсруулах, хадгалах.
Одоогийн байдлаар түгээмэл хэрэглэгддэг савны технологийг ашиглах нь асуудлыг шийдэх сонголтуудын талбарт тармуур дээр элс нэмж өгдөг.
Энэ тухай Юрий Бушмелевийн "Мод цуглуулах, хүргэх чиглэлээр тармуурын газрын зураг" илтгэлийн хуулбар байна.
Хэнд хамаатай юм бэ, муурны доор уу.
Намайг Юрий Бушмелев гэдэг. Би Лазадагийн төлөө ажилладаг. Өнөөдөр би гуалингаа хэрхэн хийсэн, хэрхэн цуглуулсан, тэнд юу бичсэн тухай ярих болно.
Бид хаанаас ирсэн бэ? Бид хэн бэ? Лазада бол Зүүн өмнөд Азийн зургаан улсын №1 онлайн худалдаачин юм. Эдгээр бүх улсууд мэдээллийн төвүүдэд хуваарилагдсан байдаг. Одоо нийт 4 дата төв бий. Энэ яагаад чухал вэ? Учир нь зарим шийдвэрүүд төвүүдийн хоорондын холбоо маш сул байгаатай холбоотой байсан. Бид бичил үйлчилгээний архитектуртай. Бид аль хэдийн 80 микро үйлчилгээтэй болохыг олж мэдээд би гайхсан. Бүртгэлтэй ажлаа эхлүүлэхэд ердөө 20 ширхэг л байсан.Түүнчлэн PHP-н өв залгамжлалын нэлээд том хэсэг байгаа бөгөөд би үүнийг бас тэвчиж, амьдрах ёстой. Энэ бүхэн нь одоогоор бидний хувьд системд нэг минутанд 6 сая гаруй мессежийг үүсгэж байна. Цаашид бид үүнтэй хэрхэн амьдрахыг хичээж байгаа, яагаад ийм байдгийг харуулах болно.
Та энэ 6 сая мессежтэй ямар нэгэн байдлаар амьдрах ёстой. Бид тэдэнтэй юу хийх ёстой вэ? 6 сая мессеж шаардлагатай:
- апп-аас илгээх
- хүргэлтээр хүлээн авна
- дүн шинжилгээ хийх, хадгалахад хүргэх.
- дүн шинжилгээ хийх
- ямар нэгэн байдлаар хадгалах.
Гурван сая мессеж ирэхэд би бараг адилхан харагдсан. Яагаад гэвэл бид хэдэн пеннитэй эхэлсэн. Өргөдлийн бүртгэл тэнд бичигдсэн нь ойлгомжтой. Жишээлбэл, мэдээллийн сантай холбогдож чадаагүй, мэдээллийн сантай холбогдож чадсан боловч ямар нэгэн зүйл уншиж чадахгүй байна. Гэхдээ үүнээс гадна манай микро үйлчилгээ бүр хандалтын бүртгэл бичдэг. Микро үйлчилгээнд ирсэн хүсэлт бүр бүртгэлд ордог. Бид яагаад үүнийг хийж байгаа юм бэ? Хөгжүүлэгчид мөшгих чадвартай байхыг хүсдэг. Хандалтын бүртгэл бүр нь traceid талбарыг агуулдаг бөгөөд үүний дагуу тусгай интерфейс нь гинжийг бүхэлд нь задалж, ул мөрийг сайхан харуулдаг. Мөр нь хүсэлт хэрхэн явагдсаныг харуулсан бөгөөд энэ нь манай хөгжүүлэгчдэд үл мэдэгдэх хог хаягдлыг хурдан шийдвэрлэхэд тусалдаг.
Түүнтэй яаж амьдрах вэ? Одоо би сонголтуудын талбарыг товч тайлбарлах болно - энэ асуудал ерөнхийдөө хэрхэн шийдэгддэг. Лог цуглуулах, шилжүүлэх, хадгалах асуудлыг хэрхэн шийдвэрлэх вэ.
Өргөдөлөөс хэрхэн бичих вэ? Янз бүрийн арга зам байгаа нь ойлгомжтой. Тэр дундаа загварлаг нөхдийн хэлж байгаачлан шилдэг туршлага бий. Өвөөгийн хэлсэнчлэн хоёр төрлийн хуучин сургууль байдаг. Өөр арга замууд бий.
Лог цуглуулснаар нөхцөл байдал ойролцоогоор ижил байна. Энэ тодорхой хэсгийг шийдэх олон сонголт байдаггүй. Тэд илүү олон байгаа ч одоогоор тийм ч олон биш байна.
Гэвч хүргэлт, дараагийн дүн шинжилгээ хийснээр өөрчлөлтүүдийн тоо дэлбэрч эхэлдэг. Би одоо сонголт бүрийг тайлбарлахгүй. Гол сонголтууд нь сэдвийг сонирхож байсан бүх хүмүүст сайн мэддэг гэж би бодож байна.
Лазада дээр бид үүнийг хэрхэн хийснийг, энэ бүхэн хэрхэн эхэлснийг би танд үзүүлэх болно.
Жилийн өмнө би Лазада хотод ирээд логоны төсөлд явуулсан. Тэнд ийм байсан. Програмын бүртгэлийг stdout болон stderr дээр бичсэн. Бүх зүйл загварлаг байдлаар хийгдсэн. Гэвч дараа нь хөгжүүлэгчид үүнийг стандарт урсгалаас хассан бөгөөд дараа нь дэд бүтцийн мэргэжилтнүүд үүнийг ямар нэгэн байдлаар олох болно. Дэд бүтцийн мэргэжилтнүүд болон хөгжүүлэгчдийн хооронд "Өө ... за, зүгээр л бүрхүүлтэй файлд боож өгье, тэгээд л болоо" гэж хэлсэн гаргагчид байдаг. Энэ бүхэн нь саванд байгаа тул тэд яг саванд нь боож, дотор нь лавлахыг зурж, тэнд байрлуулав. Юу болсон нь бүгдэд ойлгомжтой гэж би бодож байна.
Жаахан цааш харцгаая. Бид эдгээр бүртгэлийг хэрхэн хүргэсэн. Хэн нэгэн td-agent-ийг сонгосон бөгөөд энэ нь үнэхээр чөлөөтэй ярьдаг ч тийм ч сайн биш юм. Энэ хоёр төслийн уялдаа холбоог би одоо болтол ойлгоогүй ч нэг л зүйл юм шиг санагддаг. Энэ Ruby хэл дээр бичигдсэн, лог файлуудыг уншиж, зарим ердийн хэллэгийг ашиглан JSON-д задлан шинжилсэн энэ чадварлаг. Дараа нь тэднийг Кафка руу явуулсан. Түүгээр ч барахгүй Кафка дээр бид API тус бүрт 4 тусдаа сэдэвтэй байсан. Яагаад 4? Амьд байгаа учраас найруулга байгаа, stdout, stderr байгаа учраас. Хөгжүүлэгчид тэдгээрийг үйлдвэрлэдэг бөгөөд дэд бүтцийн ажилтнууд тэдгээрийг Кафкад бий болгох ёстой. Түүгээр ч барахгүй Кафкаг өөр хэлтэс хянадаг байв. Тиймээс тэд api бүрт 4 сэдэв үүсгэхийн тулд тасалбар үүсгэх шаардлагатай болсон. Бүгд үүнийг мартсан. Ер нь бол хог, хог хаягдал байсан.
Дараа нь бид юу хийсэн бэ? Бид үүнийг кафка руу явуулсан. Кафкагаас цааш модны тал нь Логсташ руу нисэв. Бүртгэлийн үлдсэн хагасыг нь хуваалцсан. Зарим нь нэг Грейлог руу, зарим нь нөгөө Грейлог руу нисэв. Үүний үр дүнд энэ бүхэн нэг Elasticsearch кластер болж хувирав. Энэ бүх замбараагүй байдал эцэст нь тэнд унав. Та үүнийг хийх шаардлагагүй!
Дээрээс нь харахад ийм л харагддаг. Та үүнийг хийх шаардлагагүй! Энд асуудалтай газруудыг нэн даруй тоогоор тэмдэглэв. Үнэндээ тэднээс илүү олон байдаг, гэхдээ 6 нь үнэхээр асуудалтай тул ямар нэг зүйл хийх шаардлагатай байна. Би одоо тэдний талаар тусад нь хэлэх болно.
Энд (1,2,3) бид файл бичдэг бөгөөд үүний дагуу энд нэг дор гурван тармуур байна.
Эхний (1) нь бид тэдгээрийг хаа нэгтээ бичих хэрэгтэй. API-д файл руу шууд бичих боломжийг олгох нь үргэлж хүсдэггүй. API нь саванд тусгаарлагдсан, зөвхөн унших боломжтой байх нь зүйтэй юм. Би системийн администратор учраас эдгээрийн талаар арай өөр бодолтой байна.
Хоёрдахь цэг (2,3) нь API-д маш олон хүсэлт ирж байгаа явдал юм. API нь файлд их хэмжээний өгөгдлийг бичдэг. Файлууд нэмэгдэж байна. Бид тэднийг эргүүлэх хэрэгтэй. Учир нь өөрөөр хэлбэл та тэнд ямар ч диск хадгалах боломжгүй болно. Тэдгээрийг бүрхүүлээр дамжуулан лавлах руу шилжүүлдэг тул эргүүлэх нь муу юм. Бид үүнийг эргүүлэх ямар ч боломжгүй. Та програмыг бариулыг дахин нээхийг хэлж чадахгүй. Учир нь хөгжүүлэгчид таныг тэнэг хүн шиг харах болно: “Ямар дүрслэгч? Бид ерөнхийдөө stdout руу бичдэг. Фреймворкүүд нь copytruncate-г logrotate болгон хувиргасан бөгөөд энэ нь зүгээр л файлын хуулбарыг хийж, эх хувийг нь холбодог. Үүний дагуу эдгээр хуулбарлах процессуудын хооронд дискний зай ихэвчлэн дуусдаг.
(4) Бид өөр өөр API-д өөр өөр форматтай байсан. Тэдгээр нь арай өөр байсан ч regexp-ийг өөрөөр бичих шаардлагатай байв. Бүгдийг хүүхэлдэй удирдаж байсан болохоор өөрийн гэсэн жоомтой ангиуд их байсан. Дээрээс нь td-агент ихэнхдээ ой санамжаа идэж, тэнэг байж, ажил хийж байгаа мэт дүр эсгэж, юу ч хийхгүй байж чаддаг. Гаднаас нь харахад түүнийг юу ч хийхгүй байгааг ойлгох боломжгүй байв. Хамгийн сайн нь тэр унах болно, дараа нь хэн нэгэн түүнийг авах болно. Бүр тодруулбал, дохиолол нисч, хэн нэгэн очоод гараараа өргөх болно.
(6) Хамгийн их хог хаягдал нь elasticsearch байсан. Учир нь энэ нь хуучин хувилбар байсан. Учир нь тэр үед манайд зориулсан мастерууд байгаагүй. Бид талбарууд нь давхцаж болох нэг төрлийн логтой байсан. Өөр өөр програмуудын өөр өөр бүртгэлийг ижил талбарын нэрээр бичиж болох боловч дотор нь өөр өөр өгөгдөл байж болно. Өөрөөр хэлбэл, нэг лог талбарт бүхэл тоотой ирдэг, жишээлбэл, түвшин. Өөр нэг бүртгэл нь түвшний талбарт String-тай ирдэг. Статик зураглал байхгүй тохиолдолд ийм гайхалтай зүйл гарч ирдэг. Хэрэв индексийг эргүүлсний дараа elasticsearch дээр мөр бүхий мессеж эхлээд ирсэн бол бид хэвийн амьдардаг. Хэрэв эхнийх нь бүхэл тоогоор ирсэн бол String-тэй хамт ирсэн дараагийн бүх мессежийг зүгээр л устгана. Учир нь талбарын төрөл таарахгүй байна.
Бид эдгээр асуултуудыг асууж эхлэв. Бид буруутай хүмүүсийг хайхгүй байхаар шийдсэн.
Гэхдээ ямар нэг зүйл хийх хэрэгтэй! Тодорхой зүйл бол стандарт тогтоох хэрэгтэй. Бид хэдийнэ стандарттай болсон. Заримыг нь бид хэсэг хугацааны дараа авчирсан. Аз болоход, тэр үед бүх API-д зориулсан нэг бүртгэлийн формат аль хэдийн батлагдсан. Энэ нь үйлчилгээний харилцан үйлчлэлийн стандартад шууд бичигдсэн байдаг. Үүний дагуу бүртгэлийг хүлээн авах хүсэлтэй хүмүүс үүнийг энэ форматаар бичих хэрэгтэй. Хэрэв хэн нэгэн энэ форматаар лог бичээгүй бол бид ямар ч баталгаа өгөхгүй.
Цаашлаад лог бүртгэх, хүргэх, цуглуулах арга барилыг нэгдсэн стандарттай болгомоор байна. Ер нь хаана бичих, яаж хүргэх вэ. Төсөлд нэг номын санг ашиглах нь хамгийн тохиромжтой нөхцөл юм. Go-д зориулсан тусдаа бүртгэлийн номын сан, PHP-д зориулсан тусдаа номын сан байдаг. Бидэнд байгаа хүн бүр, хүн бүр тэдгээрийг ашиглах ёстой. Одоогоор 80 хувийн амжилт үзүүлж байна гэж хэлмээр байна. Гэвч зарим нь какти идсээр л байна.
Тэнд (слайд дээр) "Бүртгэл хүргэх SLA" дөнгөж гарч ирж байна. Энэ хараахан гараагүй байгаа ч бид үүн дээр ажиллаж байна. Учир нь хэрэв та ийм ийм газар ийм форматаар, секундэд N-ээс илүүгүй мессеж бичвэл бид тэнд хүргэх болно гэж infra хэлэхэд маш тохиромжтой. Энэ нь маш их толгойн өвдөлтийг арилгадаг. Хэрэв SLA байгаа бол энэ нь зүгээр л гайхалтай юм!
Бид асуудлыг хэрхэн шийдэж эхэлсэн бэ? Гол тармуур нь td-agent-тай байсан. Бидний гуалин хаашаа явах нь тодорхойгүй байв. Тэд хүргэгдсэн үү? Тэд явж байна уу? Тэд хаана байгаа юм бэ? Тиймээс td-agent-ийг эхний зүйлээр солихоор шийдсэн. Үүнийг юугаар солих талаар би энд товч тайлбарлав.
Чадварлаг. Эхлээд би түүнтэй өмнөх ажил дээрээ тааралдсан бөгөөд тэр бас үе үе унадаг. Хоёрдугаарт, энэ нь адилхан, зөвхөн профайл дээр.
файлын цохилт. Энэ нь бидэнд хэр сайн байсан бэ? Тэр Go-д байгаа бөгөөд бид Go-д маш сайн туршлагатай. Үүний дагуу, хэрэв ямар нэгэн зүйл байвал бид үүнийг өөртөө нэмж болно. Тийм учраас бид аваагүй. Ингэснээр өөртөө зориулж дахин бичиж эхлэх ямар ч уруу таталт гарахгүй байх болно.
Сисадмины хувьд ойлгомжтой шийдэл бол энэ хэмжээний бүх төрлийн syslogs (syslog-ng/rsyslog/nxlog) юм.
Эсвэл өөрийнхөөрөө ямар нэг зүйл бичээрэй, гэхдээ бид үүнийг, түүнчлэн filebeat-ыг хассан. Хэрэв та ямар нэгэн зүйл бичвэл бизнест хэрэгтэй зүйл бичих нь дээр. Лог хүргэхийн тулд бэлэн зүйл авах нь дээр.
Тиймээс сонголт нь үнэндээ syslog-ng болон rsyslog хоёрын хоорондох сонголт дээр ирсэн. Бид хүүхэлдэй дээр rsyslog-ийн хичээлүүдтэй байсан тул би rsyslog руу дөхсөн бөгөөд тэдгээрийн хооронд тодорхой ялгаа олдсонгүй. Syslog гэж юу вэ, syslog гэж юу вэ. Тийм ээ, зарим баримт бичиг нь муу, зарим нь илүү сайн. Тэр үүнийг мэддэг бөгөөд үүнийг өөрөөр хийдэг.
Мөн rsyslog-ийн талаар бага зэрэг. Нэгдүгээрт, энэ нь маш олон модультай учраас дажгүй юм. Энэ нь хүний унших боломжтой RainerScript (орчин үеийн тохиргооны хэл)-тэй. Гайхалтай урамшуулал бол бид стандарт хэрэгслээр td-agent-ийн зан үйлийг дуурайж болох бөгөөд програмын хувьд юу ч өөрчлөгдөөгүй. Өөрөөр хэлбэл, бид td-agent-ийг rsyslog болгон өөрчилсөн бөгөөд бусад бүх зүйлд хараахан хүрч болохгүй. Тэгээд тэр даруй бид ажлын хүргэлтийг авдаг. Дараа нь mmnormalize бол rsyslog-ийн гайхалтай зүйл юм. Энэ нь танд логуудыг задлан шинжлэх боломжийг олгодог боловч Grok болон regexp-ээр биш. Энэ нь хийсвэр синтакс мод үүсгэдэг. Энэ нь хөрвүүлэгч эх кодыг задлан шинжилдэгтэй адил логуудыг задалдаг. Энэ нь танд маш хурдан ажиллах, бага CPU идэх боломжийг олгодог бөгөөд ерөнхийдөө энэ бол зүгээр л гайхалтай зүйл юм. Өөр олон тооны урамшуулал байдаг. Би тэдний тухай ярихгүй.
rsyslog нь илүү олон сул талуудтай. Эдгээр нь урамшуулалтай ойролцоо байна. Гол бэрхшээл нь та үүнийг хоол хийх чадвартай байх ёстой бөгөөд та хувилбарыг сонгох хэрэгтэй.
Бид логуудыг unix залгуурт бичихээр шийдсэн. Мөн /dev/log-д биш, учир нь бидэнд системийн логууд эмх замбараагүй байгаа тул энэ дамжуулах хоолойд журнал байдаг. Тиймээс захиалгат залгуур руу бичье. Бид үүнийг тусдаа дүрмийн багцад хавсаргана. Юунд ч саад болохгүй байцгаая. Бүх зүйл ил тод, ойлгомжтой байх болно. Тиймээс бид үнэхээр тэгсэн. Эдгээр залгууртай лавлах нь стандартчилагдсан бөгөөд бүх сав руу дамжуулагдана. Савнууд нь өөрт хэрэгтэй залгуурыг харж, нээж, бичиж болно.
Яагаад файл биш гэж? Учир нь хүн бүр уншсан , файлыг докер руу дамжуулахыг оролдсон бөгөөд rsyslog-г дахин эхлүүлсний дараа файлын тодорхойлогч өөрчлөгдөж, докер энэ файлыг алддаг болохыг олж мэдсэн. Тэр өөр ямар нэг зүйлийг онгойлгож өгдөг, гэхдээ тэдний бичсэн залгуур биш. Бид энэ асуудлыг тойрч гарахын зэрэгцээ блоклох асуудлыг тойрч гарахаар шийдсэн.
Rsyslog нь слайд дээр заасан үйлдлүүдийг хийж, бүртгэлийг реле эсвэл Кафка руу илгээдэг. Кафка хуучин арга барилаа дагадаг. Рэйли - Би логийг хүргэхийн тулд цэвэр rsyslog ашиглахыг оролдсон. Мессежийн дараалалгүй, стандарт rsyslog хэрэгслийг ашиглан. Үндсэндээ энэ нь ажилладаг.
Гэхдээ тэдгээрийг дараа нь энэ хэсэгт (Logstash/Graylog/ES) хэрхэн оруулах талаар нарийн ширийн зүйлс бий. Энэ хэсэг (rsyslog-rsyslog) өгөгдлийн төвүүдийн хооронд ашиглагддаг. Энд байгаа шахсан tcp холбоос нь зурвасын өргөнийг хэмнэх боломжийг олгодог бөгөөд үүний дагуу суваг дүүрсэн үед бид өөр мэдээллийн төвөөс зарим бүртгэл хүлээн авах магадлалыг нэмэгдүүлэх болно. Учир нь манайд бүх зүйл муу байдаг Индонези бий. Байнгын асуудал энд л оршдог.
Бид яг үнэндээ хэрхэн хянадаг вэ, аппликешн дээрээс бидний тэмдэглэсэн бүртгэлүүд үүнд хүрэх магадлалтай гэж бодсон уу? Бид хэмжүүрүүдийг эхлүүлэхээр шийдсэн. Rsyslog нь өөрийн гэсэн статистик цуглуулах модультай бөгөөд энэ нь зарим төрлийн тоолууртай. Жишээлбэл, энэ нь танд дарааллын хэмжээ, ийм ийм үйлдэл хийхэд хичнээн мессеж ирснийг харуулах боломжтой. Та тэднээс ямар нэгэн зүйлийг аль хэдийн авч болно. Нэмж дурдахад энэ нь таны тохируулах боломжтой тусгай тоолууртай бөгөөд жишээлбэл, зарим API-ийн бичсэн мессежийн тоог харуулах болно. Дараа нь би Python дээр rsyslog_exporter гэж бичсэн бөгөөд бид бүгдийг Prometheus руу илгээж, төлөвлөгөө зохиов. Бид Graylog хэмжигдэхүүнийг үнэхээр хүсч байсан ч одоог хүртэл бид үүнийг тохируулах цаг байсангүй.
Ямар асуудал тулгарч байна вэ? Манай Live API нь секундэд 50 мянган мессеж бичдэг болохыг олж мэдсэн (Гэнэт!) Асуудал үүссэн. Энэ бол шатлалгүй зөвхөн Live API юм. Graylog бидэнд секундэд ердөө 12 мянган мессежийг харуулдаг. Үлдэгдэл хаана байна вэ гэсэн үндэслэлтэй асуулт гарч ирэв. Үүнээс бид Грэйлог зүгээр л даван туулж чадахгүй гэж дүгнэсэн. Бид харсан бөгөөд үнэхээр Elasticsearch-тэй Graylog энэ урсгалыг эзэмшээгүй байна.
Дараа нь бидний замд хийсэн бусад нээлтүүд.
Сокет руу бичихийг хориглосон. Энэ нь яаж болсон бэ? Би хүргэхдээ rsyslog ашиглах үед бид дата төвүүдийн хоорондох сувгийг эвдсэн. Хүргэлт нэг газар, хүргэлт өөр газар боссон. Энэ бүхэн нь rsyslog залгуурт бичдэг API бүхий машин дээр буусан. Дараалал үүссэн. Дараа нь unix залгуурт бичих дараалал дүүрсэн бөгөөд энэ нь анхдагчаар 128 пакет юм. Мөн програмын блок дахь дараагийн бичих(). Бидний Go программд ашигладаг номын санг үзэхэд залгуур руу бичих нь блоклохгүй горимд явагддаг гэж тэнд бичсэн байсан. Юу ч хаагдаагүй гэдэгт бид итгэлтэй байсан. Учир нь бид уншсан энэ тухай хэн бичсэн. Гэхдээ нэг мөч байна. Мөн энэ дуудлагын эргэн тойронд хязгааргүй гогцоо байсан бөгөөд үүнд мессежийг залгуур руу түлхэх оролдлого байнга гардаг. Бид түүнийг анзаараагүй. Би номын санг дахин бичих шаардлагатай болсон. Түүнээс хойш энэ нь хэд хэдэн удаа өөрчлөгдсөн боловч одоо бид бүх дэд системүүдийн түгжээнээс салсан. Тиймээс та rsyslog-г зогсоож болох бөгөөд юу ч унахгүй.
Энэ тармуур дээр гишгэхгүй байхад тусалдаг дарааллын хэмжээг хянах шаардлагатай. Нэгдүгээрт, бид мессеж алдаж эхлэхэд хяналт тавих боломжтой. Хоёрдугаарт, бид үндсэндээ хүргэх асуудалтай байгаа эсэхийг хянах боломжтой.
Мөн өөр нэг таагүй мөч - микро үйлчилгээний архитектурт 10 дахин өсгөх нь маш хялбар юм. Бидэнд тийм ч олон ирж буй хүсэлт байдаггүй, гэхдээ эдгээр зурвасууд цааш үргэлжлэх графикийн улмаас, хандалтын бүртгэлээс шалтгаалан бид бүртгэлийн ачааллыг арав дахин нэмэгдүүлдэг. Харамсалтай нь би яг нарийн тоог тооцоолох цаг байсангүй, гэхдээ микро үйлчилгээнүүд нь яг ийм байна. Үүнийг санаж байх ёстой. Одоогийн байдлаар бүртгэл цуглуулах дэд систем нь Лазада хамгийн их ачаалалтай байгаа нь харагдаж байна.
elasticsearch асуудлыг хэрхэн шийдвэрлэх вэ? Хэрэв та бүх машиныг ажиллуулж, тэнд цуглуулахгүйн тулд бүртгэлийг нэг дороос хурдан авах шаардлагатай бол файлын санг ашиглана уу. Энэ нь ажиллах баталгаатай. Энэ нь ямар ч серверээс хийгддэг. Та тэнд дискнүүдээ нааж, syslog оруулах хэрэгтэй. Үүний дараа та бүх бүртгэлийг нэг дор байлгах баталгаатай болно. Дараа нь elasticsearch, graylog эсвэл өөр зүйлийг аажмаар тохируулах боломжтой болно. Гэхдээ та бүх бүртгэлтэй байх болно, үүнээс гадна та хангалттай дискний массив байгаа бол тэдгээрийг хадгалах боломжтой.
Намайг илтгэх үед схем иймэрхүү харагдаж эхэлсэн. Бид файл руу бичихээ бараг больсон. Одоо, хамгийн их магадлалтай, бид үлдэгдлийг унтраах болно. API ажиллаж байгаа локал машинууд дээр бид файл руу бичихээ зогсооно. Нэгдүгээрт, файлын хадгалалт байдаг бөгөөд энэ нь маш сайн ажилладаг. Хоёрдугаарт, эдгээр машинуудын зай байнга дуусч байгаа тул та үүнийг байнга хянаж байх хэрэгтэй.
Logstash, Graylog нартай энэ хэсэг үнэхээр хөөрч байна. Тиймээс та үүнээс салах хэрэгтэй. Та нэгийг нь сонгох хэрэгтэй.
Бид Логсташ, Кибана нарыг орхихоор шийдсэн. Учир нь манайх хамгаалалтын албатай. Ямар холбоотой вэ? Холболт нь X-Pack, Shield-гүй Кибана нь бүртгэлд хандах эрхийг ялгах боломжийг танд олгодоггүй. Тиймээс тэд Грейлогыг авчээ. Үүнд бүх зүйл бий. Би үүнд дургүй, гэхдээ энэ нь ажилладаг. Бид шинэ техник хангамж худалдаж авч, тэнд шинэ Graylog суулгаж, хатуу форматтай бүх бүртгэлийг тусдаа Graylog руу шилжүүлсэн. Бид зохион байгуулалтын хувьд ижил төрлийн өөр өөр төрлийн асуудлыг шийдсэн.
Шинэ Graylog-д яг юу орсон байна. Бид зүгээр л докер дээр бүгдийг бичсэн. Бид хэд хэдэн сервер авч, гурван Кафка хувилбар, 7 Graylog серверийн 2.3 хувилбарыг (би Elasticsearch хувилбар 5-ыг авахыг хүссэн учраас) гаргалаа. Энэ бүхнийг HDD-ээс авсан дайралт дээр дурдсан. Бид секундэд 100 мянган мессежийг индексжүүлэх хурдыг харсан. Долоо хоногт 140 терабайт мэдээлэл авдаг гэсэн тоог бид харсан.
Мөн дахин тармуур! Бид хоёр хямдралтай байна. Бид 6 сая бичлэгийг давсан. Грейлог бидэнд зажлах цаг байдаггүй. Ямар нэгэн байдлаар та дахин амьд үлдэх хэрэгтэй.
Ингэж л бид амьд үлдсэн. Цөөн хэдэн сервер болон SSD нэмсэн. Одоогоор бид ингэж амьдарч байна. Одоо бид секундэд 160 мянган мессеж зажилж байна. Бид хязгаарт хүрч амжаагүй байгаа тул үүнээс хэр бодитой гарах нь тодорхойгүй байна.
Эдгээр нь бидний ирээдүйн төлөвлөгөө юм. Эдгээрээс хамгийн чухал нь магадгүй өндөр хүртээмжтэй байх явдал юм. Бидэнд одоохондоо байхгүй. Хэд хэдэн машиныг ижил аргаар суулгасан боловч одоогоор бүх зүйл нэг машинаар дамжин өнгөрч байна. Тэдний хооронд дампууралтыг бий болгохын тулд цаг хугацаа зарцуулах шаардлагатай байна.
Graylog-ээс хэмжүүрүүдийг цуглуул.
Бидний зурвасын өргөн болон бусад бүх зүйлийг устгадаггүй нэг галзуу API-тай болохын тулд тарифын хязгаар тогтоо.
Эцэст нь хөгжүүлэгчидтэй нэг төрлийн SLA-д гарын үсэг зурснаар бид ийм хэмжээний үйлчилгээ үзүүлэх боломжтой болно. Илүү их юм бичвэл уучлаарай.
Мөн бичиг баримт бичнэ үү.
Товчхондоо, бидний туулсан бүх зүйлийн үр дүн. Нэгдүгээрт, стандартууд. Хоёрдугаарт, syslog бол бялуу юм. Гуравдугаарт, rsyslog нь слайд дээр бичсэн шигээ ажилладаг. Тэгээд асуултууд руугаа орцгооё.
Асуултууд.
Таны асуулт: Тэд яагаад авахгүй гэж шийдсэн юм ... (filebeat?)
Хариу хариул: Файл руу бичих шаардлагатай. Би үнэхээр хүсээгүй. Таны API секундэд хэдэн мянган мессеж бичих үед, та цагт нэг удаа эргэдэг байсан ч энэ нь сонголт биш хэвээр байна. Та хоолой руу бичиж болно. Хөгжүүлэгчид надаас "Бидний бичих үйл явц унавал юу болох вэ" гэж асуусан уу? Би зүгээр л тэдэнд юу гэж хариулахаа олсонгүй: "За, тэгье, тэгье" гэж хэлэв.
Таны асуулт: Яагаад HDFS-д лог бичдэггүй юм бэ?
Хариу хариулХ: Энэ бол дараагийн шат. Бид анхнаасаа энэ талаар бодож байсан ч одоогоор үүнийг шийдвэрлэх нөөц байхгүй тул энэ нь бидний урт хугацааны шийдэлд гацсан.
Таны асуулт: Баганын формат нь илүү тохиромжтой байх болно.
Хариу хариул: Би ойлгож байна. Бид хоёр гараараа "төлөв" байна.
Таны асуулт: Та rsyslog руу бичдэг. TCP болон UDP хоёулаа тэнд боломжтой. Гэхдээ хэрэв UDP бол хүргэлтийг яаж баталгаажуулах вэ?
Хариу хариулХ: Хоёр цэг бий. Нэгдүгээрт, бид лог хүргэх баталгаа өгөхгүй гэдгийг би хүн бүрт шууд хэлнэ. Учир нь хөгжүүлэгчид ирээд "Тэнд санхүүгийн мэдээлэл бичиж эхэлцгээе, ямар нэг зүйл тохиолдвол та үүнийг бидэнд зориулж хаа нэгтээ байрлуулна" гэж хэлэхэд бид тэдэнд "Гайхалтай! Залгуур руу бичихийг хориглож эхэлцгээе, үүнийг гүйлгээгээр хийцгээе, ингэснээр та үүнийг бидний төлөө үүрэнд хийж, нөгөө талаас нь хүлээн авсан эсэхийг баталгаажуулах болно. Мөн энэ мөчид хүн бүр шаардлагагүй болж хувирдаг. Хэрэв үгүй бол бидэнд ямар асуулт байна вэ? Хэрэв та залгуур руу бичих баталгаа өгөхийг хүсэхгүй байгаа бол бид яагаад хүргэх баталгаа өгөх вэ? Бид хамгийн сайн хүчин чармайлт гаргаж байна. Бид үнэхээр аль болох их, аль болох сайн хүргэхийг хичээдэг ч 100% баталгаа өгдөггүй. Тиймээс тэнд санхүүгийн мэдээлэл бичих шаардлагагүй. Үүний тулд гүйлгээний мэдээллийн сан байдаг.
Таны асуулт: API нь лог руу зарим нэг мессеж үүсгэж, хяналтыг микро үйлчилгээ рүү шилжүүлэх үед өөр өөр микро үйлчилгээнүүдийн мессежүүд буруу дарааллаар ирэх асуудалтай тулгарсан уу? Үүнээс болж төөрөгдөл үүсдэг.
Хариу хариулХ: Тэд өөр дарааллаар ирдэг нь хэвийн зүйл. Та үүнд бэлэн байх ёстой. Учир нь аливаа сүлжээний хүргэлт нь танд захиалга өгөх баталгаа болохгүй, эсвэл та үүнд тусгай нөөц зарцуулах шаардлагатай болно. Хэрэв бид файлын хадгалалт авдаг бол API бүр бүртгэлийг өөрийн файлд хадгалдаг. Харин rsyslog нь тэдгээрийг тэнд байгаа сангуудад задалдаг. API бүр өөрийн гэсэн бүртгэлтэй бөгөөд та тэнд очиж үзэх боломжтой бөгөөд дараа нь та энэ бүртгэл дэх цагийн тэмдгийг ашиглан тэдгээрийг харьцуулах боломжтой. Хэрэв тэд Graylog дээр хайхаар очвол тэнд цаг хугацааны тэмдгээр эрэмбэлэгдэнэ. Тэнд бүх зүйл сайхан болно.
Таны асуулт: Цагийн тэмдэг нь миллисекундээр ялгаатай байж болно.
Хариу хариул: Цагийн тэмдэг нь API өөрөө үүсгэгддэг. Энэ бол үнэн хэрэгтээ бүх зүйл юм. Бидэнд NTP байна. API нь зурваст аль хэдийн цагийн тэмдэг үүсгэдэг. Үүнийг rsyslog нэмээгүй.
Таны асуулт: Дата төвүүдийн харилцан үйлчлэл тийм ч тодорхой биш байна. Дата төвийн хүрээнд бүртгэлийг хэрхэн цуглуулж, боловсруулж байсан нь тодорхой. Дата төвүүдийн харилцан үйлчлэл хэр байна вэ? Эсвэл дата төв бүр өөрийн гэсэн амьдралаар амьдардаг уу?
Хариу хариул: Бараг л. Бид улс бүр нэг дата төвд байрладаг. Бид одоогоор тархаагүй байгаа тул нэг улсыг өөр өөр мэдээллийн төвд байрлуулсан байна. Тиймээс тэдгээрийг нэгтгэх шаардлагагүй. Төв бүр дотор бүртгэлийн реле байдаг. Энэ бол Rsyslog сервер юм. Уг нь удирдлагын хоёр машин. Тэдгээрийг ижил аргаар тохируулдаг. Гэхдээ одоогоор тэдний нэгээр л замын хөдөлгөөн явж байна. Тэр бүх зүйлийг нэгтгэн бүртгэдэг. Энэ нь ямар ч тохиолдолд дискний дараалалтай байдаг. Тэр логуудыг дарж, төв мэдээллийн төв (Сингапур) руу илгээдэг бөгөөд тэнд Грэйлогт хордсон байна. Мөн дата төв бүр өөрийн гэсэн файлын сантай. Хэрэв бид холболтоо алдсан тохиолдолд бүх бүртгэлүүд тэнд байна. Тэд тэнд үлдэх болно. Тэд тэнд хадгалагдах болно.
Таны асуулт: Та хэвийн бус нөхцөл байдлын үед тэндээс бүртгэл авдаг уу?
Хариу хариул: Та тийшээ (файл хадгалах газар руу) очоод харж болно.
Таны асуулт: Та бүртгэлээ алдахгүй байх талаар хэрхэн хянах вэ?
Хариу хариул: Бид үнэндээ тэднийг алдаж байна, бид үүнийг хянаж байна. Сарын өмнөөс хяналт тавьж эхэлсэн. Go API-уудын ашигладаг номын сан нь хэмжүүртэй. Тэр розетка руу хэдэн удаа бичиж чадаагүйгээ тоолж чадна. Одоогоор төвөгтэй эвристик байна. Тэнд буфер байна. Үүнээс залгуур руу мессеж бичихийг оролддог. Хэрэв буфер халивал тэдгээрийг хаяж эхэлнэ. Тэгээд тэр тэднийг хэдэн удаа унагасныг тоолдог. Тэнд лангуунууд дүүрч эхэлбэл энэ талаар мэдэх болно. Тэд одоо бас прометей дээр ирж байгаа бөгөөд та Графана дахь графикуудыг харж болно. Та сэрэмжлүүлэг тохируулах боломжтой. Гэвч тэднийг хэн рүү явуулах нь одоогоор тодорхойгүй байна.
Таны асуулт: Elasticsearch дээр та логуудыг илүүдэлтэй хадгалдаг. Та хэдэн хуулбартай вэ?
Хариу хариул: Нэг хуулбар.
Таны асуулт: Зөвхөн нэг мөр үү?
Хариу хариул: Энэ бол мастер болон хуулбар юм. Өгөгдлийг давхардсан хэлбэрээр хадгална.
Таны асуулт: Та rsyslog буферын хэмжээг ямар нэгэн байдлаар өөрчилсөн үү?
Хариу хариул: Бид датаграммуудыг тусгай Unix залгуурт бичдэг. Энэ нь нэн даруй бидэнд 128 килобайтын хязгаарлалт тавьдаг. Бид үүнээс илүү зүйл бичиж чадахгүй. Бид үүнийг стандартад бичсэн. Хадгалалтанд орохыг хүссэн хүн 128 килобайт бичдэг. Номын сангууд, үүнээс гадна, таслагдах, зурвас таслагдсан гэсэн туг тавих. Бидэнд мессежийн стандартад тусгай талбар байдаг бөгөөд энэ нь бичлэг хийх явцад таслагдсан эсэхийг харуулдаг. Тиймээс бидэнд энэ мөчийг хянах боломж байна.
Асуулт: Та эвдэрсэн JSON бичдэг үү?
Хариу хариул: Пакет хэт том учир эвдэрсэн JSON-г реле хийх явцад устгах болно. Эсвэл Graylog нь JSON-г задлан шинжлэх боломжгүй тул хасагдах болно. Гэхдээ энд засах шаардлагатай нюансууд байдаг бөгөөд тэдгээр нь ихэвчлэн rsyslog-тэй холбоотой байдаг. Би тэнд хэд хэдэн асуудлыг бөглөсөн байгаа бөгөөд одоо ч ажиллах шаардлагатай байна.
Асуулт: Яагаад Кафка гэж? Та RabbitMQ-г туршиж үзсэн үү? Грэйлог ийм ачааллын дор нэмэгдэхгүй байна уу?
Хариу хариул: Грэйлогтой бол болохгүй. Грэйлог хэлбэржиж байна. Энэ нь түүний хувьд үнэхээр асуудалтай юм. Тэр ямар нэгэн зүйл юм. Тэгээд үнэндээ энэ нь шаардлагагүй юм. Би rsyslog-оос elasticsearch руу шууд бичээд дараа нь Кибана үзэхийг илүүд үздэг. Гэхдээ хамгаалалтын албаныхантай асуудлыг шийдэх хэрэгтэй. Энэ нь Грэйлогийг хаяж, Кибана ашиглах үед бидний хөгжлийн боломжит хувилбар юм. Logstash нь утгагүй болно. Учир нь би rsyslog-тэй ижил зүйлийг хийж чадна. Мөн elasticsearch руу бичих модультай. Грэйлогоор бид ямар нэгэн байдлаар амьдрахыг хичээж байна. Бид бүр үүнийг бага зэрэг өөрчилсөн. Гэхдээ сайжруулах зүйл байсаар байна.
Кафкагийн тухай. Түүхэнд ийм л байсан. Намайг очиход аль хэдийн тэнд байсан бөгөөд түүн дээр бүртгэлүүд бичигдсэн байв. Бид зүгээр л кластераа босгож, логуудыг түүн рүү шилжүүлсэн. Бид түүнийг удирдаж, түүний мэдрэмжийг мэддэг. RabbitMQ-ийн хувьд ... бид RabbitMQ-тэй холбоотой асуудалтай тулгараад байна. Мөн RabbitMQ бидэнд зориулж хөгжүүлж байна. Манайд үйлдвэрлэлд байгаа бөгөөд үүнтэй холбоотой асуудал гарсан. Одоо бол худалдахаас өмнө бөөгөөр үйлчлүүлж, хэвийн ажилдаа орно. Гэхдээ үүнээс өмнө би үүнийг үйлдвэрлэлд гаргахад бэлэн биш байсан. Бас нэг цэг байна. Graylog нь AMQP 0.9 хувилбарыг уншиж, rsyslog нь AMQP 1.0 хувилбарыг бичиж чаддаг. Мөн дунд нь хоёуланг нь хийж чадах ганц шийдэл байхгүй. Нэг эсвэл нөгөө нь байдаг. Тэгэхээр одоохондоо зөвхөн Кафка. Гэхдээ бас нюансууд байдаг. Учир нь бидний ашигладаг rsyslog хувилбарын омкафка нь rsyslog-оос цуглуулсан мессежийн буферийг бүхэлд нь алдаж болзошгүй. Бид үүнийг тэвчих л бол.
Асуулт: Чамд Кафка байгаа болохоор хэрэглэж байна уу? Өөр зориулалтаар ашиглаагүй юу?
Хариу хариул: Data Science багийн ашиглаж байсан Кафка. Энэ бол бүрэн тусдаа төсөл бөгөөд харамсалтай нь би юу ч хэлж чадахгүй. Би мэдэхгүй байна. Түүнийг Data Science баг удирдаж байсан. Бүртгэлүүд эхлэхэд тэд өөрсдөө тавихгүйн тулд үүнийг ашиглахаар шийдсэн. Одоо бид Graylog-г шинэчилсэн бөгөөд Кафкагийн хуучин хувилбар байгаа тул нийцтэй байдал алдагдсан. Бид өөрсдөө хийх ёстой байсан. Үүний зэрэгцээ бид API бүрийн хувьд эдгээр дөрвөн сэдвээс салсан. Бид бүх амьд тоглолтод зориулж нэг өргөн топ, бүх тоглолтод зориулж нэг өргөн топ хийж, тэнд бүх зүйлийг л буудаж байна. Graylog энэ бүхнийг зэрэгцүүлэн гаргадаг.
Асуулт: Энэ залгууртай бөө мөргөл яагаад хэрэгтэй байна вэ? Та контейнерт зориулсан syslog бүртгэлийн драйвер ашиглаж үзсэн үү?
Хариу хариул: Бид энэ асуултыг асуух үед усан онгоцны зогсоолтой ширүүн харилцаатай байсан. Энэ нь docker 1.0 эсвэл 0.9 байсан. Докер өөрөө хачин байсан. Хоёрдугаарт, хэрэв та түүн рүү лог оруулах юм бол ... Энэ нь докер демоноор дамжуулан бүх бүртгэлийг өөрөө дамжуулдаг гэсэн баталгаагүй сэжигтэй байна. Хэрэв бидэнд нэг API галзуурах юм бол бусад API-ууд нь stdout болон stderr-г илгээх боломжгүй гэсэн дүгнэлтэд хүрнэ. Энэ нь хаашаа явахыг би мэдэхгүй. Энэ газарт docker syslog драйвер ашиглах шаардлагагүй гэсэн мэдрэмж надад төрж байна. Манай функциональ туршилтын хэлтэс нь бүртгэл бүхий Graylog кластертай. Тэд докерын бүртгэлийн драйверуудыг ашигладаг бөгөөд тэнд бүх зүйл хэвийн байгаа бололтой. Гэхдээ тэд тэр даруй Грэйлог руу GELF бичдэг. Энэ бүхнийг эхлүүлж байх тэр мөчид бидэнд зүгээр л ажиллах хэрэгтэй байсан. Магадгүй дараа нь хүн ирээд зуугаад жил хэвийн ажиллаж байна гэхээр нь оролдоно.
Асуулт: Та rsyslog ашиглан дата төвүүдийн хооронд дамжуулдаг. Кафка дээр яагаад болохгүй гэж?
Хариу хариул: Бид үүнийг хийдэг, үнэхээр ийм байна. Хоёр шалтгаанаар. Хэрэв суваг бүрэн үхсэн бол бидний бүх лог, тэр ч байтугай шахсан хэлбэрээр ч гэсэн түүгээр авирахгүй. Мөн кафка нь тэднийг үйл явцын дунд зүгээр л алдах боломжийг олгодог. Ийм байдлаар бид эдгээр гуалин наалдахаас ангижрах болно. Энэ тохиолдолд бид шууд Кафкаг ашиглаж байна. Хэрэв бидэнд сайн суваг байгаа бөгөөд түүнийг суллахыг хүсвэл бид тэдний rsyslog-г ашигладаг. Гэвч үнэн хэрэгтээ та үүнийг даван туулж чадаагүй зүйлээ унагахаар тохируулж болно. Одоогоор бид rsyslog дамжуулалтыг хаа нэг газар, хаа нэг газар Кафка ашиглаж байна.
Эх сурвалж: www.habr.com