Rudisha skuta iliyokosekana, au hadithi ya ufuatiliaji mmoja wa IoT

Mwaka mmoja uliopita tulizindua toleo la majaribio la mradi wa utangazaji wa ukodishaji wa madaraka wa scooters za umeme.

Hapo awali, mradi huo uliitwa Road-To-Barcelona, ​​​​baadaye ikawa Road-To-Berlin (kwa hivyo R2B kwenye picha za skrini), na mwishowe iliitwa xRide.

Wazo kuu la mradi lilikuwa hili: badala ya kuwa na gari la kati au huduma ya kukodisha pikipiki (tunazungumza juu ya pikipiki za umeme, sio kickscooters/scooters) tulitaka kutengeneza jukwaa la ukodishaji wa madaraka. Kuhusu shida tulizokutana nazo tayari imeandikwa mapema.

Hapo awali, mradi huo ulizingatia magari, lakini kwa sababu ya tarehe za mwisho, mawasiliano marefu sana na watengenezaji na idadi kubwa ya vizuizi vya usalama, scooters za umeme zilichaguliwa kwa majaribio.

Mtumiaji alisakinisha programu ya iOS au Android kwenye simu, akakaribia pikipiki aliyoipenda, baada ya hapo simu na pikipiki zikaanzisha muunganisho wa rika-kwa-rika, ETH ilibadilishwa na mtumiaji angeweza kuanza safari kwa kuwasha skuta kupitia. simu. Mwishoni mwa safari, iliwezekana pia kulipa safari kwa kutumia Ethereum kutoka kwa mkoba wa mtumiaji kwenye simu.

Mbali na scooters, mtumiaji aliona "chaja mahiri" kwenye programu, kwa kutembelea ambayo mtumiaji anaweza kubadilisha betri ya sasa mwenyewe ikiwa ilikuwa chini.

Hivi kwa ujumla ndivyo majaribio yetu yalivyoonekana, iliyozinduliwa Septemba mwaka jana katika miji miwili ya Ujerumani: Bonn na Berlin.

Na kisha, siku moja, huko Bonn, mapema asubuhi, timu yetu ya usaidizi (iko kwenye tovuti ili kudumisha scooters katika utaratibu wa kufanya kazi) ilitahadharishwa: moja ya scooters ilikuwa imetoweka bila kufuatilia.

Jinsi ya kuipata na kuirudisha?

Katika makala hii nitazungumzia kuhusu hili, lakini kwanza - kuhusu jinsi tulivyojenga jukwaa letu la IoT na jinsi tulivyofuatilia.

Nini na kwa nini kufuatilia: scooters, miundombinu, vituo vya malipo?

Kwa hivyo, tulitaka kufuatilia nini katika mradi wetu?

Kwanza kabisa, hizi ni pikipiki zenyewe - scooters za umeme wenyewe ni ghali kabisa, huwezi kuzindua mradi kama huo bila kuwa tayari vya kutosha; ikiwezekana, unataka kukusanya habari nyingi iwezekanavyo juu ya scooters: juu ya eneo lao, kiwango cha malipo. , na kadhalika.

Kwa kuongeza, ningependa kufuatilia hali ya miundombinu yetu ya IT - hifadhidata, huduma na kila kitu wanachohitaji kufanya kazi. Ilihitajika pia kufuatilia hali ya "chaja za smart", ikiwa zilivunjika au kuishiwa na betri kamili.

Scooters

Scooters zetu zilikuwa nini na tulitaka kujua nini kuzihusu?

Jambo la kwanza na muhimu zaidi ni kuratibu za GPS, kwa kuwa shukrani kwao tunaweza kuelewa ni wapi na wapi wanahamia.

Ifuatayo ni malipo ya betri, shukrani ambayo tunaweza kuamua kuwa malipo ya scooters yanaisha na kutuma juicer au angalau kuonya mtumiaji.

Kwa kweli, inahitajika pia kuangalia kile kinachotokea na vifaa vyetu vya maunzi:

• bluetooth inafanya kazi?
• moduli ya GPS yenyewe inafanya kazi?
  • Pia tulikuwa na tatizo na ukweli kwamba GPS inaweza kutuma viwianishi visivyo sahihi na kukwama, na hii inaweza tu kuamuliwa na ukaguzi wa ziada kwenye skuta,
    na uarifu usaidizi haraka iwezekanavyo ili kutatua suala hilo

Na mwishowe: ukaguzi wa programu, kuanzia na OS na processor, mzigo wa mtandao na diski, na kuishia na ukaguzi wa moduli zetu ambazo ni maalum zaidi kwetu (Jolocom, Nguo ya funguo).

vifaa vya ujenzi

Sehemu yetu ya "chuma" ilikuwa nini?

Kwa kuzingatia muda mfupi iwezekanavyo na hitaji la protoksi ya haraka, tulichagua chaguo rahisi zaidi kwa utekelezaji na uteuzi wa vipengele - Raspberry Pi.
Mbali na Rpi yenyewe, tulikuwa na bodi ya desturi (ambayo sisi wenyewe tulitengeneza na kuamuru kutoka China ili kuharakisha mchakato wa mkutano wa suluhisho la mwisho) na seti ya vipengele - relay (kuwasha / kuzima scooter), msomaji wa malipo ya betri, modem, antena. Yote hii iliwekwa kwa ukamilifu katika sanduku maalum la "xRide".

Inapaswa pia kuzingatiwa kuwa sanduku lote lilitumiwa na benki ya ziada ya nguvu, ambayo kwa upande wake ilitumiwa na betri kuu ya scooter.

Hii ilifanya iwezekane kutumia ufuatiliaji na kuwasha pikipiki hata baada ya mwisho wa safari, kwani betri kuu ilizimwa mara baada ya kuwasha kitufe cha kuwasha kwa nafasi ya "kuzima".

Dokta? Linux wazi? na kupelekwa

Hebu turudi kwenye ufuatiliaji, hivyo Raspberry - tuna nini?

Mojawapo ya mambo ya kwanza ambayo tulitaka kutumia kuharakisha mchakato wa kupeleka, kusasisha na kupeana vifaa kwa vifaa vya kawaida ilikuwa Docker.

Kwa bahati mbaya, ilionekana wazi kuwa Docker kwenye RPi, ingawa inafanya kazi, ina kazi nyingi, haswa katika suala la matumizi ya nishati.

