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

Денес, покрај монолитен код, нашиот проект вклучува десетици микроуслуги. Секој од нив бара да се следи. Да се ​​направи ова во таков обем со помош на инженери DevOps е проблематично. Развивме систем за следење кој работи како услуга за програмери. Тие можат самостојно да пишуваат метрики во системот за следење, да ги користат, да градат контролни табли врз основа на нив и да им прикачуваат предупредувања што ќе се активираат кога ќе се достигнат вредностите на прагот. За инженерите на DevOps, само инфраструктура и документација.

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

Минатото: шеми и планови

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

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

Имаме складирање на метрика: ова се графити, кои ќе се базираат на брзи SSD-дискови, ова се одредени агрегатори за метрика. Следно - Графана за прикажување контролни табли и Моира за предупредување. Исто така, сакавме да развиеме систем за пребарување на аномалии.

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

Вака изгледаа плановите во 2015. Но моравме да ја подготвиме не само инфраструктурата и самата услуга, туку и документацијата за неа. Развивме корпоративен стандард за себе, кој го нарекуваме мониторинг 2.0. Кои беа барањата за системот?

• постојана достапност;
• интервал на складирање на метрика = 10 секунди;
• структурирано складирање на метрика и контролни табли;
• SLA > 99,99%
• колекција на метрика на настани преку UDP (!).

Ни требаше UDP затоа што имаме голем проток на сообраќај и настани што генерираат метрика. Ако ги напишете сите на графит одеднаш, складиштето ќе пропадне. Избравме и префикси од прво ниво за сите метрики.

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

Тековно: дијаграм на интеракција на компонентите за следење

Пред сè, ги следиме апликациите: нашиот PHP код, апликациите и микросервисите - накратко, сè што пишуваат нашите програмери. Сите апликации испраќаат метрика преку UDP до агрегаторот на Brubeck (statsd, препишан во C). Испадна дека е најбрз во синтетичките тестови. И ги испраќа веќе собраните метрики до Graphite преку TCP.

Има еден вид метрика наречени тајмери. Ова е многу погодна работа. На пример, за секое корисничко поврзување со услугата, испраќате метрика со време на одговор до Brubeck. Дојдоа милион одговори, но агрегаторот врати само 10 метрики. Имате број на луѓе кои дојдоа, максимално, минимално и просечно време на одговор, медијана и 4 перцентили. Потоа податоците се пренесуваат на Graphite и сето тоа го гледаме во живо.

Имаме и агрегација за метрика на хардвер, софтвер, системска метрика и нашиот стар систем за следење Munin (нам работеше до 2015 година). Сето ова го собираме преку C daemon CollectD (има цел куп различни приклучоци вградени во него, може да ги анкетира сите ресурси на системот домаќин на кој е инсталиран, само наведете во конфигурацијата каде да се запишуваат податоците) и преку него запишете ги податоците на Graphite. Исто така, поддржува python приклучоци и скрипти за школка, за да можете да напишете свои сопствени решенија: CollectD ќе ги собере овие податоци од локален или оддалечен домаќин (претпоставувајќи Curl) и ќе ги испрати до Graphite.

Потоа ги испраќаме сите метрики што ги собравме во Carbon-c-релето. Ова е решението Carbon Relay од Graphite, модифицирано во C. Ова е рутер што ги собира сите метрики што ги испраќаме од нашите агрегатори и ги насочува до јазли. Исто така, во фазата на рутирање, ја проверува валидноста на метриката. Прво, тие мора да одговараат на шемата за префикс што ја покажав претходно и, второ, тие важат за графит. Во спротивно тие ќе паднат.

Јаглерод-c-релето потоа ја испраќа метриката до кластерот Графит. Ние користиме Carbon-cache, препишан во Go, како главно складирање на метрика. Go-carbon, поради неговата повеќенишка, далеку го надминува Carbon-cache. Добива податоци и ги запишува на дискови користејќи го пакетот whisper (стандарден, напишан во python). За да читаме податоци од нашите складишта, го користиме Graphite API. Тој е многу побрз од стандардниот Graphite WEB. Што се случува понатаму со податоците?

