Balikkeun skuter anu leungit, atanapi carita ngeunaan ngawaskeun IoT

Sataun ka tukang kami dibuka versi pilot proyek promosi pikeun rental desentralisasi of scooters listrik.

Mimitina, proyék éta disebut Road-To-Barcelona, ​​teras janten Road-To-Berlin (ku kituna R2B dina Potret layar), sareng tungtungna disebut xRide.

Gagasan utama proyék nyaéta kieu: tinimbang gaduh mobil terpusat atanapi jasa nyéwa skuter (urang ngobrol ngeunaan skuter alias motor listrik, sanés kickscooters / scooter) urang hoyong ngadamel platform pikeun nyéwa desentralisasi. Ngeunaan kasusah anu kami hadapi geus nulis baheula.

Mimitina, proyék fokus kana mobil, tapi kusabab wates waktu, komunikasi anu panjang pisan sareng produsén sareng sajumlah ageung larangan kaamanan, skuter listrik dipilih pikeun pilot.

Pamaké masang aplikasi ios atanapi Android dina telepon, ngadeukeutan skuter anu anjeunna resep, saatos telepon sareng skuter ngadegkeun sambungan peer-to-peer, ETH disilihtukeurkeun sareng pangguna tiasa ngamimitian numpak ku cara ngaktipkeun skuter via telepon. Dina ahir perjalanan, éta ogé tiasa mayar perjalanan nganggo Ethereum tina dompét pangguna dina telepon.

Salian skuter, pangguna ningali "pangecas pinter" dina aplikasi, ku ngadatangan dimana pangguna tiasa ngarobih batré ayeuna upami éta lemah.

Ieu umumna sapertos pilot urang, diluncurkeun dina bulan Séptémber taun ka tukang di dua kota Jerman: Bonn sareng Berlin.

Lajeng, hiji poé, di Bonn, mimiti isuk-isuk, tim rojongan kami (lokasina di situs pikeun ngajaga scooters dina urutan kerja) waspada: salah sahiji scooters geus ngiles tanpa renik.

Kumaha mendakanana sareng ngabalikeunana?

Dina tulisan ieu kuring bakal ngobrol ngeunaan ieu, tapi mimitina - ngeunaan kumaha urang ngawangun platform IoT sorangan sareng kumaha urang ngawaskeunana.

Naon jeung naha ngawas: scooters, infrastruktur, stasiun ngecas?

Janten, naon anu urang hoyong monitor dina proyék urang?

Anu mimiti, ieu skuter sorangan - skuter listrik sorangan rada mahal, anjeun moal bisa ngajalankeun proyék misalna tanpa keur cukup disiapkeun, upami mungkin, Anjeun hoyong ngumpulkeun saloba mungkin ngeunaan scooters: ngeunaan lokasi maranéhanana, tingkat muatan. , jsb.

Salaku tambahan, abdi hoyong ngawas kaayaan infrastruktur IT urang sorangan - database, jasa jeung sagalana maranéhna kudu jalan. Éta ogé diperyogikeun pikeun ngawas status "pangecas pinter", upami aranjeunna rusak atanapi béak batré pinuh.

Scooters

Naon skuter urang sareng naon anu urang hoyong terang ngeunaan aranjeunna?

Anu pangheulana sareng anu paling penting nyaéta koordinat GPS, sabab berkat aranjeunna urang tiasa ngartos dimana aranjeunna sareng dimana aranjeunna pindah.

Salajengna nyaéta muatan batré, hatur nuhun nu urang bisa nangtukeun yén ngecas tina scooters datang ka tungtung sarta ngirim juicer atawa sahenteuna ngingetkeun pamaké.

Tangtosna, éta ogé kedah mariksa naon anu lumangsung sareng komponén Hardware kami:

• tiasa bluetooth?
• modul GPS sorangan jalan?
  • Kami ogé ngagaduhan masalah kanyataan yén GPS tiasa ngirim koordinat anu salah sareng macét, sareng ieu ngan ukur tiasa ditangtukeun ku pamariksaan tambahan dina skuter,
    sareng wartosan dukungan pas mungkin pikeun ngabéréskeun masalah éta

Anu pamungkas: cék parangkat lunak, dimimitian ku OS sareng prosésor, jaringan sareng beban disk, ditungtungan ku cék modul urang sorangan anu langkung khusus pikeun urang (Jolocom, keycloak).

hardware

Naon bagian "beusi" urang?

Nyandak kana akun pigura waktos shortest mungkin jeung kabutuhan prototyping gancang, urang milih pilihan panggampangna pikeun palaksanaan sarta Pilihan komponén - buah prambus Pi.
Salian Rpi sorangan, urang boga dewan custom (anu urang sorangan dimekarkeun sarta maréntahkeun ti Cina pikeun nyepetkeun prosés assembly sahiji solusi final) jeung susunan komponén - relay a (pikeun ngahurungkeun / mareuman Scooter nu), pamaca muatan batré, modem, anteneu. Kabéh ieu compactly rangkep dina "kotak xRide" husus.

Ogé kudu dicatet yén sakabéh kotak ieu Powered by hiji bank kakuatan tambahan, anu dina gilirannana ieu Powered by batré utama Scooter nu.

Hal ieu ngamungkinkeun ngagunakeun monitoring jeung ngahurungkeun Scooter malah sanggeus ahir perjalanan, saprak batré utama dipareuman langsung saatos ngahurungkeun konci ignition ka posisi "off".

Docker? Linux Ubuntu biasa? jeung deployment

Hayu urang balik deui ka ngawaskeun, jadi Raspberry - naon urang boga?

Salah sahiji hal anu mimiti urang hoyong dianggo pikeun nyepetkeun prosés nyebarkeun, ngamutahirkeun sareng nganteurkeun komponén kana alat fisik nyaéta Docker.

Hanjakalna, éta gancang janten écés yén Docker on RPi, sanaos tiasa dianggo, gaduh seueur overhead, khususna dina hal konsumsi énergi.