Tofauti ya kutumia OS "asili", ingawa haikuwa na nguvu sana, bado ilikuwa ya kutosha kwetu kuwa na wasiwasi juu ya uwezekano wa kupoteza chaji haraka sana.

Sababu ya pili ilikuwa mojawapo ya maktaba za washirika wetu kwenye Node.js (sic!) - sehemu pekee ya mfumo ambayo haikuandikwa katika Go/C/C++.

Waandishi wa maktaba hawakuwa na wakati wa kutoa toleo la kufanya kazi katika lugha yoyote ya "asili".

Sio tu nodi yenyewe sio suluhisho la kifahari zaidi kwa vifaa vya utendaji wa chini, lakini maktaba yenyewe ilikuwa na njaa ya rasilimali.

Tuligundua kuwa, hata ikiwa tungetaka, kutumia Docker itakuwa kazi kubwa sana kwetu. Chaguo lilifanywa kwa niaba ya OS asilia na kufanya kazi moja kwa moja chini yake.

OS

Kama matokeo, sisi, tena, tulichagua chaguo rahisi zaidi kama OS na tukatumia Raspbian (Debian build for Pi).

Tunaandika programu zetu zote katika Go, kwa hivyo tuliandika pia moduli kuu ya wakala wa maunzi katika mfumo wetu katika Go.

Ni yeye ambaye anajibika kwa kufanya kazi na GPS, Bluetooth, kusoma malipo, kuwasha scooter, nk.

Weka

Swali liliibuka mara moja kuhusu hitaji la kutekeleza utaratibu wa kupeana masasisho kwa vifaa (OTA) - visasisho vyote kwa wakala/programu yenyewe, na masasisho kwa OS/programu yenyewe (kwani matoleo mapya ya wakala yanaweza kuhitaji masasisho kwenye kernel. au vipengele vya mfumo, maktaba, n.k.) .

Baada ya uchambuzi mrefu wa soko, iliibuka kuwa kuna suluhisho nyingi za kutoa sasisho kwenye kifaa.

Kutoka kwa urahisi, mara nyingi husasisha/huduma zenye mwelekeo wa buti mbili kama vile swupd/SWUpdate/OSTree hadi majukwaa kamili kama Mender na Balena.

Awali ya yote, tuliamua kuwa tuna nia ya ufumbuzi wa mwisho hadi mwisho, hivyo uchaguzi mara moja ulianguka kwenye majukwaa.

Mwenyewe Balena ilitengwa kwa sababu ya ukweli kwamba inatumia Docker sawa ndani ya balenaEngine yake.

Lakini naona kuwa licha ya hili, tuliishia kutumia bidhaa zao mara kwa mara Balena Etcher kwa firmware ya flash kwenye kadi za SD - matumizi rahisi na rahisi sana kwa hili.

Kwa hiyo, mwishowe uchaguzi ulianguka Mender. Mender ni jukwaa kamili la kukusanyika, kutoa na kusakinisha firmware.

Kwa ujumla jukwaa linaonekana vizuri, lakini ilituchukua takriban wiki moja na nusu kuunda toleo sahihi la programu dhibiti yetu kwa kutumia kiunda mender.
Na kadiri tulivyozama katika ugumu wa matumizi yake, ndivyo ilivyodhihirika kuwa ili kuipeleka kikamilifu tungehitaji muda mwingi zaidi kuliko tuliokuwa nao.

Ole, makataa yetu magumu yalimaanisha kwamba tulilazimika kuachana na matumizi ya Mender na kuchagua moja rahisi zaidi.

Inawezekana

Suluhisho rahisi zaidi katika hali yetu ilikuwa kutumia Ansible. Vitabu kadhaa vya michezo vilitosha kuanza.

Kiini chao kilikuwa kwamba tuliunganisha kwa urahisi kutoka kwa seva pangishi (seva ya CI) kupitia ssh kwa rasberries zetu na kusambaza masasisho kwao.

Mwanzoni, kila kitu kilikuwa rahisi - ilibidi uwe kwenye mtandao huo na vifaa, kumwaga kulifanyika kupitia Wi-Fi.

Ofisini kulikuwa na raspberries kadhaa za majaribio zilizounganishwa kwenye mtandao huo huo, kila kifaa kilikuwa na anwani ya IP tuli pia iliyoainishwa kwenye Ansible Inventory.

Ilikuwa Ansible ambayo iliwasilisha wakala wetu wa ufuatiliaji kwenye vifaa vya kumalizia

3G / LTE

Kwa bahati mbaya, kesi hii ya utumiaji ya Ansible inaweza tu kufanya kazi katika hali ya ukuzaji kabla hatujapata skuta halisi.

Kwa sababu scooters, kama unavyoelewa, usikae umeunganishwa kwenye kipanga njia kimoja cha Wi-Fi, ukingojea kila mara sasisho kwenye mtandao.

Kwa kweli, scooters haziwezi kuwa na muunganisho wowote zaidi ya 3G/LTE ya rununu (na hata hivyo si wakati wote).

Hii mara moja huweka shida na mapungufu mengi, kama kasi ya chini ya unganisho na mawasiliano yasiyokuwa thabiti.

Lakini jambo muhimu zaidi ni kwamba katika mtandao wa 3G/LTE hatuwezi kutegemea tu IP tuli iliyopewa mtandao.

Hili linatatuliwa kwa kiasi na baadhi ya watoa huduma za SIM kadi; ​​kuna hata SIM kadi maalum iliyoundwa kwa ajili ya vifaa vya IoT vilivyo na anwani za IP tuli. Lakini hatukuweza kufikia SIM kadi hizo na hatukuweza kutumia anwani za IP.

Bila shaka, kulikuwa na mawazo ya kufanya aina fulani ya usajili wa anwani za IP aka ugunduzi wa huduma mahali fulani kama Consul, lakini tulipaswa kuacha mawazo hayo, kwa kuwa katika majaribio yetu anwani ya IP inaweza kubadilika mara nyingi sana, ambayo ilisababisha kukosekana kwa utulivu mkubwa.

Kwa sababu hii, matumizi rahisi zaidi ya kuwasilisha vipimo haitakuwa kutumia muundo wa kuvuta, ambapo tungeenda kwenye vifaa kwa ajili ya vipimo vinavyohitajika, lakini kusukuma, kuwasilisha vipimo kutoka kwa kifaa moja kwa moja hadi kwenye seva.

