Mbalikake skuter sing ilang, utawa crita babagan pemantauan IoT

Setaun kepungkur, kita ngluncurake versi pilot proyek promosi kanggo rental skuter listrik desentralisasi.

Kaping pisanan, proyek kasebut diarani Road-To-Barcelona, ​​banjur dadi Road-To-Berlin (mula R2B ing gambar), lan pungkasane diarani xRide.

Ide utama proyek kasebut yaiku: tinimbang duwe layanan rental mobil utawa skuter terpusat (kita ngomong babagan skuter alias motor listrik, dudu skuter / skuter) kita pengin nggawe platform kanggo nyewa desentralisasi. Babagan kangelan sing kita temoni wis nulis sadurunge.

Kaping pisanan, proyek fokus ing mobil, nanging amarga tenggat wektu, komunikasi sing dawa banget karo manufaktur lan akeh watesan safety, skuter listrik dipilih kanggo pilot.

Pangguna nginstal aplikasi iOS utawa Android ing telpon, nyedhaki skuter sing disenengi, sawise telpon lan skuter nggawe sambungan peer-to-peer, ETH diijolke lan pangguna bisa miwiti numpak kanthi nguripake skuter liwat telpon. Ing pungkasan trip, iku uga bisa kanggo mbayar trip nggunakake Ethereum saka dompet pangguna ing telpon.

Saliyane skuter, pangguna ndeleng "pangisi daya cerdas" ing aplikasi kasebut, kanthi ngunjungi pangguna bisa ngganti baterei saiki yen kurang.

Iki umume kaya pilot kita, diluncurake ing September taun kepungkur ing rong kutha Jerman: Bonn lan Berlin.

Banjur, ing sawijining dina, ing Bonn, esuk, tim dhukungan kita (dumunung ing situs kanggo njaga skuter ing urutan kerja) diwenehi tandha: salah sawijining skuter wis ilang tanpa tilak.

Carane nemokake lan bali?

Ing artikel iki aku bakal ngomong babagan iki, nanging pisanan - babagan carane nggawe platform IoT dhewe lan kepiye ngawasi.

Apa lan ngapa kudu ngawasi: skuter, infrastruktur, stasiun pangisian daya?

Dadi, apa sing pengin dipantau ing proyek kita?

Kaping pisanan, iki skuter dhewe - skuter listrik dhewe cukup larang, sampeyan ora bisa miwiti proyek kasebut tanpa disiapake kanthi cukup, yen bisa, sampeyan pengin ngumpulake informasi sabisa babagan skuter: babagan lokasi, tingkat pangisian daya. , lsp.

Kajaba iku, aku pengin ngawasi kahanan infrastruktur IT kita dhewe - database, layanan lan kabeh sing perlu kanggo bisa. Sampeyan uga perlu kanggo ngawasi status "pangisi daya cerdas", yen padha nyuwil utawa entek batre lengkap.

Skuter

Apa skuter kita lan apa sing kita pengin ngerti babagan?

Wangsulan: Bab ingkang pisanan lan paling penting koordinat GPS, amarga thanks kanggo wong-wong mau kita bisa ngerti ngendi lagi lan ing ngendi padha obah.

Sabanjure yaiku pangisian daya baterei, amarga kita bisa nemtokake manawa pangisian daya skuter bakal rampung lan ngirim juicer utawa paling ora ngelingake pangguna.

Mesthi wae, sampeyan uga kudu mriksa apa sing kedadeyan karo komponen Hardware:

• apa bluetooth bisa?
• modul GPS dhewe bisa?
  • Kita uga duwe masalah karo kasunyatan manawa GPS bisa ngirim koordinat sing salah lan macet, lan iki mung bisa ditemtokake kanthi mriksa tambahan ing skuter,
    lan ngabari dhukungan sanalika bisa kanggo ngatasi masalah kasebut

Lan pungkasan: mriksa piranti lunak, diwiwiti karo OS lan prosesor, jaringan lan beban disk, dipungkasi kanthi mriksa modul kita dhewe sing luwih spesifik kanggo kita (Jolocom, gantungan kunci).

hardware

Apa bagean "wesi" kita?

Njupuk menyang akun pigura wektu paling cendhak lan perlu kanggo prototyping cepet, kita milih opsi paling gampang kanggo implementasine lan pilihan saka komponen - Raspberry Pi.
Saliyane ing Rpi dhewe, kita duwe papan khusus (sing dikembangake lan diprentahake saka China kanggo nyepetake proses perakitan solusi final) lan sakumpulan komponen - relay (kanggo nguripake / mateni skuter), maca daya baterei, modem, antena. Kabeh iki dikemas kanthi kompak ing "kotak xRide" khusus.

Sampeyan uga kudu nyatet sing kabeh kothak powered dening bank daya tambahan, kang siji iki powered by baterei utama scooter.

Iki ndadekake iku bisa kanggo nggunakake ngawasi lan nguripake scooter malah sawise mburi trip, amarga baterei utama dipateni langsung sawise nguripake tombol kontak menyang posisi "mati".

Docker? Linux biasa? lan penyebaran

Ayo bali menyang ngawasi, supaya Raspberry - apa sing kita duwe?

Salah sawijining perkara pisanan sing pengin digunakake kanggo nyepetake proses nyebarake, nganyari lan ngirim komponen menyang piranti fisik yaiku Docker.

Sayange, kanthi cepet dadi jelas yen Docker ing RPi, sanajan kerjane, akeh overhead, utamane babagan konsumsi energi.

