Од 2008. године, наша компанија се првенствено бави управљањем инфраструктуром и техничком подршком за веб пројекте 400 сата дневно: имамо више од 15 клијената, што је око 15% руске електронске трговине. Сходно томе, подржава се веома разнолика архитектура. Ако нешто падне, дужни смо да то поправимо у року од XNUMX минута. Али да бисте разумели да је дошло до несреће, потребно је да пратите пројекат и реагујете на инциденте. Како урадити ово?
Верујем да постоји проблем у организовању одговарајућег система праћења. Да није било проблема, мој говор би се састојао од једне тезе: „Молим вас, инсталирајте Прометхеус + Графана и додатке 1, 2, 3.“ Нажалост, то више не функционише тако. А главни проблем је што сви и даље верују у нешто што је постојало 2008. године, у смислу софтверских компоненти.
Што се тиче организације система мониторинга, усудио бих се рећи да... пројекти са компетентним мониторингом не постоје. А ситуација је толико лоша да ако нешто падне, постоји ризик да то прође незапажено - на крају крајева, сви су сигурни да се „све прати“.
Можда се све прати. Али како?
Сви смо се сусрели са оваквом причом: одређени девопс, одређени админ ради, дође им развојни тим и каже – „ослобођени смо, сада прати“. Монитор шта? Како то ради?
ОК. Пратимо старински начин. И то се већ мења, и испоставило се да сте надгледали сервис А, који је постао сервис Б, који је у интеракцији са услугом Ц. Али развојни тим вам каже: „Инсталирајте софтвер, он треба да надгледа све!“
Па шта се променило? - Све се променило!
2008 Све је у реду
Постоји неколико програмера, један сервер, један сервер базе података. Све иде одавде. Имамо неке информације, инсталирамо заббик, Нагиос, кактусе. Затим постављамо јасна упозорења на ЦПУ, на рад на диску и на простор на диску. Такође радимо неколико ручних провера како бисмо били сигурни да сајт одговара и да наруџбине стижу у базу података. И то је то - мање-више смо заштићени.
Ако упоредимо количину посла који је администратор тада урадио да обезбеди надгледање, онда је 98% тога било аутоматски: особа која врши надзор мора да разуме како да инсталира Заббик, како да га конфигурише и конфигурише упозорења. И 2% - за екстерне провере: да сајт одговара и поставља захтев бази, да су стигле нове поруџбине.
2010 Оптерећење расте
Почињемо да ширимо веб, додајући претраживач. Желимо да будемо сигурни да каталог производа садржи све производе. И та претрага производа функционише. Да база података ради, да се праве налози, да сајт реагује екстерно и одговара са два сервера и да корисник није избачен са сајта док се ребалансира на други сервер итд. Има више ентитета.
Штавише, ентитет повезан са инфраструктуром и даље остаје највећи у глави менаџера. Још увек ми је у глави идеја да је особа која врши надзор особа која ће инсталирати заббик и моћи да га конфигурише.
Али истовремено се појављује рад на спровођењу екстерних провера, на креирању скупа скрипти упита индексатора претраге, скупа скрипти за проверу да ли се претрага мења током процеса индексирања, скупа скрипти које проверава да ли се роба преноси на служба доставе итд. и тако даље.
Напомена: Написао сам „скуп скрипти“ 3 пута. Односно, особа одговорна за праћење више није она која једноставно инсталира заббик. Ово је особа која почиње да кодира. Али ништа се још није променило у главама тима.
Али свет се мења, постаје све сложенији. Додат је слој виртуелизације и неколико нових система. Они почињу да комуницирају једни са другима. Ко је рекао „мирише на микроуслуге?“ Али свака услуга и даље изгледа као веб локација појединачно. Можемо му се обратити и схватити да он пружа потребне информације и ради сам. А ако сте администратор стално укључен у пројекат који се развија 5-7-10 година, ово знање се акумулира: појављује се нови ниво - схватили сте, појављује се други ниво - схватили сте...
Али ретко ко прати пројекат 10 година.
Мониторингман'с ресуме
Претпоставимо да сте дошли у нови стартап који је одмах ангажовао 20 програмера, написао 15 микросервиса, а ви сте администратор коме је речено: „Направи ЦИ/ЦД. Молимо вас." Направили сте ЦИ/ЦД и одједном чујете: „Тешко нам је да радимо са продукцијом у „коцки“, а да не разумемо како ће апликација радити у њој. Направите од нас сандбок у истој „коцки“.
У овој коцки направите сандбок. Одмах вам кажу: „Желимо сценску базу података која се ажурира сваки дан из продукције, тако да разумемо да ради на бази података, али да у исто време не кваримо производну базу.
Ви живите у свему овоме. Остало је још 2 недеље до изласка, кажу вам: „Ајде сад да пратимо све ово...“ тј. прати инфраструктуру кластера, прати микросервисну архитектуру, прати рад са екстерним сервисима...
А моје колеге избију из главе уобичајену шему и кажу: „Е, ту је све јасно! Инсталирајте програм који ће све ово пратити.” Да, да: Прометеј + Графана + додаци.
И додају: „Имате две недеље, проверите да ли је све безбедно.
У великом броју пројеката које видимо, једна особа је одређена за праћење. Замислите да желимо да ангажујемо особу која ће вршити мониторинг на 2 недеље и да му напишемо биографију. Које вештине треба да поседује ова особа, с обзиром на све што смо до сада рекли?
- Мора да разуме праћење и специфичности рада гвоздене инфраструктуре.
- Он мора да разуме специфичности надгледања Кубернетес-а (а сви желе да оду у „коцку“, јер можете да се апстрахујете од свега, сакријете се, јер ће се администратор позабавити остатком) - себе, његову инфраструктуру и разумети како да надгледате апликације у.
- Он мора да разуме да службе међусобно комуницирају на посебне начине и да зна специфичности начина на који услуге међусобно комуницирају. Сасвим је могуће видети пројекат где неки сервиси комуницирају синхроно, јер другог начина нема. На пример, бацкенд иде преко РЕСТ-а, преко гРПЦ-а до сервиса каталога, прима листу производа и враћа је назад. Не можете чекати овде. А са другим сервисима ради асинхроно. Пренесите наруџбу у службу за доставу, пошаљите писмо итд.
Вероватно сте већ испливали од свега овога? А админ, који ово треба да прати, још више се збунио. - Он мора бити у стању да планира и планира исправно - како посао постаје све више и више.
- Он стога мора да креира стратегију од креиране услуге да би разумео како да је посебно надгледа. Потребно му је разумевање архитектуре пројекта и његовог развоја + разумевање технологија које се користе у развоју.
Сетимо се једног сасвим нормалног случаја: неки сервиси су у ПХП-у, неки сервиси су у Го-у, неки сервиси су у ЈС-у. Они некако раде једно са другим. Одатле потиче израз „микросервис”: постоји толико много појединачних система да програмери не могу да разумеју пројекат у целини. Један део тима пише сервисе на ЈС који раде сами и не знају како функционише остатак система. Други део пише сервисе у Питхон-у и не меша се у рад других сервиса; они су изоловани у својој области. Трећи је писање сервиса у ПХП-у или нечем другом.
Свих ових 20 људи подељено је у 15 служби, а постоји само један админ који све ово мора да разуме. Зауставити! само смо поделили систем на 15 микросервиса јер 20 људи не може да разуме цео систем.
Али то треба некако пратити...
Шта је резултат? Као резултат тога, постоји једна особа која смисли све оно што цео тим програмера не може да разуме, а истовремено мора да зна и може да уради оно што смо горе навели - хардверску инфраструктуру, Кубернетес инфраструктуру итд.
Шта да кажем... Хјустон, имамо проблема.
Праћење савременог софтверског пројекта је сам по себи софтверски пројекат
Из лажног уверења да је надгледање софтвер, развијамо веру у чуда. Али чуда се, нажалост, не дешавају. Не можете инсталирати заббик и очекивати да све ради. Нема смисла инсталирати Графану и надати се да ће све бити ок. Највише времена биће утрошено на организовање провера рада сервиса и њихове међусобне интеракције, провера како функционишу спољни системи. У ствари, 90% времена неће бити потрошено на писање скрипти, већ на развој софтвера. И њиме треба да се бави тим који разуме рад пројекта.
Ако у овој ситуацији једна особа буде бачена у надзор, онда ће се десити катастрофа. Што се дешава свуда.
На пример, постоји неколико сервиса који међусобно комуницирају преко Кафке. Наруџба је стигла, послали смо поруку о наруџби Кафки. Постоји сервис који слуша информације о поруџбини и шаље робу. Постоји сервис који слуша информације о поруџбини и шаље писмо кориснику. А онда се појави још гомила услуга и почињемо да се збуњујемо.
А ако ово дате и администратору и програмерима у фази када је преостало мало времена до објављивања, особа ће морати да разуме цео овај протокол. Оне. Пројекат оваквог обима захтева значајно време и то треба узети у обзир у развоју система.
Али врло често, посебно у стартапима, видимо како се праћење одлаже за касније. „Сада ћемо направити Прооф оф Цонцепт, кренућемо са њим, нека падне – спремни смо да се жртвујемо. А онда ћемо све то пратити.” Када (или ако) пројекат почне да зарађује, предузеће жели да дода још више функција - јер је почело да функционише, па га треба даље развијати! И ви сте на месту где прво треба да пратите све претходно, што не одузима 1% времена, већ много више. Успут, програмери ће бити потребни за надгледање и лакше их је пустити да раде на новим функцијама. Као резултат тога, нове функције су написане, све се зезне, а ви сте у бескрајном ћорсокаку.
Дакле, како пратити пројекат почевши од почетка, и шта да радите ако добијете пројекат који треба да се надгледа, али не знате одакле да почнете?
Прво, морате планирати.
Лирска дигресија: врло често почињу са праћењем инфраструктуре. На пример, имамо Кубернетес. Почнимо са инсталирањем Прометхеуса са Графаном, инсталирањем додатака за праћење „коцке“. Не само програмери, већ и администратори имају несрећну праксу: „Инсталираћемо овај додатак, али додатак вероватно зна како то да уради.“ Људи воле да почну са једноставним и једноставним, а не са важним радњама. А праћење инфраструктуре је једноставно.
Прво одлучите шта и како желите да надгледате, а затим изаберите алатку, јер други људи не могу да мисле уместо вас. И треба ли? Други људи су мислили у себи, о универзалном систему - или уопште нису размишљали када је овај додатак написан. А то што овај додатак има 5 хиљада корисника не значи да је од неке користи. Можда ћете постати 5001. једноставно зато што је раније тамо било 5000 људи.
Ако почнете да надгледате инфраструктуру и позадински део ваше апликације престане да реагује, сви корисници ће изгубити везу са мобилном апликацијом. Појавиће се грешка. Доћи ће до вас и рећи „Апликација не ради, шта радите овде?“ - "Пратимо." — „Како да надгледате ако не видите да апликација не ради?“
- Верујем да треба да почнете да надгледате тачно од тачке уласка корисника. Ако корисник не види да апликација ради, то је то, грешка је. И систем за праћење би требао прво да упозори на ово.
- И тек онда можемо да пратимо инфраструктуру. Или то урадите паралелно. Лакше је са инфраструктуром - овде коначно можемо само да инсталирамо заббик.
- А сада морате да идете до корена апликације да бисте разумели где ствари не функционишу.
Моја главна идеја је да праћење треба да иде паралелно са развојним процесом. Ако одвучете пажњу тима за праћење ради других задатака (креирање ЦИ/ЦД-а, сандбокинг, реорганизација инфраструктуре), надгледање ће почети да заостаје и можда никада нећете сустићи развој (или ћете пре или касније морати да га зауставите).
Све по нивоима
Овако ја видим организацију система за праћење.
1) Ниво апликације:
- праћење пословне логике апликације;
- праћење здравствених метрика услуга;
- праћење интеграције.
2) Ниво инфраструктуре:
- праћење нивоа оркестрације;
- праћење системског софтвера;
- праћење нивоа гвожђа.
3) Опет ниво примене - али као инжењерски производ:
- прикупљање и праћење дневника апликација;
- АПМ;
- прецртавање.
4) Упозорење:
- организација система упозорења;
- организација дежурног система;
- организација „базе знања” и тока рада за обраду инцидената.
То је важно: долазимо до узбуне не после, већ одмах! Нема потребе да покрећете праћење и „некако касније“ откривате ко ће примати упозорења. На крају крајева, шта је задатак надгледања: да се разуме где у систему нешто ради погрешно и да о томе сазнају прави људи. Ако ово оставите до краја, онда ће прави људи знати да нешто иде наопако само по позиву „ништа не ради за нас“.
Слој апликације – праћење пословне логике
Овде је реч о провери саме чињенице да апликација ради за корисника.
Овај ниво треба урадити у фази развоја. На пример, имамо условни Прометеј: он иде на сервер који врши провере, повлачи крајњу тачку, а крајња тачка иде и проверава АПИ.
Када се често тражи да надгледају почетну страницу како би се уверили да сајт ради, програмери дају ручицу која се може повући сваки пут када треба да се увери да АПИ ради. А програмери у овом тренутку још увек узимају и пишу /апи/тест/хелловорлд
Једини начин да се уверите да све функционише? - Не!
- Креирање таквих провера је у суштини задатак програмера. Јединичне тестове треба да пишу програмери који пишу код. Јер ако то процури администратору, „Човјече, ево листе АПИ протокола за свих 25 функција, прати све!“ - ништа неће успети.
- Ако одштампате „здраво свете“, нико никада неће знати да АПИ треба и да ради. Свака промена АПИ-ја мора да доведе до промене провера.
- Ако већ имате такав проблем, зауставите функције и доделите програмере који ће писати ове провере, или прихватите губитке, прихватите да ништа није проверено и да неће успети.
Технички савети:
- Обавезно организујте екстерни сервер за организовање провера - морате бити сигурни да је ваш пројекат доступан спољном свету.
- Организујте провере за цео АПИ протокол, а не само за појединачне крајње тачке.
- Креирајте прометхеус-крајњу тачку са резултатима теста.
Апликациони слој – праћење здравствених метрика
Сада говоримо о спољним здравственим метрикама услуга.
Одлучили смо да надгледамо све „ручке“ апликације помоћу екстерних провера, које позивамо из спољног система за надзор. Али ово су „ручице“ које корисник „види“. Желимо да будемо сигурни да наше услуге раде. Овде је боља прича: К8с има здравствене провере, тако да се бар сама „коцка“ може уверити да услуга ради. Али половина чекова које сам видео је иста штампана „здраво свете“. Оне. Па повуче једном након распоређивања, одговорио је да је све у реду - то је све. А сервис, ако пружа свој АПИ, има огроман број улазних тачака за тај исти АПИ, који такође треба да се прати, јер желимо да знамо да ради. А ми то већ пратимо унутра.
Како то исправно имплементирати технички: свака услуга излаже крајњу тачку о свом тренутном учинку, а на графиконима Графане (или било које друге апликације) видимо статус свих услуга.
- Свака промена АПИ-ја мора да доведе до промене провера.
- Креирајте нову услугу одмах са здравственим показатељима.
- Администратор може доћи до програмера и питати „додајте ми неколико функција тако да све разумем и да додам информације о овоме у свој систем за праћење.“ Али програмери обично одговарају: „Нећемо ништа додавати две недеље пре објављивања.“
Нека знају менаџери развоја да ће бити таквих губитака, нека знају и менаџмент менаџера развоја. Јер када све падне, неко ће ипак звати и захтевати да прати „услугу која стално пада“ (ц) - Успут, доделите програмерима да пишу додатке за Графану - ово ће бити добра помоћ за администраторе.
Слој апликације – Надгледање интеграције
Мониторинг интеграције се фокусира на праћење комуникација између пословно критичних система.
На пример, постоји 15 сервиса који међусобно комуницирају. Ово више нису одвојени сајтови. Оне. не можемо сами да повучемо услугу, добијемо /хелловорлд и схватимо да је услуга покренута. Пошто веб сервис за наручивање мора да пошаље информације о поруџбини аутобусу - из аутобуса, магацин сервис мора да прими ову поруку и даље ради са њом. А сервис за дистрибуцију е-поште мора ово некако даље да обради итд.
Сходно томе, не можемо да схватимо, пикајући у сваки појединачни сервис, да све то функционише. Зато што имамо одређени аутобус кроз који све комуницира и комуницира.
Дакле, ова фаза треба да означи фазу тестирања сервиса за интеракцију са другим сервисима. Немогуће је организовати праћење комуникације праћењем брокера порука. Ако постоји сервис који издаје податке и сервис који их прима, када надгледамо брокера, видећемо само податке који лете са једне на другу страну. Чак и ако смо некако успели да интерно пратимо интеракцију ових података – да одређени произвођач објави податке, неко их прочита, овај ток настави да иде ка Кафки – то нам ипак неће дати информацију да ли је један сервис послао поруку у једној верзији , али други сервис није очекивао ову верзију и прескочио ју је. Нећемо знати за ово, пошто ће нам службе рећи да све функционише.
Шта препоручујем да урадите:
- За синхрону комуникацију: крајња тачка поставља захтеве повезаним услугама. Оне. узмемо ову крајњу тачку, извучемо скрипту унутар услуге, која иде до свих тачака и каже „Могу да повучем тамо, и повучем тамо, могу да повучем тамо...“
- За асинхрону комуникацију: долазне поруке – крајња тачка проверава магистралу за тест поруке и приказује статус обраде.
- За асинхрону комуникацију: одлазне поруке – крајња тачка шаље тест поруке на магистралу.
Као што обично бива: имамо сервис који убацује податке у магистралу. Долазимо у ову услугу и тражимо од вас да нам кажете о здрављу њене интеграције. А ако услуга треба да произведе поруку негде даље (ВебАпп), онда ће произвести ову пробну поруку. А ако покренемо услугу на страни ОрдерПроцессинг, она прво објави шта може независно да објави, а ако постоје неке зависне ствари, онда она чита скуп тест порука са магистрале, разуме да може да их обради, пријави и , ако треба, постави их даље, а за ово каже - све је ок, жив сам.
Врло често чујемо питање „како то можемо тестирати на борбеним подацима?“ На пример, говоримо о истој услузи наручивања. Наредбом се шаље порука у складиште где је роба отписана: то не можемо тестирати на борбеним подацима, јер ће „моја роба бити отписана!“ Решење: Планирајте цео овај тест на почетку. Такође имате јединичне тестове који праве ругање. Дакле, урадите то на дубљем нивоу где имате канал комуникације који не штети функционисању пословања.
Инфраструктурни слој
Мониторинг инфраструктуре је нешто што се дуго сматрало самим надзором.
- Мониторинг инфраструктуре се може и треба покренути као посебан процес.
- Не би требало да почнете са надгледањем инфраструктуре на пројекту који је у току, чак и ако то заиста желите. Ово је мука за све девопове. „Прво ћу надгледати кластер, пратићу инфраструктуру“ – тј. Прво ће пратити шта се налази испод, али неће улазити у апликацију. Зато што је апликација за девопс несхватљива ствар. То му је процурило, а он не разуме како то функционише. Али он разуме инфраструктуру и почиње са њом. Али не - увек морате прво да надгледате апликацију.
- Не претерујте са бројем упозорења. С обзиром на сложеност савремених система, упозорења стално лете, а са овом гомилом упозорења морате некако да живите. А дежурна особа, након што је погледала стотину следећих упозорења, одлучиће „Не желим да размишљам о томе“. Упозорења би требало да обавештавају само о критичним стварима.
Ниво апликације као пословна јединица
Кључне тачке:
- ЕЛК. Ово је индустријски стандард. Ако из неког разлога не обједињујете евиденције, почните то да радите одмах.
- АПМ. Екстерни АПМ-ови као начин за брзо затварање надгледања апликација (НевРелиц, БлацкФире, Датадог). Можете привремено да инсталирате ову ствар да бисте бар некако разумели шта се дешава са вама.
- Прецртавање. У десетинама микросервиса морате све да уђете у траг, јер захтев више не живи сам од себе. Касније је веома тешко додати, па је боље одмах заказати праћење у развоју - то је посао и корисност програмера. Ако га још нисте имплементирали, имплементирајте га! Види Јаегер/Зипкин
Алертинг
- Организација система обавештавања: у условима праћења гомиле ствари, требало би да постоји јединствен систем за слање обавештења. Можете у Графани. На Западу сви користе ПагерДути. Упозорења треба да буду јасна (нпр. одакле су дошла...). И препоручљиво је контролисати да ли се обавештења уопште примају
- Организација дежурног система: упозорења не треба слати свима (или ће сви реаговати у гомили, или нико неће реаговати). Програмери такође морају да буду дежурни: обавезно дефинишите области одговорности, направите јасна упутства и у њима напишите кога тачно да позову у понедељак и среду, а кога да позову у уторак и петак (иначе неће звати никога чак ни у случај великог проблема - плашиће се да вас пробуде или узнемиравају: људи углавном не воле да зову и буде друге људе, посебно ноћу). И објасните да тражење помоћи није показатељ некомпетентности („Тражим помоћ, то значи да сам лош радник“), подстакните молбе за помоћ.
- Организација „базе знања“ и тока рада за обраду инцидента: за сваки озбиљнији инцидент треба планирати обдукцију, а као привремену меру треба снимити радње које ће решити инцидент. И нека пракса буде да су поновљена упозорења грех; треба их поправити у коду или инфраструктурном раду.
Технолошки стог
Замислимо да је наш стек следећи:
- прикупљање података - Прометеј + Графана;
- анализа дневника - ЕЛК;
- за АПМ или Трацинг - Јаегер (Зипкин).
Избор опција није критичан. Јер ако сте на почетку разумели како да надгледате систем и записали план, онда почињете да бирате алате који одговарају вашим захтевима. Питање је шта сте уопште изабрали да надгледате. Јер можда алат који сте изабрали на почетку уопште не одговара вашим захтевима.
Неколико техничких тачака које у последње време видим свуда:
Прометеј се гура у Кубернетес - ко је ово смислио?! Ако вам се кластер сруши, шта ћете учинити? Ако имате сложен кластер унутра, онда би требало да постоји нека врста система за праћење унутар кластера, а неки споља, који ће прикупљати податке из унутрашњости кластера.
Унутар кластера сакупљамо трупце и све остало. Али систем за надзор мора бити напољу. Веома често, у кластеру где је интерно инсталиран Промтхеус, постоје и системи који врше екстерне провере рада сајта. Шта ако су ваше везе са спољним светом пале и апликација не ради? Испоставило се да је унутра све у реду, али то не олакшава ствари корисницима.
Налази
- Праћење развоја није инсталирање услужних програма, већ развој софтверског производа. 98% данашњег праћења је кодирање. Кодирање у услугама, кодирање екстерних провера, провера спољних услуга, и то је све.
- Не губите време својих програмера на надгледање: то може да одузме до 30% њиховог посла, али вреди тога.
- Девопс, не брини да не можеш да пратиш нешто, јер неке ствари су потпуно другачији начин размишљања. Нисте били програмер, а праћење рада је управо њихов посао.
- Ако је пројекат већ покренут и није надгледан (а ви сте менаџер), доделите ресурсе за праћење.
- Ако је производ већ у производњи, а ви сте девопс коме је речено да „подеси праћење“ - покушајте да објасните менаџменту о чему сам све ово писао.
Ово је проширена верзија извештаја са Саинт Хигхлоад++ конференције.
Ако сте заинтересовани за моје идеје и размишљања о томе и сродним темама, онда можете овде ????
Извор: ввв.хабр.цом