VPN

Kama suluhisho la shida hii, tulichagua VPN - haswa Walinzi.

Wateja (scooters) mwanzoni mwa mfumo uliounganishwa kwenye seva ya VPN na waliweza kuunganishwa nao. Mtaro huu ulitumiwa kutoa masasisho.

Kinadharia, handaki moja inaweza kutumika kwa ufuatiliaji, lakini unganisho kama hilo lilikuwa ngumu zaidi na lisilotegemewa kuliko kushinikiza rahisi.

Rasilimali za wingu

Hatimaye, ni muhimu kufuatilia huduma zetu za wingu na hifadhidata, kwa kuwa tunatumia Kubernetes kwao, ili kupeleka ufuatiliaji katika nguzo iwe rahisi iwezekanavyo. Kimsingi, kutumia Helm, kwani kwa kupelekwa, tunaitumia katika hali nyingi. Na, bila shaka, kufuatilia wingu unahitaji kutumia ufumbuzi sawa na kwa scooters wenyewe.

Imetolewa

Phew, inaonekana tumepanga maelezo, hebu tutengeneze orodha ya kile tulichohitaji mwishowe:

• Suluhisho la haraka, kwa kuwa ufuatiliaji ni muhimu tayari wakati wa mchakato wa maendeleo
• Kiasi/kiasi - vipimo vingi vinavyohitajika
• Mkusanyiko wa kumbukumbu unahitajika
• Kuegemea - data ni muhimu ili kuzindua mafanikio
• Huwezi kutumia mfano wa kuvuta - unahitaji kushinikiza
• Tunahitaji ufuatiliaji wa umoja wa sio vifaa tu, bali pia wingu

Picha ya mwisho ilionekana kama hii

Uchaguzi wa rafu

Kwa hiyo, tulikabiliwa na swali la kuchagua stack ya ufuatiliaji.

Kwanza kabisa, tulikuwa tunatafuta suluhu kamili zaidi ya yote kwa moja ambayo wakati huo huo ingeshughulikia mahitaji yetu yote, lakini wakati huo huo kuwa rahisi kubadilika vya kutosha kurekebisha matumizi yake kulingana na mahitaji yetu. Bado, tulikuwa na vizuizi vingi vilivyowekwa kwetu na vifaa, usanifu na tarehe za mwisho.

Kuna aina kubwa ya ufumbuzi wa ufuatiliaji, kuanzia na mifumo kamili kama Nagios, icinga au zabbix na kumalizia na suluhu zilizotengenezwa tayari kwa usimamizi wa Meli.

Hapo awali, hii ya mwisho ilionekana kama suluhisho bora kwetu, lakini wengine hawakuwa na ufuatiliaji kamili, wengine walikuwa na uwezo mdogo sana wa matoleo ya bure, na wengine hawakufunika "matakwa" yetu au hawakuwa rahisi kubadilika ili kuendana na hali zetu. Baadhi zimepitwa na wakati tu.

Baada ya kuchambua suluhisho kadhaa zinazofanana, tulifikia hitimisho haraka kwamba itakuwa rahisi na haraka kukusanya safu kama hiyo sisi wenyewe. Ndiyo, itakuwa ngumu zaidi kuliko kupeleka jukwaa la usimamizi wa Fleet lililo tayari kabisa, lakini hatutahitaji kufanya maafikiano.

Karibu hakika, katika suluhisho nyingi kubwa, tayari kuna suluhisho lililotengenezwa tayari ambalo lingetufaa kabisa, lakini kwa upande wetu ilikuwa haraka sana kukusanya safu fulani peke yetu na kuibadilisha "kwa sisi wenyewe" badala ya. kupima bidhaa zilizotengenezwa tayari.

Pamoja na haya yote, hatukujitahidi kukusanya jukwaa zima la ufuatiliaji sisi wenyewe, lakini tulikuwa tunatafuta safu za kazi zaidi "zilizotengenezwa", tu na uwezo wa kuzisanidi kwa urahisi.

(B)ELK?

Suluhisho la kwanza ambalo lilizingatiwa kwa kweli lilikuwa safu inayojulikana ya ELK.
Kwa kweli, inapaswa kuitwa BELK, kwa sababu yote huanza na Beats - https://www.elastic.co/what-is/elk-stack

Bila shaka, ELK ni mojawapo ya ufumbuzi maarufu zaidi na wenye nguvu katika uwanja wa ufuatiliaji, na hata zaidi katika kukusanya na usindikaji wa kumbukumbu.

Tulikusudia kwamba ELK itatumika kukusanya kumbukumbu na vilevile uhifadhi wa muda mrefu wa vipimo vilivyopatikana kutoka kwa Prometheus.

Kwa taswira unaweza kutumia Grafan.

Kwa hakika, rundo jipya la ELK linaweza kukusanya vipimo kwa kujitegemea (metricbeat), na Kibana pia anaweza kuzionyesha.

Lakini bado, ELK hapo awali ilikua nje ya magogo na hadi sasa utendakazi wa metriki una shida kadhaa kubwa:

• Ni polepole sana kuliko Prometheus
• Inaunganishwa katika maeneo machache sana kuliko Prometheus
• Ni vigumu kuwawekea arifa
• Vipimo huchukua nafasi nyingi
• Kuweka dashibodi kwa vipimo katika Kiban ni ngumu zaidi kuliko katika Grafan

Kwa ujumla, metriki katika ELK ni nzito na bado sio rahisi kama katika suluhisho zingine, ambazo sasa kuna zaidi ya Prometheus tu: TSDB, Victoria Metrics, Cortex, nk, nk. Kwa kweli, ningependa sana kuwa na suluhisho kamili kwa moja mara moja, lakini kwa upande wa metricbeat kulikuwa na maelewano mengi.

Na safu ya ELK yenyewe ina wakati mgumu kadhaa:

• Ni nzito, wakati mwingine hata nzito sana ikiwa unakusanya kiasi kikubwa cha data
• Unahitaji "kujua jinsi ya kupika" - unahitaji kuipunguza, lakini hii sio jambo dogo kufanya
• Toleo la bure lililotolewa - toleo la bure halina arifa ya kawaida, na wakati wa uteuzi hapakuwa na uthibitishaji.