Bentenipun nggunakake "asli" OS, sanajan ora dadi kuwat, isih cukup kanggo kita ngati-ati saka kamungkinan ilang daya cepet banget.

Alesan liya yaiku salah sawijining perpustakaan partner ing Node.js (sic!) - siji-sijine komponen sistem sing ora ditulis ing Go / C / C ++.

Penulis perpustakaan ora duwe wektu kanggo nyedhiyakake versi sing bisa digunakake ing sembarang basa "native".

Ora mung simpul kasebut ora dadi solusi sing paling elegan kanggo piranti kinerja rendah, nanging perpustakaan kasebut uga keluwen sumber daya.

Kita nyadari yen, sanajan kita pengin, nggunakake Docker bakal dadi overhead kanggo kita. Pilihan digawe kanggo OS asli lan bisa digunakake langsung ing ngisor iki.

OS

Akibaté, kita, maneh, milih opsi paling gampang minangka OS lan digunakake Raspbian (Debian mbangun kanggo Pi).

Kita nulis kabeh piranti lunak ing Go, mula kita uga nulis modul agen hardware utama ing sistem kita ing Go.

Iku sing tanggung jawab kanggo nggarap GPS, Bluetooth, maca daya, nguripake skuter, etc.

nyebarake

Pitakonan langsung muncul babagan kudu ngetrapake mekanisme kanggo ngirim nganyari menyang piranti (OTA) - loro nganyari kanggo agen/aplikasi kita dhewe, lan nganyari OS/firmware dhewe (amarga versi anyar saka agen bisa mbutuhake nganyari kernel. utawa komponen sistem, perpustakaan, lsp).

Sawise analisis pasar sing cukup suwe, ternyata ana akeh solusi kanggo ngirim nganyari menyang piranti kasebut.

Saka relatif prasaja, biasane nganyari / dual-boot oriented keperluan kaya swupd / SWUpdate / OSTree kanggo platform lengkap kaya Mender lan Balena.

Kaping pisanan, kita mutusake yen kita kasengsem ing solusi end-to-end, mula pilihan kasebut langsung mudhun ing platform.

Tandhane Balena ora kalebu amarga kasunyatane nggunakake Docker sing padha ing balenaEngine.

Nanging aku nyathet manawa sanajan iki, kita terus nggunakake produke Whale Etcher kanggo perangkat kukuh lampu kilat ing kertu SD - sarana sing gampang lan trep kanggo iki.

Mulane, ing pungkasan pilihan tiba ing Mender. Mender minangka platform lengkap kanggo ngrakit, ngirim lan nginstal perangkat kukuh.

Sakabèhé platform katon apik, nanging kita njupuk bab minggu lan setengah mung kanggo mbangun versi bener saka perangkat kukuh kita nggunakake tukang mender.
Lan luwih akeh kita nyemplungake awake dhewe ing seluk-beluk panggunaane, luwih jelas yen kanggo nyebarake kanthi lengkap, kita butuh wektu luwih akeh tinimbang sing kita duwe.

Sayange, tenggat wektu sing nyenyet tegese kita kudu nolak panggunaan Mender lan milih sing luwih gampang.

Ansible

Solusi paling gampang ing kahanan kita yaiku nggunakake Ansible. Saperangan playbooks cukup kanggo miwiti.

Intine yaiku kita mung nyambung saka host (server CI) liwat ssh menyang rasberry lan nyebarake nganyari.

Ing wiwitan, kabeh iku prasaja - sampeyan kudu ing jaringan sing padha karo piranti, pour liwat Wi-Fi.

Ing kantor ana mung rolas test raspberries disambungake menyang jaringan sing padha, saben piranti wis alamat IP statis uga kasebut ing Ansible Inventory.

Iku Ansible sing ngirim agen ngawasi kita menyang piranti pungkasan

3G / LTE

Sayange, kasus panggunaan iki kanggo Ansible mung bisa digunakake ing mode pangembangan sadurunge kita duwe skuter nyata.

Amarga skuter, kaya sing sampeyan ngerteni, ora njagong disambungake menyang siji router Wi-Fi, terus ngenteni nganyari liwat jaringan.

Ing kasunyatan, skuter ora bisa duwe sambungan apa wae kajaba 3G / LTE seluler (malah ora kabeh wektu).

Iki langsung nyebabake akeh masalah lan watesan, kayata kacepetan sambungan sing sithik lan komunikasi sing ora stabil.

Nanging sing paling penting yaiku ing jaringan 3G / LTE kita ora bisa mung ngandelake IP statis sing ditugasake ing jaringan kasebut.

Iki sebagian ditanggulangi dening sawetara panyedhiya kertu SIM; malah ana kertu SIM khusus sing dirancang kanggo piranti IoT kanthi alamat IP statis. Nanging kita ora duwe akses menyang kertu SIM kasebut lan ora bisa nggunakake alamat IP.

Mesthi, ana gagasan kanggo nindakake sawetara jinis registrasi alamat IP alias panemuan layanan nang endi wae kaya Konsul, nanging kita kudu ninggalake gagasan kasebut, amarga ing tes kita alamat IP bisa kerep diganti, sing nyebabake ketidakstabilan gedhe.

Mulane, panggunaan sing paling trep kanggo ngirim metrik ora bakal nggunakake model tarik, ing ngendi kita bakal pindhah menyang piranti kanggo metrik sing dibutuhake, nanging push, ngirim metrik saka piranti langsung menyang server.