Одат во Графана. Ги користиме нашите графитни кластери како главен извор на податоци, плус ја имаме Grafana како веб-интерфејс за прикажување на метрика и градење контролни табли. За секоја нивна услуга, програмерите создаваат своја контролна табла. Потоа врз основа на нив градат графикони, кои ги прикажуваат метриките што ги пишуваат од нивните апликации. Покрај Графана имаме и СЛЕМ. Ова е демон на питон кој пресметува SLA врз основа на податоци од графит. Како што веќе реков, имаме неколку десетици микросервиси, од кои секоја има свои барања. Користејќи SLAM, одиме до документацијата и ја споредуваме со она што е во Графит и споредуваме колку барањата одговараат на достапноста на нашите услуги.

Ајде да одиме понатаму: алармирање. Таа е организирана со помош на силен систем - Моира. Независен е бидејќи има свој графит под хаубата. Развиено од момците од СКБ „Контур“, напишано во python и Go, целосно со отворен код. Моира го добива истиот проток што оди во графитите. Ако поради некоја причина вашето складирање згасне, вашето предупредување сепак ќе работи.

Ја распоредивме Moira во Kubernetes; тој користи кластер од сервери Redis како главна база на податоци. Резултатот беше систем толерантен на грешки. Го споредува протокот на метрика со списокот на предизвикувачи: ако во него нема споменувања, тогаш ја исфрла метриката. Така, тој е во состојба да свари гигабајти метрика во минута.

Прикачивме и корпоративен LDAP, со помош на кој секој корисник на корпоративниот систем може да креира известувања за себе врз основа на постоечки (или новосоздадени) предизвикувачи. Бидејќи Moira содржи графит, ги поддржува сите негови функции. Така, прво ја земате линијата и ја копирате во Графана. Погледнете како податоците се прикажуваат на графиконите. И тогаш ја земате истата линија и ја копирате во Моира. Го обесувате со ограничувања и добивате предупредување на излезот. За да го направите сето ова, не ви треба некое конкретно знаење. Moira може да алармира преку СМС, е-пошта, Jira, Slack... Исто така, поддржува извршување на сопствени скрипти. Кога ќе и се случи активирач, и таа е претплатена на приспособена скрипта или бинарна, таа ја извршува и испраќа JSON до stdin за оваа бинарна верзија. Според тоа, вашата програма мора да ја анализира. Што ќе правите со овој JSON зависи од вас. Ако сакаш прати го на Телеграм, ако сакаш отвори задачи во Џира, направи што.

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

Па, бидејќи сме прогресивна компанија, го следевме и Кубернетес во овој систем. Го вклучивме во системот користејќи Heapster, кој го инсталиравме во кластерот, тој собира податоци и ги испраќа до Graphite. Како резултат на тоа, дијаграмот изгледа вака:

Компоненти за следење

Еве список на врски до компонентите што ги користевме за оваа задача. Сите тие се со отворен код.

Графит:

• го-јаглерод: github.com/lomik/go-carbon
• шепоти: github.com/graphite-project/whisper
• графит-апи: github.com/brutasse/graphite-api

Јаглерод-c-реле:

github.com/grobian/carbon-c-relay

Брубек:

github.com/github/brubeck

Собрано:

собрани.org

Моира:

github.com/moira-alert

Графана:

grafana.com

Heapster:

github.com/kubernetes/heapster

статистика

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

Агрегатор (Брубек)

Број на метрика: ~300/сек
Интервал за испраќање метрика на графит: 30 сек
Користење на ресурси на серверот: ~ 6% процесор (зборуваме за полноправни сервери); ~ 1 GB RAM; ~3 Mbps LAN

Графит (го-јаглерод)

Број на метрика: ~ 1 / мин
Интервал на ажурирање на метриката: 30 сек
Шема за складирање метрика: 30 сек. 35д, 5мин. 90д., 10мин. 365д. (ви дава разбирање за тоа што се случува со услугата во подолг временски период)
Користење на ресурси на серверот: ~10% процесор; ~ 20 Gb RAM; ~30 Mbps LAN

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

Ние во Avito навистина ја цениме флексибилноста во нашата услуга за следење. Зошто всушност испадна вака? Прво, неговите компоненти се заменливи: и самите компоненти и нивните верзии. Второ, поддршка. Бидејќи целиот проект е со отворен код, можете сами да го уредувате кодот, да правите промени и да имплементирате функции што не се достапни надвор од кутијата. Се користат доста вообичаени стекови, главно Go и Python, така што ова се прави сосема едноставно.

