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 миллисекунддан аз ката менен эки метриканы ала алган жана 64 МБ оперативдүү эс тутуму бар ARM архитектурасында жана 86 менен x64_32 архитектурасында бирдей эффективдүү иштеген мониторинг тутумун таба алган жокпуз. ГБ оперативдик эс. Ошондуктан, биз мунун баарын жасай ала турган өзүбүздүн жазууну чечтик. Бул жерде бизде эмне бар:
Ар кандай тармак топологиялары үчүн үч каналдын өткөрүү жөндөмдүүлүгүн жалпылоо
Кээ бир негизги көрсөткүчтөрдүн визуализациясы
архитектура
Биз Голангды аппаратта да, маалымат борборунда да негизги программалоо тили катары колдонобуз. Ал көп тапшырманы ишке ашыруу жана ар бир кызмат үчүн бир статикалык байланышкан аткарылуучу бинардык файлды алуу мүмкүнчүлүгү менен жашоону бир топ жөнөкөйлөттү. Натыйжада, биз акыркы түзмөктөргө кызматты жайылтуу үчүн ресурстарды, ыкмаларды жана трафикти, иштеп чыгуу убактысын жана кодду оңдоону кыйла үнөмдөйбүз.
Система классикалык модулдук принцип боюнча ишке ашырылат жана бир нече подсистемаларды камтыйт:
- Метрикаларды каттоо.
Ар бир метрика өз жип менен кызмат кылат жана каналдар боюнча синхрондоштуруу. Биз 10 наносекундка чейин синхрондоштуруунун тактыгына жетише алдык. - Метрикаларды сактоо
Биз убакыт сериялары үчүн өз сактагычыбызды жазууну же мурунтан эле жеткиликтүү болгон нерсени колдонууну тандадык. Маалымат базасы кийинки визуализацияга дуушар болгон ретроспективдүү маалыматтар үчүн керек, башкача айтканда, ал каналдын ар бир 0.5 миллисекундда кечигүүлөрү же транспорт тармагындагы каталардын көрсөткүчтөрү жөнүндө маалыматтарды камтыбайт, бирок ар бир интерфейсте ар бир 500 миллисекундда ылдамдык бар. Кросс-платформага жана ресурстун аз чыгымдалышына жогорку талаптардан тышкары, биз үчүн кайра иштетүүгө жөндөмдүү болуу өтө маанилүү. маалыматтар сакталган жерде болуп саналат. Бул эбегейсиз эсептөө ресурстарын үнөмдөйт. Биз 2016-жылдан бери бул долбоордо Tarantool DBMS колдонуп келебиз жана азырынча горизонтто анын ордун көрө элекпиз. Ийкемдүү, оптималдуу ресурстарды керектөө менен, адекваттуу техникалык колдоодон ашык. Tarantool ошондой эле ГИС модулун ишке ашырат. Албетте, бул PostGIS сыяктуу күчтүү эмес, бирок бул биздин жайгашкан жерге байланыштуу көрсөткүчтөрдү (транспортко тиешелүү) сактоо үчүн жетиштүү. - Метрикалардын визуализациясы
Бул жерде баары салыштырмалуу жөнөкөй. Биз кампадан маалыматтарды алып, аны реалдуу убакытта же ретроспективдүү түрдө көрсөтөбүз. - Борбордук мониторинг системасы менен маалыматтарды синхрондоштуруу.
Борбордук мониторинг системасы бардык түзмөктөрдөн маалыматтарды кабыл алат, аны белгилүү тарыхы менен сактайт жана API аркылуу Кардардын мониторинг системасына жөнөтөт. Классикалык мониторинг системаларынан айырмаланып, анда "баш" айланып, маалыматтарды чогултат, бизде карама-каршы схема бар. Туташуу болгондо түзмөктөр өздөрү маалыматтарды жөнөтүшөт. Бул абдан маанилүү жагдай, анткени ал сиз аппараттан жеткиликтүү болбогон убакыттын ичинде маалыматтарды алууга жана аппарат жеткиликсиз болгон учурда каналдарды жана ресурстарды жүктөөгө мүмкүндүк берет. Биз Influx мониторинг серверин борбордук мониторинг системасы катары колдонобуз. Анын аналогдорунан айырмаланып, ал ретроспективдүү маалыматтарды импорттой алат (башкача айтканда, көрсөткүчтөр алынган учурдан башка убакыт белгиси менен). Чогултулган көрсөткүчтөр 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 кандай экенин эң сонун көрдүңөр жана анын көйгөйлөрүн менсиз билесиңер, андыктан постту сүрөттөр менен ашыкча жүктөбөйм.
жыйынтыктоо
Мен атайылап техникалык деталдарды сүрөттөгөн жокмун, бирок бул системанын негизги дизайнын гана сүрөттөп бердим. Биринчиден, системаны техникалык жактан толук сүрөттөө үчүн дагы бир макала керек болот. Экинчиден, буга баары эле кызыкдар боло бербейт. Кандай техникалык деталдарды билгиңиз келсе, комментарийге жазыңыз.
Эгерде кимде-ким ушул макаланын чегинен тышкары суроолору болсо, анда мага a.rodin @ qedr.com дареги боюнча жазсаңыз болот.
Source: www.habr.com