VPN

Minangka solusi kanggo masalah iki, kita milih VPN - khusus penjaga kawat.

Klien (skuter) ing wiwitan sistem disambungake menyang server VPN lan bisa nyambung menyang. Trowongan iki digunakake kanggo ngirim nganyari.

Ing teori, trowongan sing padha bisa digunakake kanggo ngawasi, nanging sambungan kasebut luwih rumit lan kurang dipercaya tinimbang push prasaja.

Sumber daya awan

Pungkasan, perlu kanggo ngawasi layanan maya lan database, amarga kita nggunakake Kubernetes kanggo wong-wong mau, saenipun supaya deploying ngawasi ing kluster minangka prasaja sabisa. Saenipun, nggunakake Helm, amarga kanggo penyebaran, kita nggunakake ing paling kasus. Lan, mesthi, kanggo ngawasi maya sampeyan kudu nggunakake solusi sing padha kanggo skuter dhewe.

diwenehi

Phew, kita katon wis ngurutake katrangan, ayo nggawe dhaptar apa sing dibutuhake ing pungkasan:

• Solusi sing cepet, amarga ngawasi perlu sajrone proses pangembangan
• Volume / jumlah - akeh metrik sing dibutuhake
• Koleksi log dibutuhake
• Reliabilitas - data penting kanggo miwiti sukses
• Sampeyan ora bisa nggunakake model narik - sampeyan kudu push
• Kita butuh pemantauan terpadu ora mung hardware, nanging uga awan

Gambar pungkasan katon kaya iki

Pilihan tumpukan

Dadi, kita ngadhepi pitakonan babagan milih tumpukan pemantauan.

Kaping pisanan, kita nggolek solusi kabeh-ing-siji sing paling lengkap sing bakal nyukupi kabeh syarat, nanging uga cukup fleksibel kanggo nyesuekake panggunaan kanggo kabutuhan. Isih, kita duwe akeh watesan sing ditindakake dening hardware, arsitektur lan tenggat wektu.

Ana macem-macem solusi ngawasi, diwiwiti kanthi sistem lengkap kaya Nagios, icinga utawa zabbix lan pungkasan karo solusi siap kanggo manajemen Armada.

Kaping pisanan, sing terakhir katon minangka solusi sing cocog kanggo kita, nanging sawetara ora duwe pemantauan lengkap, liyane duwe kemampuan winates banget kanggo versi gratis, lan liya-liyane mung ora nutupi "kepengin" utawa ora cukup fleksibel kanggo cocog karo skenario kita. Sawetara iku mung outdated.

Sawise nganalisa sawetara solusi sing padha, kita kanthi cepet nyimpulake manawa bakal luwih gampang lan luwih cepet kanggo ngumpulake tumpukan sing padha. Ya, bakal dadi luwih rumit tinimbang nggunakake platform manajemen Armada sing wis rampung, nanging kita ora kudu kompromi.

Meh mesthi, ing kabeh turah mbrawah saka solusi, wis ana siji siap sing bakal cocog karo kita, nanging ing kasus kita, iku luwih cepet kanggo ngumpulake tumpukan tartamtu dhewe lan ngatur "kanggo awake dhewe" tinimbang testing produk siap-digawe.

Kanthi kabeh iki, kita ora ngupayakake ngumpulake kabeh platform pemantauan dhewe, nanging nggoleki tumpukan "siap" sing paling fungsional, mung kanthi kemampuan kanggo ngatur kanthi fleksibel.

(B) ELK?

Solusi pisanan sing dianggep bener yaiku tumpukan ELK sing kondhang.
Ing kasunyatan, iku kudu disebut BELK, amarga iku kabeh diwiwiti karo Beats - https://www.elastic.co/what-is/elk-stack

Mesthine, ELK minangka salah sawijining solusi sing paling misuwur lan kuat ing bidang pemantauan, lan luwih akeh ing ngumpulake lan ngolah log.

Kita dimaksudake yen ELK bakal digunakake kanggo ngumpulake log lan uga panyimpenan jangka panjang metrik sing dipikolehi saka Prometheus.

Kanggo visualisasi sampeyan bisa nggunakake Grafan.

Nyatane, tumpukan ELK anyar bisa ngumpulake metrik kanthi mandiri (metricbeat), lan Kibana uga bisa nampilake.

Nanging isih, ELK wiwitane tuwuh saka log lan nganti saiki fungsi metrik kasebut duwe sawetara kekurangan sing serius:

• Ngartekno luwih alon tinimbang Prometheus
• Integrasi menyang panggonan sing luwih sithik tinimbang Prometheus
• Iku angel nyiyapake tandha kanggo wong-wong mau
• Metrik njupuk akeh papan
• Nyiyapake dashboard kanthi metrik ing Kiban luwih rumit tinimbang ing Grafan

Umumé, metrik ing ELK abot lan durung trep kaya ing solusi liyane, sing saiki ana luwih saka mung Prometheus: TSDB, Victoria Metrics, Cortex, etc., etc. Mesthi, aku pancene pengin duwe solusi kabeh-ing-siji langsung, nanging ing kasus metricbeat ana akeh banget kompromi.

Lan tumpukan ELK dhewe duwe sawetara wektu sing angel:

• Iku abot, kadhangkala malah abot banget yen sampeyan ngumpulake jumlah cukup akeh data
• Sampeyan kudu "ngerti masak" - sampeyan kudu ngukur, nanging iki ora pati penting
• Versi gratis sing diudani - versi gratis ora duwe tandha normal, lan nalika milih ora ana otentikasi

