16 мадэмаў, 4 сотавых аператара = Выходная хуткасць 933.45 Мбіт / с
Увядзенне
Прывітанне! Гэты артыкул пра тое, як мы напісалі для сябе новую сістэму маніторынгу. Ад існых яна адрозніваецца магчымасцю высокачашчыннага сінхроннага атрымання метрык і вельмі маленькім спажываннем рэсурсаў. Частата апытання можа дасягаць 0.1 мілісекунды з дакладнасцю сінхранізацыі паміж метрыкамі ў 10 нанасекунд. Усе бінарныя файлы займаюць 6 мегабайт.
Аб праекце
У нас дастаткова спецыфічны прадукт. Мы вырабляем комплекснае рашэнне для падсумоўвання прапускной здольнасці і адмоваўстойлівасці каналаў перадачы дадзеных. Гэта калі ёсць некалькі каналаў, дапусцім Аператар1 (40Мбіт/з) + Аператар2 (30Мбіт/з)+ Нешта яшчэ(5 Мбіт/з), у выніку атрымліваецца адзін стабільны і хуткі канал, хуткасць якога будзе прыкладна такі: (40+ 30+5)x0.92=75×0.92=69 Мбіт/з.
Такія рашэнні запатрабаваны там, дзе ёмістасць любога аднаго канала недастатковая. Напрыклад транспарт, сістэмы відэа-назірання і струменевай відэа-трансляцыі ў рэальным часе, трансляцыя прамых тэле-радыё-эфіраў, любыя загарадныя аб'екты дзе з аператараў сувязі ёсць толькі прадстаўнікі вялікай чацвёркі і хуткасці на адным мадэме/канале недастаткова.
Для кожнага з гэтых кірункаў мы выпускаем асобную лінейку прылад, аднак праграмная іх частка амаль аднолькавая і якасная сістэма маніторынгу – адзін з галоўных яе модуляў, без правільнай рэалізацыі якога прадукт быў бы немагчымы.
За некалькі гадоў, нам удалося стварыць шматузроўневую хуткую, кросплатформавую і легкаважную сістэму маніторынгу. Чым і жадаем падзяліцца з паважанай супольнасцю.
Пастаноўка задачы
Сістэма маніторынгу забяспечвае атрыманне метрык двух прынцыпова розных класаў: метрыкі рэальнага часу і ўсе астатнія. Да сістэмы маніторынгу было ўсяго наступныя патрабаванні:
- Высокачашчыннае сінхроннае атрыманне метрык рэальнага часу і перадача іх з сістэму кіравання сувяззю без затрымак.
Высокая частата і сінхранізацыя розных метрык - не проста важная, яна жыццёва неабходна для аналізу энтрапіі каналаў перадачы дадзеных. Калі ў адным канале перадачы дадзеных сярэдняя затрымка 30 мілісекунд, то памылка ў сінхранізацыі паміж астатнімі метрыкамі ўсяго на адну мілісекунду, прывядзе да дэградацыі хуткасці выніковага канала прыкладна на 5%. Калі мы памылімся ў сінхранізацыі на 1 мілісекунду ў 4-х каналах, дэградацыя хуткасці лёгка можа зваліцца да 30%. Акрамя гэтага, энтрапія ў каналах мяняецца вельмі хутка, таму калі вымяраць яе радзей чым адзін раз у 0.5 мілісекунд, на хуткіх каналах з маленькай затрымкай мы атрымаем высокую дэградацыю хуткасці. Зразумела, такая дакладнасць патрэбна не для ўсіх метрык і не ва ўсіх умовах. Калі затрымка ў канале будзе 500 мілісекунд, а мы працуем і з такімі, то хібнасць у 1 мілісекунд амаль не будзе прыкметная. Таксама, для метрык сістэм жыццезабеспячэння нам хапае частоты апытання і сінхранізацыі ў 2 секунды, аднак сама па сабе сістэма маніторынгу павінна ўмець працаваць са звышвысокімі частотамі апытання і звышдакладнай сінхранізацыяй метрык. - Мінімальнае спажыванне рэсурсаў і адзіны стэк.
Канчатковая прылада можа ўяўляць з сябе як магутны бартавы комплекс, які можа аналізаваць сітуацыю на дарозе ці весці біяметрычную фіксацыю людзей, так і аднаплатны кампутар памерам у далонь, які носіць пад бронекамізэлькай баец спецпрызна для перадачы відэа ў рэальным часе ва ўмовах дрэннай сувязі. Нягледзячы на такую разнастайнасць архітэктур і вылічальных магутнасцей, нам хацелася б мець аднолькавы праграмны стэк. - Парасонавая архітэктура
Метрыкі павінны збірацца і агрэгавацца на канчатковым прыладзе, мець лакальную сістэму захоўвання і візуалізацыю ў рэжыме рэальнага часу і рэтраспектыўна. У выпадку наяўнасці сувязі - перадаваць дадзеныя ў цэнтральную сістэму маніторынгу. Калі сувязі няма - чарга на адпраўку павінна назапашвацца і не спажываць аператыўную памяць. - API для інтэграцыі ў сістэму маніторынгу замоўца, таму што нікому не трэба шмат сістэм маніторынгу. Заказчык павінен збіраць дадзеныя ад любых прылад і сетак у адзіны маніторынг.
Што атрымалася
Каб нагружаць і без таго вялікі лонгрыд, я не буду прыводзіць прыклады і вымярэнні ўсіх сістэм маніторынгу. Гэта пацягне яшчэ на адзін артыкул. Проста скажу, што нам не ўдалося знайсці сістэму маніторынгу, якая здольная ўзяць дзве метрыкі адначасова з хібнасцю менш за 1 мілісекунду і якая аднолькава эфектыўна працуе як на ARM архітэктуры з 64Мбайт АЗП так і на х86_64 архітэктуры з 32 Гбайт АЗП. Таму мы вырашылі напісаць сваю, якая ўмее вось гэтае вось усё. Вось што ў нас атрымалася:
Сумаванне прапускной здольнасці трох каналаў для рознай тапалогіі сеткі
Візуалізацыя некаторых ключавых метрык
Архітэктура
У якасці асноўнай мовы праграмавання, як на прыладзе так і ў ЦАД, мы выкарыстоўваем Golang. Ён значна спрасціў жыццё сваёй рэалізацыяй шматзадачнасці і магчымасцю атрымаць адзін статычна злінкаваны выкананы бінарны файл для кожнага сэрвісу. У выніку мы значна эканомім у рэсурсах, спосабах і трафіку дэплою сэрвісу на канчатковыя прылады, часу распрацоўкі і адладкі кода.
Сістэма рэалізаваная па класічным модульным прынцыпе і ўтрымоўвае ў сабе некалькі падсістэм:
- Рэгістрацыя метрык.
Кожная метрыка абслугоўваецца ўласным патокам і сінхранізуецца праз каналы. Нам удалося атрымаць дакладнасць сінхранізацыі да 10 нанасекунд. - Захоўванне метрык
Мы выбіралі між тым, каб напісаць сваё сховішча для часовых шэрагаў або выкарыстоўваць нешта з наяўнага. База дадзеных патрэбна для рэтраспектыўных дадзеных, якія падлягаюць наступнай візуалізацыі. Г.зн. у ёй няма дадзеных аб затрымках у канале кожныя 0.5 мілісекунд або сведчаннях памылак у транспартнай сетцы, але ёсць хуткасць на кожным інтэрфейсе кожныя 500 мілісекунд. Апроч высокіх патрабаванняў да кросплатформеннасці і малому спажыванню рэсурсаў, нам вельмі важна мець магчымасць апрацаваць. дадзеныя там жа дзе яны захоўваюцца. Гэта каласальна эканоміць вылічальны рэсурс. Мы з 2016-га года выкарыстоўваем СКБД Tarantool у гэтым праекце і пакуль у гарызонце не бачым яму замены. Гнуткі, з аптымальным спажываннем рэсурсаў, больш за адэкватнай тэхпадтрымкай. Таксама ў Tarantool рэалізаваны GIS модуль. Ён вядома не такі магутны як PostGIS, але яго хапае для нашых задач захоўвання некаторых метрык прывязаных да лакацыі (актуальна для транспарта). - Візуалізацыя метрык
Тут усё адносна проста. Бярэм дадзеныя са сховішча і паказваем іх альбо ў рэальным часе альбо рэтраспектыўна. - Сінхранізацыя дадзеных з цэнтральнай сістэмай маніторынгу.
Цэнтральная сістэма маніторынгу прымае дадзеныя ад усіх прылад, захоўвае іх з зададзенай рэтраспектывай і праз API аддае іх у сістэму маніторынгу Замоўца. У адрозненні ад класічных сістэм маніторынгу, у якіх «галава» ходзіць і збірае дадзеныя – у нас зваротная схема. Прылады самі дасылаюць дадзеныя тады, калі ёсць сувязь. Гэта вельмі важны момант, паколькі ён дазваляе атрымаць дадзеныя з прылады за тыя прамежкі часу, у якія яно было не даступна і не нагружаць каналы і рэсурсы ў той час, калі прылада недаступна. У якасці цэнтральнай сістэмы маніторынгу мы выкарыстоўваем Influx monitoring server. У адрозненні ад аналагаў, умее імпартаваць рэтраспектыўныя дадзеныя (г.зн. з пазнакай часу выдатнай ад моманту атрымання метрыкі) Сабраныя метрыкі візуалізуе дапрацаваная напільнікам Grafana. Гэты стандартны стэк быў абраны яшчэ і таму, што мае гатовыя API інтэграцыі практычна з любой сістэмай маніторынгу заказчыка. - Сінхранізацыя дадзеных з цэнтральнай сістэмай кіравання прыладамі.
Сістэма кіравання прыладамі рэалізуе Zero Touch Provisioning (абнаўленне прашыўкі, канфігурацыі і г.д.) і ў адрозненні ад сістэмы маніторынгу, атрымлівае толькі праблемы па прыладам. Гэта трыгеры працы бартавых апаратных вартаўнічых сэрвісаў і ўсе метрыкі сістэм жыццезабеспячэння: тэмпература CPU і SSD, нагрузка CPU, вольнае месца і SMART здароўе на дысках. Сховішча падсістэмы пабудавана таксама на Tarantool. Гэта дае нам значную хуткасць у агрэгацыі часовых шэрагаў па тысячам прылад, а таксама цалкам вырашае пытанне сінхранізацыі дадзеных з гэтымі прыладамі. У Tarantool убудавана выдатная сістэма чэргаў і гарантаванай дастаўкі. Гэтую важную фічу мы атрымалі са скрынкі, выдатна!
Сістэма кіравання сеткай
Што далей
Пакуль самым слабым звяном у нас з'яўляецца цэнтральная сістэма маніторынгу. Яна рэалізавана на 99.9% на стандартным стэку і ў яе ёсць шэраг недахопаў:
- InfluxDB губляе дадзеныя пры адключэнні харчавання. Як правіла, Заказчык аператыўна забірае ўсё што прыходзіць ад прылад і ў самой БД няма дадзеных старэйшых за 5 хвілін, аднак у будучыні гэта можа стаць болем.
- Grafana мае шэраг праблем з агрэгацыяй дадзеных і сінхроннасцю іх адлюстравання. Самая частая праблема - калі ў базе ляжыць часовы шэраг з інтэрвалам у 2 секунды пачынаючы скажам з 00:00:00, а Grafana пачынае паказваць дадзеныя ў агрэгацыі з +1 секунду. У выніку карыстач бачыць танны графік.
- Залішняя колькасць кода для API інтэграцыі са іншымі сістэмамі маніторынгу. Можна зрабіць значна кампактней і вядома перапісаць на Go)
Мяркую ўсе вы выдатна бачылі як выглядае Grafana і без мяне ведаеце яе праблемы, таму не буду перагружаць пост карцінкамі.
Заключэнне
Я свядома не стаў апісваць тэхнічныя дэталі, а апісаў толькі апорны дызайн гэтай сістэмы. У першых, каб тэхнічна поўна апісаць сістэму запатрабуецца яшчэ адзін артыкул. Па-другое, далёка не ўсім будзе гэта цікава. Напішыце ў каментарах якія тэхнічныя дэталі вам хацелася б даведацца.
Калі ў кагосьці ўзнікнуць пытанні па-за межамі гэтага артыкула, мне можна пісаць на адрас [email protected]
Крыніца: habr.com