Год таму мы запусцілі пілотную версію прома праекта па .
Першапачаткова праект зваўся Road-To-Barcelona, пазней стаў Road-To-Berlin (адсюль сустракаемыя на скрыншотах R2B), а ў выніку і зусім быў названы xRide.
Асноўная ідэя праекта была ў наступным: замест таго каб мець цэнтралізаваны сэрвіс пракату аўтамабіляў або скутараў (гаворка пойдзе аб скутэрах aka электра-матацыклах, а не kickscooter/самакатах) мы хацелі зрабіць платформу для дэцэнтралізаванай арэнды. Аб складанасцях з якімі мы сутыкнуліся .
Першапачаткова праект арыентаваўся на аўтамабілі, але з-за тэрмінаў, вельмі доўгіх зносін з вытворцамі і велізарнай колькасці абмежаванняў па бяспецы, для пілота былі абраныя электрычныя скутэры.
Карыстальнік усталёўваў iOS або Android дадатак на тэлефон, падыходзіў да ўпадабанага яму скутара, пасля чаго тэлефон і скутэр усталёўвалі peer-to-peer злучэнне, адбываўся абмен ETH і карыстач мог пачаць паездку ўлучыўшы скутэр праз тэлефон. Па завяршэнні паездкі таксама можна было правесці аплату паездкі за кошт Ethereum з кашалька карыстальніка на тэлефоне.
Акрамя скутараў карыстач бачыў у дадатку "разумныя зарадкі", наведаўшы якую карыстач мог сам змяніць бягучую батарэю, калі яна разрадзілася.
Так у цэлым і выглядаў наш пілот, запушчаны ў верасні мінулага года ў двух гарадах Германіі: Бон і Берлін.
І вось, аднойчы, у Боне, раніцай наша каманда падтрымкі (якая знаходзіцца ў лакацыі для падтрымання скутараў у працаздольным стане) была паднята па трывозе: адзін з скутараў бясследна знік.
Як яго знайсці і вярнуць?
У гэтым артыкуле я раскажу пра гэта, але для пачатку – пра тое, як мы пабудавалі нашу ўласную IoT платформу і як мы ажыццяўлялі маніторынг над ёй.
Што і навошта маніторыць: скутэры, інфраструктура, зарадкі?
Што ж мы хацелі маніторыць у нашым праекце?
У першую чаргу гэта самі скутэры - электроскутеры самі па сабе даволі дарагія, нельга запускаць такі праект не будучы дастаткова падрыхтаванымі, па магчымасці хочацца збіраць як мага больш інфармацыі аб скутэрах: аб іх месцазнаходжанні, узроўні зарада, ітд.
Акрамя гэтага, хацелася б адсочваць стан нашай уласнай IT інфраструктуры - базы, сэрвісы і ўсё што ім неабходна для працы. Трэба было адсочваць і стан "разумных зарадак", на выпадак калі яны зламаліся ці ў іх скончыліся поўныя батарэі.
скутэры
Што ж з сябе ўяўлялі нашы скутэры і што мы хацелі пра іх ведаць?
Першае, і самае істотнае – GPS каардынаты, бо дзякуючы ім мы можам разумець, дзе яны знаходзяцца і куды рухаюцца.
Далей - зарад батарэі, дзякуючы яму мы можам вызначаць, што зарадка скутараў падыходзіць да канца і адправіць juicer'а ці хаця б папярэдзіць карыстальніка.
Вядома, неабходна таксама правяраць што адбываецца з нашымі Hardware кампанентамі:
- ці працуе Bluetooth?
- ці працуе сам GPS модуль?
- гэтак жа ў нас была праблема з тым, што GPS мог адсылаць няслушныя каардынаты і "заліпаць", а вызначыць гэта можна было толькі на ўзроўні дадатковых праверак на скутэры,
і натыфікаваць падтрымку як мага хутчэй для ўхілення праблемы
- гэтак жа ў нас была праблема з тым, што GPS мог адсылаць няслушныя каардынаты і "заліпаць", а вызначыць гэта можна было толькі на ўзроўні дадатковых праверак на скутэры,
І апошняе: праверкі софтвернай часткі, пачынальна з АС і загрузкі працэсара, сеткі і дыска, заканчваючы ўжо больш спецыфічнымі для нас праверкамі нашых уласных модуляў (, ).
апаратныя сродкі
Што ж уяўляла наша "жалезная" частка?
Улічваючы максімальна сціснутыя тэрміны і неабходнасць хуткага прататыпавання мы абралі для сябе максімальна просты для рэалізацыі і падбору кампанентаў варыянт – Raspberry Pi.
Апроч самога Rpi мы мелі кастамную борду (якія мы самі распрацавалі і заказвалі ў Кітаі для паскарэння працэсу зборкі канчатковага рашэння) і набор кампанентаў - рэле (для ўключэння/выключэнні скутэра), счытвальнік зарада батарэі, мадэм, антэны. Усё гэта было кампактна ўкамплектавана ў адмысловую скрыначку "xRide box".
Варта таксама адзначыць, што ўся скрыначка сілкавалася дадатковым павербанкам, які ў сваю чаргу сілкаваўся ад асноўнай батарэі скутэра.
Гэта дазваляла выкарыстоўваць маніторынг і ўключаць скутэр, нават пасля заканчэння паездкі, бо асноўная батарэя адключалася адразу пасля павароту ключа запальвання ў становішча "off".
Docker? Plain linux? і дэплой
Вернемся да маніторынгу, дык вось Raspberry – што ж мы маем?
Адна з першых рэчаў, якую мы хацелі выкарыстоўваць для паскарэння працэсу дэплою, абнаўлення і дастаўкі кампанентаў на фізічныя прылады быў Docker.
Нажаль, даволі хутка стала ясна што Docker на RPi хоць і працуе, але дае досыць шмат накладных выдаткаў, у прыватнасці па энергаспажыванні.
Розніца з выкарыстаннем "натыўнай" АС хай і не была настолькі моцнай, але ўсё ж дастатковай каб мы баяліся магчымасці занадта хуткай страты зарада.
Другім чыннікам стала адна з бібліятэк нашых партнёраў на Node.js (sic!) - адзіны кампанент сістэмы, які не быў напісаны на Go/C/C++.
Аўтары бібліятэкі не паспелі своечасова прадставіць рабочую версію на любой з "натыўных" моў.
Мала таго, што нода сама па сабе не з'яўляецца самым элегантным рашэннем для нізкапрадукцыйных дэвайсаў, дык яшчэ і сама бібліятэка была вельмі пражэрлівая па рэсурсах.
Мы зразумелі, што пры ўсім жаданні выкарыстанне Docker для нас будзе занадта вялікім оверхедом. Быў зроблены выбар у карысць натыўнай OS і працы пад ёй напроста.
OS
У выніку, у якасці АС мы, ізноў жа, абралі самы просты варыянт і выкарыстоўвалі Raspbian (зборка Debian для Pi).
Увесь наш софт мы пішам на Go, таму і асноўны hardware-агент модуль у нашай сістэме мы таксама напісалі на Go.
Менавіта ён і адказвае за працу з GPS, Bluetooth, счытванне зарада, уключэнне скутэра, ітд.
Дэплой
Тут жа паўстала пытанне аб неабходнасці рэалізацыі механізму дастаўкі абнаўленняў на аксэсуары (OTA) — як абнаўленняў самога нашага агента/прыкладанні, так і абнаўлення самой АС/"прашыўкі" (бо новыя версіі агента маглі патрабаваць абнаўленняў ядра або кампанентаў сістэмы, бібліятэк і г.д.) .
Пасля даволі доўгага аналізу рынку высветлілася, што існуе даволі шмат рашэнняў для дастаўкі абнаўленняў на девайс.
Ад адносна простых утыліт, па большай частцы арыентаваных на абнаўленне/dual-boot накшталт swupd/SWUpdate/OSTree да паўнавартасных платформаў накшталт Mender і Balena.
У першую чаргу мы вырашылі, што нас цікавяць менавіта end-to-end рашэнні, таму выбар адразу ўпаў на платформы.
сама была выключаная з прычыны таго, што фактычна выкарыстоўвае той жа самы Docker усярэдзіне свайго balenaEngine.
Але адзначу, што нягледзячы на гэта, у канчатковым выніку мы ўвесь час выкарыстоўвалі іх прадукт. для флэша прашывак на SD карты - простая і вельмі зручная ўтыліта для гэтага.
Таму ў выніку выбар упаў на . Mender уяўляе з сябе паўнавартасную платформу для зборкі, дастаўкі і ўсталёўкі прашывак.
У цэлым платформа выглядае проста выдатна, але нам запатрабавалася каля паўтара тыдняў толькі на тое, каб сабраць правільную версію нашай прашыўкі з дапамогай зборшчыка mender.
І чым больш мы апускаліся ў тонкасці яго выкарыстання, тым больш рабілася ясна, што на паўнавартаснае яго разгортванне нам спатрэбілася б моцна больш часу, чым у нас было.
Нажаль, нашы сціснутыя тэрміны прывялі да таго, што мы змушаныя былі адмовіцца ад выкарыстання Mender і абраць яшчэ прасцейшы хай.
анзибль
Самым простым рашэннем у нашай сітуацыі аказалася выкарыстанне Ansible. Пары playbook'ов для пачатку было суцэль досыць.
Іста іх зводзілася да таго, што мы проста падлучаліся з хаста (CI сервер) па ssh да нашых разберы і разлівалі на іх абнаўленні.
У самым пачатку ўсё было проста - трэба было знаходзіцца ў адзінай сетцы з прыладамі, разліванне ішла праз Wi-Fi.
У офісе проста знаходзілася дзясятак тэставых малінак, падлучаных да адной сеткі, кожная прылада мела статычны IP адрас гэтак жа паказаны ў Ansible Inventory.
Менавіта Ansible дастаўляў наш маніторынг-агент на канчатковыя прылады.
3G / LTE
Нажаль, такі варыянт выкарыстання Ansible мог працаваць толькі ў рэжыме распрацоўкі, пакуль у нас яшчэ не было рэальных скутараў.
Таму што скутэры, як вы разумееце, не стаяць падлучаныя да аднаго Wi-Fi роўтара стала чакаючы абнаўленні па сетцы.
У рэальнасці ў скутараў наогул не можа быць ніякага злучэння акрамя мабільнага 3G/LTE (і то не ўвесь час).
Гэта накладвае адразу шмат праблем і абмежаванняў, накшталт нізкай хуткасці злучэння і нестабільнай сувязі.
Але самае галоўнае – у 3G/LTE сеткі мы не можам проста спадзявацца на статычны IP прысвоены ў сетцы.
Гэта часткова вырашаецца некаторымі правайдэрамі SIM карт, ёсць нават спецыяльныя сімкі прызначаныя для IoT прылад са статычнымі IP адрасамі. Але мы не мелі доступу да такіх SIM карт і не маглі выкарыстоўваць IP адрасы.
Вядома, былі ідэі рабіць нейкую рэгістрацыю IP адрасоў aka service discovery недзе накшталт Consul, але ад падобных ідэй прыйшлося адмовіцца, бо ў нас у тэстах IP адрас мог мяняцца занадта часта, што прыводзіла да вялікай нестабільнасці працы.
Па гэтай прычыне, найболей зручнае выкарыстанне для дастаўкі метрык было б не з выкарыстаннем pull мадэлі, дзе мы хадзілі б за патрэбнымі метрыкамі на прылады, а push з дастаўкай метрык з прылады напроста на сервер
VPN
У якасці рашэння гэтай праблемы мы абралі VPN – а канкрэтна .
Кліенты (скутэры) на старце сістэмы падлучаліся да VPN сервера і трымалі магчымасць падлучэння да іх. Гэты тунэль і выкарыстоўваўся для дастаўкі абнаўленняў.
У тэорыі, той жа тунэль можна было выкарыстоўваць і для маніторынгу, але такое падлучэнне было складаней і менш надзейным, чым просты push.
Хмарныя рэсурсы
Апошняе - неабходна адсочваць нашы хмарныя сэрвісы і БД, бо для іх мы выкарыстоўваем Kubernetes, у ідэале каб разгортванне маніторынгу ў кластары было максімальна простым. У ідэале - з выкарыстаннем , так як для дэплою, мы ў большасці выпадкаў выкарыстоўваем яго. І, само сабой, для маніторынгу аблокі трэба выкарыстоўваць тыя ж рашэнні, што і для саміх скутараў.
Дана
Фуф, накшталт з апісаннем разабраліся, давайце складзем спіс таго, што нам было патрэбна ў выніку:
- Хуткае рашэнне, бо маніторыць неабходна ўжо падчас працэсу распрацоўкі
- Аб'ём/колькасць - трэба мноства метрык
- Збор логаў абавязковы
- Надзейнасць - дадзеныя крытычна важныя для поспеху запуску
- Нельга выкарыстоўваць pull мадэль - патрэбен push
- Патрэбны адзіны маніторынг не толькі жалеза, але і аблокі
Канчатковая карцінка выглядала прыкладна так
Выбар стэка
Такім чынам, перад намі паўстала пытанне выбару стэка для маніторынгу.
У першую чаргу, мы шукалі найбольш паўнавартаснае all-in-one рашэнне, якое адначасова пакрывала б усе нашы патрабаванні, але пры гэтым і было б дастаткова гнуткім каб падагнаць яго выкарыстанне пад нашы патрэбы. Усё ж такі, у нас было шмат абмежаванняў накладзеных на нас жалезам, архітэктурай і тэрмінамі.
Існуе мноства рашэнняў для маніторынгу, пачынаючы паўнавартаснымі сістэмамі накшталт , або і заканчваючы ўжо гатовымі рашэннямі па Fleet management.
Першапачаткова, апошнія здаваліся ідэальным для нас рашэннем, але ў адных не было паўнавартаснага маніторынгу, у іншых былі моцна зрэзаныя магчымасці бясплатных версій, а трэція проста не пакрывалі нашы "хатэлкі" або не былі дастаткова гнуткімі для падганяння пад нашы сцэнары. Некаторыя проста састарэлі.
Пасля аналізу нейкай колькасці падобных рашэнняў мы хутка дашлі да высновы, што прасцей і хутчэй будзе сабраць падобны стэк самастойна. Так, гэта будзе крыху складаней чым разгортванне цалкам гатовай Fleet management платформы, але затое нам не давядзецца ісці на кампрамісы.
Амаль напэўна, ва ўсім велізарным багацці рашэнняў і ёсць ужо гатовае якое цалкам бы нам падышло, але ў нашым выпадку значна хутчэй было сабраць нейкі стэк самастойна і падагнаць "пад сябе", чым тэставаць гатовыя прадукты.
Пры гэтым, мы не імкнуліся збіраць целиковую платформу для маніторынгу самастойна, а шукалі максімальна функцыянальныя "гатовыя" стэкі, толькі з магчымасцю іх гнутка наладжваць.
(B)ELK?
Першае рашэнне, якое рэальна разглядалася – шырока вядомы ELK стэк.
Насамрэч ён павінен называцца BELK, бо пачынаецца ўсё з Beats -
Вядома, ELK гэта адно з самых вядомых і магутных рашэнняў у вобласці маніторынгу, а ўжо ў зборы і апрацоўцы логаў, так і самае.
Мы мелі на ўвазе, што ELK будзе выкарыстоўвацца для збору логаў і, гэтак жа як доўгачасовае сховішча метрык атрыманых з Prometheus.
Для візуалізацыі можна выкарыстоўваць Grafan'у.
Насамрэч, свежы ELK стэк умее збіраць метрыкі і самастойна (metricbeat), Kibana гэтак жа ўмее паказваць іх.
Але ўсё ж першапачаткова ELK вырас з логаў і пакуль функцыянал метрык мае шэраг сур'ёзных недахопаў:
- Значна павольней Prometheus
- Інтэгруецца ў куды меншую колькасць месцаў чым Prometheus
- Складана наладзіць алертынг па іх
- Метрыкі займаюць вялікую колькасць месца
- Настройка дашбордаў з метрыкамі ў Kiban'е значна складаней Grafan'ы
Увогуле, метрыкі ў ELK цяжкія і пакуль не такія зручныя як у іншых рашэннях, якіх зараз насамрэч значна больш чым проста Prometheus: TSDB, Victoria Metrics, Cortex і т.д. Вядома, вельмі б жадалася мець адразу паўнавартаснае all-in-one рашэнне, але ў выпадку з metricbeat выходзіла занадта шмат кампрамісаў.
Ды і ў самога ELK стэка ёсць шэраг няпростых момантаў:
- Ён цяжкі, часам нават вельмі, калі ў вас збіраецца даволі вялікая колькасць дадзеных
- Яго трэба "ўмець рыхтаваць" - скаліраваць яго неабходна, але робіцца гэта нетрывіяльна
- Урэзаная бясплатная версія - у бясплатнай версіі няма нармальнага алертынгу, на момант выбару не было і аўтэнтыфікацыі
Трэба сказаць, што ў апошні час з апошнім пунктам стала лепей і апроч (у тым ліку аўтэнтыфікацыя) пачала мяняцца сама мадэль прайсінгу.
Але на момант, калі мы збіраліся разгортваць гэтае рашэнне, алертынгу не было зусім.
Магчыма, можна было паспрабаваць сабраць нешта з выкарыстаннем ElastAlert ці іншых community рашэнняў, але ўсё ж вырашылі разгледзець іншыя альтэрнатывы.
Loki - Grafana - Prometheus
На дадзены момант нядрэнным рашэннем можа быць зборка стэка маніторынгу на аснове чыста Prometheus як пастаўшчыка метрык, Loki для логаў, а для візуалізацыі можна выкарыстоўваць усё тую ж Grafana.
Нажаль, на момант старту прода пілота праекту (верасень-кастрычнік 19ого года) Loki яшчэ знаходзіўся ў бэта версіі 0.3-0.4, а на момант старту распрацоўкі і зусім не мог разглядацца як produtcion рашэнне.
Я пакуль не маю досведу рэальнага выкарыстання Loki у сур'ёзных праектах, але магу сказаць, што Promtail (агент для збору логаў) выдатна працуе як для bare-metal, так і для подаў у kubernetes.
АДМІШЧАЦЬ
Мабыць, найболей годнай (адзінай?) поўнафункцыянальнай альтэрнатывай ELK стэку цяпер можна назваць толькі TICK стэк – Telegraf, InfluxDB, Chronograf, Kapacitor.
Я апішу ўсе кампаненты ніжэй больш падрабязна, але ў цэлым ідэя такая:
- Telegraf - агент для зборкі метрык
- InfluxDB - база дадзеных метрык
- Kapacitor – апрацоўшчык метрык у рэальным часе для алертынгу
- Chronograf - вэб панэль для візуалізацыі
Для InfluxDB, Kapacitor і Chronograf ёсць афіцыйныя helm чарты, якія мы выкарыстоўвалі для іх разгортвання.
Трэба адзначыць, што ў свежай версіі Influx 2.0 (beta) Kapacitor і Chronograf сталі часткай InfluxDB і больш не існуюць асобна
Тэлеграф
- Гэта вельмі легкаважны агент для збору метрык на канчатковай машыне.
Ён умее маніторыць велізарную колькасць усяго, ад да
сервера .
У яго ёсць шэраг класных пераваг:
- Хуткі і лёгкі (напісаны на Go)
- Есць мінімальная колькасць рэсурсаў
- Push метрык па змаўчанні
- Збірае ўсе неабходныя метрыкі
- Сістэмныя метрыкі без якіх-небудзь налад
- Хардварныя метрыкі накшталт інфармацыі з датчыкаў
- Вельмі лёгка дадаваць уласныя метрыкі.
- Шмат плагінаў "са скрынкі"
- Збірае логі
Так як push метрык быў для нас неабходзен, усе астатнія перавагі былі больш за прыемнымі дадаткамі.
Зборка логаў самім жа агентам гэтак жа вельмі зручная, бо няма неабходнасці падлучаць дадатковыя ўтыліты для тэйлінгу логаў.
Influx прапануе максімальна зручны досвед працы з логамі калі вы карыстаецеся .
Telegraf наогул выдатны агент для зборкі метрык, нават калі вы не карыстаецеся ўвесь астатняй ICK стэк.
Многія скрыжоўваюць яго і з ELK і з рознымі іншымі time-series базамі па выгодзе, бо ён умее пісаць метрыкі амаль куды заўгодна.
InfluxDB
InfluxDB – асноўнае ядро TICK стэка, а менавіта time-series база дадзеных для метрык.
Апроч метрык Influx таксама можа захоўваць і логі, хоць, у сутнасці логі для яго гэта ўсяго толькі такія ж метрыкі, толькі замест звычайных лікавых паказчыкаў асноўную функцыю нясе радок тэксту лога.
InfluxDB таксама напісаны на Go і працуе, па адчуваннях, значна хутчэй у параўнанні з ELK на нашым (не самым магутным) кластары.
Да адных з крутых пераваг Influx я б таксама аднёс вельмі зручнае і багатае API для запытаў да дадзеных, якія мы вельмі актыўна выкарыстоўвалі.
Недахопы - $$$ або скалирование?
У TICK стэка ёсць толькі адзін выяўлены намі недахоп - ён дарагі. Нават вельмі.
А што ёсць у платнай версіі, чаго няма ў бясплатнай?
Наколькі нам атрымалася зразумець, адзінае чым адрозніваецца платная версія TICK стэка ад бясплатнай - магчымасці скаліравання.
А менавіта - падняць кластар з High availability можна толькі ў .
Жадаеце паўнавартаснае HA - трэба або плаціць, або гарадзіць якія-небудзь мыліцы. Ёсць пара рашэнняў супольнасці - напрыклад падобна на пісьменнае рашэнне, але напісана што не падыходзіць для прадакшэна, а гэтак жа
- Простае рашэнне з прапампоўкай дадзеных праз NATS (яго таксама прыйдзецца скаліраваць, але гэта развязальна).
Шкада, але абодва яны, падобна, закінутыя - няма свежых комітаў, выкажу здагадку, што справа ў хуткім чаканым вынахадзе новай версіі Influx 2.0 у якой шматлікае будзе інакш (пакуль інфармацыі аб скаляванні ў ёй няма).
Афіцыйна для бясплатнай версіі існуе - фактычна гэта прымітыўнае HA, але толькі з дапамогай балансавання,
бо ўсе дадзеныя будуць пісацца ва ўсе інстансы InfluxDB за load balancer'ом.
У яго ёсць некаторыя накшталт патэнцыйных праблем з перазапісам кропак і неабходнасці ствараць базы для метрык загадзя
(што пры звычайнай працы з InfluxDB адбываецца аўтаматычна).
Да таго ж , гэта азначае дадатковыя накладныя выдаткі на дуплікаваныя метрыкі (і апрацоўка і захоўванне), якія маглі вам быць не патрэбныя, але падзяліць іх магчымасці няма.
Victoria Metrics?
У выніку, нягледзячы на тое, што ва ўсім апроч платнага скалирования TICK стэк нас цалкам задавальняў, мы вырашылі паглядзець ці няма бясплатных рашэнняў, якімі можна замяніць InfluxDB базу, пакінуўшы пры гэтым астатнія кампаненты T_CK.
Time-series баз нямала, але найболей якая падае надзеі Victoria Metrics, у яе цэлы шэраг плюсаў:
- Хуткая і лёгкая, прынамсі па выніках
- Ёсць кластарная версія, пра якую зараз нават ёсць добрыя водгукі
- Яна можаш шалявацца
- Падтрымлівае InfluxDB пратакол
Мы не збіраліся будаваць цалкам кастамны стэк на аснове Victoria і асноўная надзея была на тое, што мы зможам скарыстацца ёю як drop-in заменай для InfluxDB.
Нажаль, гэта немагчыма, нягледзячы на тое, што падтрымліваецца пратакол InfluxDB, гэта працуе толькі для запісу метрык - "вонкі" даступна толькі Prometheus API, а значыць нацкаваць Chronograf на яе не атрымаецца.
Больш за тое, для метрык падтрымліваюцца толькі лікавыя значэння (мы выкарыстоўвалі радковыя значэння для кастамных метрык - пра гэта ў раздзеле ).
Відавочна, па тым жа чынніку VM не можа захоўваць логі, як гэта робіць Influx.
Таксама, трэба адзначыць, што на момант пошуку аптымальнага рашэння Victoria Metrics яшчэ не была такая папулярная, дакументацыя была значна меншая і функцыянал быў слабейшым.
(не ўзгадваю падрабязнага апісання кластарнай версіі і шаліравання).
Выбар базы
У выніку было прынята рашэнне, што для пілота мы ўсё ж абмяжуемся адзіночнай нодай InfluxDB.
Асноўных прычын такога выбару было некалькі:
- Нам вельмі падабаўся функцыянал TICK стэка цалкам
- Мы ўжо паспелі яго разгарнуць і яно выдатна працавала
- Тэрміны падціскалі і не заставалася шмат часу тэсціраваць іншыя варыянты
- У нас не чакалася такой вялікай нагрузкі
Скутараў у нас для першай фазы пілота было не так шмат, і тэсціраванне падчас распрацоўкі не выявіла якіх-небудзь праблем з прадукцыйнасцю.
Таму мы вырашылі, што для дадзенага праекта нам цалкам хопіць і адно ноды Influx без неабходнасці скаліравання (cм высновы ў канцы).
Са стэкам і базай вырашылі зараз аб астатніх кампанентах TICK стэка.
Kapacitor
Kapacitor - гэта частка TICK стэка, сэрвіс які можа сачыць за якія трапляюць у базу метрыкамі ў рэальным часе і выконваць на аснове правіл розныя дзеянні.
Наогул ён пазіцыянуецца як тул для патэнцыйнага адсочвання анамалій і машыннага навучання (не ўпэўнены што гэтыя функцыі запатрабаваныя), але найболей папулярны кейс яго выкарыстання больш банальны - гэта алертынг.
Так і мы яго выкарыстоўвалі для натыфікацый. Мы наладзілі Slack абвесткі аб тым, што той ці іншы скутэр адключыўся, тое ж самае было зроблена для разумных зарадак і важных кампанентаў інфраструктуры.
Гэта дазваляла хутка рэагаваць на праблемы, а таксама атрымліваць натыфікацыі аб тым, што ўсё прыйшло ў норму.
Просты прыклад — зламалася ці па нейкім чынніку разрадзілася дадатковая батарэя для сілкавання нашай "скрыначкі", проста паставіўшы новую мы павінны праз некаторы час атрымаць натыфікацыю аб узнаўленні працаздольнасці скутэра.
У Influx 2.0 Kapacitor стаў часткай DB
Хранограф
Я пабачыў шмат розных UI рашэнняў для маніторынгу, але магу сказаць, што па функцыянале і UX нішто не параўнаецца з Chronograf'ам.
Пачыналі мы выкарыстоўваць TICK стэк, як ні дзіўна, з Grafan'ай у якасці вэб-інтэрфейсу.
Апісваць яе функцыянал не буду, усім вядомыя яе шырокія магчымасці па наладзе ўсяго што заўгодна.
Аднак, Grafana усё ж уяўляе з сябе зусім універсальную прыладу, тады як Chronograf галоўным чынам заменчаны пад выкарыстанне з Influx.
І вядома, дзякуючы гэтаму, Chronograf можа дазволіць сябе куды хітрэйшы ці зручны функцыянал.
Мабыць, асноўная зручнасць працы з Chronograf у тым, што вы можаце глядзець вантробы вашай InfluxDB праз Explore.
Здавалася б, у Grafana ёсць амаль ідэнтычны функцыянал, але ў рэальнасці налада дашборда ў Chronograf можа ажыццяўляцца некалькімі зграямі мышы (наадварот гледзячы на візуалізацыю там жа), тады як у Grafana вам усё роўна рана ці позна прыйдзецца рэдагаваць JSON канфігурацыю (само сабой Chronograf выгрузіць вашыя настроеныя "рукамі" дашы і рэдагаваць у выглядзе JSON калі неабходна - але мне ніколі не даводзілася іх чапаць пасля стварэння на UI).
У Kibana куды багацейшыя магчымасці па стварэнні дашбордаў і кантроляў для іх, але і UX для такіх аперацый ну вельмі складаны.
Спатрэбіцца нядрэнна разабрацца, каб стварыць сабе зручны дашборд. І хоць функцыянал дашбордаў у Chronograf менш, рабіць і наладжваць іх значна прасцей.
Самі дашборды, апроч прыемнага візуальнага стылю, фактычна нічым ад дашбордаў у Grafana ці Kibana не адрозніваюцца:
Так выглядае тое самае акно запытаў:
Важна адзначыць, апроч іншага, што ведаючы тыпы палёў у базе InfluxDB хранограф часам сам можа аўтаматычна дапамагаць вам з напісаннем Query ці выбарам правільнай функцыі агрэгацыі тыпу mean.
Ну і вядома ж, Chronograf максімальна зручны для прагляду логаў. Выглядае гэта так:
Па змаўчанні Influx логі заточны пад выкарыстанне syslog і таму ў іх ёсць важны параметр – severity.
Асабліва карысны графік зверху, на ім можна ўбачыць якія ўзнікаюць памылкі і колерам адразу выразна відаць калі severity больш высокі.
Пару разоў такім чынам мы лавілі важныя багі, зайшоўшы ў прагляд логаў за апошні тыдзень і ўбачыўшы чырвоны спайк.
Вядома, у ідэале было б наладзіць алертынг на такія памылкі, балазе ў нас ужо было ўсё для гэтага.
Мы нават на нейкі час уключалі гэта, але, у працэсе падрыхтоўкі пілота высветлілася, што ў нас узнікае даволі шмат памылак (у тым ліку сістэмных накшталт недаступнасці LTE сеткі), якія занадта моцна "спамятаць" у Slack канал, пры гэтым не несучы вялікай карысці.
Правільным рашэннем было б апрацаваць большасць падобных тыпаў памылак, наладзіць для іх severity і ўжо потым уключыць алертынг.
Такім чынам у Slack пападалі б толькі новыя ці важныя памылкі. На падобны сэтап банальна не хапіла чакай ва ўмовах сціслых тэрмінаў.
аўтэнтыфікацыя
Асобна варта згадаць тое, што Chronograf падтрымлівае OAuth і OIDC у якасці аўтэнтыфікацыі.
Гэта вельмі зручна, бо дазваляе лёгка прыкруціць яго да вашага сервера і зрабіць паўнавартаснае SSO.
У нашым выпадку - серверам быў - ён выкарыстоўваўся для падлучэння да маніторынгу, але пры гэтым той жа сервер выкарыстоўваўся і для аўтэнтыфікацыі скутараў і запытаў на back-end.
"Адмінка"
Апошні кампанент, які я апішу - гэта наша самапісная "адмінка" на Vue.
У цэлым гэта проста асобны сэрвіс, які адлюстроўвае інфармацыю аб скутэрах адначасова з нашых уласных баз дадзеных, мікрасэрвісаў і дадзеныя метрык з InfluxDB.
Акрамя таго, туды былі вынесены шматлікія адміністрацыйныя функцыі, накшталт экстранай перазагрузкі ці выдаленага адкрыцця замка для каманды падтрымкі.
Таксама там былі карты. Я ўжо згадваў, што пачыналі мы з Grafana замест Chronograf – таму што для Grafana у выглядзе плагінаў даступныя карты, на якіх можна было глядзець каардынаты скутараў. Нажаль, магчымасці віджэтаў карт для Grafana вельмі абмежаваныя, і ў выніку было значна прасцей за некалькі дзён напісаць сваё ўласнае вэб прыкладанне з картамі, для таго каб не толькі бачыць каардынаты ў дадзены момант, але і адлюстроўваць пройдзены скутэрам маршрут, умець фільтраваць дадзеныя на карце, ітд (увесь той функцыянал, які мы не змаглі б наладзіць у простым дашбордзе).
Адзін з ужо згаданых плюсаў Influx - магчымасць лёгка ствараць свае ўласныя метрыкі.
Гэта дазваляе выкарыстоўваць яго для вялізнага мноства сцэнарыяў.
Мы імкнуліся запісваць туды ўсю карысную інфармацыю: зарад батарэі, стан замка, працаздольнасць датчыкаў, bluetooth, GPS, мноства іншых healthcheck'аў.
Усё гэта мы і адлюстроўвалі на адмін панэлі.
Вядома, самым галоўным крытэрам для нас было стан працы скутэра – фактычна Influx правярае гэта сам і паказвае ў раздзеле Nodes "зялёнымі лямпачкамі".
Робіцца гэта функцыяй — мы выкарыстоўвалі яе ж для разумення працаздольнасці нашай скрыначкі і дасылкі тых самых алертаў у Slack.
Дарэчы, мы звалі скутэры па імёнах персанажаў з Сімпсанаў - так іх было зручна адрозніваць сябар ад сябра
Ды і ўвогуле так было весялей. Пастаянна гучалі фразы накшталт "Хлопцы - Смітэрс памёр!"
Радковыя метрыкі
Важна, што InfluxDB дазваляе захоўваць не толькі лікавыя значэнні, як у выпадку з Victoria Metrics.
Здавалася б, гэта не так важна - бо калі не лічыць логаў, любыя метрыкі можна захоўваць у выглядзе лікаў (усяго толькі дадаць мапінг для вядомых станаў - свайго роду enum)?
У нашым выпадку, быў прынамсі адзін сцэнар, калі радковыя метрыкі былі вельмі карысныя.
Так ужо атрымалася, што пастаўшчык нашых "разумных зарадак" быў іншым, мы не мелі ніякага кантролю над працэсам распрацоўкі і інфармацыяй, якую гэтыя зарадкі могуць пастаўляць.
У выніку API зарадак было далёка ад ідэалу, але асноўнай праблемай было тое, што мы не заўсёды маглі зразумець іх стан.
Тут на дапамогу і прыйшоў Influx. Мы проста запісвалі прыходны нам радковы status у поле базы InfluxDB без змен.
Нейкі час туды пападалі толькі значэнні выгляду "online" і "offline", на аснове чаго ў нас у адмінцы адлюстроўвалася інфармацыя, а ў Slack прыходзілі апавяшчэнні. Аднак у нейкі момант туды сталі пападаць гэтак жа значэнні выгляду "disconnected".
Як пазней высветлілася, гэты статус высылаўся аднаразова пасля страты сувязі, калі зарадка не магла ўсталяваць злучэнне з серверам пасля нейкай колькасці спроб.
Такім чынам, калі б мы выкарыстоўвалі толькі фіксаваны набор значэнняў - мы маглі б не ўбачыць гэтых змен у прашыўцы ў патрэбны момант часу.
Ды і ўвогуле, радковыя метрыкі даюць куды больш магчымасцяў для выкарыстання, запісваць у іх можна фактычна любую інфармацыю. Хоць, вядома, выкарыстоўваць гэтую прыладу таксама трэба акуратна.
Апроч звычайных метрык, мы гэтак жа запісвалі ў InfluxDB інфармацыю аб GPS лакацыі. Гэта было неверагодна зручна для маніторынгу месцазнаходжання скутараў у нашай адмінскай панэлі.
Фактычна, мы заўсёды ведалі дзе і які скутэр быў у патрэбны нам момант часу.
Вельмі моцна нам гэта спатрэбілася, калі мы шукалі скутар (глядзі высновы ў канцы).
Маніторынг інфраструктуры
Акрамя саміх скутараў, нам было неабходна маніторыць і ўсю нашу (даволі шырокую) інфраструктуру.
Вельмі абагульненая архітэктура выглядала прыкладна так:
Калі вылучыць чыста стэк маніторынгу, то ён выглядае наступным чынам:
З таго што мы хацелі б правяраць у воблаку, гэта:
- Базы даных
- Плашч-ключ
- Мікрасэрвісы
Так як усе нашы хмарныя сэрвісы знаходзяцца ў Kubernetes, то было б нядрэнна збіраць інфармацыю і аб яго стане.
На шчасце, Telegraf "са скрынкі" можа збіраць велізарную колькасць метрык аб стане Kubernetes кластара, а Chronograf адразу прапануе для гэтага прыгожыя дашборды.
Мы сачылі ў асноўным за працаздольнасцю падоў і спажываннем памяці. У выпадку падзення - алерты ў Slack.
Для адсочвання подаў у Kubernetes ёсць два шляхі: DaemonSet і Sidecar.
Абодва спосабу падрабязна апісаны .
Мы выкарыстоўвалі Telegraf Sidecar і апроч метрык збіралі логі подаў.
У нашым выпадку з логамі прыйшлося павазіцца. Нягледзячы на тое, што Telegraf умее выцягваць логі з Docker API, мы жадалі мець аднастайны збор логаў з нашымі канчатковымі прыладамі і наладжвалі для гэтага syslog для кантэйнераў. Магчыма, гэтае рашэнне не было прыгожым, але нараканняў у яго працы не было і логі добра адлюстроўваліся ў Chronograf'e.
Маніторыць маніторынг???
У рэшце рэшт паўстала адвечнае пытанне маніторынгу сістэм маніторынгу, але на шчасце, ці на жаль, на гэта ў нас проста не хапіла часу.
Хоць Telegraf лёгка ўмее адпраўляць свае ўласныя метрыкі ці збіраць метрыкі InfluxDB базы для адпраўкі альбо ў той жа Influx, альбо кудысьці яшчэ.
Высновы
Якія вывады мы зрабілі па выніках пілота?
Як можна рабіць маніторынг
У першую чаргу - TICK стэк цалкам апраўдаў нашы чаканні, і даў нам нават больш магчымасцяў, чым тыя на якія мы разлічвалі першапачаткова.
Увесь функцыянал, які быў нам неабходны, прысутнічаў. Усё, што мы з ім рабілі - працавала без праблем.
Proizvoditelnost
Асноўная праблема TICK стэка ў бясплатнай версіі - адсутнасць магчымасцяў па скаліраванні. Для нас гэта ня стала праблемай.
Мы не збіралі дакладных дадзеных/лічбаў аб нагрузцы, але мы збіралі дадзеныя з прыкладна 30і скутэраў адначасова.
Кожны з іх збіраў больш за тры дзясяткі метрык. Адначасова збіраліся логі з прылад. Збор і адпраўка даных адбываліся кожныя 10 секунд.
Важна адзначыць, што праз паўтара тыдня пілота, калі асноўную масу "дзіцячых больак" атрымалася выправіць і найважнейшыя праблемы ўжо былі вырашаныя, нам прыйшлося зменшыць частату адпраўкі дадзеных на сервер да 30і секунд. Гэта стала неабходна, таму што трафік на нашых LTE SIM картах пачаў хутка раставаць.
Асноўную масу трафіку з'ядалі логі, самі метрыкі нават з 10-секундным інтэрвалам практычна не марнавалі яго.
У выніку, яшчэ праз нейкі час мы зусім адключылі збор логаў на прыладах, бо пэўныя праблемы ўжо былі відавочныя і без сталага збору.
У некаторых выпадках, калі прагляд логаў усё ж быў неабходны - мы проста падлучаліся праз WireGuard па VPN.
Яшчэ дадам, што кожны асобны environment у нас быў аддзелены сябар ад сябра, і вышэйапісаная нагрузка была актуальная толькі для прадакшэн асяроддзя.
У асяроддзі распрацоўнікаў у нас быў падняты асобны інстанс InfluxDB які працягваў збіраць дадзеныя раз у 10 секунд і мы не уткнуліся ў якія-небудзь праблемы з прадукцыйнасцю.
TICK - ідэальна для невялікіх-сярэдніх праектаў
На аснове гэтай інфармацыі я б зрабіў выснову, што TICK стэк ідэальна падыходзіць для адносна невялікіх праектаў ці праектаў, у якіх сапраўды не чакаецца які-небудзь HighLoad.
Калі ў вас няма тысяч подаў або сотняў машын нават адзін інстанс InfluxDB выдатна зладзіцца з нагрузкай.
У некаторых выпадках вас можа задаволіць Influx Relay як прымітыўнае рашэнне па High Availability.
І, само сабой, ніхто не мяшае вам наладжваць "вертыкальнае" скаліроўку і проста вылучыць розныя серверы пад розныя тыпы метрык.
Калі ж вы не ўпэўненыя ў чаканай нагрузцы на сэрвісы маніторынгу, ці ў вас гарантавана ёсць/будзе вельмі "цяжкая" архітэктура - бясплатную версію TICK стэка выкарыстоўваць я б не парэкамендаваў.
Вядома, простым рашэннем было б набыццё — але тут я не магу неяк пракаментаваць, бо сам не знаёмы з тонкасцямі. Акрамя таго, што гэта вельмі дорага і сапраўды не падыдзе для дробных кампаній.
У такім выпадку, на сённяшні дзень, я б парэкамендаваў паглядзець у бок збору метрык праз Victoria Metrics і логаў з дапамогай Loki.
Праўда, зноў абмоўлюся, што Loki/Grafana значна меней зручныя (у выглядзе сваёй большай універсальнасці) чым гатовы TICK, але затое яны бясплатныя.
Важна: уся апісаная тут інфармацыя актуальная для версіі Influx 1.8, у дадзены момант вось-вось павінен выйсці ў рэліз Influx 2.0.
Пакуль не давялося паспрабаваць яго ў баявых умовах і складана рабіць высновы аб паляпшэннях, сапраўды яшчэ лепш стаў інтэрфейс, спрасцілася архітэктура (без kapacitor і chronograf),
з'явіліся темплейты ("кілер фіча") ). Але, нажаль, у дадзены момант у версіі 2 няма ключавой рэчы, па якой мы абралі першую версію - няма збору логаў.
Гэты функцыянал у Influx 2.0 таксама з'явіцца, але якія-небудзь тэрмінаў, нават прыкладных, знайсці не ўдалося.
Як не трэба рабіць IoT платформы (зараз)
У выніку, запусціўшы пілот мы самі сабралі свой паўнавартасны IoT стэк, за адсутнасцю прыдатнай па нашых мерках альтэрнатывы.
Аднак, з нядаўняга часу ў Beta версіі даступная - шкада яе не было калі мы пачыналі рабіць праект.
Канчатковы вынік і тая платформа на аснове Ansible + TICK + WireGuard, якую мы сабралі самастойна нас поўнасцю задавальняе. Але на сённяшні дзень, я б парэкамендаваў больш уважліва паглядзець на Balena перш чым спрабаваць сабраць сваю IoT платформу самім.
Таму што, у канчатковым выніку яна ўмее рабіць большую частку таго, што мы рабілі, пры гэтым OpenBalena бясплатная, а код адкрыты.
Яно ўжо ўмее не проста рассылаць абнаўленні, але і VPN тамака ўжо ўшыты і заменчаны пад выкарыстанне ў IoT асяроддзі.
А зусім нядаўна - яны і зусім выпусцілі сваю , Якая лёгка падключаецца ў іх экасістэму.
Гэй, а што са зніклым скутэрам?
Такім чынам скутэр, "Ральф", бясследна знік.
Мы адразу пабеглі глядзець карту ў нашай "адмінцы", з дадзенымі GPS метрык з InfluxDB.
Дзякуючы звесткам маніторынгу, мы лёгка вызначылі, што паркоўку скутэр пакінуў каля 21:00 мінулага дня, праехаў недзе паўгадзіны да нейкага раёна і быў запаркаваны да 5-й раніцы побач з нейкім нямецкім домам.
Пасля 5-й раніцы дадзеных маніторынгу не паступала – гэта азначала альбо поўны разрад дадатковай батарэі, альбо зламыснік здагадаўся-такі атрымаць разумнае начынне са скутэра.
Нягледзячы на гэта, па тым адрасе, дзе знаходзіўся скутэр, усё ж была выклікана паліцыя. Скутэра там не аказалася.
Аднак уладальнік дома таксама быў гэтаму здзіўлены, бо ён сапраўды ўчора ўвечары прыехаў на гэтым скутары з офіса дадому.
Як высветлілася, адзін з супрацоўнікаў падтрымкі прыехаў раніцай і забраў скутэр, убачыўшы, што ў яго цалкам разрадзілася дадатковая батарэя і павёз яго (пешшу) на паркоўку. А дадатковая батарэя выйшла са строю з-за траплення вільгаці.
Мы скралі скутэр самі ў сябе. Не ведаю, дарэчы, як і хто потым разрульваў пытанне са справай у паліцыі, але маніторынг адпрацаваў выдатна…
Крыніца: habr.com