Beda ngagunakeun "asli" OS, sanajan teu jadi kuat, éta masih cukup pikeun urang waspada tina kamungkinan kaleungitan muatan teuing gancang.

Alesan kadua éta salah sahiji perpustakaan pasangan urang on Node.js (sic!) - hijina komponén sistem nu teu ditulis dina Go / C / C ++.

Panulis perpustakaan teu boga waktu pikeun nyadiakeun versi gawé dina salah sahiji "pribumi" basa.

Henteu ngan ukur titik éta sanés mangrupikeun solusi anu paling elegan pikeun alat-alat anu berkinerja rendah, tapi perpustakaan éta nyalira pisan-lapar sumberdaya.

Urang sadar yén, sanajan urang hayang, ngagunakeun Docker bakal jadi teuing overhead pikeun urang. Pilihanna dilakukeun pikeun milih OS asli sareng damel langsung di handapeun éta.

OS

Hasilna, urang, deui, milih pilihan pangbasajanna salaku OS jeung dipaké Raspbian (Debian ngawangun pikeun Pi).

Kami nyerat sadaya parangkat lunak kami di Go, janten kami ogé nyerat modul agén hardware utama dina sistem kami di Go.

Anjeunna jawab gawé bareng GPS, Bluetooth, maca muatan, ngahurungkeun Scooter, jsb.

Nyebarkeun

Patarosan langsung timbul ngeunaan kabutuhan pikeun nerapkeun mékanisme pikeun ngirimkeun apdet kana alat (OTA) - duanana apdet ka agén/aplikasi urang sorangan, sareng apdet kana OS/firmware sorangan (sabab versi anyar agén tiasa meryogikeun apdet kana kernel. atawa komponén sistem, perpustakaan, jsb).

Saatos analisa pasar anu panjang, tétéla aya seueur solusi pikeun nganteurkeun apdet kana alat.

Ti kawilang basajan, lolobana update / dual-boot utilitas berorientasi kawas swupd / SWUpdate / OSTree ka platform full-fledged kawas Mender na Balena.

Anu mimiti, urang mutuskeun yén kami kabetot dina solusi tungtung-to-tungtung, janten pilihan langsung murag dina platform.

Horeng Baléna ieu kaasup alatan kanyataan yén éta sabenerna ngagunakeun Docker sarua di jero balenaEngine na.

Tapi kuring dicatet yén sanajan ieu, urang réngsé nepi terus ngagunakeun produk maranéhanana Balena Etcher pikeun firmware flash dina kartu SD - utiliti basajan tur pisan merenah pikeun ieu.

Ku alatan éta, dina tungtungna pilihan murag kana Mender. Mender mangrupakeun platform lengkep pikeun assembling, delivering tur masang firmware.

Gemblengna platform Sigana hébat, tapi nyandak urang ngeunaan hiji satengah minggu ngan pikeun ngawangun versi bener tina firmware urang ngagunakeun pembina mender.
Sareng langkung seueur urang nyelapkeun diri dina seluk-beluk pamakeanna, langkung jelas yén pikeun nyebarkeunana sacara lengkep urang peryogi langkung seueur waktos tibatan anu urang gaduh.

Alas, deadlines ketat kami dimaksudkan yén kami kapaksa abandon pamakéan Mender tur milih hiji malah basajan.

Ansible

Solusi pangbasajanna dina kaayaan urang nyaéta ngagunakeun Ansible. Sababaraha playbooks cukup pikeun ngamimitian.

Intina maranéhanana éta urang ngan saukur disambungkeun ti host (server CI) via ssh ka rasberries urang jeung disebarkeun apdet pikeun aranjeunna.

Mimitina, sadayana saderhana - anjeun kedah aya dina jaringan anu sami sareng alat-alat, tuang dilakukeun liwat Wi-Fi.

Di kantor aya ngan ukur belasan raspberries tés anu nyambung ka jaringan anu sami, unggal alat ngagaduhan alamat IP statik ogé ditunjuk dina Inventory Ansible.

Éta Ansible anu nganteurkeun agén ngawaskeun kami ka alat tungtung

3G / LTE

Hanjakalna, pamakean ieu pikeun Ansible ngan ukur tiasa dianggo dina modeu pamekaran sateuacan urang gaduh skuter anu saleresna.

Kusabab skuter, sakumaha anjeun ngartos, henteu calik nyambung ka hiji router Wi-Fi, terus ngantosan apdet dina jaringan.

Kanyataanana, skuter teu tiasa gaduh sambungan naon waé lian ti mobile 3G / LTE (malah henteu sadayana waktos).

Ieu langsung nyababkeun seueur masalah sareng watesan, sapertos kacepetan sambungan anu lemah sareng komunikasi anu teu stabil.

Tapi anu paling penting nyaéta dina jaringan 3G / LTE urang henteu tiasa ngan ukur ngandelkeun IP statik anu ditugaskeun ka jaringan.

Ieu sawaréh direngsekeun ku sababaraha panyadia kartu SIM; malah aya kartu SIM husus dirancang pikeun alat IoT kalawan alamat IP statik. Tapi kami henteu ngagaduhan aksés kana kartu SIM sapertos kitu sareng henteu tiasa nganggo alamat IP.

Tangtosna, aya ideu pikeun ngalakukeun sababaraha jinis pendaptaran alamat IP alias penemuan jasa dimana waé sapertos Konsul, tapi urang kedah ngantunkeun ideu sapertos kitu, sabab dina tés kami alamat IP tiasa sering robih, anu nyababkeun instability hébat.

Ku sabab kitu, pamakéan pangmerenahna pikeun delivering metrics moal bakal ngagunakeun model tarikan, dimana urang bakal buka alat pikeun metrics diperlukeun, tapi push, delivering metrics ti alat langsung ka server.

VPN

Salaku solusi pikeun masalah ieu, kami milih VPN - khusus penjaga kawat.

