Аб стварэнні сістэмы маніторынгу мы задумаліся на этапе фармавання прадуктовых каманд. Стала зразумела, што наша справа - эксплуатацыя - у гэтыя каманды ніяк не трапляе. Чаму так?
Справа ў тым, што ўсе нашы каманды пабудаваны вакол асобных інфармацыйных сістэм, мікрасэрвісаў і франтоў, таму агульны стан здароўя ўсёй сістэмы ў цэлым каманды не бачаць. Напрыклад, яны могуць не ведаць, як нейкая невялікая частка ў глыбокім бэкендзе ўплывае на франтавую частку. Кола іх інтарэсаў абмяжоўваецца сістэмамі, з якімі інтэграваная іх сістэма. Калі ж каманда і яе сэрвіс А амаль ніяк не злучаны з сэрвісам Б, то такі сэрвіс для каманды амаль нябачны.
Наша ж каманда, у сваю чаргу, працуе з сістэмамі, якія вельмі моцна інтэграваныя паміж сабой: паміж імі мноства сувязяў, гэта вельмі вялікая інфраструктура. І ад усіх гэтых сістэм (якіх у нас, дарэчы, велізарная колькасць), залежыць праца інтэрнэт-крамы.
Вось і атрымліваецца, што наш аддзел не адносіцца ні да адной каманды, а знаходзіцца крыху ўбаку. Ва ўсёй гэтай гісторыі наша задача - разумець у комплексе, як працуюць інфармацыйныя сістэмы, іх функцыянальнасць, інтэграцыі, ПЗ, сетка, жалеза, і як усё гэта звязана паміж сабой.
Платформа, на якой функцыянуюць нашыя інтэрнэт-крамы, выглядае так:
- перад
- middle-office
- бэк-офіс
Як бы нам ні жадалася, але не бывае такога, каб усе сістэмы працавалі гладка і бездакорна. Справа, зноў жа, у колькасці сістэм і інтэграцый - пры такой, як у нас, нейкія інцыдэнты гэта непазбежнасць, нягледзячы на якасць тэсціравання. Прычым як усярэдзіне нейкай асобнай сістэмы, так і ў плане іх інтэграцыі. І трэба сачыць за станам усёй платформы комплексна, а не які-небудзь асобнай яе часткі.
У ідэале назіранне за станам здароўя ўсёй платформы трэба аўтаматызаваць. І мы дашлі да маніторынгу як да непазбежнай часткі гэтага працэсу. Першапачаткова ён быў пабудаваны толькі для франтавой часткі, пры гэтым уласныя сістэмы маніторынгу па пластах былі і ёсць у сецявікоў, адміністратараў ПА і апаратнага забеспячэння. Усе гэтыя людзі сачылі за маніторынгам толькі на сваім узроўні, комплекснага разумення таксама ні ў кога не было.
Напрыклад, калі звалілася віртуальная машына, у большасці выпадкаў пра гэта ведае толькі адміністратар, які адказвае за hardware і віртуальную машыну. Каманда фронта ў такіх выпадках бачыла сам факт падзення прыкладання, але звестак аб падзенні віртуальнай машыны ў яе не было. А адміністратар можа ведаць, хто заказчык, і прыкладна ўяўляць, што менавіта зараз на гэтай віртуальнай машыне круціцца, пры ўмове, што гэта нейкі вялікі праект. Пра малыя ён, хутчэй за ўсё, не ведае. У любым выпадку, адміністратару трэба ісці да ўладальніка, пытацца, што ж на гэтай машыне было, што трэба аднаўляць і што памяняць. А калі ламалася нешта зусім сур'ёзнае, пачыналася беганіна па крузе - таму што ніхто не бачыў сістэму ў цэлым.
У канчатковым рахунку такія разрозненыя гісторыі ўплываюць на ўвесь фронтэнд, на карыстачоў і нашу асноўную бізнэс-функцыю – інтэрнэт-продажы. Бо мы не ўваходзім у каманды, а займаемся эксплуатацыяй усіх ecommerce-прыкладанняў у складзе інтэрнэт-крамы, мы ўзялі на сябе задачу па стварэнні комплекснай сістэмы маніторынгу ecommerce-платформы.
Структура сістэмы і стэк
Мы пачалі з таго, што вылучылі некалькі пластоў маніторынгу для нашых сістэм, у разрэзе якіх нам спатрэбіцца збіраць метрыкі. І ўсё гэта трэба было аб'яднаць, што мы і зрабілі на першым этапе. Цяпер па гэтым этапе мы дапрацоўваем максімальна якасны збор метрык па ўсіх нашых пластах, каб выбудоўваць карэляцыю і разумець, як сістэмы ўплываюць сябар на сябра.
Адсутнасць комплекснага маніторынгу на пачатковых этапах запуску прыкладанняў (бо мы пачалі будаваць яго, калі большая частка сістэм была ў эксплуатацыі) прывяло да таго, што ў нас утварыўся значны тэхнічны доўг па наладзе маніторынгу ўсёй платформы. Засяроджвацца на наладзе маніторынгу нейкай адной ІС і дэталёва прапрацоўваць маніторынг для яе мы не маглі сабе дазволіць, бо астатнія сістэмы засталіся б на нейкі час без маніторынгу. Для рашэння гэтай задачы мы вызначылі спіс самых неабходных метрык адзнакі стану інфармацыйнай сістэмы па пластах і пачалі яго ўкараняць.
Таму слана вырашылі есці па частках.
Наша сістэма складаецца з:
- абсталяванне;
- аперацыйнай сістэмы;
- праграмнае забеспячэнне;
- UI-часткі ў дадатку маніторынгу;
- бізнес-метрыкі;
- прыкладанні інтэграцыі;
- інфармацыйнай бяспекі;
- сеткі;
- балансавальніка трафіку.
У цэнтры гэтай сістэмы - уласна маніторынг. Каб увогуле разумець стан усёй сістэмы, трэба ведаць, што адбываецца з прыкладаннямі на ўсіх гэтых пластах і ў разрэзе ўсяго мноства прыкладанняў.
Дык вось, пра стэк.
Выкарыстоўваны ПЗ з адкрытым зыходным кодам. У цэнтры ў нас Zabbix, які мы выкарыстоўваем у першую чаргу як сістэму алертынгу. Усім вядома, што ён ідэальна падыходзіць для маніторынгу інфраструктуры. Што тут маецца на ўвазе? Як раз тыя нізкаўзроўневыя метрыкі, якія ёсць у кожнай кампаніі, якая змяшчае свой ЦАД (а ў Спартмайстра свае ЦАДы) - тэмпература сервера, стан памяці, рэйду, метрыкі сеткавых прылад.
Мы інтэгравалі Zabbix з мэсэнджэрам Telegram і Microsoft Teams, якія актыўна выкарыстоўваюцца ў камандах. Zabbix пакрывае пласт фактычнай сеткі, жалеза і часткова ПЗ, але гэта не панацэя. Мы гэтыя дадзеныя ўзбагачаем з некаторых іншых сэрвісаў. Напрыклад, па ўзроўні апаратнага забеспячэння мы напрамую па API канэктуемся ў нашай сістэме віртуалізацыі і забіраем дадзеныя.
Што яшчэ. Апроч Zabbix мы выкарыстоўваем Prometheus, які дазваляе маніторыць метрыкі ў дадатку дынамічнага асяроддзя. Гэта значыць, мы можам атрымліваць метрыкі дадатку па HTTP endpoint і не перажываць з нагоды таго, якія метрыкі ў яе загружаць, а якія не. На падставе гэтых звестак можна прапрацоўваць аналітычныя запыты.
Крыніцы дадзеных для астатніх пластоў, напрыклад, бізнэс-метрык, у нас дзеляцца на тры складнікі.
Па-першае, гэта вонкавыя бізнэсавыя сістэмы, Google Analytics, збіраем метрыкі з логаў. З іх мы атрымліваем дадзеныя па актыўным карыстальнікам, канверсіі і ўсяму іншаму, звязанаму з бізнесам. Па-другое, гэта сістэма UI-маніторынгу. Пра яе варта расказаць больш падрабязна.
Калісьці мы пачыналі з мануальнага тэсціравання і яно перарасло ў аўтатэсты функцыяналу і інтэграцый. З яго мы і зрабілі маніторынг, пакінуўшы толькі асноўны функцыянал, і завязаліся на маркеры, якія максімальна стабільныя і не часта мяняюцца з часам.
Новая структура каманд мае на ўвазе, што ўся дзейнасць па дадатках замыкаецца на прадуктовых камандах, таму чыстым тэсціраваннем мы займацца перасталі. Замест гэтага мы з тэстаў зрабілі UI-маніторынг, напісаны на Java, Selenium і Jenkins (выкарыстоўваецца як сістэма запуску і генерацыі справаздач).
У нас было шмат тэстаў, але ў выніку мы вырашылі выходзіць на галоўную дарогу, верхнеўзроўневую метрыку. І калі ў нас будзе шмат спецыфічных тэстаў, то будзе складана падтрымліваць актуальнасць звестак. Кожны наступны рэліз будзе значна ламаць усю сістэму, а мы толькі і будзем займацца яе папраўкай. Таму мы завязаліся на зусім фундаментальныя рэчы, якія рэдка мяняюцца, і маніторым толькі іх.
Нарэшце, па-трэцяе, крыніцай даных з'яўляецца цэнтралізаваная сістэма лагіравання. Для логаў выкарыстоўваем Elastic Stack, а потым гэтыя дадзеныя можам зацягваць у нашу сістэму маніторынгу па бізнес-метрыках. У дадатак да ўсяго гэтага працуе наш уласны сэрвіс Monitoring API, напісаны на Python, які апытвае па API любыя сэрвісы і забірае ў Zabbix дадзеныя з іх.
Яшчэ адзін незаменны атрыбут маніторынгу - візуалізацыя. У нас яна будуецца на аснове Grafana. Сярод іншых сістэм візуалізацыі яна вылучаецца тым, што на дашбордзе можна візуалізаваць метрыкі з розных крыніц дадзеных. Мы можам сабраць верхнеўзроўневыя метрыкі інтэрнэт-крамы, напрыклад, колькасць заказаў, аформленых за апошнюю гадзіну, з СКБД, метрыкі прадукцыйнасці АС, на якой запушчаны гэты інтэрнэт-крама, з Zabbix, а метрыкі інстансаў гэтага прыкладання - з Prometheus. І ўсё гэта будзе на адным дашбордзе. Наглядна і даступна.
Адзначу пра бяспеку - мы зараз дапілоўваем сістэму, якую пасля будзем інтэграваць з глабальнай сістэмай маніторынгу. На мой погляд, асноўныя праблемы, з якімі сутыкаецца e-commerce у сферы інфармацыйнай бяспекі, звязаныя з ботамі, парсерамі і брутфорсам. За гэтым трэба сачыць, таму што яны ўсё гэта можа крытычна паўплываць як на працу нашых дадаткаў, так і на рэпутацыю з пункту гледжання бізнесу. І абраным стэкам мы гэтыя задачы паспяхова пакрываем.
Яшчэ важны момант - узровень прыкладанняў збіраецца Prometheusам. Сам ён ён у нас таксама інтэграваны з Zabbix. І яшчэ ў нас ёсць sitespeed, сэрвіс, які дазваляе нам адпаведна глядзець такія параметры, як хуткасць загрузкі нашай старонкі, боттлнекі, адмалёўка старонкі, загрузка скрыптоў і іншае, ён таксама па API інтэграваны. Так метрыкі ў нас збіраюцца ў Zabbix, адпаведна, алертым мы таксама адтуль. Усе алерты пакуль сыходзяць на асноўныя спосабы адпраўкі (пакуль гэта email і telegram, яшчэ падлучылі нядаўна MS Teams). У планах прапампаваць алертынг да такога стану, каб разумныя боты працавалі як сэрвіс і давалі інфармацыю па маніторынгу ўсім жадаючым прадуктовым камандам.
Для нас важныя метрыкі не толькі асобных інфармацыйных сістэм, але і агульныя метрыкі па ўсёй інфраструктуры, якую выкарыстоўваюць прыкладанні: кластары фізічных сервераў, на якіх круцяцца віртуалкі, балансавальнікі трафіку, Network Load Balancer-ы, сама сетка, утылізацыя каналаў сувязі. Плюс метрыкі па нашых уласных цод (у нас іх некалькі і інфраструктура даволі значных памераў).
Плюсы нашай сістэмы маніторынгу ў тым, што з яе дапамогай мы бачым стан працаздольнасці ўсіх сістэм, можам ацаніць іх уплыў сябар на сябра і на агульныя рэсурсы. І ў канчатковым рахунку яна дазваляе займацца планаваннем рэсурсаў, што таксама ўваходзіць у нашую зону адказнасці. Мы кіруем сервернымі рэсурсамі - пулам у рамках e-commerce, уводзім-выводзім з эксплуатацыі новае абсталяванне, дакупляем новае, праводзім аўдыт утылізацыі рэсурсаў і іншае. Кожны год каманды плануюць новыя праекты, развіваюць свае сістэмы і нам важна забяспечыць іх рэсурсамі.
І з дапамогай метрык мы бачым тэндэнцыю спажывання рэсурсаў нашымі інфармацыйнымі сістэмамі. І ўжо на іх падставе можам нешта плянаваць. На ўзроўні віртуалізацыі мы збіраем дадзеныя і бачым інфармацыю па даступнай колькасці рэсурсаў у разрэзе ЦАД. А ўжо ўнутры ЦАД бачная і ўтылізацыя, і фактычнае размеркаванне, спажыванне рэсурсаў. Прычым як са standalone-серверамі, так і віртуальнымі машынамі і кластарамі фізічных сервераў, на якіх усе гэтыя віртуалкі бадзёра круцяцца.
Перспектывы
Цяпер у нас гатова ядро сістэмы ў цэлым, але засталося дастаткова момантаў, над якімі яшчэ трэба будзе працаваць. Як мінімум гэта пласт інфармацыйнай бяспекі, але важна таксама дабрацца да сеткі, развіць алертынг і вырашыць пытанне з карэляцыяй. Пластаў і сістэм у нас шмат, на кожным пласце яшчэ мноства метрык. Атрымліваецца матрошка ў ступені матрошкі.
Наша задача - у канчатковым рахунку зрабіць правільныя алерты. Напрыклад, калі здарылася праблема з апаратнай часткай, ізноў жа, з віртуальнай машынай, а тамака было важнае прыкладанне, і сэрвіс быў ніяк не зарэзерваваны. Мы даведаемся, што віртуальная машына памерла. Затым будуць алерціць бізнэс-метрыкі: карыстачы кудысьці зніклі, канверсіі няма, UI у інтэрфейсе недаступны, ПА і сэрвісы таксама памерлі.
Пры такім раскладзе мы атрымаем спам з алертаў, а гэта ўжо не ўкладваецца ў фармат правільнай сістэмы маніторынгу. Паўстае пытанне карэляцыі. Таму ў ідэале наша сістэма маніторынгу павінна сказаць: "Хлопцы, у вас фізічная машына памерла, а разам з ёй вось гэта дадатак і такія метрыкі", з дапамогай аднаго алерта замест таго, каб люта засыпаць нас сотняй алертаў. Яна павінна паведаміць аб галоўным - аб прычыне, што спрыяе аператыўнасці ліквідацыі праблемы за кошт яе лакалізацыі.
Наша сістэма абвестак і апрацоўка алертаў пабудавана вакол кругласутачнай службы гарачай лініі. Усе алерты, якія лічацца ў нас маст-хэвам і ўваходзяць у чэк-ліст, перадаюцца туды. Кожны алерт павінен абавязкова мець апісанне: што адбылося, што гэта, уласна, значыць, на што ўплывае. А яшчэ спасылку на дашборд і інструкцыю, што ж у гэтым выпадку трэба рабіць.
Гэта ўсё, што тычыцца патрабаванняў да пабудовы алертынгу. Далей сітуацыя можа развівацца ў двух напрамках - альбо праблема ёсць і яе трэба вырашаць, альбо адбыўся збой у сістэме маніторынгу. Але ў любым выпадку трэба ісці і разбірацца.
У сярэднім зараз за суткі нам падае каля сотні алертаў, гэта з улікам таго, што карэляцыя алертаў яшчэ не настроена належным чынам. І калі трэба правесці тэхнічныя працы, і мы нешта прымусова адключаем, іх колькасць вырастае ў разы.
Апроч маніторынгу па сістэмах, якія мы эксплуатуем, і збору метрык, якія на нашым баку расцэньваюцца як важныя, сістэма маніторынгу дазваляе збіраць дадзеныя для прадуктовых каманд. Яны могуць уплываць на склад метрык у рамках інфармацыйных сістэм, якія маніторыцца ў нас.
Наш калега можа прыйсці і папрасіць дадаць якую-небудзь метрыку, якая будзе карыснай і для нас, і для каманды. Ці, напрыклад, камандзе можа быць недастаткова тых базавых метрык, якія ў нас ёсць, ім трэба адсочваць нейкую спецыфічную. У Grafana мы ствараем прастору для кожнай каманды і выдаём правы адміна. Таксама, калі камандзе патрэбны дашборды, а яны самі не могуць/не ведаюць як гэта зрабіць, мы ім дапамагаем.
Так як мы па-за патокам стварэння каштоўнасцяў каманды, іх рэлізаў і планавання, мы паступова прыходзім да таго, што рэлізы ўсіх сістэм бясшвовыя і іх можна выкочваць штодня, не ўзгадняючы пры гэтым з намі. А нам важна адсочваць гэтыя рэлізы, таму што патэнцыйна яны могуць паўплываць на працу дадатку і нешта зламаць, а гэта крытычна. Для кіравання рэлізамі мы выкарыстаем Bamboo, адкуль па API атрымліваем дадзеныя і можам бачыць, якія рэлізы ў якіх інфармацыйных сістэмах вышлі і іх статут. І самае важнае - у які час. Маркеры аб рэлізах мы накладваем на асноўныя крытычныя метрыкі, што візуальна з'яўляецца вельмі паказальным у выпадку праблем.
Такім чынам мы можам бачыць карэляцыю паміж новымі рэлізамі і якія ўзнікаюць праблемамі. Асноўная ідэя ў тым, каб разумець, як працуе сістэма на ўсіх пластах, хутка лакалізаваць праблему і гэтак жа хутка яе выправіць. Бо часта бывае так, што больш за ўсё часу займае не вырашэнне праблемы, а пошук прычыны.
І па гэтым кірунку ў будучыні мы жадаем сфакусавацца на проактивности. У ідэале хацелася б загадзя даведвацца аб надыходзячай праблеме, а не постфактум, каб займацца яе папярэджаннем, а не рашэннем. Часам здараюцца ілжывыя спрацоўванні сістэмы маніторынгу, як з-за чалавечай памылкі, так і з-за змен у дадатку. І мы працуем над гэтым, адладжваем, і стараемся перад любымі маніпуляцыямі над сістэмай маніторынгу папярэджваць аб гэтым карыстальнікаў, якія яе выкарыстоўваюць разам з намі. , альбо праводзіць гэтыя мерапрыемствы ў тех.окно.
Такім чынам, сістэма запушчана і паспяхова працуе з пачатку вясны і паказвае цалкам рэальны профіт. Вядома, гэта не яе фінальная версія, мы будзем укараняць яшчэ мноства карыснасцяў. Але прама цяпер, пры такой вялікай колькасці інтэграцый і дадаткаў, без аўтаматызацыі маніторынгу на самай справе не абысціся.
Калі вы таксама маніторыце вялікія праекты з сур'ёзнай колькасцю інтэграцый - напішыце ў каментарах, якую сярэбраную кулю знайшлі для гэтага.
Крыніца: habr.com