Еве пример за вистински проблем. Метрика во Графит е датотека. Има име. Име на датотека = метричко име. И постои начин да се стигне до таму. Имињата на датотеките во Linux се ограничени на 255 знаци. И ние имаме (како „внатрешни клиенти“) момци од одделот за база на податоци. Тие ни велат: „Сакаме да ги следиме нашите SQL прашања. И тие не се 255 знаци, туку по 8 MB. Сакаме да ги прикажеме во Графана, да ги видиме параметрите за ова барање и уште подобро, сакаме да го видиме врвот на таквите барања. Ќе биде одлично ако се прикажува во реално време. Би било навистина кул да ги ставиме во штрек“.

Примерот SQL барање е земен како пример од страницата postgrespro.ru

Поставивме Redis сервер и ги користиме нашите приклучоци Collectd, кои одат во Postgres и ги земаат сите податоци од таму, испраќајќи метрика до Graphite. Но, метричкото име го заменуваме со хашови. Истовремено го испраќаме истиот хаш до Redis како клуч и целото SQL барање како вредност. Сè што треба да направиме е да се погрижиме Графана да оди во Редис и да ги земе овие информации. Го отвораме Graphite API бидејќи... ова е главниот интерфејс за интеракција на сите компоненти за следење со графит, и таму внесуваме нова функција наречена aliasByHash() - од Grafana го добиваме името на метриката и ја користиме во барање до Redis како клуч, во одговор ја добиваме вредноста на клучот, што е нашето „SQL барање“ Така, во Grafana прикажавме приказ на SQL барање, кое теоретски беше невозможно да се прикаже таму, заедно со статистиката за него (повици, редови, total_time, ...).

Резултатите од

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

Сигурност. Сите компоненти се толерантни на грешки и добро се справуваат со нашите товари.

Ниска бариера за влез. За да го користите овој систем, не треба да учите програмски јазици и прашања во Графана. Само отворете ја вашата апликација, внесете штекер во неа што ќе испраќа метрика на Graphite, затворете ја, отворете ја Grafana, креирајте контролни табли таму и погледнете го однесувањето на вашите метрики, примајќи известувања преку Moira.

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

На што целиме?

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

1. Детектор за аномалија. Сакаме да создадеме услуга што ќе оди во нашите складишта за графит и ќе ја проверува секоја метрика користејќи различни алгоритми. Веќе има алгоритми кои сакаме да ги гледаме, има податоци, знаеме како да работиме со нив.
2. Метаподатоци. Имаме многу услуги, тие се менуваат со текот на времето, исто како и луѓето кои работат со нив. Постојаното одржување на документацијата рачно не е опција. Затоа сега ги вградуваме метаподатоците во нашите микроуслуги. Се наведува кој го развил, јазиците со кои комуницира, барањата за SLA, каде и на кого треба да се испраќаат известувања. При распоредување услуга, сите податоци за ентитетите се креираат независно. Како резултат на тоа, добивате две врски - едната до активирачите, другата до контролните табли во Графана.
3. Мониторинг во секој дом. Сметаме дека сите програмери треба да користат таков систем. Во овој случај, секогаш разбирате каде е вашиот сообраќај, што се случува со него, каде паѓа, каде се неговите слабости. Ако, на пример, нешто дојде и ја урна вашата услуга, тогаш ќе дознаете за тоа не за време на повик од менаџерот, туку од предупредување, и можете веднаш да ги отворите најновите дневници и да видите што се случило таму.
4. Високи перформанси. Нашиот проект постојано расте, а денес обработува околу 2 метрички вредности во минута. Пред една година оваа бројка беше 000. И растот продолжува, а тоа значи дека по некое време Графитот (шепот) ќе почне силно да го вчитува подсистемот на дискот. Како што веќе реков, овој систем за следење е доста универзален поради заменливоста на компонентите. Некој ја одржува и постојано ја проширува својата инфраструктура специјално за Graphite, но ние решивме да тргнеме по друг пат: користење Кликни куќа како складиште за нашите метрики. Оваа транзиција е речиси завршена, а наскоро ќе ви кажам подетално како е направено тоа: какви тешкотии имаше и како беа надминати, како помина процесот на миграција, ќе ги опишам компонентите избрани како обврзувачки и нивните конфигурации.

Ви благодариме за вниманието! Поставете ги вашите прашања на темата, ќе се обидам да одговорам овде или во следните постови. Можеби некој има искуство да изгради сличен систем за следење или да се префрли на Clickhouse во слична ситуација - споделете го во коментарите.

Извор: www.habr.com