Lazima niseme kwamba hivi karibuni hatua ya mwisho imekuwa bora na kwa kuongeza pato katika pakiti ya X-chanzo-wazi (pamoja na uthibitishaji) muundo wa bei yenyewe ulianza kubadilika.

Lakini wakati tulipokuwa tukipeleka suluhisho hili, hakukuwa na tahadhari hata kidogo.
Labda tungejaribu kuunda kitu kwa kutumia ElastAlert au suluhisho zingine za jamii, lakini bado tuliamua kuzingatia njia zingine.

Loki - Grafana - Prometheus

Kwa sasa, suluhisho zuri linaweza kuwa kuunda safu ya ufuatiliaji kulingana na Prometheus kama mtoa huduma wa vipimo, Loki ya kumbukumbu, na kwa taswira unaweza kutumia Grafana sawa.

Kwa bahati mbaya, wakati wa kuanza kwa majaribio ya mauzo ya mradi huo (Septemba-Oktoba 19), Loki alikuwa bado katika toleo la beta 0.3-0.4, na wakati wa kuanza kwa maendeleo haikuweza kuzingatiwa kama suluhisho la uzalishaji. hata kidogo.

Bado sina uzoefu wa kutumia Loki katika miradi mikubwa, lakini ninaweza kusema kwamba Promtail (wakala wa kukusanya kumbukumbu) hufanya kazi vizuri kwa chuma-tupu na maganda kwenye kubernetes.

BONYEZA

Labda mbadala inayostahiki zaidi (ya pekee?) iliyoangaziwa kamili kwa rafu ya ELK sasa inaweza kuitwa tu rundo la TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.

Nitaelezea vipengele vyote hapa chini kwa undani zaidi, lakini wazo la jumla ni hili:

• Telegraf - wakala wa kukusanya metrics
• InfluxDB - hifadhidata ya vipimo
• Kapacitor - kichakataji cha vipimo cha wakati halisi cha arifa
• Chronograf - jopo la wavuti kwa taswira

Kwa InfluxDB, Kapacitor na Chronograf kuna chati rasmi za usukani ambazo tulikuwa tukizitumia.

Ikumbukwe kwamba katika toleo jipya zaidi la Influx 2.0 (beta), Kapacitor na Chronograf zimekuwa sehemu ya InfluxDB na hazipo tena tofauti.

Telegrafu

Telegrafu ni wakala mwepesi sana wa kukusanya vipimo kwenye mashine ya serikali.

Anaweza kufuatilia kiasi kikubwa cha kila kitu, kutoka nginx kwa
seva minecraft.

Ina idadi ya faida nzuri:

• Haraka na nyepesi (iliyoandikwa katika Go)
  • Kula kiwango cha chini cha rasilimali
• Sukuma vipimo kwa chaguomsingi
• Hukusanya vipimo vyote muhimu
  • Vipimo vya mfumo bila mipangilio yoyote
  • Vipimo vya maunzi kama vile maelezo kutoka kwa vitambuzi
  • Ni rahisi sana kuongeza vipimo vyako mwenyewe
• Kura ya programu-jalizi nje ya boksi
• Hukusanya kumbukumbu

Kwa kuwa vipimo vya kushinikiza vilikuwa muhimu kwetu, faida zingine zote zilikuwa zaidi ya nyongeza za kupendeza.

Ukusanyaji wa magogo na wakala yenyewe pia ni rahisi sana, kwani hakuna haja ya kuunganisha huduma za ziada kwa magogo ya magogo.

Utitiri hutoa matumizi rahisi zaidi ya kufanya kazi na kumbukumbu ikiwa unatumia syslog.

Telegraf kwa ujumla ni wakala mzuri wa kukusanya vipimo, hata kama hutumii rafu iliyosalia ya ICK.

Watu wengi huvuka kwa ELK na hifadhidata zingine za mfululizo wa wakati kwa urahisi, kwani inaweza kuandika vipimo karibu popote.

InfluxDB

InfluxDB ndio msingi mkuu wa safu ya TICK, yaani hifadhidata ya mfululizo wa saa ya vipimo.
Mbali na metrics, Influx inaweza pia kuhifadhi kumbukumbu, ingawa, kwa asili, magogo kwa ajili yake ni metrics sawa tu, badala ya viashiria vya kawaida vya nambari, kazi kuu inafanywa na mstari wa maandishi ya logi.

InfluxDB pia imeandikwa katika Go na inaonekana kukimbia haraka sana ikilinganishwa na ELK kwenye nguzo yetu (sio yenye nguvu zaidi).

Mojawapo ya faida nzuri za Utitiri pia inaweza kujumuisha API rahisi na tajiri kwa hoja za data, ambayo tuliitumia kwa bidii.

Hasara - $$$ au kuongeza?

Mkusanyiko wa TICK una kasoro moja tu ambayo tuligundua - ni wapenzi. Hata zaidi.

Toleo la kulipwa lina nini ambalo toleo la bure halina?

Kwa kadiri tulivyoweza kuelewa, tofauti pekee kati ya toleo la kulipia la mrundikano wa TICK na lile lisilolipishwa ni uwezo wa kuongeza alama.

Yaani, unaweza kuongeza nguzo na Upatikanaji wa Juu tu ndani Matoleo ya biashara.

Ikiwa unataka HA kamili, unahitaji kulipa au kutumia magongo. Kuna suluhisho kadhaa za jamii - kwa mfano influxdb-ha inaonekana kama suluhisho linalofaa, lakini imeandikwa kuwa haifai kwa uzalishaji, na vile vile
utitiri-spout - suluhisho rahisi na kusukuma data kupitia NATS (italazimika pia kupunguzwa, lakini hii inaweza kutatuliwa).

Inasikitisha, lakini zote mbili zinaonekana kuachwa - hakuna ahadi mpya, nadhani suala hilo ni toleo linalotarajiwa la toleo jipya la Influx 2.0, ambalo mambo mengi yatakuwa tofauti (hakuna habari kuhusu. kuongeza ndani yake bado).

Rasmi kuna toleo la bure Relay - kwa kweli, hii ni HA ya zamani, lakini tu kupitia kusawazisha,
kwa kuwa data yote itaandikwa kwa matukio yote ya InfluxDB nyuma ya sawazisha la mzigo.
Ana baadhi mapungufu kama vile matatizo yanayoweza kutokea na pointi za kubatilisha na hitaji la kuunda misingi ya vipimo mapema
(ambayo hutokea kiotomatiki wakati wa kazi ya kawaida na InfluxDB).

