Бір жыл бұрын біз жарнамалық жобаның пилоттық нұсқасын іске қостық .
Бастапқыда жоба Road-To-Barselona деп аталды, кейінірек ол Road-To-Berlin болды (осылайша скриншоттарда R2B), ал соңында ол xRide деп аталды.
Жобаның негізгі идеясы мынада болды: орталықтандырылған автокөлік немесе скутерді жалға беру қызметінің орнына (біз скутерлер/скутерлер емес, скутерлер, яғни электр мотоциклдері туралы айтып отырмыз) біз орталықтандырылмаған жалға алу үшін платформа жасағымыз келді. Біз кездескен қиындықтар туралы .
Бастапқыда жоба автомобильдерге бағытталған, бірақ мерзімдерге, өндірушілермен өте ұзақ байланысқа және көптеген қауіпсіздік шектеулеріне байланысты ұшқыш үшін электр скутерлері таңдалды.
Қолданушы телефонға iOS немесе Android қолданбасын орнатты, өзіне ұнаған скутерге жақындады, содан кейін телефон мен скутер бір-бірінің арасындағы байланыс орнатты, ETH алмасылды және пайдаланушы скутерді қосу арқылы сапарды бастай алады. телефон. Сапардың соңында телефондағы пайдаланушының әмиянынан Ethereum арқылы жол ақысын төлеуге болады.
Скутерлерден басқа, пайдаланушы қолданбада «ақылды зарядтағыштарды» көрді, оған кіру арқылы пайдаланушы ағымдағы батареяны заряды аз болса, өзі өзгерте алады.
Өткен жылдың қыркүйегінде Германияның екі қаласында: Бонн мен Берлинде ұшырылған ұшқышымыз жалпы осылай болды.
Содан кейін, бір күні, Бонн қаласында, таңертең ерте біздің қолдау тобына (скутерлерді жұмыс тәртібінде ұстау үшін сайтта орналасқан) ескерту жасалды: скутерлердің бірі із-түзсіз жоғалып кетті.
Оны қалай табуға және қайтаруға болады?
Бұл мақалада мен бұл туралы айтатын боламын, бірақ алдымен IoT платформасын қалай құрдық және оны қалай бақылағанымыз туралы.
Нені және не үшін бақылау керек: мотороллер, инфрақұрылым, зарядтау?
Сонымен, біз жобамызда нені бақылағымыз келді?
Ең алдымен, бұл мотороллерлердің өздері - электрлік мотороллерлердің өзі айтарлықтай қымбат, сіз жеткілікті дайындықсыз мұндай жобаны іске қоса алмайсыз; мүмкін болса, скутерлер туралы мүмкіндігінше көбірек ақпарат жинағыңыз келеді: олардың орналасқан жері, заряд деңгейі туралы. , т.б.
Сонымен қатар, мен өзіміздің IT-инфрақұрылымның – мәліметтер базасының, қызметтерінің және олардың жұмыс істеуі үшін қажет нәрсенің барлығының жағдайын бақылап отырғым келеді. Сондай-ақ, «ақылды зарядтағыштардың» күйін олар істен шыққан немесе толық батареялары таусылған жағдайда бақылау қажет болды.
Скутерлер
Біздің скутерлеріміз қандай болды және олар туралы не білгіміз келді?
Бірінші және ең маңыздысы - GPS координаттары, өйткені олардың арқасында біз олардың қайда және қайда қозғалатынын түсіне аламыз.
Әрі қарай - батарея заряды, соның арқасында біз скутерлерді зарядтау аяқталып жатқанын анықтап, шырын сыққышты жібере аламыз немесе кем дегенде пайдаланушыны ескертеміз.
Әрине, біздің Аппараттық құрамдастармен не болып жатқанын тексеру қажет:
- bluetooth жұмыс істей ме?
- GPS модулінің өзі жұмыс істей ме?
- Бізде GPS қате координаттарды жіберіп, кептеліп қалуы мүмкін деген мәселе туындады және мұны тек скутерде қосымша тексерулер арқылы анықтауға болады,
және мәселені шешу үшін қолдау қызметіне мүмкіндігінше тезірек хабарлаңыз
- Бізде GPS қате координаттарды жіберіп, кептеліп қалуы мүмкін деген мәселе туындады және мұны тек скутерде қосымша тексерулер арқылы анықтауға болады,
Соңында: ОЖ мен процессордан бастап, желі мен дискідегі жүктемеден бастап бағдарламалық қамтамасыз етуді тексеру, бізге нақтырақ өзіміздің модульдерді тексерумен аяқталады (, ).
аппараттық
Біздің «темір» бөлігіміз қандай болды?
Ең қысқа уақыт шеңберін және жылдам прототиптеу қажеттілігін ескере отырып, біз іске асырудың және компоненттерді таңдаудың ең оңай нұсқасын таңдадық - Raspberry Pi.
Rpi-дің өзінен басқа, бізде арнайы тақта (соңғы шешімді жинау процесін жылдамдату үшін біз Қытайдан өзіміз әзірлеп, тапсырыс бердік) және компоненттер жиынтығы - реле (скутерді қосу/өшіру), батарея зарядын оқу құралы, модем, антенналар. Мұның бәрі арнайы «xRide қорабына» ықшам салынған.
Сондай-ақ, бүкіл қорап қосымша қуат банкінен қуат алғанын атап өткен жөн, ол өз кезегінде скутердің негізгі батареясынан қуат алды.
Бұл бақылауды қолдануға және сапар аяқталғаннан кейін де скутерді қосуға мүмкіндік берді, өйткені негізгі батарея тұтану кілтін «өшіру» күйіне қосқаннан кейін бірден өшірілген.
Докер? Қарапайым Linux? және орналастыру
Мониторингке оралайық, сондықтан таңқурай - бізде не бар?
Физикалық құрылғыларға құрамдастарды орналастыру, жаңарту және жеткізу процесін жылдамдату үшін біз қолданғымыз келген алғашқы нәрселердің бірі Docker болды.
Өкінішке орай, RPi-дегі Docker жұмыс істесе де, көп шығындарға, әсіресе энергияны тұтынуға байланысты екені тез белгілі болды.
«Туған» операциялық жүйені пайдаланудағы айырмашылық соншалықты күшті болмаса да, зарядты тым тез жоғалту мүмкіндігінен сақ болу үшін жеткілікті болды.
Екінші себеп Node.js (sic!) жүйесіндегі серіктес кітапханаларымыздың бірі болды - Go/C/C++ тілінде жазылмаған жүйенің жалғыз құрамдас бөлігі.
Кітапхана авторларының ешбір «ана» тілдеріндегі жұмыс нұсқасын беруге уақыты болмады.
Түйіннің өзі өнімділігі төмен құрылғылар үшін ең талғампаз шешім ғана емес, сонымен қатар кітапхананың өзі ресурстарға өте қажет болды.
Біз қаласақ та, Docker пайдалану біз үшін тым көп шығын болатынын түсіндік. Таңдау жергілікті ОЖ пайдасына жасалды және тікелей оның астында жұмыс істейді.
OS
Нәтижесінде біз тағы да ОЖ ретінде ең қарапайым опцияны таңдадық және Raspbian (Pi үшін Debian құрастыру) қолдандық.
Біз барлық бағдарламалық жасақтаманы Go бағдарламасында жазамыз, сондықтан Go жүйесінде негізгі аппараттық агент модулін де жаздық.
Ол GPS, Bluetooth-пен жұмыс істеуге, зарядты оқуға, скутерді қосуға және т.б.
Орналастыру
Құрылғыларға жаңартуларды (OTA) жеткізу механизмін енгізу қажеттілігі туралы сұрақ бірден туындады - біздің агенттің/қосымшаның өзіне де, ОЖ/микробағдарламаның өзіне жаңартулар (себебі агенттің жаңа нұсқалары ядроға жаңартуларды қажет етуі мүмкін) немесе жүйе құрамдас бөліктері, кітапханалар және т.б.) .
Нарықты ұзақ талдаудан кейін құрылғыға жаңартуларды жеткізудің көптеген шешімдері бар екені белгілі болды.
Салыстырмалы түрде қарапайым, негізінен swupd/SWUpdate/OSTree сияқты жаңарту/қос жүктеуге бағытталған утилиталардан бастап Mender және Balena сияқты толыққанды платформаларға дейін.
Ең алдымен, біз түпкілікті шешімдерге қызығушылық таныттық деп шештік, сондықтан таңдау бірден платформаларға түсті.
Бұл өте шын мәнінде balenaEngine ішінде бірдей Docker пайдаланатынына байланысты алынып тасталды.
Бірақ мен соған қарамастан, біз олардың өнімін үнемі қолданатынымызды ескертемін SD карталарындағы флэш микробағдарламасы үшін - бұл үшін қарапайым және өте ыңғайлы утилита.
Сондықтан, ақыр соңында таңдауға түсті . Mender - микробағдарламаны жинауға, жеткізуге және орнатуға арналған толық платформа.
Тұтастай алғанда платформа керемет көрінеді, бірақ mender құрастырушысын пайдаланып микробағдарламаның дұрыс нұсқасын жасау үшін бір жарым апта уақыт кетті.
Біз оны пайдаланудың қыр-сырына қаншалықты тереңірек үңілген сайын, оны толығымен енгізу үшін біздегіден әлдеқайда көп уақыт қажет болатыны анық болды.
Өкінішке орай, біздің қатаң мерзімдеріміз Мендерді пайдаланудан бас тартуға және одан да қарапайымды таңдауға мәжбүр болды.
Қажет
Біздің жағдайдағы ең қарапайым шешім Ansible пайдалану болды. Бастау үшін бірнеше ойын кітаптары жеткілікті болды.
Олардың мәні біз жай ғана хосттан (CI сервері) ssh арқылы таңқурайымызға қосылып, оларға жаңартуларды тараттық.
Ең басында бәрі қарапайым болды - құрылғылармен бір желіде болу керек болды, құю Wi-Fi арқылы жасалды.
Кеңседе бір желіге қосылған ондаған сынақ таңқурайлары болды, әр құрылғыда Ansible Inventory-де көрсетілген статикалық IP мекенжайы болды.
Біздің бақылау агентімізді соңғы құрылғыларға жеткізген Ansible болды
3G / LTE
Өкінішке орай, Ansible үшін бұл пайдалану жағдайы бізде нақты скутерлер болғанға дейін әзірлеу режимінде ғана жұмыс істей алады.
Өйткені скутерлер, сіз түсінгендей, бір Wi-Fi маршрутизаторына қосылып отырмайды, желі арқылы жаңартуларды үнемі күтіп отырады.
Шындығында, скутерлерде мобильді 3G/LTE-ден басқа ешбір қосылым болуы мүмкін емес (тіпті әрқашан емес).
Бұл төмен қосылу жылдамдығы және тұрақсыз байланыс сияқты көптеген мәселелер мен шектеулерді бірден жүктейді.
Бірақ ең бастысы, 3G/LTE желісінде біз желіге тағайындалған статикалық IP-ге ғана сене алмаймыз.
Мұны кейбір SIM картасы провайдерлері жартылай шешеді, тіпті статикалық IP мекенжайлары бар IoT құрылғыларына арналған арнайы SIM карталары бар. Бірақ бізде мұндай SIM карталарға қол жетпеді және IP мекенжайларын пайдалана алмадық.
Әрине, Консул сияқты бір жерде IP мекенжайларын тіркеудің қандай да бір түрін жасау идеялары болды, бірақ біз мұндай идеялардан бас тартуға тура келді, өйткені біздің сынақтарымызда IP мекенжайы тым жиі өзгеруі мүмкін, бұл үлкен тұрақсыздыққа әкелді.
Осы себепті метриканы жеткізу үшін ең қолайлы пайдалану біз қажетті көрсеткіштер үшін құрылғыларға баратын тарту үлгісін пайдалану емес, метриканы құрылғыдан тікелей серверге жеткізу арқылы итеру еді.
VPN
Бұл мәселені шешу үшін біз VPN таңдадық - арнайы .
Клиенттер (скутерлер) жүйенің басында VPN серверіне қосылды және оларға қосыла алды. Бұл туннель жаңартуларды жеткізу үшін пайдаланылды.
Теориялық тұрғыдан дәл сол туннельді бақылау үшін пайдалануға болады, бірақ мұндай қосылым қарапайым итеруге қарағанда күрделірек және сенімдірек болды.
Бұлтты ресурстар
Соңында, бұлттық қызметтеріміз бен дерекқорларымызды бақылау қажет, өйткені біз олар үшін Kubernetes-ті қолданамыз, бұл кластерде мониторингті қолдану мүмкіндігінше қарапайым болуы үшін. Ең дұрысы, пайдалану , өйткені орналастыру үшін біз оны көп жағдайда қолданамыз. Және, әрине, бұлтты бақылау үшін скутерлердің өздері сияқты шешімдерді пайдалану керек.
Берілген
Ой, біз сипаттаманы сұрыптап алған сияқтымыз, соңында бізге қажет нәрселердің тізімін жасайық:
- Жылдам шешім, өйткені бақылау әзірлеу процесінде қажет
- Көлем/сан – көптеген көрсеткіштер қажет
- Журнал жинау қажет
- Сенімділік - деректер сәтті іске қосу үшін маңызды
- Сіз тарту үлгісін пайдалана алмайсыз - сізге итеру керек
- Бізге тек аппараттық құралдарды ғана емес, бұлтты да біртұтас бақылау қажет
Соңғы сурет осылай көрінді
Стек таңдау
Сонымен, біз мониторинг стекін таңдау мәселесіне тап болдық.
Біріншіден, біз бір уақытта біздің барлық талаптарымызды қанағаттандыратын, бірақ сонымен бірге оны біздің қажеттіліктерімізге бейімдеу үшін жеткілікті икемді болатын ең толық барлығы бір шешімді іздедік. Дегенмен, бізде аппараттық құралдар, архитектура және мерзімдер бойынша көптеген шектеулер қойылды.
сияқты толыққанды жүйелерден бастап бақылау шешімдерінің алуан түрі бар , немесе және Флотты басқаруға арналған дайын шешімдермен аяқталады.
Бастапқыда соңғысы біз үшін тамаша шешім болып көрінді, бірақ кейбіреулерінде толық бақылау болмады, басқаларында тегін нұсқалардың мүмкіндіктері айтарлықтай шектеулі болды, ал басқалары жай ғана біздің «қалауларымызды» қамтымады немесе сценарийлерімізге сәйкес келмеді. Кейбіреулер жай ғана ескірген.
Бірқатар ұқсас шешімдерді талдағаннан кейін, біз ұқсас стекті өзіміз құрастыру оңайырақ және жылдамырақ болатыны туралы тез қорытындыға келдік. Иә, бұл толығымен дайын флотты басқару платформасын орналастырудан гөрі біршама күрделірек болады, бірақ біз ымыраға келудің қажеті жоқ.
Әрине, шешімдердің барлық үлкен көптігінде бізге толығымен сәйкес келетін дайын нұсқа бар, бірақ біздің жағдайда белгілі бір стекті өз бетінше жинап, оны «өзіміз үшін» баптау әлдеқайда жылдам болды. дайын өнімдерді сынау.
Осының бәрін ескере отырып, біз толық бақылау платформасын өзіміз жинауға ұмтылмадық, бірақ оларды икемді түрде конфигурациялау мүмкіндігі бар ең функционалды «дайын» стектерді іздедік.
(B) ELK?
Іс жүзінде қарастырылған бірінші шешім белгілі ELK стегі болды.
Негізі оны BELK деп атау керек, себебі бәрі Beats-тен басталады -
Әрине, ELK - мониторинг саласындағы ең танымал және қуатты шешімдердің бірі, одан да көп журналдарды жинау және өңдеу.
Біз ELK журналдарды жинау және сонымен қатар Prometheus-тен алынған метрикаларды ұзақ мерзімді сақтау үшін пайдаланылады деп ойладық.
Визуализация үшін Grafan қолданбасын пайдалануға болады.
Шындығында, жаңа ELK стек метриканы дербес жинай алады (метрикалық соққы) және Kibana да оларды көрсете алады.
Дегенмен, ELK бастапқыда журналдардан шықты және әзірге метриканың функционалдығында бірқатар маңызды кемшіліктер бар:
- Прометейге қарағанда айтарлықтай баяу
- Прометейге қарағанда әлдеқайда аз жерлерде біріктіріледі
- Олар үшін ескертулерді орнату қиын
- Метрикалар көп орын алады
- Кибанда метрикасы бар бақылау тақталарын орнату Графанға қарағанда әлдеқайда күрделі
Жалпы алғанда, ELK-дегі көрсеткіштер ауыр және басқа шешімдердегідей ыңғайлы емес, олардың ішінде қазір Prometheus ғана емес: TSDB, Victoria Metrics, Cortex және т.б. Әрине, мен бірден толыққанды барлығы бір шешімге ие болғым келеді, бірақ metricbeat жағдайында тым көп ымыраға келулер болды.
Ал ELK стекінің өзінде бірқатар қиын сәттер бар:
- Бұл өте үлкен көлемдегі деректерді жинасаңыз, ауыр, кейде тіпті өте ауыр
- Сіз оны «қалай пісіруді» білуіңіз керек - оны масштабтауыңыз керек, бірақ мұны істеу маңызды емес.
- Жойылған тегін нұсқа - тегін нұсқада қалыпты ескерту жоқ және таңдау кезінде аутентификация болған жоқ.
Айта кету керек, соңғы нүкте жақсырақ және қосымша болды (аутентификацияны қоса алғанда) баға моделінің өзі өзгере бастады.
Бірақ біз бұл шешімді қолданатын кезде ешқандай ескерту болған жоқ.
Мүмкін, біз ElastAlert немесе басқа қауымдастық шешімдерін пайдаланып бірдеңе құруға тырысқан болар едік, бірақ біз әлі де басқа баламаларды қарастыруды шештік.
Локи - Графана - Прометей
Қазіргі уақытта жақсы шешім тек Prometheus негізінде метрика провайдері, журналдарға арналған Loki және визуализация үшін сол Grafana-ны пайдалануға негізделген бақылау стекін құру болуы мүмкін.
Өкінішке орай, жобаның пилоттық сатылымы басталған кезде (19 жылдың қыркүйегі-қазаны) Loki әлі де 0.3-0.4 бета нұсқасында болды және әзірлеуді бастаған кезде оны өндірістік шешім ретінде қарастыру мүмкін болмады. мүлде.
Менде әлі маңызды жобаларда Loki пайдалану тәжірибесі жоқ, бірақ мен Promtail (бөренелер жинауға арналған агент) кубернеттегі жалаң металл үшін де, бұршақ үшін де жақсы жұмыс істейді деп айта аламын.
БИЛІК
Мүмкін, ELK стекіне ең лайықты (жалғыз?) толық функционалды баламаны енді тек TICK стек деп атауға болады - Telegraf, InfluxDB, Chronograf, Kapacitor.
Төменде мен барлық компоненттерді толығырақ сипаттайтын боламын, бірақ жалпы идея мынада:
- Telegraf - көрсеткіштерді жинауға арналған агент
- InfluxDB – метрикалық мәліметтер базасы
- Kapacitor – ескертуге арналған нақты уақыттағы метрика процессоры
- Хронограф - визуализацияға арналған веб-панель
InfluxDB, Kapacitor және Chronograf үшін біз оларды орналастырған ресми басқару диаграммалары бар.
Айта кету керек, Influx 2.0 (бета) соңғы нұсқасында Kapacitor және Chronograf InfluxDB құрамына кірді және енді бөлек болмайды.
Телеграф
күй машинасында көрсеткіштерді жинауға арналған өте жеңіл агент.
Ол барлығының үлкен мөлшерін бақылай алады, бастап қарай
сервер .
Оның бірқатар керемет артықшылықтары бар:
- Жылдам және жеңіл (Go тілінде жазылған)
- Ресурстардың ең аз мөлшерін жейді
- Көрсеткіштерді әдепкі бойынша басыңыз
- Барлық қажетті көрсеткіштерді жинайды
- Ешбір параметрлерсіз жүйелік көрсеткіштер
- Сенсорлардан алынған ақпарат сияқты аппараттық көрсеткіштер
- Жеке көрсеткіштерді қосу өте оңай
- Көптеген плагиндер қораптан шықты
- Журналдарды жинайды
Итермелеу көрсеткіштері бізге қажет болғандықтан, барлық басқа артықшылықтар жағымды толықтырулардан артық болды.
Агенттің өзі журналдарды жинауы да өте ыңғайлы, өйткені журналдарды тіркеу үшін қосымша утилиталарды қосудың қажеті жоқ.
Influx пайдалансаңыз, журналдармен жұмыс істеу үшін ең қолайлы тәжірибені ұсынады .
Telegraf, әдетте, ICK стекінің қалған бөлігін пайдаланбасаңыз да, көрсеткіштерді жинауға арналған тамаша агент болып табылады.
Ыңғайлы болу үшін көптеген адамдар оны ELK және басқа да уақыт сериялары дерекқорларымен қиып өтеді, өйткені ол метриканы кез келген жерде жаза алады.
InfluxDB
InfluxDB - бұл TICK стекінің негізгі өзегі, атап айтқанда метрикаға арналған уақыт сериясының дерекқоры.
Көрсеткіштерге қосымша, Influx журналдарды да сақтай алады, дегенмен оның мәні бойынша журналдар бірдей көрсеткіштер болып табылады, тек әдеттегі сандық көрсеткіштердің орнына негізгі функция журнал мәтінінің жолы арқылы орындалады.
InfluxDB сонымен қатар Go бағдарламасында жазылған және біздің (ең қуатты емес) кластердегі ELK-мен салыстырғанда әлдеқайда жылдам жұмыс істейтін сияқты.
Influx-тың керемет артықшылықтарының бірі біз өте белсенді пайдаланатын деректер сұраулары үшін өте ыңғайлы және бай API қамтиды.
Кемшіліктері - $$$ немесе масштабтау?
TICK стекінде біз анықтаған бір ғана кемшілік бар - ол сүйіктім. Тіпті өте.
Ақылы нұсқада тегін нұсқада жоқ не бар?
Біздің түсінуімізше, TICK стекінің ақылы нұсқасы мен ақысыз нұсқасы арасындағы жалғыз айырмашылық - масштабтау мүмкіндіктері.
Атап айтқанда, қол жетімділігі жоғары кластерді тек ішінде көтере аласыз .
Егер сіз толыққанды HA алғыңыз келсе, сізге төлеу керек немесе кейбір балдақтарды пайдалану керек. Бірнеше қауымдастық шешімдері бар - мысалы құзыретті шешім сияқты көрінеді, бірақ ол өндіріске жарамсыз деп жазылған, сондай-ақ
- NATS арқылы деректерді айдау арқылы қарапайым шешім (оны масштабтау керек, бірақ оны шешуге болады).
Өкінішті, бірақ олардың екеуі де бас тартылған сияқты - жаңа міндеттер жоқ, менің ойымша, мәселе Influx 2.0 жаңа нұсқасының жақын арада күтілетін шығарылымы болып табылады, онда көп нәрсе әртүрлі болады (бұл туралы ақпарат жоқ) онда әлі масштабтау).
Ресми түрде тегін нұсқасы бар - шын мәнінде, бұл қарабайыр HA, бірақ тек теңгерімдеу арқылы,
өйткені барлық деректер жүктеме балансының артындағы барлық InfluxDB даналарына жазылады.
Оның біразы бар қайта жазу нүктелерімен ықтимал проблемалар және метрика үшін негіздерді алдын ала жасау қажеттілігі сияқты
(бұл InfluxDB-мен қалыпты жұмыс кезінде автоматты түрде орын алады).
Сонымен қатар , бұл сізге қажет болмауы мүмкін қайталанатын көрсеткіштер (өңдеу және сақтау) үшін қосымша шығындарды білдіреді, бірақ оларды бөлудің ешқандай жолы жоқ.
Виктория метрикасы?
Нәтижесінде, біз ақылы масштабтаудан басқа барлық нәрседе TICK стекімен толық қанағаттанғанымызға қарамастан, қалған T_CK компоненттерін қалдыра отырып, InfluxDB дерекқорын алмастыра алатын тегін шешімдердің бар-жоғын білуді шештік.
Уақыт сериясының деректер базасы көп, бірақ ең перспективалысы Виктория метрикасы, оның бірқатар артықшылықтары бар:
- Жылдам және оңай, кем дегенде нәтижелерге сәйкес
- Кластер нұсқасы бар, ол туралы қазір тіпті жақсы пікірлер бар
- Ол сындыра алады
- InfluxDB протоколын қолдайды
Біз Виктория негізінде толығымен реттелетін стек құруды мақсат еткен жоқпыз және басты үмітіміз оны InfluxDB үшін ашылмалы ауыстыру ретінде пайдалана аламыз деген үміт болды.
Өкінішке орай, InfluxDB протоколына қолдау көрсетілетініне қарамастан, бұл мүмкін емес, ол тек көрсеткіштерді жазу үшін жұмыс істейді - тек Prometheus API «сыртында» қол жетімді, яғни оған Chronograf орнату мүмкін емес.
Сонымен қатар, көрсеткіштер үшін тек сандық мәндерге қолдау көрсетіледі (біз теңшелетін көрсеткіштер үшін жол мәндерін қолдандық - бұл туралы толығырақ бөлімде ).
Әлбетте, дәл сол себепті, VM Influx сияқты журналдарды сақтай алмайды.
Сондай-ақ, оңтайлы шешімді іздеу кезінде Victoria Metrics әлі соншалықты танымал болған жоқ, құжаттама әлдеқайда аз және функционалдық әлсіз болғанын атап өткен жөн.
(Кластер нұсқасы мен үзіндінің толық сипаттамасы есімде жоқ).
Негізгі таңдау
Нәтижесінде ұшқыш үшін біз әлі де бір InfluxDB түйінімен шектелеміз деп шешілді.
Бұл таңдаудың бірнеше негізгі себептері болды:
- Бізге TICK стекінің барлық функционалдығы қатты ұнады
- Біз оны ендіре алдық және ол тамаша жұмыс істеді
- Мерзімдер бітті және басқа нұсқаларды сынауға көп уақыт қалмады.
- Мұндай ауыр жүкті күткен жоқпыз
Бізде ұшқыштың бірінші кезеңі үшін көптеген скутерлер болған жоқ, әзірлеу кезіндегі тестілеу өнімділік мәселелерін анықтаған жоқ.
Сондықтан біз бұл жоба үшін масштабтауды қажет етпестен бір Influx түйіні жеткілікті болады деп шештік (соңында қорытындыларды қараңыз).
Біз стек пен негіз туралы шешім қабылдадық - енді TICK стекінің қалған құрамдастары туралы.
Конденсатор
Kapacitor нақты уақытта дерекқорға кіретін көрсеткіштерді бақылай алатын және ережелерге негізделген әртүрлі әрекеттерді орындай алатын TICK стекінің бөлігі болып табылады.
Жалпы, ол әлеуетті аномалияларды бақылау және машиналық оқыту құралы ретінде орналастырылған (бұл функциялардың сұранысқа ие екеніне сенімді емеспін), бірақ оны пайдаланудың ең танымал жағдайы - ескерту.
Біз оны хабарландырулар үшін осылай пайдаландық. Белгілі бір скутер желіден тыс күйде болғанда, біз Slack ескертулерін орнаттық және смарт зарядтағыштар мен маңызды инфрақұрылымдық компоненттер үшін де солай істелді.
Бұл проблемаларға жылдам жауап беруге, сондай-ақ бәрі қалпына келгені туралы хабарламаларды алуға мүмкіндік берді.
Қарапайым мысал: «қорапты» қуаттандыруға арналған қосымша батарея істен шықты немесе қандай да бір себептермен қуаты таусылды; жай ғана жаңасын орнату арқылы біраз уақыттан кейін скутердің жұмысы қалпына келтірілгені туралы хабарлама алуымыз керек.
Influx 2.0 конденсаторы МҚ бөлігі болды
Хронограф
Мен мониторингке арналған көптеген әртүрлі UI шешімдерін көрдім, бірақ функционалдық пен UX тұрғысынан ештеңе Chronograf-пен салыстыруға келмейді деп айта аламын.
Біз веб-интерфейс ретінде Grafan көмегімен TICK стекін пайдалана бастадық.
Мен оның функционалдығын сипаттамаймын, кез келген нәрсені орнатудың кең мүмкіндіктерін бәрі біледі.
Дегенмен, Grafana әлі де толығымен әмбебап құрал болып табылады, ал Chronograf негізінен Influx-пен қолдануға арналған.
Әрине, осының арқасында Chronograf әлдеқайда ақылды немесе ыңғайлы функционалдылықты қамтамасыз ете алады.
Мүмкін, Chronograf-пен жұмыс істеудің негізгі ыңғайлылығы - Explore арқылы InfluxDB-нің ішкі жағын көруге болады.
Grafana бірдей дерлік функционалдылыққа ие болып көрінеді, бірақ шын мәнінде, Chronograf-те бақылау тақтасын орнатуды тінтуірді бірнеше рет басу арқылы жасауға болады (бір уақытта визуализацияны қараңыз), ал Grafana-да сізде ерте ме, кеш пе. JSON конфигурациясын өңдеу үшін (әрине Chronograf қолмен конфигурацияланған сызықшаларды жүктеп салуға және қажет болса, оларды JSON ретінде өңдеуге мүмкіндік береді - бірақ UI-де жасағаннан кейін оларға ешқашан қол тигізбедім).
Кибана бақылау тақталары мен оларға басқару элементтерін жасау үшін әлдеқайда бай мүмкіндіктерге ие, бірақ мұндай операцияларға арналған UX өте күрделі.
Ыңғайлы бақылау тақтасын жасау үшін жақсы түсіну қажет. Chronograf бақылау тақталарының функционалдығы азырақ болса да, оларды жасау және теңшеу әлдеқайда оңай.
Бақылау тақталарының өзі, жағымды көрнекі стильден басқа, Grafana немесе Kibana-дағы бақылау тақталарынан еш айырмашылығы жоқ:
Сұрау терезесі келесідей:
Басқа нәрселермен қатар, InfluxDB дерекқорындағы өрістердің түрлерін біле отырып, хронографтың өзі кейде сұрауды жазуға немесе орташа сияқты дұрыс біріктіру функциясын таңдауға автоматты түрде көмектесетінін ескеру маңызды.
Және, әрине, Chronograf журналдарды қарау үшін мүмкіндігінше ыңғайлы. Бұл келесідей көрінеді:
Әдепкі бойынша, Influx журналдары syslog пайдалану үшін бейімделген, сондықтан олардың маңызды параметрі бар - ауырлық.
Үстіңгі жағындағы график әсіресе пайдалы, онда сіз орын алған қателерді көре аласыз және ауырлық дәрежесі жоғары болса, түс бірден анық көрінеді.
Бір-екі рет біз маңызды қателерді байқадық, соңғы аптадағы журналдарды қарап, қызыл ұшқынды көрдік.
Әрине, мұндай қателер үшін ескертулерді орнату дұрыс болар еді, өйткені бізде бұл үшін бәрі бар.
Біз оны біраз уақытқа қостық, бірақ пилотты дайындау барысында бізде Slack арнасына да «спам жіберген» көптеген қателер (соның ішінде LTE желісінің қолжетімсіздігі сияқты жүйелік қателер) пайда болды. көп, ешқандай қиындық тудырмай. үлкен пайда.
Дұрыс шешім осы қате түрлерінің көпшілігін өңдеу, олар үшін ауырлық дәрежесін реттеу және содан кейін ғана ескертуді қосу болады.
Осылайша, Slack-ке тек жаңа немесе маңызды қателер жіберіледі. Тығыз мерзімдерді ескере отырып, мұндай орнатуға уақыт жеткіліксіз болды.
Түпнұсқалық растама
Сондай-ақ, Chronograf аутентификация ретінде OAuth және OIDC қолдайтынын атап өткен жөн.
Бұл өте ыңғайлы, өйткені ол оны серверге оңай қосуға және толыққанды SSO құруға мүмкіндік береді.
Біздің жағдайда сервер болды — ол мониторингке қосылу үшін пайдаланылды, бірақ сол сервер скутерлердің аутентификациясы үшін де қолданылды.
«Әкімші»
Мен сипаттайтын соңғы компонент - бұл Vue-де өзіміз жазған «әкімші панелі».
Негізінде бұл жеке дерекқорларымыздан, микросервистерден және InfluxDB метрикасынан алынған скутер туралы ақпаратты бір уақытта көрсететін жеке қызмет.
Бұған қоса, төтенше жағдайда қайта жүктеу немесе қолдау тобы үшін құлыпты қашықтан ашу сияқты көптеген әкімшілік функциялар сол жерге ауыстырылды.
Карталар да болды. Мен қазірдің өзінде біз Chronograf орнына Grafana-дан бастағанымызды айттым - өйткені Grafana үшін карталар плагиндер түрінде қол жетімді, оларда скутерлердің координаттарын көруге болады. Өкінішке орай, Grafana үшін карта виджеттерінің мүмкіндіктері өте шектеулі, сондықтан қазіргі уақытта координаттарды көріп қана қоймай, сонымен қатар көрсету үшін бірнеше күн ішінде карталармен жеке веб-қосымшаны жазу әлдеқайда оңай болды. скутердің жүріп өткен бағыты, картадағы деректерді сүзгілеу мүмкіндігі және т.б. (қарапайым бақылау тақтасында конфигурациялай алмайтын барлық функциялар).
Influx-тың жоғарыда айтылған артықшылықтарының бірі - өзіңіздің жеке көрсеткіштеріңізді оңай жасау мүмкіндігі.
Бұл оны әртүрлі сценарийлер үшін пайдалануға мүмкіндік береді.
Біз онда барлық пайдалы ақпаратты жазуға тырыстық: батарея заряды, құлыптау күйі, сенсордың өнімділігі, bluetooth, GPS және басқа да көптеген денсаулық тексерулері.
Біз мұның барлығын әкімші панелінде көрсеттік.
Әрине, біз үшін ең маңызды критерий скутердің жұмыс жағдайы болды - шын мәнінде, Influx мұны өзі тексереді және оны Түйіндер бөлімінде «жасыл шамдармен» көрсетеді.
Бұл функция арқылы орындалады — біз оны қораптың өнімділігін түсіну және сол ескертулерді Slack-ке жіберу үшін қолдандық.
Айтпақшы, біз скутерлерді «Симпсондар» фильміндегі кейіпкерлердің атымен атадық - оларды бір-бірінен ажырату өте ыңғайлы болды.
Ал жалпы осылайша қызық болды. «Жігіттер, Смитерс өлді!» деген тіркестер үнемі естілді.
Жолдық көрсеткіштер
InfluxDB Victoria Metrics сияқты тек сандық мәндерді ғана емес сақтауға мүмкіндік беруі маңызды.
Бұл соншалықты маңызды емес сияқты - журналдардан басқа, кез келген метриканы сандар түрінде сақтауға болады (тек белгілі күйлер үшін салыстыруды қосыңыз - санаудың бір түрі)?
Біздің жағдайда жол көрсеткіштері өте пайдалы болатын кем дегенде бір сценарий болды.
Біздің «ақылды зарядтағыштардың» жеткізушісі үшінші тарап болғандықтан, біз әзірлеу процесін және осы зарядтағыштарды жеткізе алатын ақпаратты басқара алмадық.
Нәтижесінде, зарядтау API идеалдан алыс болды, бірақ басты мәселе олардың күйін әрқашан түсіне алмауымызда болды.
Бұл жерде Influx көмекке келді. Біз InfluxDB дерекқор өрісіне бізге келген жол күйін өзгертусіз жай ғана жаздық.
Біраз уақыттан бері ол жерде тек «онлайн» және «офлайн» сияқты мәндер келді, соның негізінде біздің басқару панелінде ақпарат көрсетіліп, Slack-ке хабарландырулар жіберілді. Дегенмен, бір сәтте «ажыратылған» сияқты құндылықтар да пайда бола бастады.
Кейін белгілі болғандай, зарядтағыш белгілі бір әрекеттерден кейін сервермен байланыс орната алмаса, бұл күй қосылым жоғалғаннан кейін бір рет жіберілген.
Осылайша, егер біз тек бекітілген мәндер жинағын пайдалансақ, микробағдарламада бұл өзгерістерді қажетті уақытта көре алмауымыз мүмкін.
Жалпы, жолдық көрсеткіштер пайдалану үшін әлдеқайда көп мүмкіндіктер береді; оларда іс жүзінде кез келген ақпаратты жазуға болады. Дегенмен, әрине, сіз бұл құралды мұқият пайдалануыңыз керек.
Кәдімгі көрсеткіштерден басқа, біз InfluxDB жүйесінде GPS орналасқан жер туралы ақпаратты жазып алдық. Бұл біздің басқару панеліндегі скутерлердің орналасуын бақылау үшін өте пайдалы болды.
Шындығында, біз әрқашан қай жерде және қай скутер қажет екенін білдік.
Біз скутерді іздеген кезде бұл бізге өте пайдалы болды (соңында қорытындыларды қараңыз).
Инфрақұрылым мониторингі
Скутерлердің өзінен басқа, бізге бүкіл инфрақұрылымды бақылау қажет болды.
Өте жалпы архитектура келесідей көрінді:
Егер таза мониторинг стекін бөлектесек, ол келесідей болады:
Бұлтта мынаны тексергіміз келеді:
- Деректер базасы
- пернетақта
- Микросервис
Біздің барлық бұлттық қызметтеріміз Кубернетесте орналасқандықтан, оның күйі туралы ақпаратты жинау жақсы болар еді.
Бақытымызға орай, Telegraf қораптан тыс Kubernetes кластерінің күйі туралы көптеген көрсеткіштерді жинай алады және Chronograf бірден бұл үшін әдемі бақылау тақталарын ұсынады.
Біз негізінен қосқыштардың өнімділігін және жадты тұтынуды бақыладық. Құлаған жағдайда Slack жүйесінде ескертулер береді.
Kubernetes жүйесінде подкасттарды бақылаудың екі жолы бар: DaemonSet және Sidecar.
Екі әдіс те егжей-тегжейлі сипатталған .
Біз Telegraf Sidecar-ды қолдандық және метрикадан басқа, подк журналдарды жинадық.
Біздің жағдайда бөренелерді өңдеуге тура келді. Telegraf журналдарды Docker API интерфейсінен ала алатынына қарамастан, біз соңғы құрылғыларымызбен журналдардың біркелкі жинағын және ол үшін контейнерлер үшін конфигурацияланған жүйе журналын алғымыз келді. Мүмкін, бұл шешім әдемі емес еді, бірақ оның жұмысына ешқандай шағымдар болмады және журналдар Хронографта жақсы көрсетілді.
Монитор мониторингі???
Соңында мониторинг жүйелерін бақылау туралы ескі сұрақ туындады, бірақ бақытымызға орай, немесе өкінішке орай, бізде бұған жеткілікті уақыт болмады.
Telegraf өзінің жеке көрсеткіштерін оңай жібере алады немесе InfluxDB дерекқорынан көрсеткіштерді бірдей Influx-қа немесе басқа жерге жіберу үшін жинай алады.
қорытындылар
Ұшқыштың нәтижелерінен қандай қорытынды жасадық?
Мониторингті қалай жүргізуге болады?
Біріншіден, TICK стек біздің үміттерімізді толығымен ақтады және бастапқыда біз күткеннен де көп мүмкіндіктер берді.
Бізге қажетті барлық функциялар болды. Біз онымен жасағанның бәрі қиындықсыз жұмыс істеді.
өнімділік
Тегін нұсқадағы TICK стекіндегі негізгі мәселе - масштабтау мүмкіндіктерінің болмауы. Бұл біз үшін қиындық тудырмады.
Біз нақты жүктеме деректерін/цифрларын жинамадық, бірақ біз бір уақытта шамамен 30 скутерден деректерді жинадық.
Олардың әрқайсысы үш ондаған метрика жинады. Бұл ретте құрылғылардан журналдар жиналды. Деректерді жинау және жіберу әрбір 10 секунд сайын орындалды.
Пилоттық бір жарым аптадан кейін «балалық шақтағы проблемалардың» негізгі бөлігі түзетіліп, ең маңызды мәселелер шешілген кезде, бізге деректерді серверге жіберу жиілігін азайтуға тура келгенін атап өту маңызды. 30 секунд. Бұл қажет болды, өйткені біздің LTE SIM карталарындағы трафик тез жоғала бастады.
Трафиктің негізгі бөлігін журналдар тұтынды; метриканың өзі, тіпті 10 секундтық интервал болса да, оны іс жүзінде ысырап етпеді.
Нәтижесінде, біраз уақыттан кейін біз құрылғылардағы журналдарды жинауды толығымен өшірдік, өйткені нақты мәселелер тұрақты жинақсыз да айқын болды.
Кейбір жағдайларда, журналдарды қарау әлі де қажет болса, біз VPN арқылы WireGuard арқылы қосылдық.
Сондай-ақ, әрбір жеке орта бір-бірінен бөлінгенін және жоғарыда сипатталған жүктеме тек өндіріс ортасына қатысты екенін қосамын.
Әзірлеу ортасында біз әрбір 10 секунд сайын деректерді жинауды жалғастыратын жеке InfluxDB данасын көтердік және біз өнімділік мәселесіне тап болған жоқпыз.
TICK - шағын және орта жобалар үшін өте қолайлы
Осы ақпаратқа сүйене отырып, мен TICK стегі салыстырмалы түрде шағын жобалар немесе HighLoad күтпейтін жобалар үшін өте қолайлы деп қорытындылаймын.
Егер сізде мыңдаған қосқыштар немесе жүздеген машиналар болмаса, тіпті бір InfluxDB данасы жүктемені жақсы өңдейді.
Кейбір жағдайларда, жоғары қолжетімділіктің қарапайым шешімі ретінде Influx Relay сізді қанағаттандыруы мүмкін.
Және, әрине, ешкім сізді «тік» масштабтауды орнатуға және метриканың әртүрлі түрлері үшін әртүрлі серверлерді жай ғана бөлуге кедергі келтірмейді.
Егер сіз мониторинг қызметтеріне күтілетін жүктеме туралы сенімді болмасаңыз немесе сізге өте «ауыр» архитектураға кепілдік берілсе/болатынына кепілдік берілсе, мен TICK стекінің тегін нұсқасын пайдалануды ұсынбаймын.
Әрине, қарапайым шешім сатып алу болады - бірақ мен бұл жерде қандай да бір түсініктеме бере алмаймын, өйткені мен өзім нәзіктіктермен таныс емеспін. Сонымен қатар, бұл өте қымбат және шағын компаниялар үшін қолайлы емес.
Бұл жағдайда бүгін мен Виктория метрикасы және Loki көмегімен журналдар арқылы көрсеткіштерді жинауды ұсынамын.
Рас, мен тағы да ескертемін, Loki/Grafana дайын TICK-ке қарағанда әлдеқайда ыңғайлы (олардың үлкен әмбебаптығына байланысты), бірақ олар тегін.
маңызды: мұнда сипатталған барлық ақпарат Influx 1.8 нұсқасына қатысты, қазіргі уақытта Influx 2.0 шығарылғалы жатыр.
Мен оны ұрыс жағдайында сынап көру мүмкіндігім болмағанымен және жақсартулар туралы қорытынды жасау қиын болса да, интерфейс сөзсіз жақсырақ болды, архитектура жеңілдетілді (конденсаторсыз және хронографсыз),
үлгілер пайда болды («өлтіруші мүмкіндік» - ). Бірақ, өкінішке орай, қазіргі уақытта 2-нұсқада біз бірінші нұсқаны таңдаған негізгі нәрсе жоқ - журналдар жинағы жоқ.
Бұл функция Influx 2.0 нұсқасында да пайда болады, бірақ біз ешқандай мерзімдерді, тіпті шамаланғандарын да таба алмадық.
IoT платформаларын қалай жасамауға болады (қазір)
Ақырында, пилотты іске қосып, біз өзіміздің толыққанды IoT стекімізді жинадық, біздің стандарттарға сәйкес келетін балама жоқ.
Дегенмен, жақында ол бета нұсқасында қол жетімді — Өкініштісі, біз жобаны жасай бастағанда ол жоқ болды.
Біз түпкілікті нәтижеге және өзіміз құрастырған Ansible + TICK + WireGuard негізіндегі платформаға толығымен қанағаттанамыз. Бірақ бүгін мен жеке IoT платформасын жасамас бұрын Баленаны мұқият қарауды ұсынамын.
Өйткені, сайып келгенде, ол біз жасаған нәрселердің көпшілігін жасай алады және OpenBalena тегін және ашық бастапқы көзі болып табылады.
Ол жаңартуларды жіберуді ғана емес, сонымен қатар VPN қазірдің өзінде орнатылған және IoT ортасында пайдалану үшін бейімделгенін біледі.
Жақында олар тіпті шығарды , бұл олардың экожүйесіне оңай қосылады.
Эй, жоғалған скутер ше?
Сөйтіп, «Ральф» атты скутер із-түзсіз жоғалып кетті.
Біз бірден InfluxDB-тен GPS метрикасының деректері бар «әкімші панеліндегі» картаны қарауға жүгірдік.
Мониторинг деректерінің арқасында біз скутердің өткен күні сағат 21:00 шамасында тұрақтан шығып, бір аймаққа жарты сағаттай жүріп өткенін және неміс үйінің жанында таңғы беске дейін тұрғанын оңай анықтадық.
Таңертеңгі сағат 5-тен кейін бақылау деректері алынған жоқ - бұл қосымша батареяның толығымен зарядсызданғанын немесе шабуылдаушы скутерден смарт жабдықты қалай алып тастау керектігін түсінді.
Осыған қарамастан, полицейлер скутер орналасқан мекен-жайға әлі де шақырылған. Скутер ол жерде болмады.
Дегенмен, үй иесі де бұған таң қалды, өйткені ол кеше кешкісін кеңседен үйіне осы скутерге мініп келген.
Белгілі болғандай, қолдау көрсетуші қызметкерлердің бірі таңертең ерте келіп, скутерді алып, оның қосымша батареясы толығымен таусылғанын көріп, оны (жаяу) тұраққа алып кеткен. Ал қосымша батарея ылғалдан істен шықты.
Скутерді өзімізден ұрлап алдық. Айтпақшы, мен полиция ісімен мәселені қалай және кім шешкенін білмеймін, бірақ мониторинг өте жақсы жұмыс істеді ...
Ақпарат көзі: www.habr.com