Мониторинг као услуга: модуларни систем за микросервисну архитектуру

Данас, поред монолитног кода, наш пројекат укључује десетине микросервиса. Сваки од њих захтева праћење. Учинити ово у таквом обиму помоћу ДевОпс инжењера је проблематично. Развили смо систем за праћење који ради као сервис за програмере. Они могу независно да уписују метрике у систем за праћење, да их користе, да праве контролне табле на основу њих и да им додају упозорења која ће се покренути када се достигну граничне вредности. За ДевОпс инжењере, само инфраструктура и документација.

Овај пост је транскрипт мог говора са нашим секције на РИТ++. Многи људи су од нас тражили да одатле направимо текстуалне верзије извештаја. Ако сте били на конференцији или гледали видео, нећете пронаћи ништа ново. А сви остали - добродошли у мачку. Рећи ћу вам како смо дошли до таквог система, како функционише и како планирамо да га ажурирамо.

Прошлост: шеме и планови

Како смо дошли до тренутног система праћења? Да бисте одговорили на ово питање, морате отићи у 2015. Овако је то тада изгледало:

Имали смо око 24 чвора који су били одговорни за праћење. Постоји читав пакет различитих круна, скрипти, демона који некако надгледају нешто, шаљу поруке и извршавају функције. Мислили смо да што даље идемо, такав систем ће бити мање одржив. Нема смисла развијати га: превише је гломазан.
Одлучили смо да изаберемо оне елементе праћења које ћемо задржати и развијати и оне које ћемо напустити. Било их је 19. Остали су само графити, агрегатори и Графана као инструмент табла. Али како ће изгледати нови систем? Овако:

Имамо складиште метрике: то су графити, који ће бити засновани на брзим ССД дисковима, то су одређени агрегатори за метрику. Следеће - Графана за приказ контролне табле и Моира за упозорење. Такође смо желели да развијемо систем за тражење аномалија.

Стандард: Мониторинг 2.0

Овако су изгледали планови 2015. Али морали смо да припремимо не само инфраструктуру и сам сервис, већ и документацију за њега. За себе смо развили корпоративни стандард који називамо мониторинг 2.0. Који су били захтеви за систем?

• стална доступност;
• интервал складиштења метрике = 10 секунди;
• структурирано складиштење метрике и контролне табле;
• СЛА > 99,99%
• прикупљање метрика догађаја путем УДП-а (!).

УДП нам је био потребан јер имамо велики проток саобраћаја и догађаја који генеришу метрику. Ако их све упишете у графит одједном, складиште ће се срушити. Такође смо изабрали префиксе првог нивоа за све метрике.

Сваки од префикса има неко својство. Постоје метрике за сервере, мреже, контејнере, ресурсе, апликације итд. Имплементирано је јасно, строго, откуцано филтрирање, где прихватамо метрику првог нивоа и једноставно испуштамо остатак. Овако смо планирали овај систем 2015. године. Шта је у садашњости?

Присутно: дијаграм интеракције компоненти праћења

Пре свега, пратимо апликације: наш ПХП код, апликације и микросервисе – укратко, све што наши програмери пишу. Све апликације шаљу метрику преко УДП-а у Брубецк агрегатор (статсд, преписан у Ц). Испоставило се да је најбржи у синтетичким тестовима. И шаље већ агрегиране метрике у Грапхите преко ТЦП-а.

Има врсту метрике која се зове тајмери. Ово је веома згодна ствар. На пример, за сваку корисничку везу са услугом шаљете метрику са временом одговора Брубеку. Пристигло је милион одговора, али агрегатор је вратио само 10 метрика. Имате број људи који су дошли, максимално, минимално и просечно време одговора, медијану и 4 перцентила. Затим се подаци преносе у Графит и све то видимо уживо.

Такође имамо агрегацију за метрику за хардвер, софтвер, системске метрике и наш стари Мунин систем за праћење (радио је за нас до 2015). Све ово прикупљамо преко Ц демона ЦоллецтД (има читаву гомилу различитих додатака уграђених у њега, може да анкетира све ресурсе хост система на којем је инсталиран, само наведите у конфигурацији где да упишете податке) и преко њега запишите податке у Грапхите. Такође подржава Питхон додатке и схелл скрипте, тако да можете написати сопствена прилагођена решења: ЦоллецтД ће прикупити ове податке са локалног или удаљеног хоста (под претпоставком Цурл) и послати их у Грапхите.

Затим шаљемо све метрике које смо прикупили у Царбон-ц-релаи. Ово је решење Царбон Релаи компаније Грапхите, модификовано у Ц. Ово је рутер који прикупља све метрике које шаљемо са наших агрегатора и усмерава их до чворова. Такође у фази рутирања, проверава валидност метрике. Прво, морају одговарати шеми префикса коју сам раније показао и, друго, важе за графит. У супротном ће пасти.