Mbali na hilo kugawanyika hakutumiki, hii ina maana ya ziada ya vipimo vya nakala (zote mbili za usindikaji na uhifadhi) ambazo huenda usihitaji, lakini hakuna njia ya kuzitenganisha.

Vipimo vya Victoria?

Kwa hivyo, licha ya ukweli kwamba tuliridhika kabisa na mrundikano wa TICK katika kila kitu isipokuwa kuongeza kiwango cha malipo, tuliamua kuona ikiwa kulikuwa na suluhisho za bure ambazo zinaweza kuchukua nafasi ya hifadhidata ya InfluxDB, huku tukiacha vipengee vilivyobaki vya T_CK.

Kuna hifadhidata nyingi za mfululizo wa wakati, lakini inayoahidi zaidi ni Victoria Metrics, ina faida kadhaa:

• Haraka na rahisi, angalau kulingana na matokeo vigezo
• Kuna toleo la nguzo, ambalo kuna hakiki nzuri sasa
  • Anaweza kupasua
• Inasaidia itifaki ya InfluxDB

Hatukukusudia kuunda mkusanyiko maalum kabisa kulingana na Victoria na tumaini kuu lilikuwa kwamba tunaweza kuutumia kama mbadala wa InfluxDB.

Kwa bahati mbaya, hili haliwezekani, licha ya ukweli kwamba itifaki ya InfluxDB inaauniwa, inafanya kazi tu kwa vipimo vya kurekodi - ni API ya Prometheus pekee inayopatikana "nje", ambayo inamaanisha kuwa haitawezekana kuweka Chronograf juu yake.

Zaidi ya hayo, ni thamani za nambari pekee ndizo zinazotumika kwa vipimo (tulitumia thamani za kamba kwa vipimo maalum - zaidi juu ya hiyo katika sehemu. eneo la admin).

Ni wazi, kwa sababu hiyo hiyo, VM haiwezi kuhifadhi kumbukumbu kama Influx inavyofanya.

Pia, ikumbukwe kwamba wakati wa kutafuta suluhisho bora, Victoria Metrics ilikuwa bado haijajulikana sana, nyaraka zilikuwa ndogo zaidi na utendaji ulikuwa dhaifu.
(Sikumbuki maelezo ya kina ya toleo la nguzo na sharding).

Uchaguzi wa msingi

Kama matokeo, iliamuliwa kuwa kwa majaribio bado tutajiwekea kikomo kwa nodi moja ya InfluxDB.

Kulikuwa na sababu kadhaa kuu za uchaguzi huu:

• Tulipenda sana utendakazi mzima wa safu ya TICK
• Tayari tumeweza kuipeleka na ilifanya kazi vizuri
• Makataa yalikuwa yakiisha na hapakuwa na muda mwingi uliobaki wa kujaribu chaguzi zingine.
• Hatukutarajia mzigo mzito kama huo

Hatukuwa na skuta nyingi kwa awamu ya kwanza ya majaribio, na majaribio wakati wa utayarishaji hayakuonyesha matatizo yoyote ya utendaji.

Kwa hiyo, tuliamua kwamba kwa mradi huu nodi moja ya Kuingia itakuwa ya kutosha kwetu bila ya haja ya kuongeza (angalia hitimisho mwishoni).

Tumeamua juu ya rafu na msingi - sasa kuhusu vijenzi vilivyosalia vya rafu ya TICK.

Kapacitor

Kapacitor ni sehemu ya mkusanyiko wa TICK, huduma inayoweza kufuatilia vipimo vinavyoingia kwenye hifadhidata kwa wakati halisi na kufanya vitendo mbalimbali kulingana na sheria.

Kwa ujumla, imewekwa kama zana ya ufuatiliaji unaowezekana na ujifunzaji wa mashine (sina uhakika kuwa vipengele hivi vinahitajika), lakini kesi maarufu zaidi ya matumizi yake ni ya kawaida zaidi - kuonya.

Hivyo ndivyo tulivyoitumia kwa arifa. Tuliweka arifa za Slack wakati skuta fulani ilipotoka mtandaoni, na vivyo hivyo kwa chaja mahiri na vipengele muhimu vya miundombinu.

Hii ilifanya iwezekane kujibu haraka shida, na pia kupokea arifa kwamba kila kitu kilikuwa kimerudi kawaida.

Mfano rahisi: betri ya ziada ya kuwasha "kisanduku" chetu imeharibika au kwa sababu fulani imeishiwa nguvu; kwa kusakinisha mpya tu, baada ya muda tunapaswa kupokea arifa kwamba utendakazi wa skuta umerejeshwa.

Katika Influx 2.0 Kapacitor akawa sehemu ya DB

Chronografia

Nimeona suluhisho nyingi tofauti za UI za ufuatiliaji, lakini naweza kusema kwamba kwa suala la utendakazi na UX, hakuna kinacholinganishwa na Chronograf.

Tulianza kutumia safu ya TICK, isiyo ya kawaida, na Grafan kama kiolesura cha wavuti.
Sitaelezea utendakazi wake; kila mtu anajua uwezekano wake mpana wa kusanidi chochote.

Hata hivyo, Grafana bado ni chombo cha ulimwengu wote, ilhali Chronograf imeundwa hasa kwa matumizi na Influx.

Na kwa kweli, shukrani kwa hili, Chronograf inaweza kumudu utendaji wa busara zaidi au rahisi.

Labda manufaa kuu ya kufanya kazi na Chronograf ni kwamba unaweza kutazama mambo ya ndani ya InfluxDB yako kupitia Gundua.

Inaweza kuonekana kuwa Grafana ina utendakazi karibu sawa, lakini kwa ukweli, kusanidi dashibodi katika Chronograf kunaweza kufanywa kwa kubofya mara chache kwa panya (wakati huo huo ukiangalia taswira hapo), wakati huko Grafana bado utakuwa na mapema au baadaye. ili kuhariri usanidi wa JSON (bila shaka Chronograf inaruhusu kupakia dasha zako zilizosanidiwa kwa mkono na kuzihariri kama JSON ikihitajika - lakini sikuwahi kuzigusa baada ya kuziunda kwenye Kiolesura).

