Ошентип, сиз көрсөткүчтөрдү чогултасыз. Биз болгондой. Биз ошондой эле көрсөткүчтөрдү чогултабыз. Албетте, бизнес үчүн зарыл. Бүгүн биз мониторинг системабыздын эң биринчи шилтемеси - statsd менен шайкеш топтоо сервери жөнүндө сүйлөшөбүз. , эмне үчүн жаздык жана эмне үчүн брубекти таштадык.
Мурунку макалаларыбыздан (, ) бир нече убакытка чейин биз белгилерди колдонуп жүргөнүбүздү биле аласыз . Ал C тилинде жазылган. Коддун көз карашынан алганда, бул штепсель сыяктуу жөнөкөй (бул сиз салым кошкуңуз келген учурда маанилүү) жана эң негизгиси, ал секундасына 2 миллион метрлик көлөмүн (MPS) эң жогорку чегинде иштетет. эч кандай көйгөйлөр жок. Документте жылдызча менен 4 миллион MPS колдоо көрсөтүлгөн. Бул Linux тармагында тармакты туура конфигурацияласаңыз, көрсөтүлгөн цифраны аласыз дегенди билдирет. (Сиз тармакты ошол бойдон калтырсаңыз, канча MPS ала аларыңызды билбейбиз). Бул артыкчылыктарга карабастан, биз брубекке бир нече олуттуу даттанууларды алдык.
1-доо. Долбоордун иштеп чыгуучусу Github аны колдоону токтотту: патчтарды жана оңдоолорду жарыялоо, биздики жана (биздики гана эмес) пиарды кабыл алуу. Акыркы бир нече айдын ичинде (2018-жылдын февраль-март айларында) активдүүлүк кайра жанданды, бирок ага чейин дээрлик 2 жыл толук тынччылык болгон. Мындан тышкары, долбоор иштелип жатат , бул жаңы функцияларды киргизүүгө олуттуу тоскоолдук болуп калышы мүмкүн.
2-доо. Эсептөөлөрдүн тактыгы. Брубек бириктирүү үчүн жалпысынан 65536 баалуулуктарды чогултат. Биздин учурда, кээ бир көрсөткүчтөр үчүн, топтоо мезгилинде (30 секунд) алда канча көп маанилер келиши мүмкүн (чокусунда 1). Бул тандоонун натыйжасында максималдуу жана минималдуу маанилер пайдасыз болуп калат. Мисалы, бул сыяктуу:
Болгондой
Кандай болушу керек эле
Ушул эле себептен улам, жалпысынан суммалар туура эмес эсептелет. Бул жерге 32-бит флоат толуп кеткен мүчүлүштүктөрдү кошуңуз, ал жалпысынан бейкүнөө көрсөткүчтү алганда серверди segfaultга жөнөтөт жана баары сонун болуп калат. Баса, ката оңдолгон жок.
Анан да, акырында, Доомат X. Жазып жаткан учурда, биз аны таба алган бардык 14 аз же азыраак иштеген статистикалык ишке ашырууга берүүгө даярбыз. Элестетип көрөлү, кээ бир инфраструктура ушунчалык өсүп кеткендиктен, 4 миллион МПС кабыл алуу жетишсиз болуп калды. Же ал али өсө элек болсо да, бирок көрсөткүчтөр сиз үчүн ушунчалык маанилүү болгондуктан, диаграммалардагы кыска, 2-3 мүнөттүк чөгүп кетүү да критикалык болуп, менеджерлер арасында жеңе алгыс депрессияга алып келиши мүмкүн. Депрессияны дарылоо шүгүрсүз иш болгондуктан, техникалык чечимдер керек.
Биринчиден, серверде күтүлбөгөн жерден көйгөй офисте психиатриялык зомби апокалипсисине алып келбеши үчүн, каталарга сабырдуулук. Экинчиден, Linux тармагынын стекине терең кирбестен, 4 миллиондон ашык MPS кабыл алуу үчүн масштабдоо жана талап кылынган өлчөмгө "кеңдигинде" тынч өсүү.
Бизде масштабды кеңейтүү үчүн орун бар болгондуктан, биз каталарга сабырдуулук менен баштоону чечтик. "ТУУРАЛУУ! Күнөөлөргө сабырдуулук! Бул жөнөкөй, биз муну жасай алабыз ", - деп ойлоп, 2 серверди ишке киргизип, ар биринде брубектин көчүрмөсүн көтөрдүк. Бул үчүн, биз трафикти эки серверге тең метрика менен көчүрүп, жада калса бул үчүн жазышыбыз керек болчу . Биз муну менен катага сабырдуулук маселесин чечтик, бирок... анча деле жакшы эмес. Адегенде баары сонун көрүндү: ар бир брубек топтоонун өз версиясын чогултат, 30 секундада бир жолу Graphiteге маалыматтарды жазып, эски интервалдын үстүнөн жазып турат (бул Графит тарабында жасалат). Эгер бир сервер күтүлбөгөн жерден иштебей калса, бизде ар дайым топтолгон маалыматтардын өзүнүн көчүрмөсү бар экинчи сервер болот. Бирок бул жерде көйгөй бар: сервер иштебей калса, графиктерде "ара" пайда болот. Бул Брюбектин 30 секунддук интервалдары синхрондолбогондуктан, кыйроо учурунда алардын биринин үстүнө жазылбай калгандыгы менен түшүндүрүлөт. Экинчи сервер башталганда, ошол эле нерсе болот. Абдан чыдамдуу, бирок мен жакшыраак каалайм! Масштабдуулук маселеси да жоюла элек. Бардык метрика дагы эле бир серверге "учат", демек, тармактын деңгээлине жараша биз ошол эле 2-4 миллион MPS менен чектелебиз.
Эгер сиз көйгөй жөнүндө бир аз ойлонуп, ошол эле учурда күрөк менен карды казып алсаңыз, анда төмөнкү ачык идея эсиңизге келиши мүмкүн: сизге бөлүштүрүлгөн режимде иштей ала турган statsd керек. Башкача айтканда, убакыт жана метрика боюнча түйүндөр ортосунда синхрондоштурууну ишке ашырган. "Албетте, мындай чечим мурунтан эле бар" дедик жана биз Google'га бардык .... Ошондо алар эч нерсе табышкан жок. Ар кандай statsd үчүн документтерди карап чыккандан кийин ( 11.12.2017-жылдын XNUMX-декабрына карата), биз эч нерсе тапкан жокпуз. Сыягы, иштеп чыгуучулар да, бул чечимдерди колдонуучулар дагы Мынча көп метрикага туш боло элек, антпесе алар сөзсүз түрдө бир нерсе ойлоп табышмак.
Анан биз "Оюнчук" статистикасын эстедик - "Жөн эле көңүл ачуу үчүн" хакатонунда жазылган (долбоордун аталышы хакатон башталганга чейин сценарий тарабынан түзүлгөн) жана бизге тез арада өзүбүздүн статистикабыз керек экенин түшүндүк. Эмне үчүн?
- анткени дүйнөдө статистикалык клондор өтө аз,
- анткени ал каалаган же керектүү катага чыдамдуулугун жана масштабдуулугун камсыз кылууга мүмкүн (анын ичинде серверлер ортосунда топтолгон метрикаларды синхрондоштуруу жана конфликттерди жөнөтүү маселесин чечүү),
- анткени ал Брюбекке караганда метриканы так эсептесе болот,
- анткени сиз Брубек бизге иш жүзүндө бербеген деталдуу статистиканы өзүңүз чогулта аласыз,
- анткени мен өзүмдүн hyperperformance бөлүштүрүлгөн масштабдуу лабораториялык тиркемени программалоого мүмкүнчүлүк алдым, ал дагы бир окшош гиперфордун архитектурасын толугу менен кайталабайт ... ошондой эле.
Эмнеге жазуу керек? Албетте, Руста. Неге?
- анткени буга чейин прототиби чечим бар болчу,
- анткени макаланын автору ошол кезде Rustту мурунтан эле билген жана аны ачык булакка коюу мүмкүнчүлүгү менен өндүрүш үчүн бир нерсе жазууга дилгир болгон,
- анткени GC менен тилдер алынган трафиктин мүнөзүнөн (дээрлик реалдуу убакытта) бизге ылайыктуу эмес жана GC тыныгуулары иш жүзүндө кабыл алынбайт,
- анткени сизге C менен салыштырылуучу максималдуу аткаруу керек
- анткени Rust бизге коркпостон параллелдүүлүктү камсыз кылат жана эгерде биз аны C/C++ тилинде жаза баштасак, анда биз брубекке караганда көбүрөөк аялуу жерлерге, буфердик толуп кетүүлөргө, расалык шарттарга жана башка коркунучтуу сөздөргө ээ болмокпуз.
Рустка каршы да аргумент болгон. Компаниянын Руста долбоорлорду түзүү тажрыйбасы болгон эмес, эми аны негизги долбоордо да колдонууну пландаган жокпуз. Ошондуктан, эч нерсе болбой калат деген олуттуу кооптонуулар болду, бирок биз мүмкүнчүлүк алууну чечтик жана аракет кылдык.
Убакыт өттү...
Акыры, бир нече ийгиликсиз аракеттерден кийин, биринчи жумушчу версия даяр болду. Не болду? Бул эмне болду.
Ар бир түйүн өзүнүн метрика топтомун алат жана аларды топтойт жана акыркы топтоо үчүн алардын толук топтому талап кылынган типтер үчүн көрсөткүчтөрдү бириктирбейт. Түйүндөр бири-бири менен кандайдыр бир бөлүштүрүлгөн кулпу протоколу аркылуу туташты, бул алардын арасынан Улууга метрика жөнөтүүгө татыктуу жалгызды (бул жерде биз ыйладык) тандоого мүмкүндүк берет. Учурда бул маселе чечилүүдө , бирок келечекте автордун амбициялары созулат Raft, бул жерде эң татыктуусу, албетте, консенсустун лидери түйүн болот. Консенсустан тышкары, түйүндөр көбүнчө (демейки боюнча секундасына бир жолу) кошуналарына ошол секундда чогулта алган алдын ала топтолгон көрсөткүчтөрдүн бөлүктөрүн жөнөтүшөт. Көрсө, масштабдоо жана катага чыдамдуулук сакталат - ар бир түйүндө дагы эле метрикалардын толук топтому сакталат, бирок метрикалар TCP аркылуу топтолуп жөнөтүлүп, бинардык протоколго коддолгон, ошондуктан UDP менен салыштырганда кайталоо чыгымдары бир топ кыскарат. Кирүүчү метрикалардын кыйла көп санына карабастан, топтоо өтө аз эстутумду жана андан да аз CPUну талап кылат. Биздин өтө кысылган мертиктерибиз үчүн бул бир нече ондогон мегабайт маалымат. Кошумча бонус катары, биз Бербекке окшоп, Graphite'де керексиз маалыматтарды кайра жаза албайбыз.
Өлчөмдөрү бар UDP пакеттери жөнөкөй Round Robin аркылуу тармактык жабдуулардын түйүндөрүнүн ортосунда тең салмактуу эмес. Албетте, тармактык жабдык пакеттердин мазмунун талдабайт жана ошондуктан секундасына 4 миллиондон ашык пакеттерди тарта алат, ал жөнүндө эч нерсе билбеген метрикаларды айтпаганда да. Эгерде биз метрикалар ар бир пакетте бирден келбей турганын эске алсак, анда биз бул жерде эч кандай аткаруу көйгөйлөрүн алдын ала албайбыз. Эгерде сервер бузулса, тармак түзмөгү бул фактыны тез (1-2 секунданын ичинде) аныктайт жана бузулган серверди айлануудан алып салат. Натыйжада, пассивдүү (башкача айтканда, лидер эмес) түйүндөр диаграммалардагы төмөндөөлөрдү байкабастан, иш жүзүндө күйгүзүлүп жана өчүрүлүшү мүмкүн. Биз жогото турган максимум акыркы секундада келген көрсөткүчтөрдүн бир бөлүгү болуп саналат. Лидердин күтүлбөгөн жерден жоголушу/өчүрүлүүсү/которулуусу дагы эле кичине аномалияны жаратат (30 секунддук интервал дагы эле синхрондоштуруудан тышкары), бирок түйүндөр ортосунда байланыш болсо, бул көйгөйлөрдү, мисалы, синхрондоштуруу пакеттерин жөнөтүү аркылуу азайтууга болот. .
Ички түзүлүшү жөнүндө бир аз. Тиркеме, албетте, көп агымдуу, бирок жип түзүү архитектурасы брубекте колдонулгандан башкача. Брюбектеги жиптер бирдей - алардын ар бири маалымат чогултуу жана бириктирүү үчүн жооп берет. Биоинодо жумушчулар эки топко белунет: тармакка жооптуулар жана топтоштуруу учун жооптуулар. Бул бөлүү көрсөткүчтөрдүн түрүнө жараша тиркемени ийкемдүү башкарууга мүмкүндүк берет: интенсивдүү топтоо талап кылынган жерде агрегаторлорду кошсоңуз болот, тармактык трафик көп болсо, тармак агымдарынын санын кошо аласыз. Учурда биздин серверлерде биз 8 тармакта жана 4 агрегациялык агымда иштейбиз.
Эсептөө (жыйноо үчүн жооптуу) бөлүгү абдан кызыксыз. Тармак агымдары менен толтурулган буферлер агымдарды эсептөөнүн ортосунда бөлүштүрүлөт, анда алар кийинчерээк талданат жана бириктирилет. Сурам боюнча, башка түйүндөргө жөнөтүү үчүн көрсөткүчтөр берилет. Мунун баары, анын ичинде түйүндөрдүн ортосунда маалыматтарды жөнөтүү жана консул менен иштөө асинхрондуу түрдө, алкактарда иштейт. .
Өнүктүрүү учурундагы көп көйгөйлөр метрикаларды кабыл алууга жооптуу тармак бөлүгүнөн келип чыккан. Тармак агымдарын өзүнчө объекттерге бөлүүнүн негизги максаты агым сарптаган убакытты кыскартуу болгон. жок розеткадан маалыматтарды окуу үчүн. Асинхрондук UDP жана кадимки recvmsg колдонуу параметрлери тез эле жок болду: биринчиси окуяны иштетүү үчүн колдонуучу мейкиндигиндеги CPU өтө көп керектелет, экинчиси өтө көп контексттик которуштурууну талап кылат. Ошондуктан азыр колдонулат чоң буферлер менен (жана буферлер, мырзалар, силер үчүн эч нерсе эмес!). Кадимки UDP колдоосу recvmmsg кереги жок жеңил учурларда сакталат. Мультимессаж режиминде негизги нерсеге жетишүүгө болот: көпчүлүк учурда тармак жип OS кезегин тырмалайт - розеткадан маалыматтарды окуйт жана аны колдонуучулар мейкиндигинин буферине өткөрүп берет, кээде гана толтурулган буферди берүүгө өтүшөт. агрегаторлор. Розеткадагы кезек иш жүзүндө топтолбойт, түшүп калган пакеттердин саны дээрлик өспөйт.
пикир
Демейки жөндөөлөрдө буфердин өлчөмү абдан чоң болуп коюлган. Эгер сиз күтүлбөгөн жерден серверди өзүңүздү сынап көрүүнү чечсеңиз, аз сандагы метрикаларды жөнөткөндөн кийин, алар тармактык агым буферинде калган Graphiteге келбей калышы мүмкүн. Аз сандагы метрика менен иштөө үчүн, конфигурацияда буфсизди жана тапшырма-кезеги өлчөмүн кичине маанилерге коюшуңуз керек.
Акыр-аягы, диаграмма сүйүүчүлөр үчүн кээ бир диаграммалар.
Ар бир сервер үчүн кирген метрикалардын саны боюнча статистика: 2 миллиондон ашык MPS.
Түйүндөрдүн бирин өчүрүү жана келген көрсөткүчтөрдү кайра бөлүштүрүү.
Чыгуучу метрика боюнча статистика: бир гана түйүн дайыма жөнөтөт - рейд башчысы.
Ар кандай система модулдарындагы каталарды эске алуу менен ар бир түйүндүн иштөө статистикасы.
Кирүүчү көрсөткүчтөрдүн деталдары (метрикалык аталыштар жашырылган).
Мунун баары менен мындан ары эмне кылууну пландап жатабыз? Албетте, кодду жаз, наалат...! Долбоор башында ачык булак болушу пландалган жана өмүр бою ушундай бойдон кала берет. Биздин жакынкы пландарыбызга өзүбүздүн Raft версиясына өтүү, теңдеш протоколду көчмө протоколго өзгөртүү, кошумча ички статистиканы, метрикалардын жаңы түрлөрүн, мүчүлүштүктөрдү оңдоо жана башка жакшыртууларды киргизүү кирет.
Албетте, ар бир адам долбоорду өнүктүрүүгө жардам берүүгө даяр: PR түзүү, Маселелер, мүмкүн болсо, биз жооп беребиз, жакшыртабыз, ж.б.
Ушуну менен, баары ушундай, биздин пилдерди сатып алгыла!
Source: www.habr.com