Aku kudu ngomong sing bubar titik pungkasan wis dadi luwih apik lan saliyane output ing open-source X-pack (kalebu otentikasi) model pricing dhewe wiwit ngganti.

Nanging nalika kita arep nyebarake solusi iki, ora ana tandha-tandha.
Mbok menawa kita bisa nyoba mbangun soko nggunakake ElastAlert utawa solusi komunitas liyane, nanging kita isih mutusake kanggo nimbang alternatif liyane.

Loki - Grafana - Prometheus

Saiki, solusi sing apik bisa uga yaiku mbangun tumpukan pemantauan adhedhasar Prometheus minangka panyedhiya metrik, Loki kanggo log, lan kanggo visualisasi sampeyan bisa nggunakake Grafana sing padha.

Sayange, nalika wiwitan pilot penjualan proyek kasebut (September-Oktober 19), Loki isih ana ing versi beta 0.3-0.4, lan nalika wiwitan pangembangan ora bisa dianggep minangka solusi produtcion. sakabehe.

Aku durung duwe pengalaman ing bener nggunakake Loki ing proyèk serius, nanging aku bisa ngomong sing Promtail (agen kanggo ngumpulake log) dianggo apik kanggo loro Bare-logam lan pods ing kubernetes.

TIKO

Mbok menawa alternatif sing paling pantes (mung?) Lengkap kanggo tumpukan ELK saiki mung bisa diarani tumpukan TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.

Aku bakal njlèntrèhaké kabeh komponen ing ngisor iki kanthi luwih rinci, nanging gagasan umum iki:

• Telegraf - agen kanggo ngempalaken metrik
• InfluxDB - database metrik
• Kapacitor - prosesor metrik wektu nyata kanggo menehi tandha
• Chronograf - panel web kanggo visualisasi

Kanggo InfluxDB, Kapacitor lan Chronograf ana grafik helm resmi sing digunakake kanggo nyebarake.

Perlu dicathet yen ing versi paling anyar saka Influx 2.0 (beta), Kapacitor lan Chronograf dadi bagean saka InfluxDB lan ora ana maneh kanthi kapisah.

telegraf

telegraf iku agen banget entheng kanggo ngumpulake metrik ing mesin negara.

Dheweke bisa ngawasi jumlah ageng kabeh, saka nginx kanggo
server Minecraft.

Wis sawetara kaluwihan keren:

• Cepet lan entheng (ditulis ing Go)
  • Mangan jumlah minimal sumber daya
• Metrik push kanthi gawan
• Nglumpukake kabeh metrik sing dibutuhake
  • Metrik sistem tanpa setelan
  • Metrik hardware kayata informasi saka sensor
  • Gampang banget kanggo nambah metrik sampeyan dhewe
• Akeh plugin metu saka kothak
• Nglumpukake log

Wiwit metrik push perlu kanggo kita, kabeh kaluwihan liyane luwih saka tambahan sing nyenengake.

Koleksi log dening agen dhewe uga trep banget, amarga ora perlu nyambungake keperluan tambahan kanggo log log.

Influx nawakake pengalaman sing paling trep kanggo nggarap log yen sampeyan nggunakake syslog.

Telegraf umume minangka agen sing apik kanggo ngumpulake metrik, sanajan sampeyan ora nggunakake tumpukan ICK liyane.

Akeh wong sing nyabrang karo ELK lan macem-macem database seri wektu liyane kanggo penak, amarga bisa nulis metrik meh ing endi wae.

InfluxDB

InfluxDB minangka inti utama tumpukan TICK, yaiku basis data seri wektu kanggo metrik.
Saliyane metrik, Influx uga bisa nyimpen log, sanajan, ing intine, log kasebut mung metrik sing padha, mung tinimbang indikator numerik sing biasa, fungsi utama ditindakake kanthi baris teks log.

InfluxDB uga ditulis ing Go lan katon luwih cepet dibandhingake karo ELK ing kluster (dudu sing paling kuat).

Salah sawijining kaluwihan saka Influx uga kalebu API sing trep lan sugih kanggo pitakon data, sing digunakake kanthi aktif.

Kekurangan - $$$ utawa scaling?

Tumpukan TICK mung duwe siji kekurangan sing ditemokake - yaiku dear. Malah luwih.

Apa versi mbayar sing versi gratis ora?

Sa adoh kita bisa ngerti, mung prabédan antarane versi mbayar saka tumpukan TICK lan free siji kemampuan scaling.

Yaiku, sampeyan bisa mundhakaken kluster karo kasedhiyan High mung ing versi perusahaan.

Yen sampeyan pengin HA full-fledged, sampeyan salah siji kudu mbayar utawa nggunakake sawetara crutches. Ana sawetara solusi komunitas - contone influxdb-ha katon kaya solusi wewenang, nanging ditulis sing ora cocok kanggo produksi, uga
influx-spout - solusi sing prasaja kanthi ngompa data liwat NATS (uga kudu skala, nanging iki bisa ditanggulangi).

Sayange, nanging loro-lorone katon ditinggalake - ora ana komitmen anyar, aku nganggep manawa masalah kasebut yaiku rilis versi anyar Influx 2.0, sing akeh perkara sing beda (ora ana informasi babagan scaling ing durung).

