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 миллисекунд сайын жылдамдық бар. Кросс-платформаға қойылатын жоғары талаптарға және ресурстарды аз тұтынуға қоса, біз үшін өңдеу мүмкіндігі өте маңызды. деректер сақталатын жер болып табылады. Бұл үлкен есептеу ресурстарын үнемдейді. Біз бұл жобада Tarantool ДҚБЖ-ны 2016 жылдан бері қолданып келеміз және әлі күнге дейін көкжиекте оны алмастырушыны көрмейміз. Икемді, оңтайлы ресурстарды тұтынумен, барабар техникалық қолдаудан артық. Tarantool сонымен қатар GIS модулін жүзеге асырады. Әрине, бұл PostGIS сияқты қуатты емес, бірақ бұл кейбір орынға қатысты көрсеткіштерді (тасымалдауға қатысты) сақтау міндеттеріміз үшін жеткілікті. - Метрикаларды визуализациялау
Мұнда бәрі салыстырмалы түрде қарапайым. Біз қоймадан деректерді аламыз және оны нақты уақытта немесе ретроспективті түрде көрсетеміз. - Мәліметтерді орталық бақылау жүйесімен синхрондау.
Орталық бақылау жүйесі барлық құрылғылардан деректерді алады, оны белгілі бір тарихпен сақтайды және API арқылы Тұтынушының мониторинг жүйесіне жібереді. Классикалық бақылау жүйелерінен айырмашылығы, онда «бас» жүріп, деректер жинайды, бізде керісінше схема бар. Қосылым болған кезде құрылғылардың өзі деректерді жібереді. Бұл өте маңызды сәт, өйткені ол құрылғыдан ол қолжетімді болмаған уақыт кезеңдері үшін деректерді алуға және құрылғы қолжетімсіз болған кезде арналар мен ресурстарды жүктемеуге мүмкіндік береді. Біз Influx мониторинг серверін орталық бақылау жүйесі ретінде пайдаланамыз. Өзінің аналогтарынан айырмашылығы, ол ретроспективті деректерді импорттай алады (яғни, көрсеткіштер алынған сәттен басқа уақыт белгісімен).Жиналған көрсеткіштер файлмен өзгертілген Grafana арқылы визуалды. Бұл стандартты стек сонымен қатар кез келген тұтынушыны бақылау жүйесімен дайын API интеграциясына ие болғандықтан таңдалды. - Орталық құрылғыны басқару жүйесімен деректерді синхрондау.
Құрылғыны басқару жүйесі Zero Touch Provisioning (микробағдарламаны жаңарту, конфигурациялау және т. Бұл борттық аппараттық бақылау қызметтерінің жұмысына арналған триггерлер және өмірді қамтамасыз ету жүйелерінің барлық көрсеткіштері: процессор мен SSD температурасы, процессордың жүктемесі, бос орын және дискілердегі SMART денсаулығы. Ішкі жүйе қоймасы сонымен қатар Tarantool жүйесінде жасалған. Бұл мыңдаған құрылғыларда уақыт қатарларын жинақтауда айтарлықтай жылдамдық береді, сонымен қатар деректерді осы құрылғылармен синхрондау мәселесін толығымен шешеді. Tarantool-да тамаша кезек және кепілді жеткізу жүйесі бар. Біз бұл маңызды мүмкіндікті қораптан алдық, тамаша!
Желіні басқару жүйесі
Ары қарай не
Әзірге біздің ең әлсіз буынымыз – орталық бақылау жүйесі. Ол стандартты стекте 99.9% орындалды және бірқатар кемшіліктері бар:
- InfluxDB қуат жоғалған кезде деректерді жоғалтады. Әдетте, Тұтынушы құрылғылардан келетін барлық нәрсені дереу жинайды және дерекқордың өзінде 5 минуттан асқан деректер жоқ, бірақ болашақта бұл ауыртпалық болуы мүмкін.
- Grafana-да деректерді жинақтау және оның дисплейін синхрондау кезінде бірқатар проблемалар бар. Ең жиі кездесетін мәселе - дерекқорда, мысалы, 2:00:00-ден басталатын 00 секунд аралығы бар уақыт қатары болғанда және Grafana +1 секундтан бастап біріктірілген деректерді көрсете бастайды. Нәтижесінде пайдаланушы билеу графигін көреді.
- Үшінші тарап бақылау жүйелерімен API интеграциясы үшін кодтың шамадан тыс мөлшері. Оны әлдеқайда ықшам етіп жасауға және, әрине, Go бағдарламасында қайта жазуға болады)
Менің ойымша, сіз бәріңіз Графананың қандай екенін жақсы көрдіңіз және менсіз оның мәселелерін білесіз, сондықтан мен постты суреттермен шамадан тыс жүктемеймін.
қорытынды
Мен әдейі техникалық бөлшектерді сипаттамадым, тек осы жүйенің негізгі дизайнын сипаттадым. Біріншіден, жүйені техникалық толық сипаттау үшін басқа мақала қажет болады. Екіншіден, бұған бәрі бірдей қызығушылық танытпайды. Түсініктемелерде қандай техникалық мәліметтерді білгіңіз келетінін жазыңыз.
Егер кімде-кім осы мақаланың шеңберінен тыс сұрақтары болса, сіз маған a.rodin @ qedr.com мекенжайына жаза аласыз.
Ақпарат көзі: www.habr.com