Kibana ana uwezo mkubwa zaidi wa kuunda dashibodi na vidhibiti kwao, lakini UX ya shughuli kama hizo ni ngumu sana.

Itachukua uelewa mzuri kuunda dashibodi inayofaa. Na ingawa utendakazi wa dashibodi za Chronograf ni mdogo, kuzitengeneza na kubinafsisha ni rahisi zaidi.

Dashibodi zenyewe, mbali na mtindo wa kupendeza wa kuona, kwa kweli hazina tofauti na dashibodi za Grafana au Kibana:

Hivi ndivyo dirisha la swali linavyoonekana:

Ni muhimu kutambua, miongoni mwa mambo mengine, kwamba kujua aina za sehemu katika hifadhidata ya InfluxDB, kronografu yenyewe wakati mwingine inaweza kukusaidia kiatomati kwa kuandika Hoja au kuchagua chaguo sahihi la kukokotoa kama wastani.

Na bila shaka, Chronograf ni rahisi iwezekanavyo kwa kutazama kumbukumbu. Inaonekana kama hii:

Kwa chaguo-msingi, kumbukumbu za Utitiri zimeundwa ili kutumia syslog na kwa hivyo zina kigezo muhimu - ukali.

Grafu iliyo hapo juu ni muhimu sana; juu yake unaweza kuona makosa yanayotokea na rangi inaonyesha wazi mara moja ikiwa ukali ni mkubwa zaidi.

Mara kadhaa tulinasa hitilafu muhimu kwa njia hii, tukienda kutazama kumbukumbu za wiki iliyopita na kuona spike nyekundu.

Kwa kweli, kwa kweli itakuwa kuanzisha arifa za makosa kama haya, kwani tayari tulikuwa na kila kitu kwa hili.

Tuliwasha hii kwa muda, lakini katika mchakato wa kuandaa majaribio ilibainika kuwa tulikuwa tukipata makosa mengi (pamoja na yale ya mfumo kama kutopatikana kwa mtandao wa LTE), ambayo "ilituma barua taka" kwenye kituo cha Slack pia. nyingi, bila kusababisha matatizo yoyote faida kubwa.

Suluhisho sahihi litakuwa kushughulikia zaidi ya aina hizi za makosa, kurekebisha ukali kwao, na kisha tu kuwezesha tahadhari.

Kwa njia hii, ni makosa mapya au muhimu pekee yangetumwa kwa Slack. Hakukuwa na wakati wa kutosha wa usanidi kama huo kutokana na muda uliowekwa.

Uthibitishaji

Inafaa pia kutaja kuwa Chronograf inasaidia OAuth na OIDC kama uthibitishaji.

Hii ni rahisi sana, kwani hukuruhusu kuiunganisha kwa urahisi kwenye seva yako na kuunda SSO kamili.

Kwa upande wetu, seva ilikuwa Nguo ya funguo - ilitumiwa kuunganishwa na ufuatiliaji, lakini seva hiyo hiyo pia ilitumiwa kuthibitisha scooters na maombi kwenye sehemu ya nyuma.

“Msimamizi”

Kipengele cha mwisho nitakachoeleza ni "jopo la msimamizi" tulilojiandikia katika Vue.
Kimsingi ni huduma ya pekee inayoonyesha maelezo ya skuta kutoka hifadhidata zetu wenyewe, huduma ndogo ndogo na data ya vipimo kutoka kwa InfluxDB kwa wakati mmoja.

Aidha, vipengele vingi vya utendakazi vya usimamizi vilihamishiwa hapo, kama vile kuwasha tena dharura au kufungua kufuli kwa timu ya usaidizi kwa mbali.

Pia kulikuwa na ramani. Tayari nilitaja kuwa tulianza na Grafana badala ya Chronograf - kwa sababu kwa Grafana ramani zinapatikana katika mfumo wa programu-jalizi, ambazo tunaweza kutazama kuratibu za scooters. Kwa bahati mbaya, uwezo wa vilivyoandikwa vya ramani kwa Grafana ni mdogo sana, na kwa sababu hiyo, ilikuwa rahisi zaidi kuandika programu yako ya wavuti na ramani katika siku chache, ili sio tu kuona kuratibu kwa sasa, lakini pia kuonyesha. njia iliyochukuliwa na skuta, kuwa na uwezo wa kuchuja data kwenye ramani, n.k. (utendaji wote huo ambao hatukuweza kusanidi katika dashibodi rahisi).

Mojawapo ya faida zilizotajwa tayari za Utitiri ni uwezo wa kuunda metriki zako mwenyewe kwa urahisi.
Hii inaruhusu kutumika kwa aina kubwa ya matukio.

Tulijaribu kurekodi maelezo yote muhimu hapo: chaji ya betri, hali ya kufuli, utendaji wa kihisi, bluetooth, GPS, na ukaguzi mwingine mwingi wa afya.
Tulionyesha haya yote kwenye paneli ya msimamizi.

Kwa kweli, kigezo muhimu zaidi kwetu kilikuwa hali ya kufanya kazi ya skuta - kwa kweli, Influx huangalia hii yenyewe na kuionyesha na "taa za kijani" kwenye sehemu ya Nodi.

Hii inafanywa na kazi mtu aliyekufa - tuliitumia kuelewa utendakazi wa kisanduku chetu na kutuma arifa hizo hizo kwa Slack.

Kwa njia, tuliita scooters baada ya majina ya wahusika kutoka The Simpsons - ilikuwa rahisi sana kuwatofautisha kutoka kwa kila mmoja.

Na kwa ujumla ilikuwa ya kufurahisha zaidi kwa njia hii. Maneno kama "Guys, Smithers amekufa!" yalisikika kila mara.

Vipimo vya kamba

Ni muhimu InfluxDB ikuruhusu kuhifadhi sio tu nambari za nambari, kama ilivyo kwa Victoria Metrics.

Inaweza kuonekana kuwa hii sio muhimu sana - baada ya yote, mbali na magogo, metrics yoyote inaweza kuhifadhiwa kwa namna ya nambari (ongeza tu ramani kwa majimbo inayojulikana - aina ya enum)?