Resmi ana versi gratis Relay - nyatane, iki HA primitif, nanging mung liwat imbangan,
amarga kabeh data bakal ditulis kanggo kabeh InfluxDB kedadean konco load balancer.
Dheweke duwe sawetara cacat kaya masalah potensial karo TCTerms overwriting lan perlu kanggo nggawe dhasar kanggo metrik ing advance
(sing kedadeyan kanthi otomatis sajrone kerja normal karo InfluxDB).

Kejabi sharding ora didhukung, iki tegese overhead tambahan kanggo metrik duplikat (loro pangolahan lan panyimpenan) sing sampeyan ora perlu, nanging ora ana cara kanggo misahake.

Victoria Metrik?

Akibaté, senadyan kasunyatan sing kita padha rampung wareg karo tumpukan TICK ing kabeh liyane saka njongko mbayar, kita mutusaké kanggo ndeleng apa ana free solusi sing bisa ngganti database InfluxDB, nalika ninggalake komponen T_CK isih.

Ana akeh database seri wektu, nanging sing paling njanjeni yaiku Victoria Metrics, duwe sawetara kaluwihan:

• Cepet lan gampang, paling ora miturut asil pathokan
• Ana versi kluster, sing saiki ana ulasan sing apik
  • Dheweke bisa shard
• Ndhukung protokol InfluxDB

Kita ora arep mbangun tumpukan khusus adhedhasar Victoria lan pangarep-arep utama yaiku supaya bisa digunakake minangka panggantos drop-in kanggo InfluxDB.

Sayange, iki ora bisa ditindakake, sanajan protokol InfluxDB didhukung, mung bisa digunakake kanggo ngrekam metrik - mung Prometheus API sing kasedhiya "njaba", tegese ora bisa nyetel Chronograf.

Kajaba iku, mung nilai numerik sing didhukung kanggo metrik (kita nggunakake nilai senar kanggo metrik khusus - luwih akeh babagan ing bagean kasebut. panel admin).

Temenan, kanthi alesan sing padha, VM ora bisa nyimpen log kaya Influx.

Uga, kudu dicathet yen nalika nggoleki solusi sing optimal, Victoria Metrics durung populer, dokumentasi luwih cilik lan fungsine luwih lemah.
(Aku ora ngelingi katrangan rinci babagan versi kluster lan sharding).

Pilihan dhasar

Akibaté, diputusake yen kanggo pilot kita isih bakal mbatesi awake dhewe menyang simpul InfluxDB tunggal.

Ana sawetara alasan utama kanggo pilihan iki:

• Kita pancene disenengi kabeh fungsi tumpukan TICK
• Kita wis bisa nyebarake lan kerjane apik
• Tenggat wektu wis entek lan ora akeh wektu kanggo nyoba opsi liyane.
• Kita ora nyana beban sing abot

Kita ora duwe akeh skuter kanggo tahap pertama pilot, lan tes sajrone pembangunan ora nuduhake masalah kinerja.

Mulane, kita mutusake yen kanggo proyek iki siji simpul Influx cukup kanggo kita tanpa perlu skala (ndeleng kesimpulan ing pungkasan).

Kita wis mutusake tumpukan lan dhasar - saiki babagan komponen tumpukan TICK sing isih ana.

Kapasitor

Kapacitor minangka bagéan saka tumpukan TICK, layanan sing bisa ngawasi metrik sing mlebu ing database kanthi wektu nyata lan nindakake macem-macem tumindak adhedhasar aturan.

Umumé, dipanggonke minangka alat kanggo nelusuri anomali potensial lan sinau mesin (Aku ora yakin manawa fungsi kasebut dikarepake), nanging kasus sing paling populer babagan panggunaan luwih umum - menehi tandha.

Mangkene carane kita digunakake kanggo kabar. We nyiyapake tandha Slack nalika scooter tartamtu dadi offline, lan padha rampung kanggo pangisi daya pinter lan komponen infrastruktur penting.

Iki nggawe bisa cepet nanggapi masalah, uga nampa kabar yen kabeh wis normal maneh.

Conto prasaja: baterei tambahan kanggo daya "kothak" kita wis rusak utawa sakperangan alesan wis entek daya; mung kanthi nginstal anyar, sawise sawetara wektu, kita kudu nampa kabar sing fungsi skuter wis dibalèkaké.

Ing Influx 2.0 Kapacitor dadi bagéan saka DB

Kronografis

Aku wis ndeleng macem-macem solusi UI kanggo ngawasi, nanging aku bisa ngomong yen ing babagan fungsi lan UX, ora ana sing bisa dibandhingake karo Chronograf.

Kita miwiti nggunakake tumpukan TICK, cukup aneh, karo Grafan minangka antarmuka web.
Aku ora bakal njlèntrèhaké fungsi sawijining; kabeh wong ngerti kemungkinan gedhe kanggo nyetel apa wae.

Nanging, Grafana isih dadi instrumen universal, dene Chronograf utamane dirancang kanggo nggunakake Influx.

Lan mesthi, amarga iki, Chronograf bisa entuk fungsi sing luwih cerdas utawa trep.

Mbok menawa penak utama nggarap Chronograf yaiku sampeyan bisa ndeleng bagian njero InfluxDB liwat Jelajahi.