Klién (scooters) dina mimiti sistem disambungkeun ka server VPN tur éta bisa nyambung ka aranjeunna. Torowongan ieu dipaké pikeun nganteurkeun apdet.

Dina tiori, torowongan anu sami tiasa dianggo pikeun ngawaskeun, tapi sambungan sapertos kitu langkung rumit sareng kirang dipercaya tibatan push basajan.

sumberdaya awan

Panungtungan, perlu pikeun ngawas jasa awan sareng basis data urang, sabab kami nganggo Kubernetes pikeun aranjeunna, saéna supados nyebarkeun monitoring dina kluster saderhana pisan. Ideally, ngagunakeun helem, saprak pikeun deployment, kami nganggo eta di hal nu ilahar. Sareng, tangtosna, pikeun ngawas awan anjeun kedah nganggo solusi anu sami sareng skuter sorangan.

Dipasihan

Phew, sigana urang parantos nyortir pedaran, hayu urang ngadamel daptar naon anu urang peryogikeun dina tungtungna:

• Solusi anu gancang, sabab ngawaskeun diperyogikeun salami prosés pangwangunan
• Jilid / kuantitas - seueur métrik anu diperyogikeun
• Koléksi log diperyogikeun
• Réliabilitas - data penting pikeun ngaluncurkeun kasuksésan
• Anjeun teu tiasa nganggo modél tarik - anjeun peryogi push
• Urang peryogi ngawaskeun ngahijikeun henteu ngan ukur hardware, tapi ogé awan

Gambar ahir katingali sapertos kieu

Pilihan tumpukan

Janten, kami disanghareupan patarosan milih tumpukan monitoring.

Anu mimiti, urang milarian solusi sadaya-dina-hiji anu paling lengkep anu sakaligus nutupan sadaya sarat urang, tapi dina waktos anu sami janten cukup fleksibel pikeun nyaluyukeun panggunaanana pikeun kabutuhan urang. Leungit, urang ngagaduhan seueur larangan anu ditumpukeun ku hardware, arsitéktur sareng wates waktu.

Aya rupa-rupa leyuran ngawaskeun, dimimitian ku sistem full-fledged kawas Nagios, icinga atawa zabbih sareng ditungtungan ku solusi anu siap pikeun manajemén Armada.

Mimitina, anu terakhir sigana mangrupikeun solusi anu idéal pikeun urang, tapi sabagian henteu gaduh pangawasan pinuh, anu sanésna ngagaduhan kamampuan terbatas tina versi gratis, sareng anu sanésna henteu nutupan "kahayang" urang atanapi henteu cukup fleksibel pikeun nyocogkeun kana skenario urang. Sababaraha ngan saukur luntur.

Saatos analisa sababaraha solusi anu sami, kami gancang nyimpulkeun yén éta bakal langkung gampang sareng langkung gancang pikeun ngumpul tumpukan anu sami. Leres, éta bakal langkung rumit tibatan nyebarkeun platform manajemén Armada anu siap-siap, tapi urang henteu kedah kompromi.

Ampir pasti, dina sagala kelimpahan solusi anu ageung, parantos aya anu siap-siap anu leres-leres cocog sareng urang, tapi dina hal urang éta langkung gancang pikeun ngumpul tumpukan tangtu nyalira sareng ngaropea "kanggo diri urang sorangan" tinimbang nguji produk siap-dijieun.

Sareng sadaya ieu, kami henteu narékahan pikeun ngumpul sadayana platform ngawaskeun diri, tapi milarian tumpukan "siap-siap" anu paling fungsional, ngan ukur tiasa ngonpigurasikeunana sacara fleksibel.

(B) ELK?

Solusi kahiji anu sabenerna dianggap éta tumpukan ELK well-dipikawanoh.
Nyatana, kedah disebat BELK, sabab sadayana dimimitian ku Beats - https://www.elastic.co/what-is/elk-stack

Tangtosna, ELK mangrupikeun salah sahiji solusi anu paling kasohor sareng kuat dina widang ngawaskeun, komo deui dina ngumpulkeun sareng ngolah log.

Kami dimaksudkeun yén ELK bakal dianggo pikeun ngumpulkeun log sareng ogé neundeun métrik jangka panjang anu dicandak tina Prometheus.

Pikeun visualisasi anjeun tiasa nganggo Grafan.

Kanyataanna, tumpukan ELK anyar tiasa ngumpulkeun métrik sacara mandiri (metricbeat), sareng Kibana ogé tiasa nampilkeunana.

Tapi tetep, ELK mimitina tumbuh tina log sareng dugi ka fungsionalitas métrik ngagaduhan sababaraha kalemahan anu serius:

• Nyata laun ti Prometheus
• Integrates kana tempat jauh leuwih saeutik ti Prometheus
• Hese nyetél panggeuing pikeun aranjeunna
• Métrik nyokot loba spasi
• Nyetél dasbor sareng métrik di Kiban langkung pajeulit tibatan di Grafan

Sacara umum, métrik dina ELK beurat sareng henteu acan saé sapertos dina solusi anu sanés, anu ayeuna langkung seueur tibatan Prometheus: TSDB, Victoria Metrics, Cortex, jsb., jsb. Tangtosna, kuring hoyong pisan gaduh solusi sadaya-dina-hiji langsung, tapi dina kasus metricbeat seueur teuing kompromi.

Sareng tumpukan ELK sorangan ngagaduhan sababaraha waktos anu susah:

• Éta beurat, sakapeung malah beurat pisan lamun ngumpulkeun jumlah data anu cukup badag
• Anjeun kedah "nyaho kumaha carana masak" éta - anjeun kedah skala, tapi ieu sanés hal anu penting
• Vérsi bébas dilucuti - versi bébas teu boga alerting normal, sarta dina waktos seleksi teu aya auténtikasi.

Kuring kudu disebutkeun yen nembe titik panungtungan geus jadi hadé tur salian kaluaran dina open-source X-pack (kaasup auténtikasi) model harga sorangan mimiti robah.