Царбон-ц-релаи затим шаље метрику у графитну групу. Користимо Царбон-цацхе, преписан у Го, као главно складиште метрике. Го-царбон, због своје вишенитности, далеко надмашује Царбон-цацхе. Он прима податке и записује их на дискове користећи шапат пакет (стандардан, написан у питону). Да бисмо читали податке из наших складишта, користимо Грапхите АПИ. Много је бржи од стандардног Грапхите ВЕБ-а. Шта се даље дешава са подацима?

Одлазе у Графану. Користимо наше графитне кластере као главни извор података, плус имамо Графану као веб интерфејс за приказивање метрике и прављење контролних табли. За сваку од својих услуга, програмери креирају сопствену контролну таблу. Затим граде графиконе на основу њих, који приказују метрику коју пишу из својих апликација. Поред Графане имамо и СЛАМ. Ово је питхон демон који израчунава СЛА на основу података из графита. Као што сам већ рекао, имамо неколико десетина микросервиса, од којих сваки има своје захтеве. Користећи СЛАМ, идемо на документацију и упоређујемо је са оним што је у Грапхите-у и упоређујемо колико се захтеви подударају са доступношћу наших услуга.

Идемо даље: узбуњивање. Организује се по снажном систему - Мојри. Независан је јер има свој Графит испод хаубе. Развили су га момци из СКБ „Контур“, написан на питону и гоу, потпуно отвореног кода. Мојра прима исти ток који иде у графите. Ако из неког разлога ваше складиште умре, ваше упозорење ће и даље радити.

Моира смо поставили у Кубернетес; он користи кластер Редис сервера као главну базу података. Резултат је био систем отпоран на грешке. Он упоређује ток метрика са листом покретача: ако у њему нема помена, онда испушта метрику. Дакле, може да свари гигабајте метрике у минути.

Уз њега смо приложили и корпоративни ЛДАП, уз помоћ којег сваки корисник корпоративног система може за себе да креира обавештења на основу постојећих (или новонасталих) тригера. Пошто Моира садржи графит, подржава све његове карактеристике. Дакле, прво узмете линију и копирате је у Графану. Погледајте како се подаци приказују на графиконима. И онда узмете исти ред и копирате га у Моира. Окачите га са ограничењима и добијате упозорење на излазу. Да бисте све ово урадили, нису вам потребна посебна знања. Моира може да упозорава путем СМС-а, е-поште, Јира, Слацк-а... Такође подржава извршавање прилагођених скрипти. Када јој се деси окидач, а она је претплаћена на прилагођену скрипту или бинарну датотеку, она је покреће и шаље ЈСОН на стдин за ову бинарну датотеку. Сходно томе, ваш програм мора да га рашчлани. Шта ћете урадити са овим ЈСОН-ом зависи од вас. Ако хоћеш, пошаљи у Телеграм, ако хоћеш отвори задатке у Јира, ради шта год.

Такође користимо сопствени развој за узбуњивање - Имаготаг. Панел, који се обично користи за електронске ценовнике у продавницама, прилагодили смо нашим потребама. Донели смо окидаче из Моире. Означава у каквом су стању и када су се догодили. Неки од развојних момака су напустили обавештења у Слацк-у и е-пошту у корист овог панела.

Па, пошто смо ми прогресивна компанија, пратили смо и Кубернетес у овом систему. Укључили смо га у систем користећи Хеапстер, који смо инсталирали у кластер, он прикупља податке и шаље их Грапхите-у. Као резултат, дијаграм изгледа овако:

Мониторинг Цомпонентс

Ево листе веза до компоненти које смо користили за овај задатак. Сви су отвореног кода.

графит:

• го-карбон: гитхуб.цом/ломик/го-царбон
• шапнути: гитхуб.цом/грапхите-пројецт/вхиспер
• графит-апи: гитхуб.цом/брутассе/грапхите-апи

Царбон-ц-релеј:

гитхуб.цом/гробиан/царбон-ц-релаи

Брубецк:

гитхуб.цом/гитхуб/брубецк

Прикупљено:

цоллецтд.орг

Моира:

гитхуб.цом/моира-алерт

Графана:

графана.цом

Хеапстер:

гитхуб.цом/кубернетес/хеапстер

Статистика

А ево неколико бројева о томе како систем функционише за нас.

агрегатор (брубецк)

Број метрика: ~300/сек
Интервал за слање метрике у Грапхите: 30 сек
Коришћење ресурса сервера: ~ 6% ЦПУ (говоримо о пуноправним серверима); ~ 1Гб РАМ; ~3 Мбпс ЛАН

Графит (го-карбон)

Број метрика: ~ 1 / мин
Интервал ажурирања метрике: 30 сек
Шема складиштења метрике: 30 секунди 35д, 5мин 90д, 10мин 365д (даје вам разумевање шта се дешава са услугом током дужег временског периода)
Коришћење ресурса сервера: ~10% ЦПУ; ~ 20Гб РАМ; ~30 Мбпс ЛАН

Флексибилност

Ми у Авитоу заиста ценимо флексибилност у нашој услузи надгледања. Зашто је заправо испао овакав? Прво, његове компоненте су заменљиве: и саме компоненте и њихове верзије. Друго, подршка. Пошто је цео пројекат отвореног кода, можете сами да уређујете код, уносите измене и имплементирате функције које нису доступне. Користе се прилично уобичајени стекови, углавном Го и Питхон, тако да се то ради прилично једноставно.