Koyone Grafana nduweni fungsi sing meh padha, nanging nyatane, nyetel dashboard ing Chronograf bisa ditindakake kanthi sawetara klik mouse (ing wektu sing padha ndeleng visualisasi ing kana), dene ing Grafana sampeyan isih bakal duwe. kanggo ngowahi konfigurasi JSON (mesthi Chronograf ngidini ngunggah dashas sing dikonfigurasi tangan lan ngowahi minangka JSON yen perlu - nanging aku ora kudu nutul sawise nggawe ing UI).

Kibana nduweni kemampuan sing luwih sugih kanggo nggawe dashboard lan kontrol, nanging UX kanggo operasi kasebut rumit banget.

Perlu sawetara pangerten sing apik kanggo nggawe dashboard sing trep. Lan sanajan fungsi dashboard Chronograf kurang, nggawe lan ngatur luwih gampang.

Dashboard dhewe, kajaba saka gaya visual sing nyenengake, sejatine ora beda karo dasbor ing Grafana utawa Kibana:

Iki minangka jendela pitakon:

Iku penting kanggo Wigati, antarane liyane, sing ngerti jinis lapangan ing database InfluxDB, chronograph dhewe kadhangkala bisa kanthi otomatis mbantu karo nulis Query utawa milih fungsi agregasi bener kaya tegese.

Lan mesthi, Chronograf minangka trep kanggo ndeleng log. Katon kaya iki:

Kanthi gawan, log Influx dicocogake kanggo nggunakake syslog lan mulane duwe parameter penting - keruwetan.

Grafik ing sisih ndhuwur utamane migunani; sampeyan bisa ndeleng kesalahan sing kedadeyan lan warna kasebut langsung nuduhake yen tingkat keruwetan luwih dhuwur.

Kaping pirang-pirang kita nyekel kewan omo penting kanthi cara iki, arep ndeleng log minggu kepungkur lan ndeleng lonjakan abang.

Mesthine, saenipun, nyiyapake tandha kanggo kesalahan kasebut, amarga kita wis duwe kabeh babagan iki.

Kita malah ngaktifake iki sawetara wektu, nanging ing proses nyiapake pilot, ternyata akeh kesalahan (kalebu sistem kaya ora kasedhiya jaringan LTE), sing uga "spam" saluran Slack. akeh, tanpa nyebabake masalah, entuk manfaat gedhe.

Solusi sing bener yaiku kanggo nangani sebagian besar kesalahan kasebut, nyetel tingkat keruwetan, lan mung ngaktifake tandha.

Kanthi cara iki, mung kesalahan anyar utawa penting sing bakal dikirim menyang Slack. Ora ana wektu sing cukup kanggo persiyapan kasebut amarga tenggat wektu sing ketat.

Otentikasi

Sampeyan uga kudu disebutake manawa Chronograf ndhukung OAuth lan OIDC minangka otentikasi.

Iki trep banget, amarga ngidini sampeyan gampang masang menyang server lan nggawe SSO lengkap.

Ing kasus kita, server ana gantungan kunci - iki digunakake kanggo nyambung menyang ngawasi, nanging server padha uga digunakake kanggo keasliane skuter lan panjalukan kanggo mburi-mburi.

"Admin"

Komponen pungkasan sing bakal dakgambarake yaiku "panel admin" sing ditulis dhewe ing Vue.
Sejatine, iku mung layanan mandiri sing nampilake informasi skuter saka database, layanan mikro, lan data metrik saka InfluxDB kanthi bebarengan.

Kajaba iku, akeh fungsi administratif sing dipindhah ing kana, kayata urip maneh darurat utawa mbukak kunci kanggo tim dhukungan saka adoh.

Ana uga peta. Aku wis kasebut yen kita miwiti karo Grafana tinimbang Chronograf - amarga kanggo Grafana peta kasedhiya ing wangun plugins, kang kita bisa ndeleng koordinat skuter. Sayange, kemampuan widget peta kanggo Grafana winates banget, lan minangka asil, luwih gampang kanggo nulis aplikasi web dhewe nganggo peta ing sawetara dina, supaya ora mung ndeleng koordinat saiki, nanging uga nampilake rute dijupuk dening scooter, bisa nyaring data ing peta, etc.. (kabeh fungsi sing kita ora bisa ngatur ing dashboard prasaja).

Salah sawijining kaluwihan Influx sing wis kasebut yaiku kemampuan nggawe metrik sampeyan kanthi gampang.
Iki ngidini bisa digunakake kanggo macem-macem skenario.

Kita nyoba ngrekam kabeh informasi sing migunani ing kana: pangisi daya baterei, status kunci, kinerja sensor, bluetooth, GPS, lan akeh pemeriksaan kesehatan liyane.
Kita nampilake kabeh iki ing panel admin.

Mesthi, kritéria sing paling penting kanggo kita yaiku kondisi operasi skuter - nyatane, Influx mriksa iki dhewe lan nuduhake "lampu ijo" ing bagean Node.

Iki ditindakake kanthi fungsi wong mati - kita digunakake kanggo ngerti kinerja kothak kita lan ngirim tandha sing padha kanggo Slack.

Miturut cara, kita dijenengi skuter miturut jeneng karakter saka The Simpsons - dadi trep kanggo mbedakake saka saben liyane.

Lan umume luwih nyenengake kanthi cara iki. Frasa kaya "Guys, Smithers wis mati!" terus-terusan keprungu.

Metrik string

Penting yen InfluxDB ngidini sampeyan nyimpen ora mung angka numerik, kayadene ing Victoria Metrics.

Iku bakal katon yen iki ora pati penting - sawise kabeh, loro saka log, sembarang metrik bisa disimpen ing wangun nomer (mung nambah pemetaan kanggo negara dikenal - jenis enum)?