Tapi dina waktos urang badé nyebarkeun solusi ieu, teu aya peringatan pisan.
Panginten urang tiasa nyobian ngawangun hiji hal nganggo ElastAlert atanapi solusi komunitas anu sanés, tapi urang tetep mutuskeun mertimbangkeun alternatif anu sanés.

Loki - Grafana - Prometheus

Ayeuna, solusi anu saé nyaéta ngawangun tumpukan ngawaskeun dumasar kana Prometheus salaku panyadia métrik, Loki pikeun log, sareng pikeun visualisasi anjeun tiasa nganggo Grafana anu sami.

Hanjakalna, dina waktos ngamimitian pilot penjualan proyék éta (Séptémber-Oktober 19), Loki masih aya dina versi béta 0.3-0.4, sareng dina waktos mimiti pangwangunan éta henteu tiasa dianggap salaku solusi produtcion. pisan.

Kuring teu acan gaduh pangalaman dina sabenerna ngagunakeun Loki dina proyék serius, tapi abdi tiasa disebutkeun yen Promtail (agén pikeun ngumpulkeun log) jalan gede pikeun duanana bulistir-logam jeung pods di kubernetes.

Keletik

Panginten anu paling pantes (hiji-hijina?) Alternatif lengkep pikeun tumpukan ELK ayeuna ngan tiasa disebat tumpukan TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.

Kuring bakal ngajelaskeun sadaya komponén di handap sacara langkung rinci, tapi ideu umum nyaéta kieu:

• Telegraf - agén pikeun ngumpulkeun metrics
• InfluxDB - database métrik
• Kapacitor - prosésor métrik real-time pikeun ngageter
• Chronograf - panel wéb pikeun visualisasi

Pikeun InfluxDB, Kapacitor sareng Chronograf aya grafik helm resmi anu kami biasa nyebarkeunana.

Perlu dicatet yén dina versi panganyarna tina Influx 2.0 (beta), Kapacitor sareng Chronograf janten bagian tina InfluxDB sareng henteu aya deui nyalira.

Telegraf

Telegraf mangrupakeun agén pisan lightweight pikeun ngumpulkeun metrics dina mesin kaayaan.

Anjeunna tiasa ngawas jumlah badag sagalana, ti nginx ka
sérver minecraft.

Éta ngagaduhan sababaraha kaunggulan anu keren:

• Gancang sareng ringan (ditulis dina Go)
  • Eats jumlah minimum sumberdaya
• Push metrics sacara standar
• Kumpulkeun sadaya métrik anu diperyogikeun
  • Métrik sistem tanpa setélan
  • Métrik hardware sapertos inpormasi ti sénsor
  • Gampang pisan pikeun nambihan métrik anjeun nyalira
• Seueur plugins out of the box
• Ngumpulkeun log

Kusabab push metrics dipikabutuh pikeun urang, sagala kaunggulan sejenna éta leuwih ti tambahan pikaresepeun.

Koléksi log ku agén sorangan ogé gampang pisan, sabab henteu kedah nyambungkeun utilitas tambahan pikeun log log.

Influx nawiskeun pangalaman anu paling merenah pikeun damel sareng log upami anjeun nganggo syslog.

Telegraf sacara umum mangrupikeun agén anu saé pikeun ngumpulkeun métrik, sanaos anjeun henteu nganggo tumpukan ICK sesa.

Seueur jalma nyebrang éta sareng ELK sareng sababaraha database séri waktos sanés pikeun genah, sabab tiasa nyerat métrik ampir dimana waé.

InfluxDB

InfluxDB mangrupikeun inti utama tumpukan TICK, nyaéta database séri waktos pikeun métrik.
Salian métrik, Influx ogé tiasa nyimpen log, sanaos, dina dasarna, log pikeun éta ngan ukur métrik anu sami, ngan tibatan indikator numerik biasa, fungsi utama dilaksanakeun ku garis téks log.

InfluxDB ogé diserat dina Go sareng sigana ngajalankeun langkung gancang dibandingkeun sareng ELK dina klaster urang (sanés anu paling kuat).

Salah sahiji kaunggulan keren tina Influx ogé bakal kalebet API anu saé pisan sareng beunghar pikeun patarosan data, anu kami dianggo pisan aktip.

Kakurangan - $$$ atanapi skala?

Tumpukan TICK ngan ukur gaduh hiji kalemahan anu kami mendakan - éta dear. Komo deui.

Naon versi anu mayar anu henteu aya dina versi gratis?

Sajauh anu urang tiasa ngartos, hiji-hijina bédana antara versi mayar tumpukan TICK sareng anu gratis nyaéta kamampuan skala.

Nyaéta, anjeun tiasa ngangkat klaster kalayan kasadiaan High ngan dina Vérsi perusahaan.

Upami anjeun hoyong HA full-fledged, Anjeun boh kedah mayar atanapi nganggo sababaraha crutches. Aya sababaraha solusi komunitas - contona influxdb-ha Sigana mah solusi kompeten, tapi ditulis yén éta téh teu cocog pikeun produksi, kitu ogé
asup-spout - solusi saderhana sareng ngompa data ngaliwatan NATS (éta ogé kedah diskalakeun, tapi ieu tiasa direngsekeun).

Karunya, tapi duanana sigana ditinggalkeun - teu aya commits seger, kuring nganggap yén masalahna nyaéta release pas ekspektasi tina versi anyar Influx 2.0, nu loba hal bakal béda (teu aya informasi ngeunaan skala di dinya acan).

Resmina aya versi gratis relay - kanyataanna, ieu HA primitif, tapi ngan ngaliwatan balancing,
Kusabab sadaya data bakal diserat ka sadaya instansi InfluxDB di tukangeun beban balancer.
Anjeunna gaduh sababaraha shortcomings kawas masalah poténsi kalayan titik overwriting sarta kudu nyieun basa pikeun metrics sateuacanna
(anu lumangsung sacara otomatis nalika dianggo normal sareng InfluxDB).