Kwa upande wetu, kulikuwa na angalau hali moja ambapo vipimo vya kamba vilikuwa muhimu sana.
Ilifanyika tu kwamba mtoa huduma wa "chaja mahiri" alikuwa mtu wa tatu, hatukuwa na udhibiti wa mchakato wa uundaji na maelezo ambayo chaja hizi zinaweza kutoa.

Kama matokeo, API ya malipo ilikuwa mbali na bora, lakini shida kuu ilikuwa kwamba hatukuweza kuelewa hali yao kila wakati.

Hapa ndipo Utitiri ulikuja kuwaokoa. Tuliandika tu hali ya kamba iliyotujia kwenye uwanja wa hifadhidata wa InfluxDB bila mabadiliko.

Kwa muda, ni thamani tu kama vile "mtandaoni" na "nje ya mtandao" zilifika hapo, kulingana na maelezo ambayo yalionyeshwa kwenye paneli yetu ya wasimamizi, na arifa zilitumwa kwa Slack. Walakini, wakati fulani, maadili kama "kukataliwa" pia yalianza kuonekana hapo.

Kama ilivyotokea baadaye, hali hii ilitumwa mara moja baada ya kupoteza muunganisho, ikiwa chaja haikuweza kuanzisha muunganisho na seva baada ya idadi fulani ya majaribio.

Kwa hivyo, ikiwa tungetumia seti maalum ya maadili, hatuwezi kuona mabadiliko haya kwenye programu dhibiti kwa wakati ufaao.

Na kwa ujumla, vipimo vya kamba hutoa uwezekano zaidi wa matumizi; unaweza kurekodi karibu habari yoyote ndani yao. Ingawa, bila shaka, unahitaji pia kutumia chombo hiki kwa makini.

Kando na vipimo vya kawaida, pia tulirekodi maelezo ya eneo la GPS katika InfluxDB. Hii ilikuwa muhimu sana kwa ufuatiliaji wa eneo la scooters kwenye paneli yetu ya msimamizi.
Kwa kweli, kila wakati tulijua wapi na ni skuta gani wakati tuliohitaji.

Hii ilikuwa muhimu sana kwetu tulipokuwa tunatafuta skuta (angalia hitimisho mwishoni).

Ufuatiliaji wa miundombinu

Mbali na pikipiki zenyewe, tulihitaji pia kufuatilia miundombinu yetu yote (badala ya kina).

Usanifu wa jumla sana ulionekana kama hii:

Ikiwa tutaangazia safu safi ya ufuatiliaji, inaonekana kama hii:

Tunachotaka kuangalia kwenye wingu ni:

• Takwimu
• Nguo ya funguo
• Huduma ndogo ndogo

Kwa kuwa huduma zetu zote za wingu ziko Kubernetes, itakuwa nzuri kukusanya habari kuhusu hali yake.

Kwa bahati nzuri, Telegraf nje ya boksi inaweza kukusanya idadi kubwa ya vipimo kuhusu hali ya nguzo ya Kubernetes, na Chronograf mara moja hutoa dashibodi nzuri kwa hili.

Tulifuatilia sana utendaji wa maganda na utumiaji wa kumbukumbu. Ikitokea kuanguka, arifa katika Slack.

Kuna njia mbili za kufuatilia maganda katika Kubernetes: DaemonSet na Sidecar.
Njia zote mbili zimeelezewa kwa kina katika chapisho hili la blogi.

Tulitumia Telegraf Sidecar na, pamoja na metriki, tulikusanya kumbukumbu za maganda.

Kwa upande wetu, tulilazimika kuchezea magogo. Licha ya ukweli kwamba Telegraf inaweza kuvuta kumbukumbu kutoka kwa API ya Docker, tulitaka kuwa na mkusanyiko sare wa kumbukumbu na vifaa vyetu vya mwisho na kusanidi syslog kwa vyombo kwa hili. Labda suluhisho hili halikuwa nzuri, lakini hapakuwa na malalamiko juu ya kazi yake na magogo yalionyeshwa vizuri katika Chronograf.

Kufuatilia ufuatiliaji???

Mwishowe, swali la zamani la mifumo ya ufuatiliaji wa ufuatiliaji liliibuka, lakini kwa bahati nzuri, au kwa bahati mbaya, hatukuwa na wakati wa kutosha kwa hili.

Ingawa Telegraf inaweza kutuma vipimo vyake yenyewe kwa urahisi au kukusanya vipimo kutoka kwa hifadhidata ya InfluxDB kwa kutuma kwa Utitiri sawa au mahali pengine.

Matokeo

Je, ni hitimisho gani tulilopata kutokana na matokeo ya majaribio?

Unawezaje kufanya ufuatiliaji?

Kwanza kabisa, safu ya TICK ilikidhi matarajio yetu kikamilifu na ilitupa fursa zaidi ya ile tuliyotarajia mwanzoni.

Utendaji wote tuliohitaji ulikuwepo. Kila kitu tulichofanya nacho kilifanya kazi bila shida.

Uzalishaji

Tatizo kuu la TICK stack katika toleo la bure ni ukosefu wa uwezo wa kuongeza. Hili halikuwa tatizo kwetu.

Hatukukusanya data/takwimu kamili za upakiaji, lakini tulikusanya data kutoka kwa skuta 30 kwa wakati mmoja.

Kila mmoja wao alikusanya zaidi ya dazeni tatu za metriki. Wakati huo huo, kumbukumbu kutoka kwa vifaa zilikusanywa. Ukusanyaji na utumaji wa data ulifanyika kila sekunde 10.

Ni muhimu kutambua kwamba baada ya wiki moja na nusu ya majaribio, wakati wingi wa "vidonda vya utoto" vilirekebishwa na matatizo muhimu zaidi yalikuwa yametatuliwa, tulipaswa kupunguza mzunguko wa kutuma data kwa seva. Sekunde 30. Hii ikawa muhimu kwa sababu trafiki kwenye SIM kadi zetu za LTE ilianza kutoweka haraka.

Wingi wa trafiki ulitumiwa na kumbukumbu; vipimo vyenyewe, hata kwa muda wa sekunde 10, kwa kweli havikupoteza.

Matokeo yake, baada ya muda tulizima kabisa mkusanyiko wa magogo kwenye vifaa, kwani matatizo maalum yalikuwa tayari dhahiri hata bila mkusanyiko wa mara kwa mara.