Ing kasus kita, paling ora ana siji skenario ing ngendi metrik senar migunani banget.
Iku mung kedaden sing supplier saka "pangisi daya pinter" kita iku pihak katelu, kita wis ora kontrol liwat proses pembangunan lan informasi sing pangisi daya iki bisa nyedhiyani.

Akibaté, daya API adoh saka becik, nanging masalah utama iku kita ora bisa tansah ngerti negara.

Iki ngendi Influx teka kanggo ngluwari. Kita mung nulis status string sing teka menyang lapangan database InfluxDB tanpa owah-owahan.

Kanggo sawetara wektu, mung nilai kaya "online" lan "offline", adhedhasar informasi sing ditampilake ing panel admin kita, lan kabar dikirim menyang Slack. Nanging, ing sawetara titik, nilai-nilai kaya "pedhot" uga wiwit katon ing kono.

Dadi metu mengko, status iki dikirim sapisan sawise mundhut saka sambungan, yen pangisi daya ora bisa nggawe sambungan karo server sawise nomer tartamtu saka usaha.

Dadi, yen kita mung nggunakake sakumpulan nilai sing tetep, kita bisa uga ora bisa ndeleng owah-owahan kasebut ing perangkat kukuh ing wektu sing tepat.

Lan umume, metrik senar nyedhiyakake luwih akeh kemungkinan kanggo digunakake; sampeyan bisa ngrekam meh kabeh informasi kasebut. Sanajan, mesthi, sampeyan uga kudu nggunakake alat iki kanthi ati-ati.

Saliyane metrik biasa, kita uga ngrekam informasi lokasi GPS ing InfluxDB. Iki pancen migunani kanggo ngawasi lokasi skuter ing panel admin kita.
Nyatane, kita mesthi ngerti ngendi lan skuter sing saiki dibutuhake.

Iki migunani banget kanggo kita nalika kita nggoleki skuter (ndeleng kesimpulan ing pungkasan).

Pemantauan infrastruktur

Saliyane skuter dhewe, kita uga kudu ngawasi kabeh infrastruktur (rada ekstensif).

Arsitektur umum banget katon kaya iki:

Yen kita nyorot tumpukan pemantauan murni, katon kaya iki:

Sing pengin dipriksa ing awan yaiku:

• Databases
• gantungan kunci
• Layanan mikro

Amarga kabeh layanan awan kita ana ing Kubernetes, luwih becik ngumpulake informasi babagan negara kasebut.

Begjanipun, Telegraf metu saka kothak bisa ngumpulake nomer ageng metrik babagan negara klompok Kubernetes, lan Chronograf langsung nawakake dashboards ayu kanggo iki.

Kita utamane ngawasi kinerja pods lan konsumsi memori. Ing cilik saka tiba, tandha ing Slack.

Ana rong cara kanggo nglacak pods ing Kubernetes: DaemonSet lan Sidecar.
Kaloro cara kasebut diterangake kanthi rinci ing kirim blog iki.

Kita nggunakake Telegraf Sidecar lan, saliyane metrik, nglumpukake log pod.

Ing kasus kita, kita kudu tinker karo log. Sanajan kasunyatane Telegraf bisa narik log saka Docker API, kita pengin duwe koleksi log sing seragam karo piranti pungkasan lan ngatur syslog kanggo wadhah kasebut. Mungkin solusi iki ora apik, nanging ora ana keluhan babagan karyane lan log ditampilake kanthi apik ing Chronograf.

Monitoring???

Pungkasane, pitakonan lawas babagan sistem pemantauan ngawasi muncul, nanging untunge, utawa sayangé, kita ora duwe cukup wektu kanggo iki.

Sanajan Telegraf bisa kanthi gampang ngirim metrik dhewe utawa ngumpulake metrik saka database InfluxDB kanggo ngirim menyang Influx sing padha utawa ing papan liya.

temonan

Apa kesimpulan sing dijupuk saka asil pilot?

Kepiye carane sampeyan bisa ngawasi?

Kaping pisanan, tumpukan TICK wis nyukupi pangarepan lan menehi kesempatan luwih akeh tinimbang sing dikarepake.

Kabeh fungsi sing dibutuhake wis ana. Kabeh sing ditindakake kanthi makarya tanpa masalah.

Produktivitas

Masalah utama tumpukan TICK ing versi gratis yaiku kekurangan kemampuan skala. Iki ora dadi masalah kanggo kita.

Kita ora ngumpulake data beban pas / tokoh, nanging kita diklumpukake data saka bab 30 skuter ing wektu.

Saben wong nglumpukake luwih saka telung rolas metrik. Ing wektu sing padha, log saka piranti diklumpukake. Pangumpulan lan ngirim data dumadi saben 10 detik.

Wigati dicathet yen sawise seminggu lan setengah pilot, nalika akeh "masalah kanak-kanak" didandani lan masalah sing paling penting wis dirampungake, kita kudu nyuda frekuensi ngirim data menyang server. 30 detik. Iki dadi perlu amarga lalu lintas ing kertu SIM LTE wiwit ilang kanthi cepet.

Umume lalu lintas dikonsumsi dening log; metrik kasebut dhewe, sanajan kanthi interval 10 detik, praktis ora mbuwang.

Akibaté, sawise sawetara wektu, kita rampung mateni koleksi log ing piranti, amarga masalah tartamtu wis ketok sanajan tanpa koleksi pancet.

