Isang taon na ang nakalipas naglunsad kami ng pilot na bersyon ng isang proyektong pang-promosyon para sa .
Sa una, ang proyekto ay tinawag na Road-To-Barcelona, nang maglaon ay naging Road-To-Berlin (kaya R2B sa mga screenshot), at sa huli ay tinawag itong xRide.
Ang pangunahing ideya ng proyekto ay ito: sa halip na magkaroon ng isang sentralisadong serbisyo sa pagrenta ng kotse o scooter (pinag-uusapan natin ang tungkol sa mga scooter aka electric motorcycle, hindi kickscooter/scooter) gusto naming gumawa ng isang platform para sa desentralisadong pagrenta. Tungkol sa mga paghihirap na aming naranasan .
Sa una, ang proyekto ay nakatuon sa mga kotse, ngunit dahil sa mga deadline, napakahabang komunikasyon sa mga tagagawa at isang malaking bilang ng mga paghihigpit sa kaligtasan, ang mga electric scooter ay pinili para sa piloto.
Ang gumagamit ay nag-install ng isang iOS o Android na application sa telepono, nilapitan ang scooter na gusto niya, pagkatapos nito ang telepono at ang scooter ay nagtatag ng isang peer-to-peer na koneksyon, ang ETH ay ipinagpalit at ang user ay maaaring magsimulang sumakay sa pamamagitan ng pag-on sa scooter sa pamamagitan ng ang telepono. Sa pagtatapos ng biyahe, posible ring magbayad para sa biyahe gamit ang Ethereum mula sa wallet ng user sa telepono.
Bilang karagdagan sa mga scooter, nakita ng user ang "mga matalinong charger" sa application, sa pamamagitan ng pagbisita kung saan maaaring baguhin mismo ng user ang kasalukuyang baterya kung mababa ito.
Sa pangkalahatan, ganito ang hitsura ng aming piloto, na inilunsad noong Setyembre noong nakaraang taon sa dalawang lungsod ng Germany: Bonn at Berlin.
At pagkatapos, isang araw, sa Bonn, madaling araw, ang aming team ng suporta (na matatagpuan sa site upang mapanatili ang mga scooter sa kaayusan ng trabaho) ay inalertuhan: isa sa mga scooter ay nawala nang walang bakas.
Paano ito mahahanap at ibalik?
В этой статье я расскажу об этом, но для начала — о том как мы построили нашу собственную IoT платформу и как мы осуществляли мониторинг над ней.
Ano at bakit dapat subaybayan: mga scooter, imprastraktura, pagsingil?
Kaya, ano ang gusto naming subaybayan sa aming proyekto?
Una sa lahat, ito ang mga scooter mismo - ang mga electric scooter mismo ay medyo mahal, hindi ka maaaring maglunsad ng naturang proyekto nang hindi sapat na handa; kung maaari, nais mong mangolekta ng maraming impormasyon hangga't maaari tungkol sa mga scooter: tungkol sa kanilang lokasyon, antas ng singil , atbp.
Bilang karagdagan, gusto kong subaybayan ang estado ng aming sariling imprastraktura ng IT - mga database, serbisyo at lahat ng kailangan nila upang gumana. Kinakailangan din na subaybayan ang katayuan ng "mga matalinong charger", kung sakaling masira o maubusan ang mga ito ng buong baterya.
Mga scooter
Ano ang aming mga scooter at ano ang gusto naming malaman tungkol sa kanila?
Ang una at pinakamahalagang bagay ay ang mga coordinate ng GPS, dahil salamat sa kanila naiintindihan namin kung nasaan sila at kung saan sila gumagalaw.
Susunod ay ang singil ng baterya, salamat sa kung saan maaari naming matukoy na ang pagsingil ng mga scooter ay matatapos at magpadala ng isang juicer o hindi bababa sa babalaan ang gumagamit.
Siyempre, kailangan ding suriin kung ano ang nangyayari sa aming mga bahagi ng Hardware:
- gumagana ba ang bluetooth?
- gumagana ba ang GPS module mismo?
- Nagkaroon din kami ng problema sa katotohanan na ang GPS ay maaaring magpadala ng mga maling coordinate at ma-stuck, at ito ay matutukoy lamang ng mga karagdagang pagsusuri sa scooter,
at abisuhan ang suporta sa lalong madaling panahon upang malutas ang isyu
- Nagkaroon din kami ng problema sa katotohanan na ang GPS ay maaaring magpadala ng mga maling coordinate at ma-stuck, at ito ay matutukoy lamang ng mga karagdagang pagsusuri sa scooter,
At panghuli: mga pagsusuri sa software, simula sa OS at processor, network at disk load, na nagtatapos sa mga pagsusuri sa sarili naming mga module na mas partikular sa amin (, ).
hardware
Ano ang ating "bakal" na bahagi?
Учитывая максимально сжатые сроки и необходимость быстрого прототипирования мы выбрали для себя максимально простой для реализации и подбора компонентов вариант — Raspberry Pi.
Bilang karagdagan sa Rpi mismo, mayroon kaming isang pasadyang board (na kami mismo ang bumuo at nag-order mula sa China upang pabilisin ang proseso ng pagpupulong ng pangwakas na solusyon) at isang hanay ng mga bahagi - isang relay (upang i-on/i-off ang scooter), isang battery charge reader, isang modem, mga antenna. Ang lahat ng ito ay compactly packaged sa isang espesyal na "xRide box".
Dapat ding tandaan na ang buong kahon ay pinalakas ng isang karagdagang power bank, na kung saan ay pinalakas ng pangunahing baterya ng scooter.
Ginawa nitong posible na gumamit ng pagsubaybay at i-on ang scooter kahit na matapos ang biyahe, dahil ang pangunahing baterya ay naka-off kaagad pagkatapos na i-on ang ignition key sa "off" na posisyon.
Docker? Plain Linux? at deployment
Bumalik tayo sa pagsubaybay, kaya Raspberry - ano ang mayroon tayo?
Одна из первых вещей которую мы хотели использовать для ускорения процесса деплоя, обновления и доставки компонентов на физические устройства был Docker.
Sa kasamaang palad, mabilis na naging malinaw na ang Docker sa RPi, bagama't gumagana ito, ay may maraming overhead, lalo na sa mga tuntunin ng pagkonsumo ng enerhiya.
Ang pagkakaiba gamit ang "katutubong" OS, bagama't hindi masyadong malakas, ay sapat pa rin para mag-ingat kami sa posibilidad na mawalan ng bayad nang masyadong mabilis.
Ang pangalawang dahilan ay isa sa aming mga partner na library sa Node.js (sic!) - ang tanging bahagi ng system na hindi nakasulat sa Go/C/C++.
Ang mga may-akda ng aklatan ay walang oras upang magbigay ng gumaganang bersyon sa alinman sa mga "katutubong" wika.
Hindi lamang ang node mismo ang hindi pinaka-eleganteng solusyon para sa mga device na mababa ang pagganap, ngunit ang library mismo ay gutom na gutom sa mapagkukunan.
Мы поняли, что при всем желании использование Docker для нас будет слишком большим оверхедом. Был сделан выбор в пользу нативной OS и работы под ней напрямую.
OS
Bilang resulta, muli naming pinili ang pinakasimpleng opsyon bilang OS at ginamit namin ang Raspbian (Debian build para sa Pi).
Isinulat namin ang lahat ng aming software sa Go, kaya isinulat din namin ang pangunahing module ng ahente ng hardware sa aming system sa Go.
Siya ang may pananagutan sa pagtatrabaho sa GPS, Bluetooth, pagbabasa ng singil, pag-on ng scooter, atbp.
I-deploy
Agad na bumangon ang tanong tungkol sa pangangailangang magpatupad ng mekanismo para sa paghahatid ng mga update sa mga device (OTA) - parehong mga update sa aming ahente/application mismo, at mga update sa OS/firmware mismo (dahil ang mga bagong bersyon ng ahente ay maaaring mangailangan ng mga update sa kernel o mga bahagi ng system, mga aklatan, atbp.) .
Matapos ang medyo mahabang pagsusuri sa merkado, lumabas na napakaraming solusyon para sa paghahatid ng mga update sa device.
Mula sa medyo simple, karamihan sa mga utility na naka-update/dual-boot oriented tulad ng swupd/SWUpdate/OSTree hanggang sa ganap na mga platform tulad ng Mender at Balena.
Una sa lahat, nagpasya kaming interesado kami sa mga end-to-end na solusyon, kaya ang pagpili ay agad na nahulog sa mga platform.
Ang napaka ay hindi kasama dahil sa katotohanang ginagamit talaga nito ang parehong Docker sa loob ng balenaEngine nito.
Ngunit tandaan ko na sa kabila nito, napunta kami sa patuloy na paggamit ng kanilang produkto para sa flash firmware sa mga SD card - isang simple at lubos na maginhawang utility para dito.
Поэтому в итоге выбор пал на . Mender представляет из себя полноценную платформу для сборки, доставки и установки прошивок.
Sa pangkalahatan, maganda ang hitsura ng platform, ngunit tumagal kami ng halos isang linggo at kalahati para lang mabuo ang tamang bersyon ng aming firmware gamit ang mender builder.
At habang mas ibinaon natin ang ating mga sarili sa masalimuot na paggamit nito, mas naging malinaw na para ganap na maipatupad ito ay kakailanganin natin ng mas maraming oras kaysa mayroon tayo.
Naku, ang aming masikip na mga deadline ay nangangahulugan na napilitan kaming iwanan ang paggamit ng Mender at pumili ng mas simple.
Ansible
Самым простым решением в нашей ситуации оказалось использование Ansible. Пары playbook’ов для начала было вполне достаточно.
Ang kanilang kakanyahan ay na kumonekta kami mula sa host (CI server) sa pamamagitan ng ssh sa aming mga rasberry at namahagi ng mga update sa kanila.
Sa pinakadulo simula, ang lahat ay simple - kailangan mong nasa parehong network kasama ang mga device, ang pagbuhos ay ginawa sa pamamagitan ng Wi-Fi.
Sa opisina ay mayroon lamang isang dosenang test raspberry na konektado sa parehong network, ang bawat device ay may static na IP address na tinukoy din sa Ansible Inventory.
Ang Ansible ang naghatid ng aming ahente sa pagsubaybay sa mga end device
3G / LTE
Sa kasamaang palad, ang use case na ito para sa Ansible ay maaari lamang gumana sa development mode bago kami magkaroon ng mga aktwal na scooter.
Dahil ang mga scooter, tulad ng naiintindihan mo, ay hindi nakaupo na konektado sa isang Wi-Fi router, patuloy na naghihintay ng mga update sa network.
Sa katotohanan, ang mga scooter ay hindi maaaring magkaroon ng anumang koneksyon maliban sa mobile 3G/LTE (at kahit na hindi sa lahat ng oras).
Agad itong nagpapataw ng maraming problema at limitasyon, tulad ng mababang bilis ng koneksyon at hindi matatag na komunikasyon.
Ngunit ang pinakamahalagang bagay ay na sa isang 3G/LTE network hindi tayo basta-basta umaasa sa isang static na IP na nakatalaga sa network.
Bahagyang nalutas ito ng ilang provider ng SIM card; may mga espesyal na SIM card na idinisenyo para sa mga IoT device na may mga static na IP address. Ngunit wala kaming access sa mga naturang SIM card at hindi kami makagamit ng mga IP address.
Siyempre, may mga ideya na gumawa ng ilang uri ng pagpaparehistro ng mga IP address aka pagtuklas ng serbisyo sa isang lugar tulad ng Consul, ngunit kinailangan naming iwanan ang mga ganoong ideya, dahil sa aming mga pagsubok ang IP address ay maaaring magbago nang madalas, na humantong sa malaking kawalang-tatag.
Para sa kadahilanang ito, ang pinaka-maginhawang paggamit para sa paghahatid ng mga sukatan ay hindi ang paggamit ng pull model, kung saan kami pupunta sa mga device para sa mga kinakailangang sukatan, ngunit itulak, na naghahatid ng mga sukatan mula sa device nang direkta sa server.
VPN
В качестве решения этой проблемы мы выбрали VPN — а конкретно .
Ang mga kliyente (scooter) sa simula ng system ay nakakonekta sa VPN server at nakakonekta sa kanila. Ginamit ang tunnel na ito para maghatid ng mga update.
Sa teorya, ang parehong tunel ay maaaring gamitin para sa pagsubaybay, ngunit ang naturang koneksyon ay mas kumplikado at hindi gaanong maaasahan kaysa sa simpleng push.
Mga mapagkukunan ng ulap
Panghuli, kinakailangan na subaybayan ang aming mga serbisyo sa cloud at database, dahil ginagamit namin ang mga Kubernetes para sa kanila, sa perpektong paraan upang ang pag-deploy ng pagsubaybay sa cluster ay kasing simple hangga't maaari. Sa isip, gamit , так как для деплоя, мы в большинстве случаев используем его. И, само собой, для мониторинга облака нужно использовать те же решения, что и для самих скутеров.
Ibinigay
Phew, mukhang inayos namin ang paglalarawan, gumawa tayo ng isang listahan ng kung ano ang kailangan namin sa dulo:
- Isang mabilis na solusyon, dahil kailangan na ang pagsubaybay sa panahon ng proseso ng pag-unlad
- Dami/dami – maraming sukatan ang kailangan
- Kinakailangan ang koleksyon ng log
- Pagkakaaasahan - ang data ay mahalaga upang ilunsad ang tagumpay
- Hindi mo magagamit ang pull model - kailangan mo ng push
- Kailangan namin ng pinag-isang pagsubaybay hindi lamang sa hardware, kundi pati na rin sa cloud
Конечная картинка выглядела примерно так
Pagpili ng stack
Kaya, kami ay nahaharap sa tanong ng pagpili ng isang monitoring stack.
В первую очередь, мы искали наиболее полноценное all-in-one решение, которое одновременно покрывало бы все наши требования, но при этом и было бы достаточно гибким чтобы подогнать его использование под наши нужды. Все-таки, у нас было много ограничений наложенных на нас железом, архитектурой и сроками.
Mayroong isang malaking iba't ibang mga solusyon sa pagsubaybay, simula sa ganap na mga sistema tulad ng , o at nagtatapos sa mga handa na solusyon para sa pamamahala ng Fleet.
Sa una, ang huli ay tila isang mainam na solusyon para sa amin, ngunit ang ilan ay walang ganap na pagsubaybay, ang iba ay may mahigpit na limitadong mga kakayahan ng mga libreng bersyon, at ang iba ay hindi lamang sumasakop sa aming "mga gusto" o hindi sapat na kakayahang umangkop upang magkasya sa aming mga sitwasyon. Ang ilan ay hindi na napapanahon.
Matapos suriin ang ilang katulad na mga solusyon, mabilis kaming napagpasyahan na magiging mas madali at mas mabilis na mag-assemble ng katulad na stack sa aming sarili. Oo, magiging mas kumplikado ito kaysa sa pag-deploy ng ganap na handa na platform ng pamamahala ng Fleet, ngunit hindi namin kailangang gumawa ng mga kompromiso.
Halos tiyak, sa lahat ng napakalaking kasaganaan ng mga solusyon, mayroon nang isang handa na ganap na angkop sa amin, ngunit sa aming kaso ay mas mabilis na mag-ipon ng isang tiyak na stack sa aming sarili at i-customize ito "para sa aming sarili" kaysa sa pagsubok ng mga produktong handa.
При всем этом, мы не стремились собирать целиковую платформу для мониторинга самостоятельно, а искали максимально функциональные "готовые" стеки, только с возможностью их гибко настраивать.
(B)ELK?
Ang unang solusyon na talagang isinasaalang-alang ay ang kilalang ELK stack.
Sa katunayan, ito ay dapat na tinatawag na BELK, dahil ang lahat ay nagsisimula sa Beats -
Siyempre, ang ELK ay isa sa pinakasikat at makapangyarihang solusyon sa larangan ng pagsubaybay, at higit pa sa pagkolekta at pagproseso ng mga log.
Inilaan namin na ang ELK ay gagamitin upang mangolekta ng mga log at pati na rin ang pangmatagalang imbakan ng mga sukatan na nakuha mula sa Prometheus.
Para sa visualization maaari mong gamitin ang Grafan.
Sa katunayan, ang bagong ELK stack ay maaaring mangolekta ng mga sukatan nang nakapag-iisa (metricbeat), at maaari ding ipakita ni Kibana ang mga ito.
Ngunit gayon pa man, ang ELK sa simula ay lumago mula sa mga log at sa ngayon ang paggana ng mga sukatan ay may ilang mga seryosong disbentaha:
- Kapansin-pansing mas mabagal kaysa sa Prometheus
- Sumasama sa mas kaunting lugar kaysa sa Prometheus
- Mahirap mag-set up ng mga alerto para sa kanila
- Ang mga sukatan ay tumatagal ng maraming espasyo
- Настройка дашбордов с метриками в Kiban’е значительно сложнее Grafan’ы
В общем, метрики в ELK тяжелые и пока не такие удобные как в других решениях, которых сейчас на самом деле значительно больше чем просто Prometheus: TSDB, Victoria Metrics, Cortex итд итп. Конечно, очень бы хотелось иметь сразу полноценное all-in-one решение, но в случае с metricbeat выходило слишком много компромиссов.
At ang ELK stack mismo ay may ilang mahihirap na sandali:
- Ito ay mabigat, kung minsan kahit na napakabigat kung mangolekta ka ng isang medyo malaking halaga ng data
- Kailangan mong "marunong magluto" nito - kailangan mong sukatin ito, ngunit hindi ito maliit na gawin
- Inalis ang libreng bersyon - ang libreng bersyon ay walang normal na pag-aalerto, at sa oras ng pagpili ay walang pagpapatunay
Dapat kong sabihin na kamakailan ang huling punto ay naging mas mahusay at bilang karagdagan (kabilang ang pagpapatunay) ang modelo ng pagpepresyo mismo ay nagsimulang magbago.
Ngunit sa oras kung kailan namin i-deploy ang solusyon na ito, walang anumang alerto.
Marahil ay maaari naming sinubukang bumuo ng isang bagay gamit ang ElastAlert o iba pang mga solusyon sa komunidad, ngunit nagpasya pa rin kaming isaalang-alang ang iba pang mga alternatibo.
Loki - Grafana - Prometheus
Sa ngayon, ang isang magandang solusyon ay maaaring bumuo ng isang monitoring stack na nakabatay lamang sa Prometheus bilang isang tagapagbigay ng sukatan, Loki para sa mga log, at para sa visualization maaari mong gamitin ang parehong Grafana.
Sa kasamaang palad, sa oras ng pagsisimula ng pilot ng pagbebenta ng proyekto (Setyembre-Oktubre 19), si Loki ay nasa beta na bersyon 0.3-0.4 pa rin, at sa oras ng pagsisimula ng pag-unlad ay hindi ito maituturing bilang isang solusyon sa produtcion sa lahat.
Wala pa akong karanasan sa aktwal na paggamit ng Loki sa mga seryosong proyekto, ngunit masasabi kong mahusay ang Promtail (isang ahente para sa pagkolekta ng mga log) para sa parehong bare-metal at pods sa kubernetes.
tik
Marahil ang pinaka-karapat-dapat (ang nag-iisang?) na buong tampok na alternatibo sa ELK stack ay maaari na ngayong tawaging TICK stack - Telegraf, InfluxDB, Chronograf, Kapacitor.
Ilalarawan ko ang lahat ng mga bahagi sa ibaba nang mas detalyado, ngunit ang pangkalahatang ideya ay ito:
- Telegraf — агент для сборки метрик
- InfluxDB - database ng mga sukatan
- Kapacitor - real-time na metrics processor para sa pag-alerto
- Chronograf - web panel para sa visualization
Para sa InfluxDB, Kapacitor at Chronograf mayroong mga opisyal na helm chart na ginamit namin upang i-deploy ang mga ito.
Надо отметить, что в свежей версии Influx 2.0 (beta) Kapacitor и Chronograf стали частью InfluxDB и больше не существуют отдельно
Telegraph
ay isang napakagaan na ahente para sa pagkolekta ng mga sukatan sa isang makina ng estado.
Maaari niyang subaybayan ang isang malaking halaga ng lahat, mula sa sa
server .
У него есть ряд классных преимуществ:
- Быстрый и легкий (написан на Go)
- Kumakain ng pinakamababang halaga ng mga mapagkukunan
- Push metrics bilang default
- Kinokolekta ang lahat ng kinakailangang sukatan
- Системные метрики без каких-либо настроек
- Mga sukatan ng hardware gaya ng impormasyon mula sa mga sensor
- Очень легко добавлять собственные метрики
- Maraming plugin sa labas ng kahon
- Nangongolekta ng mga log
Dahil kailangan para sa amin ang mga sukatan ng push, ang lahat ng iba pang mga pakinabang ay higit pa sa mga kaaya-ayang karagdagan.
Ang koleksyon ng mga log ng ahente mismo ay napaka-maginhawa, dahil hindi na kailangang ikonekta ang mga karagdagang kagamitan para sa pag-log log.
Influx ay nag-aalok ng pinaka-maginhawang karanasan para sa pagtatrabaho sa mga log kung gagamit ka .
Ang Telegraf sa pangkalahatan ay isang mahusay na ahente para sa pagkolekta ng mga sukatan, kahit na hindi mo ginagamit ang natitirang bahagi ng ICK stack.
Maraming tao ang tumatawid nito sa ELK at iba't ibang mga database ng serye ng oras para sa kaginhawahan, dahil maaari itong sumulat ng mga sukatan halos kahit saan.
InfluxDB
Ang InfluxDB ay ang pangunahing core ng TICK stack, katulad ng isang time-series database para sa mga sukatan.
Bilang karagdagan sa mga sukatan, maaari ding mag-imbak ng mga log ang Influx, bagama't, sa esensya, ang mga log para dito ay pareho lang ng mga sukatan, tanging sa halip na mga karaniwang numerical indicator, ang pangunahing function ay isinasagawa ng isang linya ng log text.
InfluxDB тоже написан на Go и работает, по ощущениям, значительно быстрее в сравнении с ELK на нашем (не самом мощном) кластере.
Isa sa mga cool na bentahe ng Influx ay magsasama rin ng isang napaka-maginhawa at mayaman na API para sa mga query sa data, na ginamit namin nang napakaaktibo.
Mga disadvantage - $$$ o scaling?
Ang TICK stack ay mayroon lamang isang disbentaha na aming natuklasan - ito sinta. Даже очень.
Ano ang mayroon ang bayad na bersyon na wala sa libreng bersyon?
Sa abot ng aming naiintindihan, ang tanging pagkakaiba sa pagitan ng bayad na bersyon ng TICK stack at ng libre ay ang mga kakayahan sa pag-scale.
А именно — поднять кластер с High availability можно только в .
Kung gusto mo ng ganap na HA, kailangan mong magbayad o gumamit ng ilang saklay. Mayroong ilang mga solusyon sa komunidad - halimbawa mukhang isang karampatang solusyon, ngunit ito ay nakasulat na ito ay hindi angkop para sa produksyon, pati na rin
- isang simpleng solusyon na may data pumping sa pamamagitan ng NATS (kailangan din itong i-scale, ngunit ito ay malulutas).
Nakakalungkot, ngunit pareho silang tila inabandona - walang mga bagong commit, ipinapalagay ko na ang isyu ay ang malapit na inaasahang paglabas ng bagong bersyon ng Influx 2.0, kung saan maraming mga bagay ang magkakaiba (walang impormasyon tungkol sa scaling sa ito pa).
Opisyal na mayroong libreng bersyon - sa katunayan, ito ay isang primitive na HA, ngunit sa pamamagitan lamang ng pagbabalanse,
dahil ang lahat ng data ay isusulat sa lahat ng InfluxDB instance sa likod ng load balancer.
Meron siya tulad ng mga potensyal na problema sa mga overwriting point at ang pangangailangang gumawa ng mga base para sa mga sukatan nang maaga
(na awtomatikong nangyayari sa panahon ng normal na trabaho sa InfluxDB).
Bilang karagdagan , это означает дополнительные накладные расходы на дуплицированные метрики (и обработка и хранение), которые могли вам быть не нужны, но разделить их возможности нет.
Victoria Sukatan?
Bilang resulta, sa kabila ng katotohanan na ganap kaming nasiyahan sa TICK stack sa lahat ng bagay maliban sa bayad na scaling, nagpasya kaming tingnan kung mayroong anumang mga libreng solusyon na maaaring palitan ang database ng InfluxDB, habang iniiwan ang natitirang bahagi ng T_CK.
Mayroong maraming mga database ng serye ng oras, ngunit ang pinaka-maaasahan ay ang Victoria Metrics, mayroon itong isang bilang ng mga pakinabang:
- Быстрая и легкая, по крайней мере по результатам
- Mayroong isang bersyon ng kumpol, tungkol sa kung saan mayroon nang magagandang pagsusuri ngayon
- Kaya niya shard
- Sinusuportahan ang InfluxDB protocol
Hindi namin nilayon na bumuo ng ganap na custom na stack batay sa Victoria at ang pangunahing pag-asa ay magagamit namin ito bilang isang drop-in na kapalit para sa InfluxDB.
К сожалению, это невозможно, несмотря на то, что поддерживается протокол InfluxDB, это работает только для записи метрик — "наружу" доступно только Prometheus API, а значит натравить Chronograf на нее не получится.
Bukod dito, ang mga numerong halaga lamang ang sinusuportahan para sa mga sukatan (ginamit namin ang mga halaga ng string para sa mga pasadyang sukatan - higit pa doon sa seksyon ).
Malinaw, para sa parehong dahilan, ang VM ay hindi maaaring mag-imbak ng mga log tulad ng ginagawa ng Influx.
Gayundin, dapat tandaan na sa oras ng paghahanap para sa pinakamainam na solusyon, ang Victoria Metrics ay hindi pa masyadong sikat, ang dokumentasyon ay mas maliit at ang pag-andar ay mas mahina.
(Wala akong maalala na detalyadong paglalarawan ng bersyon ng kumpol at sharding).
Pagpili ng base
Bilang resulta, napagpasyahan na para sa piloto ay lilimitahan pa rin namin ang aming sarili sa isang node ng InfluxDB.
Mayroong ilang mga pangunahing dahilan para sa pagpili na ito:
- Нам очень нравился функционал TICK стека целиком
- Nagawa na namin itong i-deploy at mahusay itong gumana
- Сроки поджимали и не оставалось много времени тестировать другие варианты
- Hindi namin inaasahan na ganito kabigat ang kargada
Wala kaming maraming mga scooter para sa unang yugto ng pilot, at ang pagsubok sa panahon ng pag-unlad ay hindi nagpapakita ng anumang mga isyu sa pagganap.
Samakatuwid, napagpasyahan namin na para sa proyektong ito ang isang Influx node ay magiging sapat para sa amin nang hindi nangangailangan ng pag-scale (tingnan ang mga konklusyon sa dulo).
Napagpasyahan namin ang stack at base - ngayon tungkol sa mga natitirang bahagi ng TICK stack.
Kapasitor
Ang Kapacitor ay bahagi ng TICK stack, isang serbisyong maaaring sumubaybay sa mga sukatan na pumapasok sa database nang real time at magsagawa ng iba't ibang aksyon batay sa mga panuntunan.
Sa pangkalahatan, ito ay nakaposisyon bilang isang tool para sa potensyal na pagsubaybay sa anomalya at machine learning (hindi ako sigurado na ang mga function na ito ay in demand), ngunit ang pinakasikat na kaso ng paggamit nito ay mas karaniwan - nag-aalerto.
Так и мы его использовали для нотификаций. Мы настроили Slack оповещения о том, что тот или иной скутер отключился, то же самое было сделано для умных зарядок и важных компонентов инфраструктуры.
Это позволяло быстро реагировать на проблемы, а также получать нотификации о том, что все пришло в норму.
Простой пример — сломалась или по какой-то причине разрядилась дополнительная батарея для питания нашей "коробочки", просто поставив новую мы должны через некоторое время получить нотификацию о восстановлении работоспособности скутера.
Sa Influx 2.0 Kapacitor ay naging bahagi ng DB
Chronograf
Nakita ko ang maraming iba't ibang mga solusyon sa UI para sa pagsubaybay, ngunit maaari kong sabihin na sa mga tuntunin ng pag-andar at UX, walang maihahambing sa Chronograf.
Начинали мы использовать TICK стек, как ни странно, с Grafan’ой в качестве веб-интерфейса.
Hindi ko ilalarawan ang functionality nito; alam ng lahat ang malawak nitong posibilidad para sa pag-set up ng kahit ano.
Gayunpaman, ang Grafana ay isa pa ring ganap na unibersal na instrumento, habang ang Chronograf ay pangunahing idinisenyo para gamitin sa Influx.
At siyempre, salamat dito, kayang bayaran ng Chronograf ang mas matalino o maginhawang pag-andar.
Marahil ang pangunahing kaginhawahan ng pagtatrabaho sa Chronograf ay na maaari mong tingnan ang loob ng iyong InfluxDB sa pamamagitan ng Explore.
Казалось бы, в Grafana есть почти идентичный функционал, но в реальности настройка дашборда в Chronograf может осуществляться несколькими кликами мыши (попутно смотря на визуализацию там же), тогда как в Grafana вам все равно рано или поздно придется редактировать JSON конфигурацию (само собой Chronograf позволяет выгрузить ваши настроенные "руками" даши и редактировать в виде JSON если необходимо — но мне никогда не приходилось их трогать после создания на UI).
Ang Kibana ay may mas mayamang mga kakayahan para sa paglikha ng mga dashboard at mga kontrol para sa kanila, ngunit ang UX para sa mga naturang operasyon ay napakasalimuot.
Kakailanganin ng ilang mahusay na pag-unawa upang lumikha ng isang maginhawang dashboard. At kahit na ang functionality ng Chronograf dashboard ay mas kaunti, ang paggawa at pag-customize ng mga ito ay mas simple.
Ang mga dashboard mismo, bukod sa magandang visual na istilo, ay talagang hindi naiiba sa mga dashboard sa Grafana o Kibana:
Ito ang hitsura ng window ng query:
Важно отметить, помимо прочего, что зная типы полей в базе InfluxDB хронограф иногда сам может автоматически помогать вам с написанием Query или выбором правильной функции агрегации типа mean.
At siyempre, ang Chronograf ay maginhawa hangga't maaari para sa pagtingin sa mga log. Mukhang ganito:
Bilang default, ang mga Influx log ay iniayon sa paggamit ng syslog at samakatuwid mayroon silang mahalagang parameter - kalubhaan.
Ang graph sa itaas ay partikular na kapaki-pakinabang; dito makikita mo ang mga error na nagaganap at agad na malinaw na ipinapakita ng kulay kung mas mataas ang kalubhaan.
Ilang beses kaming nakahuli ng mahahalagang bug sa ganitong paraan, titingnan ang mga log para sa nakaraang linggo at nakakakita ng pulang spike.
Siyempre, pinakamainam na mag-set up ng mga alerto para sa gayong mga error, dahil mayroon na kaming lahat para dito.
Na-on pa namin ito saglit, ngunit sa proseso ng paghahanda ng piloto, napag-alaman na marami kaming natatanggap na mga error (kabilang ang mga system tulad ng hindi magagamit ng LTE network), na "nag-spam" din sa Slack channel marami, nang hindi nagdudulot ng malaking pakinabang.
Ang tamang solusyon ay upang mahawakan ang karamihan sa mga ganitong uri ng mga error, ayusin ang kalubhaan para sa mga ito, at pagkatapos lamang paganahin ang pag-alerto.
Sa ganitong paraan, mga bago o mahahalagang error lang ang ipo-post sa Slack. Kulang lang ang oras para sa ganoong setup dahil sa masikip na mga deadline.
Pagpapatunay
Nararapat ding banggitin na sinusuportahan ng Chronograf ang OAuth at OIDC bilang pagpapatunay.
Ito ay napaka-maginhawa, dahil ito ay nagbibigay-daan sa iyo upang madaling ilakip ito sa iyong server at lumikha ng ganap na SSO.
В нашем случае — сервером был — ito ay ginamit upang kumonekta sa pagsubaybay, ngunit ang parehong server ay ginamit din upang patotohanan ang mga scooter at mga kahilingan sa back-end.
“Админка”
Последний компонент, который я опишу — это наша самописная "админка" на Vue.
Sa pangkalahatan, ito ay isang standalone na serbisyo lamang na nagpapakita ng impormasyon ng scooter mula sa aming sariling mga database, microservice, at data ng sukatan mula sa InfluxDB nang sabay-sabay.
Помимо того, туда были вынесены многие административные функции, вроде экстренной перезагрузки или удаленного открытия замка для команды поддержки.
Nagkaroon din ng mga mapa. Nabanggit ko na na nagsimula kami sa Grafana sa halip na Chronograf - dahil para sa mga mapa ng Grafana ay magagamit sa anyo ng mga plugin, kung saan maaari naming tingnan ang mga coordinate ng mga scooter. Sa kasamaang palad, ang mga kakayahan ng mga widget ng mapa para sa Grafana ay napakalimitado, at bilang isang resulta, mas madaling magsulat ng iyong sariling web application gamit ang mga mapa sa loob ng ilang araw, upang hindi lamang makita ang mga coordinate sa sandaling ito, ngunit ipakita din. ang rutang tinahak ng scooter, magagawang i-filter ang data sa mapa, atbp. (lahat ng functionality na iyon na hindi namin ma-configure sa isang simpleng dashboard).
Isa sa mga nabanggit na bentahe ng Influx ay ang kakayahang madaling gumawa ng sarili mong sukatan.
Ito ay nagpapahintulot na ito ay magamit para sa isang malaking iba't ibang mga sitwasyon.
Sinubukan naming i-record ang lahat ng kapaki-pakinabang na impormasyon doon: charge ng baterya, status ng lock, performance ng sensor, bluetooth, GPS, at marami pang ibang pagsusuri sa kalusugan.
Ipinakita namin ang lahat ng ito sa admin panel.
Siyempre, ang pinakamahalagang pamantayan para sa amin ay ang kondisyon ng pagpapatakbo ng scooter - sa katunayan, sinusuri ito mismo ng Influx at ipinapakita ito gamit ang "mga berdeng ilaw" sa seksyon ng Nodes.
Ginagawa ito ng function — ginamit namin ito upang maunawaan ang pagganap ng aming kahon at ipadala ang parehong mga alerto sa Slack.
Sa pamamagitan ng paraan, pinangalanan namin ang mga scooter pagkatapos ng mga pangalan ng mga character mula sa The Simpsons - napakaginhawa upang makilala ang mga ito mula sa bawat isa
Да и вообще так было веселее. Постоянно звучали фразы вроде "Ребята — Смитерс умер!"
Mga sukatan ng string
Mahalagang pinapayagan ka ng InfluxDB na mag-imbak hindi lamang ng mga numerong halaga, tulad ng kaso sa Victoria Metrics.
Mukhang hindi ito napakahalaga - pagkatapos ng lahat, bukod sa mga log, anumang sukatan ay maaaring maimbak sa anyo ng mga numero (magdagdag lamang ng pagmamapa para sa mga kilalang estado - isang uri ng enum)?
Sa aming kaso, mayroong kahit isang senaryo kung saan ang mga sukatan ng string ay lubhang kapaki-pakinabang.
Nagkataon lang na ang supplier ng aming "smart charger" ay isang third party, wala kaming kontrol sa proseso ng pag-develop at ang impormasyon na maibibigay ng mga charger na ito.
Bilang resulta, ang charging API ay malayo sa perpekto, ngunit ang pangunahing problema ay hindi namin palaging naiintindihan ang kanilang estado.
Dito nagligtas si Influx. Isinulat lang namin ang string status na dumating sa amin sa InfluxDB database field nang walang pagbabago.
Какое-то время туда попадали только значения вида "online" и "offline", на основе чего у нас в админке отображалась информация, а в Slack приходили уведомления. Однако в какой-то момент туда стали попадать так же значения вида "disconnected".
Tulad ng nangyari sa ibang pagkakataon, ang katayuang ito ay ipinadala nang isang beses pagkatapos ng pagkawala ng koneksyon, kung ang charger ay hindi makapagtatag ng isang koneksyon sa server pagkatapos ng isang tiyak na bilang ng mga pagtatangka.
Kaya, kung gumamit lang kami ng isang nakapirming hanay ng mga halaga, maaaring hindi namin makita ang mga pagbabagong ito sa firmware sa tamang oras.
At sa pangkalahatan, ang mga sukatan ng string ay nagbibigay ng higit pang mga posibilidad para magamit; maaari mong i-record ang halos anumang impormasyon sa mga ito. Bagaman, siyempre, kailangan mo ring maingat na gamitin ang tool na ito.
Bilang karagdagan sa mga karaniwang sukatan, naitala din namin ang impormasyon ng lokasyon ng GPS sa InfluxDB. Ito ay hindi kapani-paniwalang kapaki-pakinabang para sa pagsubaybay sa lokasyon ng mga scooter sa aming admin panel.
Sa katunayan, palagi naming alam kung saan at kung aling scooter ang nasa sandaling kailangan namin.
Очень сильно нам это пригодилось, когда мы разыскивали скутер (смотри выводы в конце).
Pagsubaybay sa imprastraktura
Bilang karagdagan sa mga scooter mismo, kailangan din naming subaybayan ang aming buong (medyo malawak) na imprastraktura.
Очень обобщенная архитектура выглядела примерно так:
Kung i-highlight natin ang isang purong monitoring stack, ganito ang hitsura:
Ang gusto naming suriin sa cloud ay:
- Mga database
- keycloak
- Mga microservice
Dahil ang lahat ng aming mga serbisyo sa cloud ay matatagpuan sa Kubernetes, mainam na mangolekta ng impormasyon tungkol sa estado nito.
Sa kabutihang palad, ang Telegraf sa labas ng kahon ay maaaring mangolekta ng isang malaking bilang ng mga sukatan tungkol sa estado ng Kubernetes cluster, at agad na nag-aalok ang Chronograf ng magagandang dashboard para dito.
Мы следили в основном за работоспособностью подов и потреблением памяти. В случае падения — алерты в Slack.
Mayroong dalawang paraan upang subaybayan ang mga pod sa Kubernetes: DaemonSet at Sidecar.
Оба способа подробно описаны .
Gumamit kami ng Telegraf Sidecar at, bilang karagdagan sa mga sukatan, nakolekta ang mga log ng pod.
Sa aming kaso, kinailangan naming pag-usapan ang mga log. Sa kabila ng katotohanang maaaring hilahin ng Telegraf ang mga log mula sa Docker API, gusto naming magkaroon ng pare-parehong koleksyon ng mga log sa aming mga end device at i-configure ang syslog para sa mga container para dito. Marahil ang solusyon na ito ay hindi maganda, ngunit walang mga reklamo tungkol sa trabaho nito at ang mga log ay ipinakita nang maayos sa Chronograf.
Subaybayan ang pagsubaybay???
Sa huli, ang lumang tanong tungkol sa pagsubaybay sa mga sistema ng pagsubaybay ay lumitaw, ngunit sa kabutihang palad, o sa kasamaang palad, wala kaming sapat na oras para dito.
Bagama't madaling magpadala ang Telegraf ng sarili nitong mga sukatan o mangolekta ng mga sukatan mula sa database ng InfluxDB para sa pagpapadala sa parehong Influx o sa ibang lugar.
Natuklasan
Anong mga konklusyon ang nakuha natin mula sa mga resulta ng piloto?
Paano mo magagawa ang pagsubaybay?
Una sa lahat, ganap na natugunan ng TICK stack ang aming mga inaasahan at nagbigay sa amin ng mas maraming pagkakataon kaysa sa una naming inaasahan.
Ang lahat ng pag-andar na kailangan namin ay naroroon. Lahat ng ginawa namin dito ay gumana nang walang problema.
Pagiging Produktibo
Ang pangunahing problema sa stack ng TICK sa libreng bersyon ay ang kakulangan ng mga kakayahan sa pag-scale. Hindi ito naging problema sa amin.
Hindi kami nangongolekta ng eksaktong data/mga numero ng pag-load, ngunit nangongolekta kami ng data mula sa humigit-kumulang 30 scooter sa isang pagkakataon.
Ang bawat isa sa kanila ay nakolekta ng higit sa tatlong dosenang sukatan. Kasabay nito, ang mga log mula sa mga device ay nakolekta. Naganap ang pangongolekta at pagpapadala ng data bawat 10 segundo.
Mahalagang tandaan na pagkatapos ng isang linggo at kalahati ng pilot, kapag ang karamihan sa "mga problema sa pagkabata" ay naitama at ang pinakamahahalagang problema ay nalutas na, kailangan naming bawasan ang dalas ng pagpapadala ng data sa server sa 30 segundo. Naging kailangan ito dahil nagsimulang mabilis na mawala ang trapiko sa aming mga LTE SIM card.
Ang karamihan ng trapiko ay naubos ng mga log; ang mga sukatan mismo, kahit na may 10 segundong pagitan, ay halos hindi ito sinayang.
Bilang isang resulta, pagkatapos ng ilang oras ay ganap naming hindi pinagana ang koleksyon ng mga log sa mga device, dahil ang mga partikular na problema ay halata na kahit na walang patuloy na koleksyon.
Sa ilang mga kaso, kung kailangan pa ring tingnan ang mga log, kumonekta lang kami sa pamamagitan ng WireGuard sa pamamagitan ng VPN.
Idaragdag ko rin na ang bawat hiwalay na kapaligiran ay pinaghiwalay sa isa't isa, at ang pag-load na inilarawan sa itaas ay may kaugnayan lamang para sa kapaligiran ng produksyon.
Sa development environment, nagtaas kami ng hiwalay na InfluxDB instance na patuloy na nangongolekta ng data tuwing 10 segundo at hindi kami naranasan ng anumang mga problema sa performance.
TICK - perpekto para sa maliliit hanggang katamtamang mga proyekto
На основе этой информации я бы сделал вывод, что TICK стек идеально подходит для относительно небольших проектов или проектов, у которых точно не ожидается какого-либо HighLoad.
Если у вас нет тысяч подов или сотен машин — даже один инстанс InfluxDB прекрасно справится с нагрузкой.
Sa ilang mga kaso, maaari kang masiyahan sa Influx Relay bilang isang primitive High Availability na solusyon.
At, siyempre, walang pumipigil sa iyo sa pag-set up ng "vertical" scaling at simpleng paglalaan ng iba't ibang mga server para sa iba't ibang uri ng mga sukatan.
Kung hindi ka sigurado tungkol sa inaasahang pagkarga sa mga serbisyo sa pagsubaybay, o ikaw ay garantisadong magkakaroon/magkakaroon ng napaka "mabigat" na arkitektura, hindi ko irerekomenda ang paggamit ng libreng bersyon ng TICK stack.
Siyempre, ang isang simpleng solusyon ay ang pagbili — но тут я не могу как-то прокомментировать, так как сам не знаком с тонкостями. Кроме того, что это очень дорого и точно не подойдет для мелких компаний.
Sa kasong ito, ngayon, irerekomenda ko ang pagtingin sa pagkolekta ng mga sukatan sa pamamagitan ng Victoria Metrics at mga log gamit ang Loki.
Totoo, muli akong magpapareserba na ang Loki/Grafana ay hindi gaanong maginhawa (dahil sa kanilang higit na kakayahang magamit) kaysa sa yari na TICK, ngunit libre sila.
Mahalagang: вся описанная здесь информация актуальна для версии Influx 1.8, в данный момент вот-вот должен выйти в релиз Influx 2.0.
Пока не довелось попробовать его в боевых условиях и сложно делать выводы об улучшениях, точно еще лучше стал интерфейс, упростилась архитектура (без kapacitor и chronograf),
lumitaw ang mga template ("killer feature" - ). Ngunit, sa kasamaang-palad, sa ngayon, ang bersyon 2 ay walang pangunahing bagay kung saan pinili namin ang unang bersyon - walang koleksyon ng log.
Lalabas din ang functionality na ito sa Influx 2.0, ngunit wala kaming mahanap na mga deadline, kahit na mga tinatayang.
Как не нужно делать IoT платформы (теперь)
Sa huli, nang mailunsad ang pilot, kami mismo ang nag-assemble ng sarili naming buong IoT stack, sa kawalan ng alternatibong angkop sa aming mga pamantayan.
Однако, с недавнего времени в Beta версии доступна — sayang wala siya nung nagsimula kaming gumawa ng project.
Конечный результат и та платформа на основе Ansible + TICK + WireGuard, которую мы собрали самостоятельно нас полностью устраивает. Но на сегодняшний день, я бы порекомендовал внимательней посмотреть на Balena прежде чем пытаться собрать свою IoT платформу самим.
Потому что, в конечном итоге она умеет делать большую часть того, что мы делали, при этом OpenBalena бесплатна, а код открыт.
Alam na nito kung paano hindi lamang magpadala ng mga update, kundi pati na rin ang isang VPN ay naka-built in at iniakma para sa paggamit sa isang IoT na kapaligiran.
At kamakailan lang, inilabas pa nila ang kanilang , na madaling kumokonekta sa kanilang ecosystem.
Эй, а что с пропавшим скутером?
Kaya ang scooter, "Ralph", ay nawala nang walang bakas.
Agad kaming tumakbo upang tingnan ang mapa sa aming "admin panel", na may data ng mga sukatan ng GPS mula sa InfluxDB.
Salamat sa data ng pagsubaybay, madali naming natukoy na umalis ang scooter sa parking lot bandang 21:00 noong nakaraang araw, humigit-kumulang kalahating oras papunta sa ilang lugar at naka-park hanggang 5 am sa tabi ng ilang German house.
Pagkalipas ng 5 a.m., walang natanggap na data sa pagsubaybay—ang ibig sabihin nito ay tuluyan nang na-discharge ang karagdagang baterya, o sa wakas ay naisip ng umaatake kung paano alisin ang smart hardware mula sa scooter.
Несмотря на это, по тому адресу, где находился скутер все же была вызвана полиция. Скутера там не оказалось.
Gayunpaman, nagulat din dito ang may-ari ng bahay, dahil nakasakay talaga siya nitong scooter pauwi ng opisina kagabi.
Как выяснилось, один из сотрудников поддержки приехал рано утром и забрал скутер, увидев, что у него полностью разрядилась дополнительная батарея и повез его (пешком) на парковку. А дополнительная батарея вышла из строя из-за попадания влаги.
Ninakaw namin ang scooter sa aming sarili. Siyanga pala, hindi ko alam kung paano at kung sino ang nagresolba sa isyu sa kaso ng pulisya, ngunit gumana nang perpekto ang pagsubaybay...
Pinagmulan: www.habr.com