Katika baadhi ya matukio, ikiwa kutazama kumbukumbu bado ilikuwa muhimu, tuliunganisha tu kupitia WireGuard kupitia VPN.

Pia nitaongeza kuwa kila mazingira tofauti yalitengwa kutoka kwa kila mmoja, na mzigo ulioelezwa hapo juu ulikuwa muhimu tu kwa mazingira ya uzalishaji.

Katika mazingira ya usanidi, tulianzisha mfano tofauti wa InfluxDB ambao uliendelea kukusanya data kila baada ya sekunde 10 na hatukukumbana na matatizo yoyote ya utendakazi.

TICK - bora kwa miradi midogo na ya kati

Kulingana na maelezo haya, ningehitimisha kuwa mkusanyiko wa TICK ni bora kwa miradi midogo au miradi ambayo kwa hakika haitarajii Mzigo Mkuu wowote.

Ikiwa huna maelfu ya maganda au mamia ya mashine, hata mfano mmoja wa InfluxDB utashughulikia mzigo vizuri.

Katika baadhi ya matukio, unaweza kuridhishwa na Relay ya Kuingia kwa wingi kama suluhisho la awali la Upatikanaji wa Juu.

Na, bila shaka, hakuna mtu anayekuzuia kuweka kiwango cha "wima" na kutenga seva tofauti kwa aina tofauti za vipimo.

Ikiwa huna uhakika kuhusu mzigo unaotarajiwa kwenye huduma za ufuatiliaji, au umehakikishiwa kuwa na / utakuwa na usanifu "nzito" sana, singependekeza kutumia toleo la bure la stack ya TICK.

Bila shaka, suluhisho rahisi itakuwa kununua Biashara ya InfluxDB - lakini hapa siwezi kutoa maoni kwa njia fulani, kwani mimi mwenyewe sijui hila. Licha ya ukweli kwamba ni ghali sana na dhahiri haifai kwa makampuni madogo.

Katika hali hii, leo, ningependekeza tuangalie jinsi ya kukusanya vipimo kupitia Victoria Metrics na kumbukumbu kwa kutumia Loki.

Ni kweli, nitahifadhi tena kuwa Loki/Grafana ni rahisi sana (kutokana na uchangamano wao) kuliko TICK iliyotengenezwa tayari, lakini ni bure.

Ni muhimu: maelezo yote yaliyofafanuliwa hapa yanafaa kwa toleo la Influx 1.8, kwa sasa Influx 2.0 inakaribia kutolewa.

Ingawa sijapata nafasi ya kuijaribu katika hali ya mapigano na ni ngumu kufikia hitimisho juu ya maboresho, kiolesura hakika kimekuwa bora zaidi, usanifu umerahisishwa (bila kapacitor na chronograf),
templeti zilionekana ("kipengele cha muuaji" - unaweza kufuatilia wachezaji katika Fortnite na kupokea arifa mchezaji unayempenda anaposhinda mchezo) Lakini, kwa bahati mbaya, kwa sasa, toleo la 2 halina jambo muhimu ambalo tulichagua toleo la kwanza - hakuna mkusanyiko wa logi.

Utendaji huu pia utaonekana katika Influx 2.0, lakini hatukuweza kupata makataa yoyote, hata yale yaliyokadiriwa.

Jinsi ya kutotengeneza majukwaa ya IoT (sasa)

Mwishowe, baada ya kuzindua majaribio, sisi wenyewe tulikusanya safu yetu kamili ya IoT, bila kukosekana kwa njia mbadala inayofaa kwa viwango vyetu.

Walakini, inapatikana hivi karibuni katika toleo la Beta OpenBalena - inasikitisha kuwa hakuwepo wakati tunaanza kutengeneza mradi.

Tumeridhishwa kabisa na matokeo ya mwisho na jukwaa kulingana na Ansible + TICK + WireGuard ambayo tulijikusanya wenyewe. Lakini leo, ningependekeza uangalie kwa karibu Balena kabla ya kujaribu kujenga jukwaa lako la IoT mwenyewe.

Kwa sababu hatimaye inaweza kufanya mengi ya yale tuliyofanya, na OpenBalena ni chanzo cha bure na wazi.

Tayari inajua jinsi ya sio tu kutuma sasisho, lakini pia VPN tayari imejengwa ndani na iliyoundwa kwa matumizi katika mazingira ya IoT.

Na hivi majuzi, hata walitoa yao vifaa vya ujenzi, ambayo inaunganishwa kwa urahisi na mfumo wao wa ikolojia.

Halo, vipi kuhusu skuta iliyokosekana?

Kwa hivyo pikipiki, "Ralph", ikatoweka bila kuwaeleza.

Mara moja tulikimbia kuangalia ramani katika "paneli yetu ya msimamizi", na data ya vipimo vya GPS kutoka InfluxDB.

Shukrani kwa data ya ufuatiliaji, tuliamua kwa urahisi kuwa skuta iliondoka kwenye maegesho mwendo wa saa 21:00 siku iliyopita, ikaendesha kwa takriban nusu saa hadi eneo fulani na iliegeshwa hadi saa 5 asubuhi karibu na nyumba fulani ya Wajerumani.

Baada ya saa 5 asubuhi, hakuna data ya ufuatiliaji iliyopokelewa-hii ilimaanisha kuwa betri ya ziada ilitolewa kabisa, au mshambuliaji hatimaye alifikiria jinsi ya kuondoa maunzi mahiri kutoka kwa skuta.
Pamoja na hayo, polisi bado waliitwa kwenye anwani ilipokuwa pikipiki hiyo. Pikipiki haikuwepo.

Walakini, mmiliki wa nyumba hiyo pia alishangazwa na hii, kwani kwa kweli alipanda pikipiki hii nyumbani kutoka ofisini jana usiku.

Ikawa, mmoja wa wafanyikazi wa usaidizi alifika asubuhi na mapema na kuchukua skuta, akiona kuwa betri yake ya ziada ilikuwa imetolewa kabisa na kuipeleka (kwa miguu) kwenye kura ya maegesho. Na betri ya ziada ilishindwa kutokana na unyevu.

Tuliiba skuta kutoka kwetu. Kwa njia, sijui jinsi na ni nani aliyesuluhisha suala hilo na kesi ya polisi, lakini ufuatiliaji ulifanya kazi kikamilifu ...

Chanzo: mapenzi.com