Энэ бол 2019 он бөгөөд бид Кубернетес дэх лог нэгтгэх стандарт шийдэлгүй хэвээр байна. Энэ нийтлэлд бид бодит практикийн жишээнүүдийг ашиглан хайлт, тулгарч буй асуудлууд, тэдгээрийн шийдлүүдийг хуваалцахыг хүсч байна.
Гэсэн хэдий ч, эхлээд би янз бүрийн үйлчлүүлэгчид бүртгэл цуглуулах замаар маш өөр зүйлийг ойлгодог захиалга хийх болно:
- хэн нэгэн аюулгүй байдал, аудитын бүртгэлийг харахыг хүсдэг;
- хэн нэгэн - бүх дэд бүтцийн төвлөрсөн бүртгэл;
- мөн зарим хүмүүсийн хувьд, жишээ нь тэнцвэржүүлэгчээс бусад програмын бүртгэлийг цуглуулахад хангалттай.
Бид янз бүрийн "хүслийн жагсаалт"-ыг хэрхэн хэрэгжүүлсэн, ямар бэрхшээл тулгарсан талаар доороос үзнэ үү.
Онол: мод бэлтгэх хэрэгслийн тухай
Мод бэлтгэх системийн бүрэлдэхүүн хэсгүүдийн талаархи суурь мэдээлэл
Мод бэлтгэлийн ажил маш урт замыг туулсан бөгөөд үүний үр дүнд мод цуглуулах, дүн шинжилгээ хийх арга зүйг боловсруулсан бөгөөд үүнийг өнөөдөр бидний ашиглаж байна. 1950-иад онд Фортран стандарт оролт/гаралтын урсгалын аналогийг нэвтрүүлсэн нь программист программдаа дибаг хийхэд тусалсан. Эдгээр нь тухайн үеийн програмистуудын амьдралыг хөнгөвчлөх анхны компьютерийн бүртгэлүүд байв. Өнөөдөр бид мод бэлтгэх системийн эхний бүрэлдэхүүн хэсгийг харж байна. бүртгэлийн эх сурвалж буюу "үйлдвэрлэгч".
Компьютерийн шинжлэх ухаан зогссонгүй: компьютерийн сүлжээнүүд гарч ирэв, анхны кластерууд ... Хэд хэдэн компьютерээс бүрдсэн цогц системүүд ажиллаж эхлэв. Одоо системийн администраторууд хэд хэдэн машинаас бүртгэл цуглуулахаас өөр аргагүй болсон бөгөөд онцгой тохиолдолд системийн доголдлыг судлах шаардлагатай тохиолдолд үйлдлийн системийн цөмийн мессежийг нэмж болно. Төвлөрсөн бүртгэл цуглуулах системийг тайлбарлахын тулд 2000-аад оны эхээр хэвлэгдсэн , энэ нь remote_syslog-г стандартчилсан. Өөр нэг чухал бүрэлдэхүүн хэсэг ингэж гарч ирэв: лог цуглуулагч болон тэдгээрийн хадгалалт.
Бүртгэлийн хэмжээ нэмэгдэж, вэб технологийг өргөнөөр нэвтрүүлснээр хэрэглэгчдэд ямар бүртгэлийг хялбархан харуулах шаардлагатай вэ гэсэн асуулт гарч ирэв. Энгийн консолын хэрэгслүүд (awk/sed/grep) илүү дэвшилтэт хэрэглүүрээр солигдсон үзэгчдийг бүртгэх - гурав дахь бүрэлдэхүүн хэсэг.
Бүртгэлийн хэмжээ нэмэгдсэний улмаас өөр нэг зүйл тодорхой болсон: лог хэрэгтэй, гэхдээ бүгдийг нь биш. Мөн янз бүрийн гуалин нь өөр өөр түвшний хадгалалт шаарддаг: зарим нь өдөрт алдагдаж, зарим нь 5 жилийн турш хадгалагдах шаардлагатай болдог. Тиймээс бүртгэлийн системд мэдээллийн урсгалыг шүүх, чиглүүлэх бүрэлдэхүүн хэсэг нэмэгдсэн - үүнийг нэрлэе. шүүлтүүр.
Хадгалах нь мөн томоохон үсрэлт хийсэн: ердийн файлуудаас харилцааны мэдээллийн сан руу, дараа нь баримт бичигт чиглэсэн хадгалалт (жишээлбэл, Elasticsearch). Тиймээс агуулахыг коллектороос тусгаарласан.
Эцсийн дүндээ гуалин гэдэг ойлголт нь бидний түүхэнд үлдээхийг хүсч буй үйл явдлын хийсвэр урсгал болон өргөжсөн. Бүр тодруулбал, мөрдөн байцаалтын ажиллагаа явуулах эсвэл аналитик дүгнэлт гаргах шаардлагатай бол...
Үүний үр дүнд харьцангуй богино хугацаанд бүртгэлийн цуглуулга нь том мэдээллийн дэд хэсгүүдийн нэг гэж нэрлэгдэх чухал дэд систем болон хөгжсөн.
Нэгэн цагт энгийн хэвлэмэл материал нь "мод бэлтгэх систем"-д хангалттай байсан бол одоо байдал маш их өөрчлөгдсөн.
Кубернетес ба бүртгэлүүд
Кубернетес дэд бүтцэд ирэхэд одоо байгаа бүртгэл цуглуулах асуудал ч үүнийг тойрч гарсангүй. Зарим талаараа энэ нь бүр ч зовлонтой болсон: дэд бүтцийн платформыг удирдах нь зөвхөн хялбаршуулаад зогсохгүй нэгэн зэрэг төвөгтэй болсон. Олон хуучин үйлчилгээнүүд бичил үйлчилгээ рүү шилжиж эхэлсэн. Бүртгэлийн хүрээнд энэ нь бүртгэлийн эх үүсвэрүүдийн тоо нэмэгдэж, тэдгээрийн онцгой амьдралын мөчлөг, логоор дамжуулан системийн бүх бүрэлдэхүүн хэсгүүдийн харилцааг хянах хэрэгцээ шаардлагад тусгагдсан болно...
Урагшаа харахад, харамсалтай нь Кубернетесийн хувьд бусадтай харьцуулах стандарт мод бэлтгэх сонголт байхгүй гэдгийг би хэлж чадна. Нийгэмд хамгийн алдартай схемүүд нь дараах байдалтай байна.
- хэн нэгэн стекийг буулгаж байна EFK (Elasticsearch, Fluentd, Кибана);
- хэн нэгэн саяхан гарсаныг оролдож байна эсвэл ашигладаг ;
- нас (магадгүй зөвхөн бид ч биш үү? ..) Би өөрийнхөө хөгжилд сэтгэл хангалуун байдаг - ...
Дүрмээр бол бид K8s кластерт дараах багцуудыг ашигладаг (өөрийгөө байршуулсан шийдлүүдийн хувьд):
- ;
- .
Гэсэн хэдий ч би тэдгээрийг суулгах, тохируулах зааврын талаар ярихгүй. Үүний оронд би тэдний дутагдалтай тал дээр анхаарлаа төвлөрүүлж, ерөнхийдөө гуалинтай холбоотой нөхцөл байдлын талаархи дэлхий нийтийн дүгнэлтэд анхаарлаа хандуулах болно.
K8-д бүртгэлтэй дадлага хий
“Өдөр тутмын бүртгэлүүд”, та нарын хэд нь байна вэ?..
Нэлээд том хэмжээний дэд бүтцээс бүртгэлийг төвлөрсөн цуглуулах нь лог цуглуулах, хадгалах, боловсруулахад ихээхэн хэмжээний нөөц шаарддаг. Төрөл бүрийн төслүүдийг хэрэгжүүлэх явцад бид янз бүрийн шаардлага, тэдгээрээс үүссэн үйл ажиллагааны бэрхшээлтэй тулгарсан.
ClickHouse-г туршиж үзье
Логуудыг нэлээд идэвхтэй үүсгэдэг програмтай төсөл дээрх төвлөрсөн хадгалалтыг харцгаая: секундэд 5000 гаруй мөр. ClickHouse-д нэмж, түүний бүртгэлүүдтэй ажиллаж эхэлцгээе.
Хамгийн их бодит цаг шаардлагатай бол ClickHouse бүхий 4 цөмт сервер дискний дэд системд аль хэдийн хэт ачаалалтай байх болно.
Энэ төрлийн ачаалал нь бид ClickHouse дээр аль болох хурдан бичихийг хичээж байгаатай холбоотой юм. Мэдээллийн сан нь дискний ачаалал ихэссэнээр хариу үйлдэл үзүүлдэг бөгөөд энэ нь дараахь алдааг үүсгэж болзошгүй юм.
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Цэг байна ClickHouse-д (тэдгээр нь бүртгэлийн өгөгдлийг агуулдаг) бичих үйл ажиллагааны явцад өөрийн гэсэн бэрхшээлтэй байдаг. Тэдгээрт оруулсан өгөгдөл нь түр зуурын хуваалтыг үүсгэдэг бөгөөд дараа нь үндсэн хүснэгттэй нэгтгэгддэг. Үүний үр дүнд бичлэг нь дискэн дээр маш их шаардагддаг бөгөөд энэ нь дээр дурдсан мэдэгдлийн хязгаарлалтад хамаарна: 1 секундын дотор 300-аас илүүгүй дэд хуваалтыг нэгтгэх боломжгүй (үнэндээ энэ нь 300 оруулга юм. секундэд).
Энэ зан үйлээс зайлсхийхийн тулд аль болох том хэсгүүдэд, 1 секунд тутамд 2-ээс илүүгүй удаа. Гэсэн хэдий ч том үсгээр бичих нь бид ClickHouse-д цөөн бичихийг санал болгож байна. Энэ нь эргээд буфер халих, бүртгэлийг алдахад хүргэдэг. Үүний шийдэл нь Fluentd буферийг нэмэгдүүлэх боловч дараа нь санах ойн хэрэглээ нэмэгдэх болно.
тайлбар: ClickHouse-тай хийсэн бидний шийдлийн өөр нэг асуудал бол манай тохиолдолд (логоны байшин) хуваалт нь холбогдсон гадаад хүснэгтүүдээр хэрэгждэгтэй холбоотой байв. . Энэ нь том хугацааны интервалыг түүвэрлэхдээ хэт их RAM шаардагддаг, учир нь мета хүснэгт нь бүх хуваалтуудаар дамждаг, тэр ч байтугай шаардлагатай өгөгдлийг агуулаагүй ч гэсэн. Гэсэн хэдий ч одоо энэ хандлагыг ClickHouse-ийн одоогийн хувилбаруудад аюулгүйгээр хуучирсан гэж зарлаж болно (c ).
Үүний үр дүнд төсөл бүр ClickHouse-д лог цуглуулах хангалттай нөөцтэй байдаггүй нь тодорхой болсон (илүү нарийвчлалтай, тэдгээрийн хуваарилалт нь тохиромжгүй болно). Үүнээс гадна та ашиглах хэрэгтэй болно зай, бид дараа нь буцаж ирэх болно. Дээр дурдсан хэрэг бодитой. Тухайн үед бид үйлчлүүлэгчдэд тохирсон найдвартай, тогтвортой шийдлийг санал болгож чадаагүй бөгөөд хамгийн бага сааталтай гуалин цуглуулах боломжийг бидэнд олгодог ...
Elasticsearch-ийн талаар юу хэлэх вэ?
Elasticsearch нь ажлын ачаалал ихтэй байдаг. Үүнийг ижил төсөл дээр туршиж үзье. Одоо ачаалал дараах байдалтай байна.
Elasticsearch өгөгдлийн урсгалыг шингээж чаддаг байсан ч түүнд ийм хэмжээ бичих нь CPU-г их хэмжээгээр ашигладаг. Үүнийг кластер зохион байгуулах замаар шийддэг. Техникийн хувьд энэ нь асуудал биш, гэхдээ зүгээр л лог цуглуулах системийг ажиллуулахын тулд бид аль хэдийн 8 цөмийг ашигладаг бөгөөд системд нэмэлт ачаалал ихтэй бүрэлдэхүүн хэсэг байдаг ...
Доод шугам: Энэ сонголтыг зөвтгөж болох боловч төсөл нь том бөгөөд удирдлага нь төвлөрсөн мод бэлтгэлийн системд ихээхэн хэмжээний нөөцийг зарцуулахад бэлэн байгаа тохиолдолд л болно.
Дараа нь байгалийн асуулт гарч ирнэ:
Ямар бүртгэлүүд үнэхээр хэрэгтэй вэ?
Арга барилаа өөрөө өөрчлөхийг хичээцгээе: бүртгэлүүд нь нэгэн зэрэг мэдээлэлтэй байх ёстой бөгөөд хамрах ёсгүй Бүгд систем дэх үйл явдал.
Бид амжилттай онлайн дэлгүүртэй боллоо гэж бодъё. Ямар бүртгэл чухал вэ? Жишээлбэл, төлбөрийн гарцаас аль болох их мэдээлэл цуглуулах нь маш сайн санаа юм. Гэхдээ бүтээгдэхүүний каталог дахь зураг зүсэх үйлчилгээний бүх бүртгэлүүд бидний хувьд чухал биш: зөвхөн алдаа, дэвшилтэт хяналт хангалттай байдаг (жишээлбэл, энэ бүрэлдэхүүн хэсгийн үүсгэсэн 500 алдааны хувь).
Тиймээс бид ийм дүгнэлтэд хүрсэн төвлөрсөн мод бэлтгэх нь үргэлж зөвтгөгддөггүй. Үйлчлүүлэгч ихэвчлэн бүх бүртгэлийг нэг дор цуглуулахыг хүсдэг ч үнэндээ бүх бүртгэлээс бизнест чухал ач холбогдолтой мессежүүдийн зөвхөн 5% нь л шаардлагатай байдаг.
- Заримдаа зөвхөн савны бүртгэлийн хэмжээ болон алдаа цуглуулагчийг (жишээ нь, Sentry) тохируулахад хангалттай.
- Алдааны мэдэгдэл болон орон нутгийн том бүртгэл нь ихэвчлэн тохиолдлуудыг судлахад хангалттай байж болно.
- Бидэнд зөвхөн функциональ туршилтууд болон алдаа цуглуулах системүүдээр хийгдсэн төслүүд байсан. Хөгжүүлэгчид лог шаардлагагүй байсан - тэд алдааны ул мөрөөс эхлээд бүгдийг харсан.
Амьдралаас авсан зураг
Өөр нэг түүх бол сайн жишээ болж чадна. Бид Kubernetes-ийг нэвтрүүлэхээс өмнө боловсруулсан арилжааны шийдлийг аль хэдийн ашиглаж байсан үйлчлүүлэгчдийнхээ аюулгүй байдлын багаас хүсэлт хүлээн авсан.
Байгууллагын асуудал илрүүлэх мэдрэгч - QRadar бүхий бүртгэл цуглуулах төвлөрсөн системтэй "найз болох" шаардлагатай байв. Энэ систем нь syslog протоколоор дамжуулан бүртгэлийг хүлээн авч, FTP-ээс татаж авах боломжтой. Гэсэн хэдий ч үүнийг fluentd-д зориулсан remote_syslog залгаастай шууд нэгтгэх боломжгүй байсан (мэдэгдэж байгаагаар, ). QRadar-ыг тохируулахтай холбоотой асуудал нь үйлчлүүлэгчийн хамгаалалтын багийн талд байсан.
Үүний үр дүнд бизнесийн чухал бүртгэлүүдийн нэг хэсгийг FTP QRadar-д байршуулж, нөгөө хэсгийг нь алсын системээр дамжуулан зангилаанаас шууд чиглүүлэв. Үүний тулд бид бүр бичсэн - магадгүй энэ нь хэн нэгэнд үүнтэй төстэй асуудлыг шийдвэрлэхэд туслах болно ... Үүссэн схемийн ачаар үйлчлүүлэгч өөрөө чухал бүртгэлүүдийг хүлээн авч, дүн шинжилгээ хийсэн (дуртай хэрэгслээр нь) ба бид мод бэлтгэх системийн зардлыг бууруулж, зөвхөн модыг хэмнэж чадсан. өнгөрсөн сар.
Өөр нэг жишээ бол юу хийх ёсгүйг маш сайн харуулж байна. Боловсруулах манай үйлчлүүлэгчдийн нэг тус бүрээс Хэрэглэгчээс ирж буй үйл явдлууд, олон шугам хийсэн бүтэцгүй гаралт бүртгэл дэх мэдээлэл. Таны таамаглаж байгаагаар ийм лог нь унших, хадгалахад туйлын тохиромжгүй байсан.
Бүртгэлийн шалгуур
Ийм жишээнүүд нь лог цуглуулах системийг сонгохоос гадна танд хэрэгтэй гэсэн дүгнэлтэд хүргэдэг мөн логуудыг өөрсдөө зохион бүтээдэг! Энд ямар шаардлага тавигдаж байна вэ?
- Бүртгэл нь машинд уншигдахуйц форматтай байх ёстой (жишээ нь, JSON).
- Бүртгэлүүд нь авсаархан байх ёстой бөгөөд гарч болзошгүй асуудлуудыг дибаг хийх зорилгоор бүртгэлийн түвшинг өөрчлөх чадвартай байх ёстой. Үүний зэрэгцээ үйлдвэрлэлийн орчинд та бүртгэлийн түвшний системүүдийг ажиллуулах хэрэгтэй Сануулга буюу Алдаа.
- Бүртгэлийг хэвийн болгох ёстой, өөрөөр хэлбэл бүртгэлийн объектод бүх мөр нь ижил төрлийн талбартай байх ёстой.
Бүтэцгүй бүртгэлүүд нь бүртгэлийг хадгалах сан руу ачаалах, боловсруулалтыг бүрэн зогсооход асуудал үүсгэдэг. Үүний жишээ болгон 400 алдаатай жишээг энд оруулав, үүнд олон хүн fluentd лог дээр тулгарч байсан:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Алдаа нь төрөл нь тогтворгүй талбарыг бэлэн зураглалын хамт индекс рүү илгээж байна гэсэн үг. Хамгийн энгийн жишээ бол nginx лог дахь хувьсагчтай талбар юм $upstream_status. Энэ нь тоо эсвэл мөр агуулсан байж болно. Жишээлбэл:
{ "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"}
Бүртгэлээс харахад сервер 10.100.0.10 нь 404 алдаатай хариу өгсөн бөгөөд хүсэлтийг өөр контентын сан руу илгээсэн байна. Үүний үр дүнд лог дахь утга дараах байдалтай болсон.
"upstream_response_time": "0.001, 0.007"
Энэ нөхцөл байдал маш түгээмэл тул тусдаа байх ёстой .
Найдвартай байдлын талаар юу хэлэх вэ?
Үл хамаарах зүйлгүй бүх бүртгэлүүд амин чухал байх үе байдаг. Үүнтэй холбогдуулан дээр санал болгосон/хэлэлцсэн K8-д зориулсан лог цуглуулах ердийн схемд асуудал гардаг.
Жишээлбэл, fluentd нь богино хугацааны савнаас лог цуглуулж чадахгүй. Манай төслүүдийн нэгэнд өгөгдлийн сангийн шилжилтийн контейнер 4 секундээс бага хугацаанд ажиллаж, дараа нь устгагдсан - холбогдох тайлбарын дагуу:
"helm.sh/hook-delete-policy": hook-succeeded
Үүнээс болж шилжүүлгийн гүйцэтгэлийн бүртгэлийг хадгалах санд оруулаагүй болно. Энэ тохиолдолд улс төр тусалж чадна. before-hook-creation.
Өөр нэг жишээ бол Docker log rotation юм. Лог руу идэвхтэй бичдэг програм байгаа гэж бодъё. Хэвийн нөхцөлд бид бүх бүртгэлийг боловсруулж чаддаг боловч асуудал гармагц - жишээлбэл, буруу форматтай дээр дурдсанчлан - боловсруулалт зогсч, Docker файлыг эргүүлдэг. Үүний үр дүнд бизнесийн чухал бүртгэлүүд алдагдах магадлалтай.
Тийм учраас л лог урсгалыг салгах нь чухал юм, аюулгүй байдлыг хангах үүднээс хамгийн үнэ цэнтэйг нь шууд програм руу илгээх. Үүнээс гадна, заримыг бий болгох нь илүүц байх болно бүртгэлийн "аккумлятор", энэ нь чухал мессежийг хадгалахын зэрэгцээ санах ойн санах ойн богино хугацааны боломжгүй үед тэсвэрлэх чадвартай.
Эцэст нь бид үүнийг мартаж болохгүй Аливаа дэд системийг зөв хянах нь чухал юм. Үгүй бол чөлөөтэй ярьдаг нөхцөл байдалд ороход амархан байдаг CrashLoopBackOff юу ч илгээдэггүй бөгөөд энэ нь чухал мэдээлэл алдагдахыг амлаж байна.
үр дүн нь
Энэ нийтлэлд бид Datadog шиг SaaS шийдлүүдийг авч үзэхгүй. Энд дурдсан олон асуудлыг лог цуглуулах чиглэлээр мэргэшсэн арилжааны компаниуд аль хэдийн аль хэдийн шийдвэрлэсэн боловч хүн бүр янз бүрийн шалтгааны улмаас SaaS ашиглаж чадахгүй. (Үндсэн нь зардал, 152-FZ-д нийцсэн байдал).
Төвлөрсөн бүртгэл цуглуулах нь эхлээд энгийн ажил мэт харагддаг боловч огт тийм биш юм. Үүнийг санах нь чухал:
- Зөвхөн чухал бүрэлдэхүүн хэсгүүдийг нарийвчлан бүртгэх шаардлагатай байдаг бол хяналт, алдаа цуглуулалтыг бусад системд тохируулж болно.
- Шаардлагагүй ачааллыг нэмэхгүйн тулд үйлдвэрлэлийн бүртгэлийг хамгийн бага байлгах хэрэгтэй.
- Бүртгэл нь машинд уншигдахуйц, хэвийн, хатуу форматтай байх ёстой.
- Үнэхээр чухал логуудыг тусдаа урсгалаар илгээх ёстой бөгөөд үүнийг үндсэн хэсгээс тусгаарлах ёстой.
- Өндөр ачааллын тэсрэлтээс аварч, агуулах дээрх ачааллыг илүү жигд болгодог лог аккумляторыг анхаарч үзэх нь зүйтэй.
Эдгээр энгийн дүрмийг хаа сайгүй дагаж мөрдвөл дээр дурдсан хэлхээнүүд нь чухал бүрэлдэхүүн хэсгүүд (батарей) байхгүй байсан ч ажиллах боломжийг олгоно. Хэрэв та ийм зарчмуудыг дагаж мөрддөггүй бол даалгавар нь таныг болон дэд бүтцийг системийн өөр нэг өндөр ачаалалтай (мөн нэгэн зэрэг үр дүнгүй) бүрэлдэхүүн хэсэг рүү хөтөлнө.
PS
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «".
Эх сурвалж: www.habr.com