Salian ti éta sharding teu dirojong, Ieu ngandung harti overhead tambahan pikeun duplikat metrics (duanana ngolah jeung neundeun) nu bisa jadi teu butuh, tapi teu aya deui jalan pikeun misahkeun aranjeunna.

Métrik Victoria?

Hasilna, sanajan kanyataan yén kami sagemblengna wareg jeung tumpukan TICK dina sagalana lian ti skala dibayar, urang mutuskeun ningali lamun aya wae bebas solusi nu bisa ngaganti database InfluxDB, bari ninggalkeun komponén T_CK sésana.

Aya seueur database séri waktos, tapi anu paling ngajangjikeun nyaéta Victoria Metrics, éta ngagaduhan sababaraha kaunggulan:

• Gancang sareng gampang, sahenteuna dumasar kana hasil patokan
• Aya versi klaster, ngeunaan nu aya malah ulasan alus ayeuna
  • Manehna bisa beling
• Ngarojong protokol InfluxDB

Kami henteu ngarencanakeun ngawangun tumpukan khusus anu didasarkeun kana Victoria sareng harepan utama nyaéta yén kami tiasa dianggo salaku gaganti serelek pikeun InfluxDB.

Hanjakalna, ieu henteu mungkin, sanaos kanyataan yén protokol InfluxDB dirojong, éta ngan ukur dianggo pikeun métrik ngarékam - ngan ukur Prometheus API anu sayogi "di luar", anu hartosna éta moal mungkin pikeun nyetél Chronograf dina éta.

Sumawona, ngan ukur nilai numerik anu dirojong pikeun métrik (kami nganggo nilai string pikeun métrik khusus - langkung seueur ngeunaan éta dina bagian panel admin).

Jelas, pikeun alesan anu sami, VM teu tiasa nyimpen log sapertos Influx.

Ogé, éta kedah dicatet yén dina waktos milarian solusi anu optimal, Victoria Metrics henteu acan populer, dokuméntasina langkung alit sareng fungsionalitasna langkung lemah.
(Kuring teu apal pedaran lengkep ngeunaan versi klaster jeung sharding).

Pilihan dasar

Hasilna, diputuskeun yén pikeun pilot urang masih bakal ngawatesan diri kana hiji titik InfluxDB tunggal.

Aya sababaraha alesan utama pikeun pilihan ieu:

• Kami resep pisan kana fungsionalitas tumpukan TICK
• Kami parantos tiasa nyebarkeun éta sareng éta damel saé
• Deadlines parantos kaluar sareng teu aya waktos anu tinggal pikeun nguji pilihan anu sanés.
• Kami henteu nyangka beban anu beurat sapertos kitu

Kami henteu ngagaduhan seueur skuter pikeun fase mimiti pilot, sareng uji nalika pangwangunan henteu nunjukkeun masalah kinerja.

Kituna, urang mutuskeun yén pikeun proyék ieu hiji titik Influx bakal cukup pikeun urang tanpa perlu skala (tingali conclusions dina tungtungna).

Kami parantos mutuskeun dina tumpukan sareng dasar - ayeuna ngeunaan komponén sésana tina tumpukan TICK.

Kapasitor

Kapacitor mangrupikeun bagian tina tumpukan TICK, jasa anu tiasa ngawas métrik anu asup kana pangkalan data sacara real waktos sareng ngalaksanakeun sababaraha tindakan dumasar kana aturan.

Sacara umum, éta diposisikan salaku alat pikeun tracking anomali poténsi sarta learning mesin (Kuring teu yakin yén fungsi ieu di paménta), tapi kasus nu pang populerna di pamakéan na leuwih lumrah - alerting.

Éta kumaha kami nganggo éta pikeun béwara. Urang nyetél Slack ngabejaan lamun Scooter tinangtu indit offline, sarta hal anu sarua dipigawé pikeun carjer pinter jeung komponén infrastruktur penting.

Ieu ngamungkinkeun pikeun gancang ngabales masalah, ogé nampi béwara yén sadayana normal deui.

Conto saderhana: batré tambahan pikeun ngawasa "kotak" urang parantos rusak atanapi kusabab sababaraha alesan parantos kaluar tina kakuatan; ngan ku masang anu énggal, saatos sababaraha waktos urang kedah nampi béwara yén fungsionalitas skuter parantos dibalikeun.

Dina Influx 2.0 Kapacitor janten bagian tina DB

Kronograf

Kuring geus katempo loba solusi UI béda pikeun ngawaskeun, tapi abdi tiasa disebutkeun yen dina watesan fungsionalitas na UX, euweuh compares mun Chronograf.

Urang mimitian nganggo tumpukan TICK, cukup aneh, sareng Grafan salaku antarmuka wéb.
Kuring moal ngajelaskeun pungsionalitasna; sadayana terang kamungkinan anu lega pikeun nyetél naon waé.

Nanging, Grafana masih mangrupikeun alat anu universal, sedengkeun Chronograf utamina dirancang pikeun dianggo sareng Influx.

Sareng tangtosna, hatur nuhun kana ieu, Chronograf tiasa mampuh fungsionalitas anu langkung pinter atanapi langkung merenah.

Panginten genah utama damel sareng Chronograf nyaéta anjeun tiasa ningali lebet InfluxDB anjeun ngalangkungan Jelajah.

Sigana mah Grafana ngagaduhan pungsionalitas anu ampir sami, tapi dina kanyataanana, nyetél dasbor di Chronograf tiasa dilakukeun ku sababaraha klik beurit (dina waktos anu sami ningali visualisasi di dinya), sedengkeun di Grafana anjeun bakal tetep gancang-gancang. pikeun ngédit konfigurasi JSON (tangtu Chronograf ngamungkinkeun unggah dashas leungeun-konpigurasi anjeun sarta ngédit aranjeunna salaku JSON lamun perlu - tapi kuring pernah ngalaman noél aranjeunna sanggeus nyieun eta dina UI).

