Бұл 2019 жыл және бізде әлі күнге дейін Kubernetes жүйесінде журналдарды біріктіруге арналған стандартты шешім жоқ. Бұл мақалада біз нақты тәжірибеден алынған мысалдарды пайдалана отырып, ізденістермен, кездесетін мәселелермен және олардың шешімдерімен бөліскіміз келеді.
Дегенмен, біріншіден, журналдарды жинау арқылы әртүрлі тұтынушылардың әртүрлі нәрселерді түсінетінін ескертемін:
- біреу қауіпсіздік және аудит журналдарын көргісі келеді;
- біреу – бүкіл инфрақұрылымның орталықтандырылған каротажы;
- ал кейбіреулер үшін, мысалы, балансерлерді қоспағанда, тек қолданба журналдарын жинау жеткілікті.
Төменде біз әртүрлі «тілектер тізімдерін» қалай жүзеге асырғанымыз және қандай қиындықтарға тап болғанымыз туралы қысқаша мәлімет берілген.
Теория: каротаж құралдары туралы
Каротаж жүйесінің құрамдас бөліктері туралы түсінік
Ағаш кесу ұзақ жолдан өтті, соның нәтижесінде журналдарды жинау және талдау әдістемелері әзірленді, оны біз бүгін қолданамыз. 1950 жылдары Фортран стандартты енгізу/шығару ағындарының аналогын енгізді, бұл бағдарламашыға өз бағдарламасын жөндеуге көмектесті. Бұл сол кездегі бағдарламашылардың өмірін жеңілдеткен алғашқы компьютерлік журналдар болды. Бүгін біз олардан каротаж жүйесінің бірінші құрамдас бөлігін көреміз - журналдардың көзі немесе «өндіруші»..
Информатика бір орында тұрған жоқ: компьютерлік желілер пайда болды, алғашқы кластерлер... Бірнеше компьютерден тұратын күрделі жүйелер жұмыс істей бастады. Енді жүйелік әкімшілер журналдарды бірнеше машиналардан жинауға мәжбүр болды және ерекше жағдайларда олар жүйенің ақаулығын тексеру қажет болған жағдайда ОЖ ядросының хабарламаларын қоса алады. Орталықтандырылған журналдарды жинау жүйелерін сипаттау үшін 2000 жылдардың басында ол жарияланды , ол remote_syslog стандартты. Тағы бір маңызды компонент осылай пайда болды: журнал жинағыш және оларды сақтау.
Журналдар көлемінің ұлғаюымен және веб-технологиялардың кеңінен енгізілуімен пайдаланушыларға қандай журналдарды ыңғайлы түрде көрсету керек деген сұрақ туындады. Қарапайым консоль құралдары (awk/sed/grep) жетілдірілген құралдармен ауыстырылды көрушілер журналы - үшінші компонент.
Бөренелердің көлемінің ұлғаюына байланысты тағы бір нәрсе анық болды: журналдар қажет, бірақ олардың барлығы емес. Және әртүрлі журналдар әртүрлі деңгейде сақтауды талап етеді: кейбіреулері бір күнде жоғалуы мүмкін, ал басқалары 5 жыл бойы сақталуы керек. Сонымен, тіркеу жүйесіне деректер ағындарын сүзуге және бағыттауға арналған компонент қосылды - оны шақырайық сүзгі.
Сақтау да үлкен секіріс жасады: кәдімгі файлдардан реляциялық дерекқорларға, содан кейін құжатқа бағытталған жадқа (мысалы, Elasticsearch). Осылайша қойма коллектордан бөлінген.
Сайып келгенде, журнал ұғымының өзі тарих үшін сақтап қалғымыз келетін оқиғалардың дерексіз ағынына дейін кеңейді. Дәлірек айтқанда, тергеу жүргізу немесе аналитикалық есеп беру қажет болған жағдайда...
Нәтижесінде, салыстырмалы түрде қысқа уақыт ішінде журналдар жинағы үлкен деректердегі кіші бөлімдердің бірі деп атауға болатын маңызды ішкі жүйеге айналды.
Егер бір кездері кәдімгі баспалар «каротаж жүйесі» үшін жеткілікті болса, қазір жағдай айтарлықтай өзгерді.
Кубернеттер және журналдар
Кубернетес инфрақұрылымға келгенде, бұрыннан бар журналдарды жинау мәселесі де оны айналып өтпеді. Кейбір жолдармен бұл одан да ауыр болды: инфрақұрылымдық платформаны басқару оңайлатылып қана қоймай, сонымен қатар күрделі болды. Көптеген ескі қызметтер микросервистерге көшуді бастады. Журналдар контекстінде бұл журнал көздерінің көбеюінен, олардың ерекше өмірлік циклінен және журналдар арқылы барлық жүйе құрамдастарының қарым-қатынастарын қадағалау қажеттілігінен көрінеді...
Болашаққа қарап, мен қазір, өкінішке орай, Кубернетес үшін басқалармен жақсы салыстырылатын стандартталған тіркеу нұсқасы жоқ екенін айта аламын. Қоғамда ең танымал схемалар келесідей:
- біреу стекті ашады EFK (Elasticsearch, Fluentd, Kibana);
- біреу жақында шығарылғанды сынап жатыр немесе пайдаланады ;
- нас (және біз ғана емес шығар?..) Мен өзімнің дамуыма қанағаттанамын - ...
Әдетте, біз 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-пен шешіміміздің тағы бір проблемалық аспектісі біздің жағдайда (loghouse) бөлу қосылған сыртқы кестелер арқылы жүзеге асырылатынына байланысты болды. . Бұл үлкен уақыт интервалдарын іріктеу кезінде шамадан тыс жедел жадты қажет етеді, өйткені мета кесте барлық бөлімдер арқылы қайталанады - тіпті қажетті деректерді анық қамтымайтындар. Дегенмен, енді бұл тәсілді ClickHouse-тың ағымдағы нұсқалары үшін ескірген деп жариялауға болады (c ).
Нәтижесінде, ClickHouse-та нақты уақыт режимінде журналдарды жинау үшін әрбір жобада жеткілікті ресурстар жоқ екені белгілі болады (дәлірек айтқанда, оларды тарату орынды болмайды). Бұған қоса, сіз пайдалануыңыз керек аккумулятор, оған кейінірек ораламыз. Жоғарыда сипатталған жағдай шынайы. Сол кезде біз тұтынушыға сәйкес келетін және аз кідіріспен журналдарды жинауға мүмкіндік беретін сенімді және тұрақты шешім ұсына алмадық...
Elasticsearch туралы не деуге болады?
Elasticsearch ауыр жұмыс жүктемелерін өңдейтіні белгілі. Сол жобада қолданып көрейік. Енді жүктеме келесідей көрінеді:
Elasticsearch деректер ағынын қорыта алды, дегенмен оған мұндай көлемдерді жазу процессорды көп пайдаланады. Бұл кластерді ұйымдастыру арқылы шешіледі. Техникалық тұрғыдан алғанда, бұл проблема емес, бірақ журналдарды жинау жүйесін пайдалану үшін біз шамамен 8 ядроны қолданамыз және жүйеде қосымша жоғары жүктелген компонент бар...
Қорытынды: бұл опцияны негіздеуге болады, бірақ егер жоба үлкен болса және оның басшылығы орталықтандырылған тіркеу жүйесіне айтарлықтай ресурстарды жұмсауға дайын болса ғана.
Сонда табиғи сұрақ туындайды:
Қандай журналдар шынымен қажет?
Тәсілдің өзін өзгертуге тырысайық: журналдар бір уақытта ақпараттық болуы керек және жабылмауы керек әрқайсысы жүйедегі оқиға.
Бізде сәтті интернет-дүкен бар делік. Қандай журналдар маңызды? Мүмкіндігінше көбірек ақпарат жинау, мысалы, төлем шлюзінен - тамаша идея. Бірақ өнім каталогындағы кескінді кесу қызметінің барлық журналдары біз үшін маңызды емес: тек қателер мен кеңейтілген бақылау жеткілікті (мысалы, осы құрамдас тудыратын 500 қатенің пайызы).
Осылайша біз мынадай қорытындыға келдік орталықтандырылған ағаш кесу әрқашан ақтала бермейді. Көбінесе клиент барлық журналдарды бір жерде жинағысы келеді, дегенмен іс жүзінде бүкіл журналдан бизнес үшін маңызды хабарлардың шартты 5% ғана қажет:
- Кейде конфигурациялау жеткілікті, айталық, тек контейнер журналының өлшемін және қате жинағышты (мысалы, Sentry).
- Қате туралы хабарландыру және үлкен жергілікті журналдың өзі оқиғаларды зерттеу үшін жиі жеткілікті болуы мүмкін.
- Бізде тек қана функционалды сынақтар мен қателерді жинау жүйелерімен айналысатын жобалар болды. Әзірлеушіге журналдар қажет болмады - олар қате іздерінен бастап бәрін көрді.
Өмірден алынған иллюстрация
Тағы бір оқиға жақсы мысал бола алады. Біз Kubernetes енгізілмес бұрын жасалған коммерциялық шешімді пайдаланып жүрген клиенттеріміздің бірінің қауіпсіздік тобынан сұрау алдық.
Корпоративтік ақауларды анықтау сенсоры - QRadar көмегімен журналдарды жинаудың орталықтандырылған жүйесімен «дос табу» қажет болды. Бұл жүйе журналдарды syslog протоколы арқылы қабылдай алады және оларды FTP жүйесінен шығарып алады. Дегенмен, оны fluentd үшін remote_syslog плагинімен біріктіру бірден мүмкін болмады (анықталғандай, ). QRadar орнатуға қатысты мәселелер клиенттің қауіпсіздік командасының жағында болып шықты.
Нәтижесінде бизнес үшін маңызды журналдардың бір бөлігі FTP QRadar-қа жүктелді, ал басқа бөлігі қашықтағы жүйе арқылы тікелей түйіндерден қайта бағытталды. Бұл үшін біз тіпті жаздық - бәлкім, бұл біреуге ұқсас мәселені шешуге көмектесетін шығар... Алынған схеманың арқасында клиенттің өзі сыни журналдарды алды және талдады (өзінің сүйікті құралдарын пайдалана отырып), біз журналды тіркеу жүйесінің құнын төмендете алдық, тек өткен айда.
Тағы бір мысал не істеуге болмайтынын көрсетеді. Өңдеу үшін біздің клиенттеріміздің бірі әрқайсысының пайдаланушыдан келетін оқиғалар, көп жолды құрады құрылымсыз өнім журналдағы ақпарат. Сіз болжағандай, мұндай журналдар оқуға да, сақтауға да ыңғайсыз болды.
Журналға арналған критерийлер
Мұндай мысалдар журналдарды жинау жүйесін таңдаудан басқа, сізге қажет деген қорытындыға әкеледі сонымен қатар журналдарды өздері жобалайды! Мұнда қандай талаптар қойылады?
- Журналдар машина оқылатын пішімде болуы керек (мысалы, JSON).
- Журналдар ықшам болуы керек және ықтимал ақаулықтарды жою үшін журналға жазу дәрежесін өзгерту мүмкіндігі бар. Сонымен қатар, өндірістік орталарда журналға жазу деңгейі сияқты жүйелерді іске қосу керек ескерту немесе қателік.
- Журналдар қалыпқа келтірілуі керек, яғни журнал нысанында барлық жолдар бірдей өріс түріне ие болуы керек.
Құрылымы жоқ журналдар журналдарды қоймаға жүктеу және оларды өңдеуді толық тоқтату мәселелеріне әкелуі мүмкін. Мысал ретінде мұнда 400 қатесі бар мысал келтірілген, ол көптеген адамдар еркін журналдарда кездескен:
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 журналының айналуы. Журналдарға белсенді түрде жазатын қолданба бар делік. Қалыпты жағдайда біз барлық журналдарды өңдей аламыз, бірақ мәселе пайда болған кезде – мысалы, жоғарыда дұрыс емес пішіммен сипатталғандай – өңдеу тоқтатылады және Docker файлды айналдырады. Нәтижесінде бизнес үшін маңызды журналдар жоғалуы мүмкін.
Міне, сондықтан журнал ағындарын бөлу маңызды, олардың қауіпсіздігін қамтамасыз ету үшін ең құндыларын тікелей қолданбаға жіберу. Оған қоса, кейбірін жасау артық болмас еді журналдардың «аккумуляторы»., ол маңызды хабарларды сақтау кезінде қысқа жадтың қолжетімсіздігіне төтеп бере алады.
Ақырында, біз мұны ұмытпауымыз керек Кез келген ішкі жүйені дұрыс бақылау маңызды. Әйтпесе, еркін сөйлейтін жағдайға тап болу оңай CrashLoopBackOff және ештеңе жібермейді және бұл маңызды ақпаратты жоғалтуды уәде етеді.
қорытындылар
Бұл мақалада біз Datadog сияқты SaaS шешімдерін қарастырмаймыз. Мұнда сипатталған көптеген проблемаларды журналдарды жинауға маманданған коммерциялық компаниялар бір жолмен шешіп қойған, бірақ әркім әртүрлі себептермен SaaS пайдалана алмайды. (негізгілері - құны және 152-ФЗ сәйкестігі).
Орталықтандырылған журнал жинау бастапқыда қарапайым тапсырма сияқты көрінеді, бірақ ол мүлде емес. Мынаны есте сақтау маңызды:
- Тек маңызды құрамдастарды егжей-тегжейлі тіркеу керек, ал бақылау және қателерді жинау басқа жүйелер үшін конфигурациялануы мүмкін.
- Өндірістегі журналдар қажетсіз жүктемені қоспау үшін минималды болуы керек.
- Журналдар машинада оқылатын, нормаланған және қатаң пішімге ие болуы керек.
- Шын мәнінде сыни журналдар негізгілерден бөлінуі керек бөлек ағынмен жіберілуі керек.
- Бөрене аккумуляторын қарастырған жөн, ол сізді жоғары жүктеменің жарылуынан құтқарып, қоймадағы жүктемені біркелкі етеді.
Бұл қарапайым ережелер, егер барлық жерде қолданылса, жоғарыда сипатталған схемалардың жұмыс істеуіне мүмкіндік береді - тіпті оларда маңызды компоненттер (батарея) жоқ болса да. Егер сіз мұндай принциптерді ұстанбасаңыз, тапсырма сізді және инфрақұрылымды жүйенің басқа жоғары жүктелген (және сонымен бірге тиімсіз) құрамдас бөлігіне оңай әкеледі.
PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com