Ing sawetara kasus, yen ndeleng log isih perlu, kita mung nyambung liwat WireGuard liwat VPN.

Aku uga bakal nambah sing saben lingkungan kapisah iki kapisah saka saben liyane, lan mbukak sing diterangake ing ndhuwur mung cocog kanggo lingkungan produksi.

Ing lingkungan pangembangan, kita ngunggahake conto InfluxDB sing kapisah sing terus ngumpulake data saben 10 detik lan kita ora ngalami masalah kinerja.

TICK - becik kanggo proyek cilik nganti medium

Adhedhasar informasi iki, aku bakal nganakke sing tumpukan TICK becik kanggo proyèk relatif cilik utawa proyèk sing mesthi ora nyana HighLoad sembarang.

Yen sampeyan ora duwe ewu pods utawa atusan mesin, malah siji conto InfluxDB bakal nangani beban kanthi apik.

Ing sawetara kasus, sampeyan bisa uga wareg karo Influx Relay minangka solusi High Availability primitif.

Lan, mesthi, ora ana sing ngalangi sampeyan nyetel skala "vertikal" lan mung nyedhiyakake server sing beda kanggo macem-macem jinis metrik.

Yen sampeyan ora yakin bab mbukak samesthine ing layanan ngawasi, utawa sampeyan dijamin duwe / bakal arsitektur banget "abot", Aku ora nyaranake nggunakake free versi tumpukan OTIK.

Mesthi, solusi sing gampang yaiku tuku Perusahaan InfluxDB - nanging ing kene aku ora bisa menehi komentar, amarga aku ora ngerti subtleties kasebut. Kajaba iku larang banget lan mesthi ora cocog kanggo perusahaan cilik.

Ing kasus iki, dina iki, aku bakal nyaranake nggoleki metrik liwat Victoria Metrics lan log nggunakake Loki.

Bener, aku bakal nggawe reservasi maneh sing Loki / Grafana luwih trep (amarga versatility sing luwih gedhe) tinimbang TICK sing wis siap, nanging gratis.

penting: kabeh informasi sing diterangake ing kene cocog kanggo versi Influx 1.8, ing wayahe Influx 2.0 bakal dirilis.

Nalika aku ora duwe kesempatan kanggo nyoba ing kahanan pertempuran lan angel kanggo nggawe kesimpulan babagan dandan, antarmuka wis mesthi dadi luwih apik, arsitektur wis simplified (tanpa kapacitor lan chronograf).
template muncul ("fitur pembunuh" - sampeyan bisa nglacak pemain ing Fortnite lan nampa kabar nalika pemain favorit menang game). Nanging, sayangé, ing wayahe, versi 2 ora duwe bab tombol sing kita milih versi pisanan - ora ana koleksi log.

Fungsi iki uga bakal katon ing Influx 2.0, nanging ora bisa nemokake tenggat wektu, malah kira-kira.

Kepiye carane ora nggawe platform IoT (saiki)

Pungkasane, sawise ngluncurake pilot, kita dhewe nglumpukake tumpukan IoT sing lengkap, tanpa ana alternatif sing cocog karo standar kita.

Nanging, bubar kasedhiya ing versi Beta OpenBalena - Sayange dheweke ora ana nalika kita miwiti nggawe proyek kasebut.

Kita wareg karo asil pungkasan lan platform adhedhasar Ansible + TICK + WireGuard sing kita kumpul dhewe. Nanging dina iki, aku bakal menehi saran supaya mriksa Balena sadurunge nyoba nggawe platform IoT sampeyan dhewe.

Amarga pungkasane bisa nindakake kabeh sing ditindakake, lan OpenBalena gratis lan mbukak sumber.

Iku wis ngerti carane ora mung ngirim nganyari, nanging uga VPN wis dibangun lan dirancang kanggo nggunakake ing lingkungan IoT.

Lan bubar, dheweke malah ngeculake hardware, sing gampang nyambung menyang ekosistem.

Lho, piye skuter sing ilang?

Dadi skuter, "Ralph", ilang tanpa tilak.

Kita langsung mlayu kanggo ndeleng peta ing "panel admin", kanthi data metrik GPS saka InfluxDB.

Thanks kanggo data ngawasi, kita gampang nemtokake manawa skuter ninggalake parkir watara jam 21:00 dina pungkasan, nyopir watara setengah jam menyang sawetara wilayah lan diparkir nganti jam 5 ing jejere sawetara omah Jerman.

Sawise jam 5, ora ana data ngawasi sing ditampa-iki tegese baterei tambahan wis kosong, utawa panyerang pungkasane ngerti carane mbusak hardware cerdas saka skuter.
Senadyan mangkono, polisi isih ditimbali menyang alamat ing ngendi skuter kasebut. Skuter ora ana.

Nanging, sing duwe omah uga kaget, amarga dheweke pancen numpak skuter iki mulih saka kantor.

Dadi metu, salah siji saka karyawan support teka ing wayah esuk lan njupuk scooter, weruh sing baterei tambahan wis rampung kosong lan njupuk (mlaku) menyang parking. Lan baterei tambahan gagal amarga kelembapan.

Kita nyolong skuter saka awake dhewe. Ngomong-ngomong, aku ora ngerti kepiye lan sapa sing ngrampungake masalah kasebut karo kasus polisi, nanging pemantauan kasebut bisa ditindakake kanthi becik ...

Source: www.habr.com