Kibana gaduh kamampuan anu langkung ageung pikeun nyiptakeun dasbor sareng kadali pikeun aranjeunna, tapi UX pikeun operasi sapertos kitu rumit pisan.

Bakal butuh sababaraha pamahaman alus pikeun nyieun hiji dasbor merenah. Sareng sanaos pungsionalitas dasbor Chronograf kirang, ngadamel sareng ngaropea aranjeunna langkung saderhana.

Dashboards sorangan, sajaba ti gaya visual pikaresepeun, sabenerna mah béda ti dashboards di Grafana atanapi Kibana:

Ieu kumaha tampilan jandela query:

Kadé dicatet, diantara hal séjén, nu nyaho jenis widang dina database InfluxDB, chronograph sorangan kadang bisa otomatis mantuan anjeun ku nulis Query atawa milih fungsi aggregation bener kawas mean.

Sareng tangtosna, Chronograf sabisa-gancang pikeun ningali log. Sigana mah kieu:

Sacara standar, log Influx disaluyukeun nganggo syslog sahingga aranjeunna gaduh parameter penting - parah.

Grafik di luhur hususna kapaké; di dinya anjeun tiasa ningali kasalahan anu kajantenan sareng warna langsung jelas nunjukkeun upami parahna langkung luhur.

Sababaraha kali urang nyekel kutu penting ku cara ieu, bade ningali log kanggo minggu kamari sareng ningali spike beureum.

Tangtosna, idéal nyaéta nyetél panggeuing pikeun kasalahan sapertos kitu, sabab urang parantos ngagaduhan sadayana pikeun ieu.

Kami malah ngaktipkeun ieu sakedap, tapi dina prosés nyiapkeun pilot tétéla yén kami ngagaduhan seueur kasalahan (kalebet sistem sapertos henteu sayogi jaringan LTE), anu ogé "spam" saluran Slack. loba, tanpa ngabalukarkeun masalah nanaon.

Solusi anu bener nyaéta pikeun nanganan kalolobaan jinis kasalahan ieu, saluyukeun parahna pikeun aranjeunna, sareng ngan ukur ngaktifkeun ngageter.

Ku cara ieu, ngan ukur kasalahan anyar atanapi penting anu bakal dipasang ka Slack. Aya ngan saukur teu cukup waktu pikeun setup kitu dibere deadlines ketat.

Konfirmasi

Éta ogé kedah disebatkeun yén Chronograf ngadukung OAuth sareng OIDC salaku auténtikasi.

Ieu pisan merenah, sabab ngidinan Anjeun pikeun gampang ngagantelkeun kana server anjeun sarta nyieun SSO full-fledged.

Dina kasus urang, server éta keycloak - ieu dipaké pikeun nyambung ka ngawas, tapi server sarua ieu ogé dipaké pikeun ngabuktoskeun kaaslianana scooters na requests ka tukang-tungtung.

"Admin"

Komponén anu terakhir anu kuring bakal ngajelaskeun nyaéta "panel admin" anu ditulis diri urang dina Vue.
Dasarna éta ngan ukur layanan mandiri anu nampilkeun inpormasi skuter tina pangkalan data, jasa mikro, sareng data métrik urang sorangan tina InfluxDB sakaligus.

Salaku tambahan, seueur fungsi administrasi anu dipindahkeun ka dinya, sapertos reboot darurat atanapi jarak jauh muka konci pikeun tim dukungan.

Aya ogé peta. Kuring geus disebutkeun yen urang dimimitian kalawan Grafana tinimbang Chronograf - sabab keur peta Grafana sadia dina bentuk plugins, nu urang bisa nempo koordinat scooters. Hanjakalna, kamampuan widget peta pikeun Grafana terbatas pisan, sareng salaku hasilna, langkung gampang nyerat aplikasi wéb anjeun nyalira nganggo peta dina sababaraha dinten, supados henteu ngan ukur ningali koordinat ayeuna, tapi ogé nunjukkeun. jalur dicokot ku Scooter nu, bisa nyaring data dina peta, jeung sajabana (sadayana fungsionalitas nu urang teu bisa ngonpigurasikeun dina dasbor basajan).

Salah sahiji kaunggulan anu parantos disebatkeun tina Influx nyaéta kamampuan ngadamel métrik anjeun nyalira.
Hal ieu ngamungkinkeun eta bisa dipaké pikeun rupa badag skenario.

Kami nyobian ngarékam sadaya inpormasi anu mangpaat di dinya: ngeusi batre, status konci, kinerja sensor, bluetooth, GPS, sareng seueur pamariksaan kaséhatan anu sanés.
Urang ditampilkeun sadayana ieu dina panel admin.

Tangtosna, kritéria anu paling penting pikeun urang nyaéta kaayaan operasi skuter - kanyataanna, Influx pariksa ieu sorangan sareng nunjukkeun éta "lampu héjo" dina bagian Nodes.

Hal ieu dilakukeun ku fungsi jelema maot - kami nganggo éta pikeun ngartos kinerja kotak kami sareng ngirim béwara anu sami ka Slack.

Ku jalan kitu, urang dingaranan scooters tina ngaran karakter ti The Simpsons - éta jadi merenah pikeun ngabedakeun aranjeunna tina unggal lianna.

Sarta sacara umum éta leuwih senang ku cara kieu. Frasa sapertos "Guys, Smithers tos maot!" terus kadéngé.

Métrik string

Kadé InfluxDB ngidinan Anjeun pikeun nyimpen teu ukur nilai numerik, sakumaha dina kasus Victoria Metrics.

Ieu bakal sigana nu ieu teu jadi penting - sanggeus kabeh, sajaba ti log, sagala metrics bisa disimpen dina bentuk angka (ngan nambahan pemetaan pikeun nagara dipikawanoh - jenis enum)?