Ево примера стварног проблема. метрика у Грапхите-у је датотека. Има име. Име датотеке = назив метрике. И постоји начин да се стигне тамо. Имена датотека у Линук-у су ограничена на 255 знакова. А ми имамо (као „интерне купце”) момке из одељења базе података. Кажу нам: „Желимо да надгледамо наше СКЛ упите. И нису 255 карактера, већ по 8 МБ. Желимо да их прикажемо у Графани, да видимо параметре за овај захтев, а још боље, желимо да видимо врх таквих захтева. Биће сјајно ако се прикаже у реалном времену. Било би стварно супер ставити их на узбуну.”

Пример СКЛ упита је узет као пример из сајт постгреспро.ру

Постављамо Редис сервер и користимо наше Цоллецтд додатке, који иду у Постгрес и преузимају све податке одатле, шаљући метрику у Грапхите. Али име метрике замењујемо хешовима. Истовремено шаљемо исти хеш Редис-у као кључ, а цео СКЛ упит као вредност. Све што треба да урадимо је да обезбедимо да Графана може да оде у Редис и узме ове информације. Отварамо Грапхите АПИ јер... ово је главни интерфејс за интеракцију свих компоненти за праћење са графитом и ту уносимо нову функцију под називом алиасБиХасх() - од Графане добијамо назив метрике, и користимо га у захтеву Редис-у као кључ, у одговор добијамо вредност кључа, што је наш "СКЛ упит" " Тако смо у Графани приказали приказ СКЛ упита, који је теоретски било немогуће тамо приказати, заједно са статистиком о њему (позиви, редови, укупно_време, ...).

Резултати

Доступност. Наша услуга праћења доступна је 24/7 из било које апликације и било ког кода. Ако имате приступ складишним просторима, можете уписати податке у услугу. Није битан језик, нису важне одлуке. Потребно је само да знате како да отворите утичницу, ставите метрику тамо и затворите утичницу.

Поузданост. Све компоненте су отпорне на грешке и добро подносе наша оптерећења.

Ниска баријера за улазак. Да бисте користили овај систем, не морате да учите програмске језике и упите у Графани. Само отворите своју апликацију, унесите утичницу у њу која ће слати метрику у Грапхите, затворите је, отворите Графану, креирајте контролне табле тамо и погледајте понашање ваших метрика, примајући обавештења преко Моире.

Независност. Све ово можете да урадите сами, без помоћи ДевОпс инжењера. И ово је предност, јер можете да надгледате свој пројекат одмах, не морате никога да тражите - било да започне рад или да изврши промене.

чему тежимо?

Све доле наведено нису само апстрактне мисли, већ нешто ка чему су учињени барем први кораци.

1. Детектор аномалија. Желимо да направимо услугу која ће ићи у наша Грапхите складишта и проверавати сваку метрику користећи различите алгоритаме. Већ постоје алгоритми које желимо да погледамо, постоје подаци, знамо како да радимо са њима.
2. Метаподаци. Имамо много услуга, оне се временом мењају, као и људи који са њима раде. Стално ручно одржавање документације није опција. Зато сада уграђујемо метаподатке у наше микроуслуге. Наводи ко га је развио, језике са којима комуницира, СЛА захтеве, где и коме треба слати обавештења. Приликом постављања услуге, сви подаци ентитета се креирају независно. Као резултат, добијате две везе - једну до окидача, другу до контролне табле у Графани.
3. Мониторинг у сваком дому. Верујемо да сви програмери треба да користе такав систем. У овом случају увек разумете где је ваш саобраћај, шта се са њим дешава, где пада, где су његове слабости. Ако, на пример, нешто дође и сруши вашу услугу, онда ћете сазнати о томе не током позива од менаџера, већ из упозорења, и можете одмах отворити најновије евиденције и видети шта се тамо догодило.
4. Високих перформанси. Наш пројекат стално расте и данас обрађује око 2 метричких вредности у минути. Пре годину дана ова цифра је била 000 000. И раст се наставља, а то значи да ће након неког времена Графит (шапат) почети да оптерећује подсистем диска. Као што сам већ рекао, овај систем за праћење је прилично универзалан због заменљивости компоненти. Неко одржава и стално проширује своју инфраструктуру посебно за Грапхите, али ми смо одлучили да идемо другим путем: користимо ЦлицкХоусе као складиште за наше метрике. Ова транзиција је скоро завршена и врло брзо ћу вам рећи детаљније како је то урађено: које су потешкоће постојале и како су превазиђене, како је текао процес миграције, описаћу компоненте које су изабране као обавезујуће и њихове конфигурације.

Хвала на пажњи! Постављајте своја питања на тему, покушаћу да одговорим овде или у наредним постовима. Можда неко има искуства у изградњи сличног система за праћење или преласка на Цлицкхоусе у сличној ситуацији - поделите то у коментарима.

Извор: ввв.хабр.цом