Журналдар жүйенің маңызды бөлігі болып табылады, ол күткендей жұмыс істеп тұрғанын (немесе жұмыс істемейтінін) түсінуге мүмкіндік береді. Микросервис архитектурасында журналдармен жұмыс арнайы олимпиадаға арналған жеке пәнге айналады. Бірден бірнеше сұрақтарды шешу керек:
- қолданбадан журналдарды қалай жазу керек;
- журналдарды қайда жазу керек;
- журналдарды сақтауға және өңдеуге қалай жеткізу керек;
- журналдарды өңдеу және сақтау жолы.
Қазіргі уақытта танымал контейнерлік технологияларды пайдалану мәселені шешу нұсқаларының өрісіне тырманың үстіне құм қосады.
Юрий Бушмелевтің «Бөренелерді жинау және жеткізу саласындағы тырмалардың картасы» баяндамасының стенограммасы дәл осы туралы.
Кімге бәрібір, мысықтың астында өтінемін.
Менің атым Юрий Бушмелев. Мен Лазада жұмыс істеймін. Бүгін мен журналдарымызды қалай жасағанымыз, оларды қалай жинағанымыз және онда не жазатынымыз туралы айтатын боламын.
Біз қайданбыз? Біз кімбіз? Lazada - Оңтүстік-Шығыс Азиядағы алты елдегі №1 онлайн сатушы. Бұл елдердің барлығы біздің деректер орталықтары арасында бөлінген. Қазіргі уақытта барлығы 4 дата орталығы бар.Бұл неліктен маңызды? Өйткені кейбір шешімдер орталықтар арасындағы байланыстың өте әлсіз болуына байланысты болды. Бізде микросервис архитектурасы бар. Бізде қазірдің өзінде 80 микросервис бар екеніне таң қалдым. Тапсырманы журналдармен бастаған кезде олардың тек 20-сы ғана болды, сонымен қатар PHP мұрасының өте үлкен бөлігі бар, мен де онымен өмір сүріп, төтеп беруім керек. Осының барлығы қазіргі уақытта тұтастай алғанда жүйе үшін минутына 6 миллионнан астам хабарлама жасайды. Келесіде мен мұнымен қалай өмір сүруге тырысатынымызды және неге бұлай екенін көрсетемін.
Сіз осы 6 миллион хабарламамен өмір сүруіңіз керек. Олармен не істеуіміз керек? Сізге қажет 6 миллион хабарлама:
- қолданбадан жіберу
- жеткізуге қабылдайды
- талдау және сақтау үшін жеткізу.
- талдау жасау
- оны қандай да бір жолмен сақтаңыз.
Үш миллион хабарлама пайда болғанда, мен бірдей болдым. Өйткені біз аз ғана тиынға кірістік. Онда қолданбалар журналдары жазылғаны анық. Мысалы, мен дерекқорға қосыла алмадым, дерекқорға қосыла алдым, бірақ ештеңе оқи алмадым. Сонымен қатар, біздің әрбір микросервисіміз кіру журналын жазады. Микросервиске келген әрбір сұрау журналға жазылады. Неге біз мұны істеп жатырмыз? Әзірлеушілер қадағалай алғылары келеді. Әрбір кіру журналында арнайы интерфейс бүкіл тізбекті босатып, ізді әдемі көрсетеді. Бақылау сұраудың қалай өткенін көрсетеді және бұл біздің әзірлеушілерге кез келген анықталмаған қоқыспен жылдам күресуге көмектеседі.
Мұнымен қалай өмір сүруге болады? Енді мен опциялар өрісін қысқаша сипаттаймын - бұл мәселе жалпы алғанда қалай шешіледі. Журналдарды жинау, беру және сақтау мәселесін қалай шешуге болады.
Өтініштен қалай жазуға болады? Түрлі жолдар бар екені анық. Атап айтқанда, сәнді жолдастарымыз айтқандай, озық тәжірибе бар. Аталарымыз айтқандай ескі мектептің екі түрі бар. Басқа жолдар бар.
Бөренелерді жинау жағдайы шамамен бірдей. Бұл нақты бөлікті шешудің көптеген нұсқалары жоқ. Олардың саны қазірдің өзінде көп, бірақ әлі көп емес.
Бірақ жеткізу және кейінгі талдау арқылы вариациялар саны жарылып кете бастайды. Мен қазір әрбір нұсқаны сипаттамаймын. Негізгі нұсқалар тақырыпқа қызығушылық танытатындардың барлығына жақсы таныс деп ойлаймын.
Мен мұны Лазадада қалай жасағанымызды және барлығы қалай басталғанын көрсетемін.
Бір жыл бұрын мен Лазадаға келдім және бөренелер туралы жобаға жіберілдім. Мынадай нәрсе болды. Қолданбалар журналы stdout және stderr үшін жазылған. Барлығы сәнді түрде жасалды. Бірақ содан кейін әзірлеушілер оны стандартты ағындардан лақтырып тастады, содан кейін инфрақұрылым мамандары оны қалай болғанда да анықтайды. Инфрақұрылым мамандары мен әзірлеушілер арасында: «Ух... жарайды, оларды қабықшасы бар файлға орап алайық, болды» деген шығарушылар да бар. Мұның бәрі контейнерде болғандықтан, оны контейнердің өзіне орап, ішіне каталогты картаға түсіріп, сол жерге қойды. Менің ойымша, бұл барлығына түсінікті болды.
Әзірге сәл әрі қарай қарастырайық. Біз бұл журналдарды қалай жеткіздік? Біреу td-агентті таңдады, ол шын мәнінде еркін сөйлейді, бірақ өте еркін емес. Мен бұл екі жобаның арасындағы қарым-қатынасты әлі түсінбеймін, бірақ олар бірдей нәрсе сияқты. Және бұл Ruby тілінде жазылған, журнал файлдарын оқиды, оларды JSON-ға қандай да бір жүйелілік арқылы талдады. Содан кейін мен оларды Кафкаға жібердім. Сонымен қатар, Кафкада бізде әр API үшін 4 бөлек тақырып болды. Неліктен 4? Себебі тікелей эфир бар, қойылым бар, және stdout және stderr болғандықтан. Әзірлеушілер оларды жасайды, ал инфрақұрылымды әзірлеушілер оларды Кафкада жасауы керек. Оның үстіне Кафканы басқа департамент басқарды. Сондықтан олар әр api үшін 4 тақырып жасайтындай билет жасау керек болды. Оны бәрі ұмытты. Жалпы, қоқыс пен әбігер болды.
Бұдан әрі біз мұнымен не істедік? Біз оны Кафкаға жібердік. Содан кейін Кафкадан алынған бөренелердің жартысы Логсташқа ұшып кетті. Бөренелердің қалған жартысы бөлінді. Кейбіреулер бір Грейлогқа, кейбірі басқа Грейлогқа ұшып кетті. Нәтижесінде мұның бәрі бір Elasticsearch кластеріне кірді. Яғни, бұл тәртіпсіздіктің бәрі сонда аяқталды. Бұлай істеме!
Жоғарыдан қарасаңыз, осылай көрінеді. Бұлай істеме! Мұнда проблемалық аймақтар бірден сандармен белгіленеді. Іс жүзінде олардың саны көп, бірақ 6-уы шынымен проблемалы, олар туралы бірдеңе істеу керек. Мен қазір олар туралы бөлек айтып беремін.
Мұнда (1,2,3) файлдарды жазамыз және сәйкесінше мұнда бірден үш тырма бар.
Бірінші (1) - біз оларды бір жерде жазуымыз керек. API-ге файлға тікелей жазу мүмкіндігін беру әрқашан қажет емес. API контейнерде оқшауланғаны немесе одан да жақсырақ, тек оқуға арналған болғаны жөн. Мен жүйелік әкімшімін, сондықтан менде бұл нәрселерге балама көзқарасым бар.
Екінші тармақ (2,3) - API-ге көптеген сұраныстар келіп түседі. API файлға көп деректерді жазады. Файлдар өсіп жатыр. Біз оларды айналдыруымыз керек. Өйткені, әйтпесе ол жерде ешбір дискіге жинақтай алмайсыз. Оларды айналдыру нашар, себебі олар қабық арқылы каталогқа қайта бағыттау арқылы жасалады. Біз оны қайта қарауға мүмкіндік жоқ. Қолданбаға тұтқаларды қайта ашуды айта алмайсыз. Өйткені әзірлеушілер сізге ақымақ сияқты қарайды: «Қандай дескрипторлар? Біз әдетте stdout-қа жазамыз ». Инфрақұрылым әзірлеушілері файлдың көшірмесін жасап, түпнұсқаны транскрипциялайтын logrotate үшін copytruncate жасады. Тиісінше, осы көшіру процестері арасында әдетте дискілік кеңістік таусылады.
(4) Бізде әртүрлі API интерфейстерінде әртүрлі пішімдер болды. Олар сәл өзгеше болды, бірақ regexp басқаша жазылуы керек еді. Мұның бәрін Қуыршақ басқарғандықтан, өз тарақандары бар көптеген сыныптар болды. Сонымен қатар, td-агент көбіне жадты жеп, ақымақ бола алады, ол жұмыс істеп тұрғандай кейіп танытып, ештеңе істемейді. Сырттай қарағанда оның ештеңе істеп жатқанын түсіну мүмкін емес еді. Ең дұрысы, ол құлап қалады, оны кейінірек біреу көтеріп алады. Дәлірек айтқанда, дабыл келіп, біреу барып қолымен көтереді.
(6) Ең қоқыс пен қалдық elasticsearch болды. Өйткені ол ескі нұсқа болатын. Өйткені бізде ол кезде өз ісіне берілген шеберлер жоқ еді. Бізде өрістері қабаттасуы мүмкін гетерогенді журналдар болды. Әртүрлі қолданбалардың әртүрлі журналдары бірдей өріс атауларымен жазылуы мүмкін, бірақ ішінде әртүрлі деректер болуы мүмкін. Яғни, бір журнал өрісте бүтін санмен бірге келеді, мысалы, деңгей. Басқа журнал деңгей өрісінде Жолмен бірге келеді. Статикалық карта болмаған жағдайда бұл керемет нәрсе. Егер индексті elasticsearch-те айналдырғаннан кейін алдымен жолы бар хабарлама келсе, онда біз қалыпты өмір сүреміз. Бірақ егер біріншісі бүтін саннан келсе, жолдан келген барлық кейінгі хабарлар жай ғана жойылады. Өйткені өріс түрі сәйкес келмейді.
Осы сұрақтарды қоя бастадық. Біз кінәлілерді іздемейміз деп шештік.
Бірақ бірдеңе істеу керек! Бізге стандарттарды орнату керек екені анық. Бізде әлдеқашан стандарттар болған. Біз біраз уақытты кейінірек бастадық. Бақытымызға орай, сол уақытта барлық API интерфейстері үшін бір журнал пішімі бекітілген болатын. Ол тікелей қызметтер арасындағы өзара әрекеттесу стандарттарына жазылған. Тиісінше, журналдарды алғысы келетіндер оларды осы форматта жазуы керек. Егер біреу осы форматта журналдарды жазбаса, біз ештеңеге кепілдік бермейміз.
Әрі қарай, журналдарды жазу, жеткізу және жинау әдістерінің бірыңғай стандартын жасағым келеді. Шын мәнінде, оларды қайда жазу керек және оларды қалай жеткізу керек. Идеал жағдай - жобалар бір кітапхананы пайдаланған кезде. Go үшін бөлек журналдар кітапханасы және PHP үшін бөлек кітапхана бар. Бізде бар әрбір адам оларды пайдалануы керек. Қазіргі таңда бұл істе 80 пайыз табыстымыз дер едім. Бірақ кейбір адамдар кактустарды жеуді жалғастыруда.
Сол жерде (слайдта) «Бөренелерді жеткізуге арналған SLA» әрең шыға бастайды. Бұл әлі жоқ, бірақ біз онымен жұмыс істеп жатырмыз. Өйткені инфрақұрылым анау-мынау форматта анау-мынау жерге жазып, секундына N хабарламадан аспайтын болса, оны анау-мынау жерге жеткіземіз десе, өте ыңғайлы. Бұл көптеген бас ауруларын жеңілдетеді. Егер SLA бар болса, бұл өте керемет!
Мәселені шешуді қалай бастадық? Негізгі мәселе td-агентте болды. Біздің бөренелер қайда кеткені белгісіз болды. Олар жеткізілді ме? Олар барады ма? Олар бәрібір қайда? Сондықтан бірінші тармақ td-агентті ауыстыру туралы шешім қабылдады. Мен мұнда оны немен ауыстыруға болатын нұсқаларды қысқаша сипаттадым.
Еркін. Біріншіден, мен оны бұрынғы жұмыста кездестірдім, ол да мезгіл-мезгіл сол жерде құлап кетті. Екіншіден, бұл бірдей нәрсе, тек профильде.
Filebeat. Бізге қаншалықты ыңғайлы болды? Өйткені ол Go-да және бізде Go-да көп тәжірибе бар. Тиісінше, егер бірдеңе болса, біз оған өзіміз үшін қандай да бір жолмен қоса аламыз. Сондықтан біз оны алмадық. Сондықтан оны өзіңіз үшін қайта жазуды бастауға ешқандай азғырулар болмайды.
Жүйелік әкімші үшін айқын шешім - бұл сандағы жүйенің барлық түрлері (syslog-ng/rsyslog/nxlog).
Немесе өзіңіздің бірдеңеңізді жазыңыз, бірақ біз оны, сондай-ақ filebeat қолданбасын алып тастадық. Бірдеңе жазсаң, бизнеске пайдалы нәрсе жазған дұрыс. Бөренелерді жеткізу үшін дайын нәрсені алған дұрыс.
Сондықтан таңдау шын мәнінде syslog-ng және rsyslog арасындағы таңдауға келді. Мен rsyslog-ке бейім болдым, өйткені бізде Puppet-те rsyslog үшін сабақтар болды және мен олардың арасында айқын айырмашылықты таппадым. Syslog дегеніміз не, syslog дегеніміз не. Иә, кейбіреулерінің құжаттары нашар, кейбіреулері жақсырақ. Мынау былай істей алады, ал екіншісі басқаша жасай алады.
Және rsyslog туралы аздап. Ең алдымен, бұл керемет, өйткені оның көптеген модульдері бар. Онда адам оқи алатын RainerScript (қазіргі заманғы конфигурация тілі) бар. Бұл стандартты құралдарды пайдалана отырып, td-агент әрекетіне еліктеуге болатын керемет бонус және қолданбалар үшін ештеңе өзгерген жоқ. Яғни, біз td-агентті rsyslog деп өзгертеміз, ал қалғандарының барлығын әзірге жалғыз қалдырамыз. Біз бірден жұмыс жеткізілімін аламыз. Әрі қарай, mmnormalize - rsyslog ішіндегі керемет нәрсе. Ол журналдарды талдауға мүмкіндік береді, бірақ Grok және regexp қолданбайды. Ол дерексіз синтаксис ағашын жасайды. Ол журналдарды компилятор көздерді талдайтындай етіп талдайды. Бұл өте жылдам жұмыс істеуге, аз процессорды тұтынуға мүмкіндік береді және жалпы алғанда, бұл өте керемет нәрсе. Басқа да көптеген бонустар бар. Мен оларға тоқталмаймын.
rsyslog басқа да көптеген кемшіліктері бар. Олар бонустармен шамамен бірдей. Негізгі проблемалар - сіз оны қалай дайындау керектігін білуіңіз керек және нұсқаны таңдауыңыз керек.
Біз журналдарды unix ұяшығына жазамыз деп шештік. Және /dev/log ішінде емес, себебі бізде жүйелік журналдар шатастырылған, журнал осы құбырда. Сонымен, реттелетін ұяшыққа жазайық. Біз оны бөлек ережелер жинағына қосамыз. Ештеңеге араласпайық. Барлығы ашық және түсінікті болады. Біз дәл солай істедік. Бұл ұяшықтары бар каталог стандартталған және барлық контейнерлерге жіберіледі. Контейнерлер өздеріне қажетті розетканы көріп, ашып, оған жаза алады.
Неге файл емес? Өйткені оны бәрі оқиды , файлды докерге жіберуге әрекеттенді және rsyslog қайта іске қосылғаннан кейін файл дескрипторы өзгеріп, докер бұл файлды жоғалтқаны анықталды. Ол басқа нәрсені ашық ұстайды, бірақ олар жазып жатқан розетка емес. Біз бұл мәселені шешуді шештік, сонымен бірге блоктау мәселесін де айналып өтеміз.
Rsyslog слайдта көрсетілген әрекеттерді орындайды және журналдарды релеге немесе Кафкаға жібереді. Кафка ескі жолмен жүреді. Реле - журналдарды жеткізу үшін таза rsyslog журналын қолдануға тырыстым. Хабарлама кезегі жоқ, стандартты rsyslog құралдарын пайдалану. Негізінде ол жұмыс істейді.
Бірақ оларды осы бөлікке (Logstash/Graylog/ES) қалай итеру керектігі туралы нюанстар бар. Бұл бөлік (rsyslog-rsyslog) деректер орталықтары арасында қолданылады. Мұнда қысылған tcp сілтемесі бар, ол өткізу қабілеттілігін үнемдеуге мүмкіндік береді және сәйкесінше, арна бітеліп қалған кезде басқа деректер орталығынан кейбір журналдарды алу ықтималдығын арттырады. Өйткені бізде Индонезия бар, онда бәрі нашар. Тұрақты мәселе осында жатыр.
Біз қолданбадан жазып алған журналдардың соңына жетуі қаншалықты ықтимал екенін қалай бақылауға болатынын ойладық? Біз метрика жасауды шештік. rsyslog-тің өзіндік статистикалық жинақ модулі бар, онда санауыштардың бір түрі бар. Мысалы, ол кезектің өлшемін немесе осындай әрекетте қанша хабарлама келгенін көрсете алады. Сіз олардан бірдеңе алуға болады. Оған қоса, оның конфигурациялануы мүмкін теңшелетін есептегіштері бар және ол сізге, мысалы, кейбір API жазған хабарлар санын көрсетеді. Содан кейін мен Python тілінде rsyslog_exporter жаздым және біз оның бәрін Прометейге жіберіп, графиктерді құрастырдық. Біз шынымен Graylog метрикасын алғымыз келеді, бірақ бізде оларды орнатуға әлі уақыт болмады.
Қандай проблемалар болды? Біздің Live API интерфейстері секундына 50 мың хабарлама жазып жатқанын білгенде (КЕНТЕТ!) мәселелер туындады. Бұл кезеңсіз Live API ғана. Ал Graylog бізге секундына небәрі 12 мың хабарлама көрсетеді. Және орынды сұрақ туындады: қалдықтар қайда? Осыдан біз Graylog жай ғана жеңе алмайды деген қорытындыға келдік. Біз қарадық, шынында да, Graylog және Elasticsearch бұл ағынды басқара алмады.
Әрі қарай, біз жол бойында басқа да жаңалықтар аштық.
Розеткаға жазулар бұғатталған. Бұл қалай болды? Мен жеткізу үшін rsyslog пайдаланған кезде, бір сәтте деректер орталықтары арасындағы арна бұзылды. Жеткізу бір жерде тоқтап қалды, басқа жерде жеткізу тоқтады. Мұның бәрі rsyslog ұяшығына жазатын API интерфейстері бар машинаға жетті. Ол жерде кезек болды. Содан кейін әдепкі бойынша 128 пакет болатын unix ұясына жазу кезегі толтырылды. Ал қолданбадағы келесі write() бұғатталған. Біз Go қолданбаларында қолданатын кітапхананы қарағанымызда, розеткаға жазу блокталмаған режимде орындалатыны жазылған. Біз ештеңе бұғатталмағанына сенімді болдық. Өйткені біз оқимыз ол туралы кім жазды. Бірақ бір сәт бар. Сондай-ақ бұл қоңыраудың айналасында шексіз цикл болды, онда хабарламаны ұяшыққа итермелеу әрекеті болды. Біз оны байқамадық. Мен кітапхананы қайта жазуға тура келді. Содан бері ол бірнеше рет өзгерді, бірақ қазір біз барлық ішкі жүйелерде блоктаудан құтылдық. Сондықтан, сіз rsyslog жұмысын тоқтата аласыз және ештеңе бұзылмайды.
Кезектердің көлемін қадағалау қажет, бұл осы тырмаға баспауға көмектеседі. Біріншіден, біз хабарларды жоғалтқан кезде бақылай аламыз. Екіншіден, жеткізуде қиындықтар бар екенін бақылай аламыз.
Және тағы бір жағымсыз сәт - микросервис архитектурасында 10 есе күшейту өте оңай. Бізде көптеген кіріс сұраулары жоқ, бірақ бұл хабарламалар әрі қарай жүретін графикке байланысты, кіру журналдарының арқасында біз журнал жүктемесін шамамен он есе арттырамыз. Өкінішке орай, менде нақты сандарды есептеуге уақытым болмады, бірақ микросервистер - бұл. Мұны есте сақтау керек. Қазіргі уақытта журналдарды жинаудың ішкі жүйесі Lazada-да ең көп жүктелгені белгілі болды.
Elasticsearch мәселесін қалай шешуге болады? Барлық машиналарға жүгірмеу және оларды жинамау үшін журналдарды бір жерден жылдам алу қажет болса, файлдарды сақтау орнын пайдаланыңыз. Бұл жұмыс істеуге кепілдік береді. Оны кез келген серверден жасауға болады. Ол жерге дискілерді жабыстырып, syslog орнату керек. Осыдан кейін сізге барлық журналдардың бір жерде болуына кепілдік беріледі. Содан кейін elasticsearch, graylog және тағы бір нәрсені баяу конфигурациялауға болады. Бірақ сізде қазірдің өзінде барлық журналдар болады, сонымен қатар сіз оларды диск массивтері жеткілікті болғанша сақтай аласыз.
Менің есеп беру кезінде схема осылай көріне бастады. Біз файлға жазуды іс жүзінде тоқтаттық. Енді, ең алдымен, біз қалғандарын өшіреміз. API жұмыс істейтін жергілікті машиналарда файлдарға жазуды тоқтатамыз. Біріншіден, файлды сақтау орны бар, ол өте жақсы жұмыс істейді. Екіншіден, бұл машиналарда орын үнемі таусылады, оны үнемі бақылап отыру керек.
Logstash және Graylog бар бұл бөлік шынымен де көтеріледі. Сондықтан, одан құтылуымыз керек. Сіз бір нәрсені таңдауыңыз керек.
Біз Логсташ пен Кибананы тастауды шештік. Өйткені бізде қауіпсіздік бөлімі бар. Қандай байланыс? Қосылым мынада: X-Pack және Shield жоқ Kibana журналдарға кіру құқықтарын ажыратуға мүмкіндік бермейді. Сондықтан біз Грейлогты алдық. Оның бәрі бар. Маған ұнамайды, бірақ ол жұмыс істейді. Біз жаңа жабдықты сатып алдық, сонда жаңа Graylog орнаттық және қатаң пішімдері бар барлық журналдарды бөлек Graylog-ке көшірдік. Біз ұйымдық түрде бірдей өрістердің әртүрлі түрлерімен мәселені шештік.
Жаңа Graylog-қа нақты не кіреді. Біз барлығын докерге жаздық. Біз көптеген серверлерді алдық, үш Kafka данасын, 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 сервері. Іс жүзінде екі басқару машинасы. Олардың көзқарасы бірдей. Бірақ әзірге трафик олардың біреуі арқылы өтеді. Ол барлық журналдарды біріктіреді. Оның диск кезегі бар. Ол журналдарды жүктеп алып, оларды орталық деректер орталығына (Сингапур) жібереді, содан кейін олар Graylog қызметіне жіберіледі. Және әрбір деректер орталығында өзінің файлдық қоймасы бар. Біздің байланысымыз жоғалған жағдайда, бізде барлық журналдар бар. Олар сонда қалады. Олар сонда сақталады.
сұрақ: Қалыпты жағдайлар болған жағдайда, журналдарды сол жерден аласыз ба?
жауап: Ол жерге (файл қоймасына) барып, қарауға болады.
сұрақ: Журналдарды жоғалтпауыңызды қалай бақылайсыз?
жауап: Біз оларды жоғалтып жатырмыз және біз оны бақылап жатырмыз. Мониторинг бір ай бұрын басталған. Go API интерфейстері пайдаланатын кітапханада көрсеткіштер бар. Ол розеткаға қанша рет жаза алмағанын санай алады. Қазіргі уақытта ол жерде ақылды эвристика бар. Онда буфер бар. Ол одан розеткаға хабарлама жазуға тырысады. Егер буфер толып кетсе, ол оларды түсіре бастайды. Және олардың қаншасын түсіргенін санайды. Егер ол жерде есептегіштер толып кете бастаса, бұл туралы білетін боламыз. Олар қазір прометейге келеді және сіз Графанадағы графиктерді көре аласыз. Ескертулерді орнатуға болады. Бірақ оларды кімге жіберетіні әзірге белгісіз.
сұрақ: elasticsearch жүйесінде журналдарды артықшылықпен сақтайсыз. Сізде қанша көшірме бар?
жауап: Бір жол.
сұрақ: Бұл бір ғана сызық па?
жауап: Бұл негізгі және көшірме. Деректер екі данада сақталады.
сұрақ: Сіз rsyslog буферінің өлшемін қандай да бір жолмен реттедіңіз бе?
жауап: Біз пайдаланушы unix ұясына датаграммаларды жазамыз. Бұл бізге бірден 128 килобайт шектеу қояды. Оған артық жаза алмаймыз. Біз мұны стандартқа жаздық. Жадқа түскісі келетіндер 128 килобайт жазады. Оның үстіне, кітапханалар кесіліп, хабардың кесілгені туралы жалауша қойылады. Хабарламаға арналған стандартымыздың өзінде оның жазу кезінде үзілгенін немесе өшірілгенін көрсететін арнайы өріс бар. Ендеше, бізде де осы сәтті қадағалауға мүмкіндігіміз бар.
Сұрақ: Сіз бұзылған JSON жазасыз ба?
жауап: Бұзылған JSON реле кезінде жойылады, себебі пакет тым үлкен. Немесе Graylog жойылады, себебі ол JSON талдауын жасай алмайды. Бірақ түзетуді қажет ететін нюанстар бар және олар негізінен rsyslog-ге байланысты. Мен онда бірнеше мәселені толтырдым, әлі де жұмыс істеу керек.
Сұрақ: Неге Кафка? Сіз RabbitMQ-ны қолданып көрдіңіз бе? Graylog мұндай жүктемелерде сәтсіздікке ұшырай ма?
жауап: Graylog бізге көмектеспейді. Ал Graylog біз үшін қалыптасып жатыр. Ол шынымен проблемалы. Ол біртүрлі нәрсе. Және, шын мәнінде, бұл қажет емес. Мен rsyslog-тен тікелей elasticsearch-ке жазып, содан кейін Кибанаға қарағым келеді. Бірақ біз бұл мәселені күзетшілермен шешуіміз керек. Бұл Грейлогты тастап, Kibana пайдаланған кезде біздің дамуымыздың мүмкін нұсқасы. Logstash пайдаланудың мағынасы жоқ. Өйткені мен rsyslog арқылы бірдей нәрсені жасай аламын. Және оның elasticsearch-ке жазуға арналған модулі бар. Біз Грейлогпен қалай да өмір сүруге тырысамыз. Біз оны тіпті аздап баптадық. Бірақ әлі де жақсартуға мүмкіндік бар.
Кафка туралы. Тарихи тұрғыдан осылай болды. Мен келгенде, ол қазірдің өзінде болды және оған журналдар жазылды. Біз жай ғана кластерді көтеріп, оған журналдарды көшірдік. Біз оның басшылығымыз, оның сезімін білеміз. RabbitMQ-ге келетін болсақ, ол біз үшін RabbitMQ-мен жұмыс істемейді. Ал RabbitMQ біз үшін қалыптасып жатыр. Бізде бұл өндірісте бар және онымен проблемалар болды. Енді сату алдында олар оны сүйсіндіретін және ол қалыпты жұмыс істей бастады. Бірақ оған дейін өндіріске шығаруға дайын емес едім. Тағы бір нүкте бар. Graylog AMQP 0.9 нұсқасын оқи алады, ал rsyslog AMQP 1.0 нұсқасын жаза алады. Ал ортада екеуін де жасай алатын бірде-бір шешім жоқ. Бұл бір немесе екіншісі. Сондықтан, қазіргі уақытта тек Кафка. Бірақ оның да өзіндік нюанстары бар. Өйткені біз қолданатын rsyslog нұсқасының омкафкасы rsyslog-тен шығарған бүкіл хабар буферін жоғалтуы мүмкін. Әзірше шыдадық.
Сұрақ: Кафканы сізде бұрыннан бар болғандықтан пайдаланасыз ба? Енді ешқандай мақсатта пайдаланылмай ма?
жауап: Кафканы Data Science тобы пайдаланады. Бұл мүлдем бөлек жоба, ол туралы, өкінішке орай, мен ештеңе айта алмаймын. Мен білмеймін. Оны Data Science командасы басқарды. Журналдар жасалған кезде, біз өзімізді орнатпау үшін оны пайдалануды шештік. Енді біз Graylog жаңарттық және біз үйлесімділікті жоғалттық, өйткені онда Кафканың ескі нұсқасы бар. Біз өзімізден бастауға тура келді. Сонымен бірге біз әрбір API үшін осы төрт тақырыптан құтылдық. Тікелей эфирде барлығына бір кең тақырып, барлық қойылымдар үшін бір кең тақырып жасап, барлығын сол жерге қойдық. Graylog мұның бәрін параллельді түрде сызып тастайды.
Сұрақ: Бұл розеткалы шамандық бізге не үшін керек? Контейнерлер үшін жүйе журналының драйверін пайдаланып көрдіңіз бе?
жауап: Біз бұл сұрақты қойған кезде докермен қарым-қатынасымыз шиеленіскен еді. Бұл докер 1.0 немесе 0.9 болды. Докердің өзі біртүрлі болды. Екіншіден, егер сіз оған журналдарды да итерсеңіз... Менің тексерілмеген күдігім бар, ол барлық журналдарды өзі арқылы, докер демоны арқылы өткізеді. Егер бір API есінен шықса, қалған API интерфейстері stdout және stderr жібере алмайтындығына байланысты. Мұның қайда апаратынын білмеймін. Бұл жерде Docker syslog драйверін пайдаланудың қажеті жоқ деген сезім деңгейінде менде күдік бар. Біздің функционалдық тестілеу бөлімінде журналдары бар жеке Graylog кластері бар. Олар Docker журналының драйверлерін пайдаланады және онда бәрі жақсы сияқты. Бірақ олар бірден Graylog-ке GELF жазады. Осының бәрін бастаған кезде бізге тек жұмыс істеу керек еді. Мүмкін, кейінірек біреу келіп, жүз жыл бойы жақсы жұмыс істеп жатыр десе, біз тырысамыз.
Сұрақ: rsyslog көмегімен деректер орталықтары арасында жеткізуді орындайсыз. Неге Кафка емес?
жауап: Біз екеуін де істейміз. Екі себеп бойынша. Егер арна толығымен өлі болса, онда біздің барлық журналдар, тіпті қысылған түрде де, ол арқылы өтпейді. Ал Кафка оларды процесс барысында жоғалтуға мүмкіндік береді. Осы бөренелердің кептелуінен осылай құтыламыз. Біз бұл жағдайда тікелей Кафканы қолданамыз. Егер бізде жақсы арна болса және оны босатқымыз келсе, біз олардың rsyslog-ін пайдаланамыз. Бірақ шын мәнінде, сіз оны өзі сәйкес келмеген нәрсені түсіретін етіп конфигурациялай аласыз. Қазіргі уақытта біз rsyslog жеткізуін бір жерде, ал Кафканы бір жерде пайдаланамыз.
Ақпарат көзі: www.habr.com