Dina hal urang, sahenteuna aya hiji skenario dimana métrik string pohara kapaké.
Ieu ngan jadi kajadian nu supplier of "carjer pinter" urang éta pihak katilu, urang teu boga kontrol ngaliwatan prosés ngembangkeun sarta informasi nu chargers ieu bisa nyadiakeun.

Hasilna, ngecas API éta tebih ti idéal, tapi masalah utama éta urang teu salawasna bisa ngarti kaayaan maranéhanana.

Ieu dimana Influx sumping ka nyalametkeun. Urang ngan saukur nulis status string anu datang ka kami kana widang database InfluxDB tanpa parobahan.

Pikeun sababaraha waktos, ngan ukur nilai sapertos "online" sareng "offline", dumasar kana inpormasi anu dipidangkeun dina panel admin kami, sareng bewara dikirim ka Slack. Nanging, dina sababaraha waktos, nilai sapertos "pegatkeun" ogé mimiti muncul di dinya.

Salaku tétéla engké, status ieu dikirim sakali sanggeus leungitna sambungan, lamun carjer teu bisa nyieun sambungan kalawan server sanggeus sababaraha usaha.

Janten, upami urang ngan ukur nganggo sakumpulan nilai anu tetep, urang panginten henteu ningali parobihan ieu dina firmware dina waktos anu pas.

Sareng sacara umum, métrik senar nyayogikeun langkung seueur kamungkinan pikeun dianggo; anjeun tiasa ngarékam ampir sadaya inpormasi dina éta. Sanaos, tangtosna, anjeun ogé kedah nganggo alat ieu sacara saksama.

Salian métrik biasa, kami ogé ngarékam inpormasi lokasi GPS di InfluxDB. Ieu incredibly mangpaat pikeun ngawas lokasi scooters dina panel admin urang.
Kanyataanna, urang salawasna terang dimana jeung nu Scooter éta dina momen urang diperlukeun.

Ieu mangpaat pisan pikeun urang nalika urang pilari Scooter a (tingali conclusions dina tungtungna).

Pengawasan infrastruktur

Salian scooters sorangan, urang diperlukeun pikeun ngawas sakabéh infrastruktur urang (rada éksténsif).

Arsitéktur anu umum pisan katingali sapertos kieu:

Upami urang nyorot tumpukan ngawaskeun murni, sigana sapertos kieu:

Anu kami hoyong pariksa dina awan nyaéta:

• Databases
• keycloak
• Microservices

Kusabab sadaya jasa awan kami aya di Kubernetes, langkung saé pikeun ngumpulkeun inpormasi ngeunaan kaayaanana.

Untungna, Telegraf out of the box tiasa ngumpulkeun sajumlah ageung métrik ngeunaan kaayaan klaster Kubernetes, sareng Chronograf langsung nawiskeun dasbor anu saé pikeun ieu.

Urang utamana ngawas kinerja pods sarta konsumsi memori. Bisi ragrag, ngabejaan di Slack.

Aya dua cara pikeun ngalacak pods di Kubernetes: DaemonSet sareng Sidecar.
Duanana métode dijelaskeun sacara rinci dina tulisan blog ieu.

Kami nganggo Telegraf Sidecar sareng, salian ti métrik, ngumpulkeun log pod.

Dina kasus urang, urang kedah tinker sareng log. Sanaos kanyataan yén Telegraf tiasa narik log tina Docker API, kami hoyong gaduh koleksi log anu seragam sareng alat tungtung kami sareng ngonpigurasikeun syslog pikeun wadah pikeun ieu. Panginten solusi ieu henteu saé, tapi henteu aya keluhan ngeunaan karyana sareng logna ditampilkeun saé dina Chronograf.

Ngawas monitor???

Tungtungna, patarosan umur-lami ngeunaan sistem monitoring ngawas timbul, tapi untungna, atanapi hanjakalna, urang ngan saukur teu boga cukup waktu pikeun ieu.

Sanajan Telegraf bisa kalayan gampang ngirim metrics sorangan atawa ngumpulkeun metrics tina database InfluxDB pikeun ngirim boh ka Influx sarua atawa tempat sejenna.

papanggihan

Naon kacindekan anu urang tarik tina hasil pilot?

Kumaha anjeun tiasa ngalakukeun monitoring?

Anu mimiti, tumpukan TICK sapinuhna nyumponan ekspektasi kami sareng masihan kami langkung seueur kasempetan tibatan anu kami ngarepkeun.

Sadaya pungsionalitas anu urang peryogikeun aya. Sadayana anu urang laksanakeun sareng éta damel tanpa masalah.

kakuwatan keur ngasilkeun

Masalah utama tumpukan TICK dina versi gratis nyaéta kurangna kamampuan skala. Ieu teu masalah keur urang.

Kami henteu ngumpulkeun data beban / angka anu pasti, tapi kami ngumpulkeun data tina sakitar 30 skuter sakaligus.

Tiap di antarana dikumpulkeun leuwih ti tilu belasan metrics. Dina waktos anu sami, log tina alat dikumpulkeun. Pangumpulan sareng pangiriman data lumangsung unggal 10 detik.

Penting pikeun dicatet yén saatos saminggu satengah pilot, nalika sabagéan ageung "masalah budak leutik" dilereskeun sareng masalah anu paling penting parantos direngsekeun, urang kedah ngirangan frékuénsi ngirim data ka server. 30 detik. Ieu janten diperlukeun sabab patalimarga dina kartu SIM LTE urang mimiti gancang ngaleungit.

Seuseueurna lalu lintas dikonsumsi ku log; métrik sorangan, sanaos kalayan interval 10 detik, praktis henteu ngabuang-buang éta.

Hasilna, saatos sababaraha waktos urang ditumpurkeun lengkep koleksi log dina alat, sabab masalah khusus parantos atra sanaos tanpa koleksi konstan.

Dina sababaraha kasus, upami ningali log masih diperyogikeun, urang ngan saukur nyambung via WireGuard via VPN.

