Біз өнім топтарын қалыптастыру кезеңінде мониторинг жүйесін құру туралы ойладық. Біздің бизнес – қанау бұл ұжымдарға түспейтіні белгілі болды. Неге бұлай?
Біздің барлық командалар жеке ақпараттық жүйелердің, микросервистердің және фронттардың айналасында құрылған, сондықтан командалар тұтас жүйенің жалпы денсаулығын көрмейді. Мысалы, олар терең сервердегі кейбір кішкене бөлік алдыңғы жаққа қалай әсер ететінін білмеуі мүмкін. Олардың қызығушылық аясы олардың жүйесі біріктірілген жүйелермен шектеледі. Егер команда және оның А қызметі В қызметімен дерлік байланысы болмаса, онда мұндай қызмет командаға дерлік көрінбейді.
Біздің команда, өз кезегінде, бір-бірімен өте күшті интеграцияланған жүйелермен жұмыс істейді: олардың арасында көптеген байланыстар бар, бұл өте үлкен инфрақұрылым. Интернет-дүкеннің жұмысы осы жүйелердің барлығына байланысты (олардың бізде, айтпақшы, үлкен саны бар).
Демек, біздің бөлім ешбір ұжымға жатпайды, сәл шетте орналасқан екен. Бұл бүкіл тарихта біздің міндетіміз ақпараттық жүйелердің қалай жұмыс істейтінін, олардың функционалдығын, интеграциясын, бағдарламалық қамтамасыз етуді, желіні, аппараттық құралдарды және мұның бәрі бір-бірімен қалай байланысты екенін жан-жақты түсіну болып табылады.
Біздің интернет-дүкендер жұмыс істейтін платформа келесідей:
- алдыңғы
- орта кеңсе
- Артқа кеңсе
Біз қанша қаласақ та, барлық жүйелер біркелкі және мінсіз жұмыс істейтіні болмайды. Мәселе, тағы да, жүйелер мен интеграциялардың саны - біз сияқты нәрсемен тестілеу сапасына қарамастан, кейбір оқиғалар сөзсіз. Оның үстіне, жеке жүйе шеңберінде де, олардың интеграциясы жағынан да. Және сіз оның жеке бөлігін ғана емес, бүкіл платформаның күйін жан-жақты бақылауыңыз керек.
Ең дұрысы, денсаулықты бақылау платформасы бойынша автоматтандырылған болуы керек. Біз мониторингке осы процестің міндетті бөлігі ретінде келдік. Бастапқыда ол тек алдыңғы қатарға арналған, ал желі мамандарында, бағдарламалық және аппараттық құралдар әкімшілерінде деңгейлік бақылау жүйелері бар және әлі де бар. Бұл адамдардың барлығы мониторингті өз деңгейінде ғана бақылаған, ешкімде жан-жақты түсінік болған жоқ.
Мысалы, егер виртуалды машина бұзылса, көп жағдайда бұл туралы тек аппараттық құрал мен виртуалды машинаға жауапты әкімші ғана біледі. Мұндай жағдайларда алдыңғы қатардағы команда қолданбаның апатқа ұшырау фактісін көрді, бірақ виртуалды машинаның апатқа ұшырауы туралы деректер болмады. Әкімші тұтынушының кім екенін біле алады және бұл виртуалды машинада не істеп жатқаны туралы шамамен түсінікке ие болады, егер бұл қандай да бір үлкен жоба болса. Ол кішкентайлар туралы білмейтін шығар. Қалай болғанда да, әкімші иесіне барып, осы машинада не болғанын, нені қалпына келтіру керектігін және нені өзгерту керектігін сұрауы керек. Ал егер шынымен маңызды нәрсе бұзылса, олар шеңбер бойымен жүгіре бастады - өйткені ешкім жүйені тұтас көрмеді.
Сайып келгенде, мұндай әртүрлі әңгімелер бүкіл интерфейске, пайдаланушыларға және біздің негізгі бизнес функциямызға - онлайн сатылымдарға әсер етеді. Біз команданың бөлігі емеспіз, бірақ интернет-дүкеннің бөлігі ретінде барлық электрондық коммерция қосымшаларымен айналысатындықтан, біз электронды коммерция платформасы үшін кешенді бақылау жүйесін құру міндетін алдық.
Жүйе құрылымы және стек
Біз жүйелеріміз үшін бірнеше бақылау қабаттарын анықтаудан бастадық, олардың ішінде метрика жинау керек. Осының барлығын біріктіру керек болды, біз бірінші кезеңде осылай жасадық. Енді осы кезеңде корреляцияны құру және жүйелердің бір-біріне қалай әсер ететінін түсіну үшін барлық қабаттарымыздағы көрсеткіштердің ең жоғары сапалы жиынын аяқтаймыз.
Қолданбаны іске қосудың бастапқы кезеңдерінде жан-жақты мониторингтің болмауы (жүйелердің көпшілігі өндірісте болған кезде біз оны құруды бастағандықтан) бүкіл платформаның мониторингін орнату үшін бізде айтарлықтай техникалық қарыздар болғанына әкелді. Бір АЖ үшін мониторингті орнатуға және оның мониторингін егжей-тегжейлі әзірлеуге назар аудару мүмкін болмады, өйткені қалған жүйелер біраз уақытқа мониторингсіз қалады. Бұл мәселені шешу үшін біз деңгейлер бойынша ақпараттық жүйенің күйін бағалау үшін ең қажетті өлшемдердің тізімін анықтадық және оны жүзеге асыруға кірістік.
Сондықтан олар пілді бөліктерге бөліп жеуге шешім қабылдады.
Біздің жүйе мыналардан тұрады:
- аппараттық құрал;
- операциялық жүйе;
- бағдарламалық жасақтама;
- Мониторинг қолданбасындағы UI бөліктері;
- іскерлік көрсеткіштер;
- интеграциялық қосымшалар;
- ақпараттық қауіпсіздік;
- желілер;
- қозғалыс теңгерімшісі.
Бұл жүйенің орталығында өзін бақылау жатыр. Бүкіл жүйенің күйін жалпы түсіну үшін барлық осы қабаттардағы және қолданбалардың бүкіл жиынтығы бойынша қолданбалармен не болып жатқанын білу керек.
Сонымен, стек туралы.
Біз ашық бастапқы бағдарламалық құралды қолданамыз. Орталықта бізде Zabbix бар, біз оны негізінен ескерту жүйесі ретінде қолданамыз. Оның инфрақұрылымдық мониторинг үшін өте қолайлы екенін бәрі біледі. Бұл нені білдіреді? Дәл сол төмен деңгейлі көрсеткіштер өзінің жеке деректер орталығына қызмет көрсететін әрбір компанияда (және Sportmaster-де өз деректер орталықтары бар) - сервер температурасы, жад күйі, рейд, желілік құрылғы көрсеткіштері.
Біз Zabbix-ті командаларда белсенді қолданылатын Telegram мессенджерімен және Microsoft Teams-пен біріктірдік. Zabbix нақты желінің, аппараттық құралдардың және кейбір бағдарламалық жасақтаманың қабатын қамтиды, бірақ бұл панацея емес. Біз бұл деректерді кейбір басқа қызметтерден байытамыз. Мысалы, аппараттық деңгейде біз виртуалдандыру жүйемізге API арқылы тікелей қосылып, деректерді жинаймыз.
Тағы да не. Zabbix-тен басқа, біз динамикалық орта қолданбасында көрсеткіштерді бақылауға мүмкіндік беретін Prometheus қолданамыз. Яғни, біз HTTP соңғы нүктесі арқылы қолданба метрикасын ала аламыз және оған қандай көрсеткіштерді жүктеп, қайсысын жүктейтінін ойламаймыз. Осы деректер негізінде аналитикалық сұрауларды әзірлеуге болады.
Басқа деңгейлерге арналған деректер көздері, мысалы, іскери көрсеткіштер үш құрамдасқа бөлінеді.
Біріншіден, бұл сыртқы бизнес жүйелері, Google Analytics, біз журналдардан көрсеткіштерді жинаймыз. Олардан біз белсенді пайдаланушылар, конверсиялар және бизнеске қатысты барлық нәрселер туралы деректерді аламыз. Екіншіден, бұл UI бақылау жүйесі. Оны толығырақ сипаттау керек.
Бір кездері біз қолмен тестілеуден бастадық және ол функционалдылық пен интеграцияның автоматты сынақтарына айналды. Бұдан біз тек негізгі функционалдылықты қалдырып, мүмкіндігінше тұрақты және уақыт өте жиі өзгермейтін маркерлерге сүйеніп, мониторинг жасадық.
Жаңа топ құрылымы қолданбалы әрекеттердің барлығы өнім топтарымен шектелетінін білдіреді, сондықтан біз таза тестілеуді тоқтаттық. Оның орнына біз Java, Selenium және Jenkins тілдерінде жазылған сынақтардан UI мониторингін жасадық (есептерді іске қосу және шығару жүйесі ретінде пайдаланылады).
Бізде көптеген сынақтар болды, бірақ соңында біз негізгі жолға, жоғары деңгейлі метрикаға баруды шештік. Ал егер бізде нақты сынақтар көп болса, деректерді жаңартып отыру қиынға соғады. Әрбір келесі шығарылым бүкіл жүйені айтарлықтай бұзады және біз оны түзетеміз. Сондықтан біз сирек өзгеретін өте іргелі нәрселерге назар аудардық және біз оларды тек бақылаймыз.
Соңында, үшіншіден, деректер көзі орталықтандырылған тіркеу жүйесі болып табылады. Біз журналдар үшін Elastic Stack пайдаланамыз, содан кейін біз бұл деректерді бизнес көрсеткіштері үшін бақылау жүйемізге тарта аламыз. Осының бәріне қоса, бізде Python тілінде жазылған, API арқылы кез келген қызметтерді сұрайтын және олардан Zabbix-ке деректерді жинайтын өзіміздің Monitoring API қызметі бар.
Мониторингтің тағы бір таптырмас атрибуты – визуализация. Біздікі Графанаға негізделген. Ол басқа визуализация жүйелері арасында ерекшеленеді, себебі ол бақылау тақтасындағы әртүрлі деректер көздерінен алынған көрсеткіштерді визуализациялауға мүмкіндік береді. Біз интернет-дүкен үшін жоғары деңгейлі көрсеткіштерді жинай аламыз, мысалы, ДҚБЖ-дан соңғы сағатта орналастырылған тапсырыстар саны, осы интернет-дүкен Zabbix-тен іске қосылған ОЖ үшін өнімділік көрсеткіштері және осы қолданбаның даналарына арналған көрсеткіштер Прометейден. Мұның бәрі бір бақылау тақтасында болады. Ашық және қол жетімді.
Қауіпсіздік туралы айта кетейін – біз қазір жүйені аяқтап жатырмыз, оны кейінірек жаһандық мониторинг жүйесімен біріктіреміз. Менің ойымша, электрондық коммерцияның ақпараттық қауіпсіздік саласында кездесетін негізгі проблемалары боттарға, талдаушыларға және дөрекі күшке қатысты. Біз мұны қадағалап отыруымыз керек, өйткені мұның бәрі біздің қолданбаларымыздың жұмысына да, іскерлік көзқарастағы беделімізге де сыни әсер етуі мүмкін. Ал таңдалған стекпен біз бұл тапсырмаларды сәтті орындаймыз.
Тағы бір маңызды жайт, қолданбалы қабат Прометей құрастырады. Оның өзі де Zabbix-пен біріктірілген. Сондай-ақ бізде сайт жылдамдығы бар, бұл біздің бетті жүктеу жылдамдығы, кедергілер, бетті көрсету, сценарийлерді жүктеу және т.б. сияқты параметрлерді көруге мүмкіндік беретін қызмет, сонымен қатар API біріктірілген. Осылайша, біздің көрсеткіштер Zabbix-те жиналады, сәйкесінше біз де сол жерден ескертеміз. Барлық ескертулер қазір негізгі жіберу әдістеріне жіберіледі (әзірше бұл электрондық пошта және телеграмма, MS Teams де жақында қосылды). Смарт-боттар қызмет ретінде жұмыс істейтін және барлық мүдделі өнім топтарына мониторинг ақпаратын беретін күйге дейін ескертуді жаңарту жоспарлануда.
Біз үшін көрсеткіштер жеке ақпараттық жүйелер үшін ғана емес, сонымен қатар қолданбалар пайдаланатын барлық инфрақұрылым үшін жалпы көрсеткіштер маңызды: виртуалды машиналар жұмыс істейтін физикалық серверлердің кластерлері, трафикті теңестірушілер, желі жүктемесін теңестірушілер, желінің өзі, байланыс арналарын пайдалану . Біздің жеке деректер орталықтары үшін қосымша көрсеткіштер (бізде олардың бірнешеуі бар және инфрақұрылым өте үлкен).
Біздің мониторинг жүйеміздің артықшылықтары оның көмегімен біз барлық жүйелердің денсаулық жағдайын көреміз және олардың бір-біріне және ортақ ресурстарға әсерін бағалай аламыз. Сайып келгенде, бұл бізге ресурстарды жоспарлаумен айналысуға мүмкіндік береді, бұл да біздің жауапкершілігіміз. Біз серверлік ресурстарды басқарамыз - электрондық коммерциядағы пул, жаңа жабдықты іске қосу және пайдаланудан шығару, қосымша жаңа жабдықты сатып алу, ресурстарды пайдалану аудитін жүргізу және т.б. Жыл сайын командалар жаңа жобаларды жоспарлайды, олардың жүйелерін дамытады және біз үшін оларды ресурстармен қамтамасыз ету маңызды.
Ал метриканың көмегімен біз ақпараттық жүйелеріміздің ресурстарды тұтыну үрдісін көреміз. Солардың негізінде біз бірдеңені жоспарлай аламыз. Виртуализация деңгейінде біз деректерді жинаймыз және деректер орталығы бойынша ресурстардың қолжетімді көлемі туралы ақпаратты көреміз. Ал қазірдің өзінде деректер орталығының ішінде сіз ресурстарды қайта өңдеуді, нақты бөлуді және тұтынуды көре аласыз. Сонымен қатар, дербес серверлермен де, виртуалды машиналармен де және барлық осы виртуалды машиналар қарқынды айналатын физикалық серверлердің кластерлерімен.
Болашағы
Қазір бізде тұтастай жүйенің өзегі дайын, бірақ әлі де көп жұмыс істеу керек. Кем дегенде, бұл ақпараттық қауіпсіздік деңгейі, бірақ желіге қол жеткізу, ескертуді дамыту және корреляция мәселесін шешу де маңызды. Бізде көптеген қабаттар мен жүйелер бар және әр қабатта басқа да көптеген көрсеткіштер бар. Бұл матрешка дәрежесіндегі матрешка болып шығады.
Біздің міндетіміз – сайып келгенде дұрыс ескертулер жасау. Мысалы, егер аппараттық құралда, тағы да виртуалды машинада ақау болса және маңызды қолданба бар болса және қызмет ешбір жолмен сақтық көшірмесі жасалмаса. Біз виртуалды машинаның өлгенін білеміз. Содан кейін іскери көрсеткіштер сізді ескертеді: пайдаланушылар бір жерде жоғалып кетті, конверсия жоқ, интерфейстегі UI қолжетімсіз, бағдарламалық құрал мен қызметтер де өлді.
Бұл жағдайда біз ескертулерден спам аламыз және бұл енді тиісті бақылау жүйесінің пішіміне сәйкес келмейді. Корреляция туралы сұрақ туындайды. Сондықтан, ең дұрысы, біздің бақылау жүйеміз: «Жігіттер, сіздің физикалық машинаңыз өлді және онымен бірге бұл қолданба және осы көрсеткіштер» деп бізді жүз ескертулермен ашуланудың орнына, бір ескертудің көмегімен айтуы керек. Ол ең бастысы туралы хабарлауы керек - оның локализациясына байланысты мәселені тез жоюға көмектесетін себеп.
Біздің хабарландыру жүйесі мен ескертулерді өңдеу тәулік бойы жұмыс істейтін жедел желі қызметінің айналасында құрылған. Міндетті деп саналатын және бақылау парағына енгізілген барлық ескертулер сонда жіберіледі. Әрбір ескертудің сипаттамасы болуы керек: не болды, ол нені білдіреді, не әсер етеді. Сондай-ақ бақылау тақтасына сілтеме және бұл жағдайда не істеу керектігі туралы нұсқаулар.
Мұның бәрі ескертуді құру талаптары туралы. Сонда жағдай екі бағытта дамуы мүмкін - не мәселе бар және оны шешу қажет, немесе бақылау жүйесінде ақаулық орын алды. Бірақ кез келген жағдайда, сіз барып, оны анықтауыңыз керек.
Ескертулердің корреляциясы әлі дұрыс конфигурацияланбағанын ескере отырып, біз қазір орташа есеппен күніне жүзге жуық ескерту аламыз. Ал техникалық жұмыстарды жүргізу керек болса, біз бір нәрсені күштеп өшірсек, олардың саны айтарлықтай артады.
Біз жұмыс істейтін жүйелерді бақылау және біз үшін маңызды деп саналатын көрсеткіштерді жинаумен қатар, мониторинг жүйесі өнім топтары үшін деректерді жинауға мүмкіндік береді. Олар біз бақылайтын ақпараттық жүйелердегі көрсеткіштердің құрамына әсер ете алады.
Біздің әріптесіміз келіп, бізге де, командаға да пайдалы болатын кейбір көрсеткіштерді қосуды сұрауы мүмкін. Немесе, мысалы, командада бізде бар негізгі көрсеткіштер жеткіліксіз болуы мүмкін; олар кейбір нақты көрсеткіштерді қадағалауы керек. Grafana-да біз әр топ үшін кеңістік жасаймыз және әкімші құқықтарын береміз. Сондай-ақ, командаға бақылау тақталары қажет болса, бірақ олар мұны қалай жасау керектігін білмесе/білмесе, біз оларға көмектесеміз.
Біз команданың құндылығын құру, олардың шығарылымдары мен жоспарлау ағынынан тыс болғандықтан, біз бірте-бірте барлық жүйелердің шығарылымдары үздіксіз және бізбен келісусіз күн сайын шығарылуы мүмкін деген қорытындыға келеміз. Біз үшін бұл шығарылымдарды бақылау маңызды, өйткені олар қолданбаның жұмысына әсер етуі және бір нәрсені бұзуы мүмкін және бұл өте маңызды. Шығарылымдарды басқару үшін біз API арқылы деректерді алатын және қай ақпараттық жүйелерде қай шығарылымдар шығарылғанын және олардың күйін көре алатын Bamboo пайдаланамыз. Ал ең бастысы қай уақытта. Біз шығару маркерлерін негізгі критикалық көрсеткіштерге орналастырамыз, бұл проблемалар туындаған жағдайда көрнекі түрде көрсетеді.
Осылайша біз жаңа шығарылымдар мен пайда болатын мәселелер арасындағы корреляцияны көре аламыз. Негізгі идея - жүйенің барлық қабаттарда қалай жұмыс істейтінін түсіну, мәселені тез локализациялау және оны тез шешу. Өйткені, мәселені шешу емес, себебін іздеу көп уақытты қажет ететіні жиі кездеседі.
Ал бұл салада алдағы уақытта белсенділікке баса назар аударғымыз келеді. Ең дұрысы, мен мәселені шешкеннен кейін емес, алдын ала білгім келеді, сондықтан оны шешудің орнына алдын ала аламын. Кейде бақылау жүйесінің жалған дабылдары адамның қателігінен де, қолданбадағы өзгерістерге байланысты да пайда болады.Және біз осымен жұмыс істейміз, оны түзетеміз және оны бізбен бірге пайдаланатын пайдаланушыларды бақылау жүйесін кез келген манипуляциялар алдында ескертуге тырысамыз. , немесе осы әрекеттерді техникалық терезеде орындаңыз.
Сонымен, жүйе іске қосылып, көктемнің басынан бері сәтті жұмыс істеп жатыр... және өте нақты пайда көрсетуде. Әрине, бұл оның соңғы нұсқасы емес; біз көптеген пайдалы мүмкіндіктерді енгізетін боламыз. Бірақ дәл қазір, көптеген интеграциялар мен қосымшалармен бақылауды автоматтандыру шынымен де сөзсіз.
Егер сіз интеграциялардың айтарлықтай саны бар ірі жобаларды бақылайтын болсаңыз, бұл үшін қандай күміс оқ тапқаныңызды түсініктемелерде жазыңыз.
Ақпарат көзі: www.habr.com