Kuring ogé bakal nambahan yén unggal lingkungan misah ieu dipisahkeun ti silih, sarta beban ditétélakeun di luhur éta relevan ukur keur lingkungan produksi.

Dina lingkungan pamekaran, kami ngangkat conto InfluxDB anu misah anu terus ngumpulkeun data unggal 10 detik sareng kami henteu ngalaman masalah kinerja.

TICK - idéal pikeun proyék-proyék leutik nepi ka sedeng

Dumasar inpormasi ieu, kuring bakal nyimpulkeun yén tumpukan TICK idéal pikeun proyék-proyék anu kawilang leutik atanapi proyék anu pasti henteu nyangka HighLoad.

Upami anjeun teu gaduh rébuan pods atanapi ratusan mesin, bahkan hiji conto InfluxDB bakal nanganan beban anu saé.

Dina sababaraha kasus, Anjeun bisa jadi wareg jeung Influx Relay salaku solusi High Availability primitif.

Sareng, tangtosna, teu aya anu ngahalangan anjeun tina nyetél skala "vertikal" sareng ngan ukur ngalokasikeun server anu béda pikeun sababaraha jinis métrik.

Mun anjeun teu yakin kana beban ekspektasi dina jasa ngawaskeun, atawa anjeun dijamin gaduh / bakal boga pisan "beurat" arsitéktur, Abdi teu bakal nyarankeun make versi bébas tina tumpukan keletik.

Tangtosna, solusi anu saderhana nyaéta mésér Perusahaan InfluxDB - tapi di dieu kuring teu bisa mairan kumaha bae, sabab kuring sorangan teu wawuh jeung subtleties. Di sagigireun kanyataan yén éta pisan mahal jeung pasti teu cocog pikeun pausahaan leutik.

Dina hal ieu, ayeuna, kuring bakal nyarankeun ningali ka arah ngumpulkeun métrik ngaliwatan Victoria Metrics sareng log nganggo Loki.

Leres, kuring bakal deui ngadamel reservasi yén Loki / Grafana langkung kirang merenah (kusabab versatility anu langkung ageung) tibatan TICK anu siap-siap, tapi aranjeunna gratis.

penting: Sadaya inpormasi anu dijelaskeun di dieu relevan pikeun versi Influx 1.8, ayeuna Influx 2.0 badé dileupaskeun.

Sanaos kuring henteu ngagaduhan kasempetan pikeun nyobian éta dina kaayaan tempur sareng hese ngagambar kacindekan ngeunaan perbaikan, antarmuka pasti janten langkung saé, arsitéktur parantos disederhanakeun (tanpa kapacitor sareng chronograf),
témplat muncul ("fitur pembunuh" - Anjeun tiasa ngalacak pamaén di Fortnite sareng nampi béwara nalika pamuter karesep anjeun meunang kaulinan). Tapi, hanjakalna, dina momen, versi 2 teu boga hal konci nu urang milih versi munggaran - euweuh koleksi log.

Pungsi ieu ogé bakal muncul dina Influx 2.0, tapi urang teu bisa manggihan deadlines wae, sanajan leuwih perkiraan.

Kumaha henteu ngadamel platform IoT (ayeuna)

Tungtungna, sanggeus ngaluncurkeun pilot, urang sorangan ngumpul tumpukan IoT pinuh kami sorangan, dina henteuna alternatif cocog ku standar urang.

Nanging, ayeuna éta sayogi dina versi Beta OpenBalena - hanjakalna manehna teu aya nalika urang mimiti nyieun proyek.

Kami lengkep wareg ku hasil ahir sareng platform dumasar kana Ansible + TICK + WireGuard anu kami kumpulkeun sorangan. Tapi ayeuna, kuring bakal nyarankeun ningali langkung caket Balena sateuacan nyobian ngawangun platform IoT anjeun nyalira.

Kusabab pamustunganana éta tiasa ngalakukeun kalolobaan naon anu urang laksanakeun, sareng OpenBalena gratis sareng open source.

Éta parantos terang kumaha henteu ngan ukur ngirim apdet, tapi ogé VPN parantos diwangun sareng disaluyukeun pikeun dianggo dina lingkungan IoT.

Sarta ngan nembe, aranjeunna malah ngarilis maranéhna hardware, nu gampang nyambung ka ékosistem maranéhanana.

Hei, kumaha upami skuter anu leungit?

Jadi Scooter, "Ralph", ngiles tanpa renik.

Kami langsung lumpat ningali peta dina "panel admin" kami, kalayan data métrik GPS tina InfluxDB.

Hatur nuhun kana data mantau, urang gampang ditangtukeun yén Scooter nu ditinggalkeun tempat parkir sabudeureun 21:00 poé panungtungan, drove ngeunaan satengah jam ka sababaraha wewengkon sarta diparkir dugi 5 am gigireun sababaraha imah Jerman.

Saatos jam 5 énjing, teu aya data ngawaskeun anu ditampi-ieu hartosna batré tambahan parantos dikaluarkeun, atanapi panyerang tungtungna terang kumaha carana nyabut hardware pinter tina skuter.
Sanajan ieu, pulisi masih disebut alamat dimana Scooter ieu lokasina. Scooter éta teu aya.

Sanajan kitu, nu boga imah ogé kaget ieu, saprak anjeunna sabenerna rode ieu scooter imah ti kantor tadi peuting.

Salaku tétéla, salah sahiji karyawan rojongan anjog mimiti isuk-isuk sarta nyokot Scooter nu, ningali yén batré tambahan na tos rengse discharged sarta nyandak eta (jalan kaki) ka tempat parkir. Jeung batré tambahan gagal alatan Uap.

Urang maling skuter ti diri urang sorangan. Ku jalan kitu, kuring henteu terang kumaha sareng saha anu teras ngarengsekeun masalah sareng kasus pulisi, tapi ngawaskeun jalanna sampurna ...

sumber: www.habr.com