Kembalikan skuter yang hilang, atau kisah satu pemantauan IoT

Setahun yang lalu kami melancarkan versi perintis projek promosi untuk penyewaan skuter elektrik yang terdesentralisasi.

Pada mulanya, projek itu dipanggil Road-To-Barcelona, ​​​​kemudian ia menjadi Road-To-Berlin (oleh itu R2B dalam tangkapan skrin), dan pada akhirnya ia dipanggil xRide.

Idea utama projek ini ialah: daripada mempunyai perkhidmatan penyewaan kereta atau skuter berpusat (kita bercakap tentang skuter aka motosikal elektrik, bukan skuter/skuter) kami ingin membuat platform untuk penyewaan terpencar. Tentang kesulitan yang kami hadapi dah tulis tadi.

Pada mulanya, projek itu memberi tumpuan kepada kereta, tetapi disebabkan tarikh akhir, komunikasi yang sangat panjang dengan pengeluar dan sejumlah besar sekatan keselamatan, skuter elektrik dipilih untuk juruterbang.

Pengguna memasang aplikasi iOS atau Android pada telefon, menghampiri skuter yang disukainya, selepas itu telefon dan skuter mewujudkan sambungan peer-to-peer, ETH telah ditukar dan pengguna boleh memulakan perjalanan dengan menghidupkan skuter melalui telefon itu. Pada penghujung perjalanan, anda juga boleh membayar perjalanan menggunakan Ethereum daripada dompet pengguna di telefon.

Selain skuter, pengguna melihat "pengecas pintar" dalam aplikasi, dengan melawati yang mana pengguna boleh menukar sendiri bateri semasa jika ia rendah.

Ini secara amnya rupa juruterbang kami, yang dilancarkan pada September tahun lalu di dua bandar Jerman: Bonn dan Berlin.

Dan kemudian, pada suatu hari, di Bonn, pada awal pagi, pasukan sokongan kami (terletak di tapak untuk mengekalkan skuter dalam keadaan berfungsi) telah dimaklumkan: salah satu skuter telah hilang tanpa jejak.

Bagaimana untuk mencari dan mengembalikannya?

Dalam artikel ini saya akan bercakap tentang perkara ini, tetapi pertama - tentang cara kami membina platform IoT kami sendiri dan cara kami memantaunya.

Apakah dan mengapa perlu dipantau: skuter, infrastruktur, stesen pengecasan?

Jadi, apakah yang kami mahu pantau dalam projek kami?

Pertama sekali, ini adalah skuter itu sendiri - skuter elektrik sendiri agak mahal, anda tidak boleh melancarkan projek sedemikian tanpa cukup bersedia; jika boleh, anda ingin mengumpul sebanyak mungkin maklumat tentang skuter: tentang lokasi mereka, tahap caj , dan lain-lain.

Di samping itu, saya ingin memantau keadaan infrastruktur IT kita sendiri - pangkalan data, perkhidmatan dan semua yang mereka perlukan untuk berfungsi. Ia juga perlu untuk memantau status "pengecas pintar", sekiranya ia rosak atau kehabisan bateri penuh.

Skuter

Apakah skuter kami dan apakah yang kami ingin ketahui tentang mereka?

Perkara pertama dan paling penting ialah koordinat GPS, kerana terima kasih kepada mereka kita dapat memahami di mana mereka berada dan di mana mereka bergerak.

Seterusnya ialah pengecasan bateri, yang mana kita boleh menentukan bahawa pengecasan skuter akan berakhir dan menghantar pemerah jus atau sekurang-kurangnya memberi amaran kepada pengguna.

Sudah tentu, anda juga perlu menyemak perkara yang berlaku dengan komponen Perkakasan kami:

• adakah bluetooth berfungsi?
• adakah modul GPS itu sendiri berfungsi?
  • Kami juga menghadapi masalah dengan hakikat bahawa GPS boleh menghantar koordinat yang salah dan tersekat, dan ini hanya boleh ditentukan dengan pemeriksaan tambahan pada skuter,
    dan maklumkan sokongan secepat mungkin untuk menyelesaikan isu tersebut

Dan terakhir: semakan perisian, bermula dengan OS dan pemproses, rangkaian dan beban cakera, berakhir dengan semakan modul kami sendiri yang lebih khusus kepada kami (Jolocom, Jubah kunci).

perkakasan

Apakah bahagian "besi" kami?

Dengan mengambil kira tempoh masa yang sesingkat mungkin dan keperluan untuk prototaip pantas, kami memilih pilihan termudah untuk pelaksanaan dan pemilihan komponen - Raspberry Pi.
Sebagai tambahan kepada Rpi itu sendiri, kami mempunyai papan tersuai (yang kami sendiri bangunkan dan pesan dari China untuk mempercepatkan proses pemasangan penyelesaian akhir) dan satu set komponen - geganti (untuk menghidupkan/mematikan skuter), pembaca cas bateri, modem, antena. Semua ini dibungkus padat dalam "kotak xRide" khas.

Ia juga harus diperhatikan bahawa keseluruhan kotak dikuasakan oleh bank kuasa tambahan, yang seterusnya dikuasakan oleh bateri utama skuter.

Ini memungkinkan untuk menggunakan pemantauan dan menghidupkan skuter walaupun selepas tamat perjalanan, kerana bateri utama dimatikan serta-merta selepas menghidupkan kunci pencucuhan ke kedudukan "mati".

Docker? Linux biasa? dan penempatan

Mari kita kembali kepada pemantauan, jadi Raspberry - apa yang kita ada?

Salah satu perkara pertama yang kami mahu gunakan untuk mempercepatkan proses mengatur, mengemas kini dan menghantar komponen ke peranti fizikal ialah Docker.

Malangnya, ia dengan cepat menjadi jelas bahawa Docker pada RPi, walaupun ia berfungsi, mempunyai banyak overhed, terutamanya dari segi penggunaan kuasa.

Perbezaan menggunakan OS "asli", walaupun tidak begitu kuat, masih mencukupi untuk kami berwaspada dengan kemungkinan kehilangan caj terlalu cepat.

Sebab kedua ialah salah satu perpustakaan rakan kongsi kami di Node.js (sic!) - satu-satunya komponen sistem yang tidak ditulis dalam Go/C/C++.

Pengarang perpustakaan tidak mempunyai masa untuk menyediakan versi yang berfungsi dalam mana-mana bahasa "asli".

Bukan sahaja nod itu sendiri bukan penyelesaian yang paling elegan untuk peranti berprestasi rendah, tetapi perpustakaan itu sendiri sangat haus sumber.

Kami menyedari bahawa, walaupun kami mahu, menggunakan Docker akan menjadi terlalu mahal untuk kami. Pilihan dibuat memihak kepada OS asli dan berfungsi secara langsung di bawahnya.

OS

Akibatnya, kami, sekali lagi, memilih pilihan paling mudah sebagai OS dan menggunakan Raspbian (binaan Debian untuk Pi).

Kami menulis semua perisian kami dalam Go, jadi kami juga menulis modul ejen perkakasan utama dalam sistem kami dalam Go.

Dialah yang bertanggungjawab untuk bekerja dengan GPS, Bluetooth, membaca caj, menghidupkan skuter, dll.

Sebarkan

Persoalan segera timbul tentang keperluan untuk melaksanakan mekanisme untuk menyampaikan kemas kini kepada peranti (OTA) - kedua-dua kemas kini kepada ejen/aplikasi kami sendiri dan kemas kini kepada OS/perisian tegar itu sendiri (kerana versi baharu ejen mungkin memerlukan kemas kini pada kernel atau komponen sistem, perpustakaan, dsb.) .

Selepas analisis pasaran yang agak panjang, ternyata terdapat banyak penyelesaian untuk menyampaikan kemas kini kepada peranti.

Daripada yang agak mudah, kebanyakannya utiliti berorientasikan kemas kini/dwi-but seperti swupd/SWUpdate/OSTree kepada platform lengkap seperti Mender dan Balena.

Pertama sekali, kami memutuskan bahawa kami berminat dengan penyelesaian hujung ke hujung, jadi pilihan segera jatuh pada platform.

Yang sangat Balena telah dikecualikan kerana fakta bahawa ia sebenarnya menggunakan Docker yang sama di dalam balenaEnginenya.

Tetapi saya perhatikan bahawa walaupun ini, kami akhirnya sentiasa menggunakan produk mereka Balena Etcher untuk perisian tegar kilat pada kad SD - utiliti yang mudah dan sangat mudah untuk ini.

Oleh itu, pada akhirnya pilihan jatuh pada Lembut. Mender ialah platform lengkap untuk memasang, menghantar dan memasang perisian tegar.

Secara keseluruhannya platform ini kelihatan hebat, tetapi kami mengambil masa kira-kira satu setengah minggu untuk membina versi perisian tegar kami yang betul menggunakan pembina mender.
Dan semakin kita melibatkan diri dalam selok-belok penggunaannya, semakin jelas bahawa untuk menggunakannya sepenuhnya kita memerlukan lebih banyak masa daripada yang kita ada.

Malangnya, tarikh akhir kami yang ketat bermakna kami terpaksa meninggalkan penggunaan Mender dan memilih yang lebih mudah.

Ansible

Penyelesaian paling mudah dalam situasi kami ialah menggunakan Ansible. Beberapa buku permainan sudah cukup untuk bermula.

Intipatinya ialah kami hanya menyambung dari hos (pelayan CI) melalui ssh ke rasberi kami dan mengedarkan kemas kini kepada mereka.

Pada mulanya, segala-galanya adalah mudah - anda perlu berada pada rangkaian yang sama dengan peranti, menuangkan dilakukan melalui Wi-Fi.

Di pejabat terdapat hanya sedozen raspberi ujian yang disambungkan ke rangkaian yang sama, setiap peranti mempunyai alamat IP statik yang juga dinyatakan dalam Inventori Ansible.

Ia adalah Ansible yang menghantar ejen pemantauan kami ke peranti akhir

3G / LTE

Malangnya, kes penggunaan untuk Ansible ini hanya boleh berfungsi dalam mod pembangunan sebelum kami mempunyai skuter sebenar.

Kerana skuter, seperti yang anda faham, tidak duduk disambungkan ke satu penghala Wi-Fi, sentiasa menunggu kemas kini melalui rangkaian.

Pada hakikatnya, skuter tidak boleh mempunyai sebarang sambungan sama sekali selain daripada 3G/LTE mudah alih (dan itupun tidak sepanjang masa).

Ini serta-merta mengenakan banyak masalah dan batasan, seperti kelajuan sambungan yang rendah dan komunikasi yang tidak stabil.

Tetapi perkara yang paling penting ialah dalam rangkaian 3G/LTE kita tidak boleh hanya bergantung pada IP statik yang diberikan kepada rangkaian.

Ini sebahagiannya diselesaikan oleh beberapa pembekal kad SIM; malah terdapat kad SIM khas yang direka untuk peranti IoT dengan alamat IP statik. Tetapi kami tidak mempunyai akses kepada kad SIM sedemikian dan tidak boleh menggunakan alamat IP.

Sudah tentu, terdapat idea untuk melakukan beberapa jenis pendaftaran alamat IP atau penemuan perkhidmatan di suatu tempat seperti Konsul, tetapi kami terpaksa meninggalkan idea sedemikian, kerana dalam ujian kami alamat IP boleh berubah terlalu kerap, yang membawa kepada ketidakstabilan yang besar.

Atas sebab ini, penggunaan yang paling mudah untuk menyampaikan metrik tidak akan menggunakan model tarik, di mana kita akan pergi ke peranti untuk metrik yang diperlukan, tetapi menolak, menghantar metrik daripada peranti terus ke pelayan

VPN

Sebagai penyelesaian kepada masalah ini, kami memilih VPN - khususnya Pengawal Wire.

Pelanggan (skuter) pada permulaan sistem disambungkan ke pelayan VPN dan dapat menyambung kepada mereka. Terowong ini digunakan untuk menyampaikan kemas kini.

Secara teorinya, terowong yang sama boleh digunakan untuk pemantauan, tetapi sambungan sedemikian adalah lebih rumit dan kurang dipercayai daripada tolakan mudah.

Sumber awan

Akhir sekali, adalah perlu untuk memantau perkhidmatan awan dan pangkalan data kami, kerana kami menggunakan Kubernetes untuk mereka, sebaik-baiknya supaya penggunaan pemantauan dalam kluster semudah mungkin. Sebaik-baiknya, menggunakan Helm, kerana untuk penggunaan, kami menggunakannya dalam kebanyakan kes. Dan, sudah tentu, untuk memantau awan anda perlu menggunakan penyelesaian yang sama seperti untuk skuter itu sendiri.

Diberi

Fuh, kami nampaknya telah menyusun huraian, mari buat senarai apa yang kami perlukan pada akhirnya:

• Penyelesaian yang cepat, kerana pemantauan diperlukan semasa proses pembangunan
• Kelantangan/kuantiti – banyak metrik diperlukan
• Pengumpulan log diperlukan
• Kebolehpercayaan - data adalah penting untuk melancarkan kejayaan
• Anda tidak boleh menggunakan model tarik - anda perlu menolak
• Kami memerlukan pemantauan bersepadu bukan sahaja perkakasan, tetapi juga awan

Imej akhir kelihatan seperti ini

Pemilihan timbunan

Jadi, kami berhadapan dengan persoalan memilih timbunan pemantauan.

Pertama sekali, kami sedang mencari penyelesaian semua-dalam-satu yang paling lengkap yang akan merangkumi semua keperluan kami secara serentak, tetapi pada masa yang sama cukup fleksibel untuk menyesuaikan penggunaannya mengikut keperluan kami. Namun, kami mempunyai banyak sekatan yang dikenakan ke atas kami oleh perkakasan, seni bina dan tarikh akhir.

Terdapat pelbagai jenis penyelesaian pemantauan, bermula dengan sistem lengkap seperti Nagios, icinga atau zabbix dan berakhir dengan penyelesaian sedia untuk pengurusan Armada.

Pada mulanya, yang kedua kelihatan seperti penyelesaian yang ideal untuk kami, tetapi sesetengahnya tidak mempunyai pemantauan penuh, yang lain mempunyai keupayaan yang sangat terhad untuk versi percuma, dan yang lain hanya tidak memenuhi "kehendak" kami atau tidak cukup fleksibel untuk menyesuaikan senario kami. Ada yang sudah ketinggalan zaman.

Selepas menganalisis beberapa penyelesaian yang serupa, kami dengan cepat membuat kesimpulan bahawa lebih mudah dan lebih cepat untuk memasang sendiri timbunan serupa. Ya, ia akan menjadi sedikit lebih rumit daripada menggunakan platform pengurusan Armada yang telah siap sepenuhnya, tetapi kami tidak perlu membuat kompromi.

Hampir pasti, dalam semua kelimpahan penyelesaian yang banyak, sudah ada penyelesaian siap yang benar-benar sesuai dengan kita, tetapi dalam kes kami, lebih cepat untuk memasang timbunan tertentu sendiri dan menyesuaikannya "untuk diri kita sendiri" daripada menguji produk siap pakai.

Dengan semua ini, kami tidak berusaha untuk memasang sendiri keseluruhan platform pemantauan, tetapi sedang mencari tindanan "siap sedia" yang paling berfungsi, hanya dengan keupayaan untuk mengkonfigurasinya secara fleksibel.

(B)ELK?

Penyelesaian pertama yang sebenarnya dipertimbangkan ialah timbunan ELK yang terkenal.
Malah, ia sepatutnya dipanggil BELK, kerana semuanya bermula dengan Beats - https://www.elastic.co/what-is/elk-stack

Sudah tentu, ELK adalah salah satu penyelesaian yang paling terkenal dan berkuasa dalam bidang pemantauan, dan lebih-lebih lagi dalam mengumpul dan memproses log.

Kami berhasrat bahawa ELK akan digunakan untuk mengumpul log dan serta penyimpanan jangka panjang metrik yang diperoleh daripada Prometheus.

Untuk visualisasi anda boleh menggunakan Grafan.

Malah, tindanan ELK baharu boleh mengumpul metrik secara bebas (metricbeat), dan Kibana juga boleh memaparkannya.

Namun begitu, ELK pada mulanya berkembang daripada log dan setakat ini kefungsian metrik mempunyai beberapa kelemahan yang serius:

• Lebih perlahan daripada Prometheus
• Bersepadu ke tempat yang jauh lebih sedikit daripada Prometheus
• Sukar untuk menyediakan makluman untuk mereka
• Metrik mengambil banyak ruang
• Menyediakan papan pemuka dengan metrik di Kiban adalah lebih rumit daripada di Grafan

Secara umum, metrik dalam ELK adalah berat dan belum lagi semudah dalam penyelesaian lain, yang kini terdapat lebih daripada sekadar Prometheus: TSDB, Victoria Metrics, Cortex, dsb., dsb. Sudah tentu, saya benar-benar ingin mendapatkan penyelesaian menyeluruh sepenuhnya dengan segera, tetapi dalam kes metricbeat terdapat terlalu banyak kompromi.

Dan timbunan ELK itu sendiri mempunyai beberapa detik sukar:

• Ia berat, kadang-kadang sangat berat jika anda mengumpul jumlah data yang agak besar
• Anda perlu "tahu cara memasak" - anda perlu mengukurnya, tetapi ini bukan perkara remeh untuk dilakukan
• Versi percuma yang dilucutkan - versi percuma tidak mempunyai amaran biasa, dan pada masa pemilihan tiada pengesahan

Saya mesti mengatakan bahawa baru-baru ini titik terakhir telah menjadi lebih baik dan sebagai tambahan output dalam X-pack sumber terbuka (termasuk pengesahan) model harga itu sendiri mula berubah.

Tetapi pada masa kami akan menggunakan penyelesaian ini, tiada amaran langsung.
Mungkin kami boleh cuba membina sesuatu menggunakan ElastAlert atau penyelesaian komuniti lain, tetapi kami masih memutuskan untuk mempertimbangkan alternatif lain.

Loki - Grafana - Prometheus

Pada masa ini, penyelesaian yang baik mungkin adalah membina timbunan pemantauan berdasarkan Prometheus semata-mata sebagai penyedia metrik, Loki untuk log, dan untuk visualisasi anda boleh menggunakan Grafana yang sama.

Malangnya, pada masa permulaan perintis jualan projek (September-Oktober 19), Loki masih dalam versi beta 0.3-0.4, dan pada masa permulaan pembangunan ia tidak boleh dianggap sebagai penyelesaian produk sama sekali.

Saya belum mempunyai pengalaman dalam menggunakan Loki dalam projek yang serius, tetapi saya boleh mengatakan bahawa Promtail (ejen untuk mengumpul log) berfungsi dengan baik untuk kedua-dua logam kosong dan pod dalam kubernetes.

TIKET

Mungkin alternatif berciri penuh yang paling layak (satu-satunya?) kepada timbunan ELK kini hanya boleh dipanggil timbunan TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.

Saya akan menerangkan semua komponen di bawah dengan lebih terperinci, tetapi idea umum adalah ini:

• Telegraf - ejen untuk mengumpul metrik
• InfluxDB - pangkalan data metrik
• Kapacitor - pemproses metrik masa nyata untuk memberi amaran
• Chronograf — веб панель для визуализации

Untuk InfluxDB, Kapacitor dan Chronograf terdapat carta pimpinan rasmi yang kami gunakan untuk menggunakan carta tersebut.

Perlu diingat bahawa dalam versi terkini Influx 2.0 (beta), Kapacitor dan Chronograf menjadi sebahagian daripada InfluxDB dan tidak lagi wujud secara berasingan

telegraf

telegraf ialah ejen yang sangat ringan untuk mengumpul metrik pada mesin keadaan.

Dia boleh memantau sejumlah besar segala-galanya, daripada nginx kepada
pelayan minecraft.

Ia mempunyai beberapa kelebihan hebat:

• Cepat dan ringan (ditulis dalam Go)
  • Makan jumlah minimum sumber
• Tolak metrik secara lalai
• Mengumpul semua metrik yang diperlukan
  • Metrik sistem tanpa sebarang tetapan
  • Metrik perkakasan seperti maklumat daripada penderia
  • Sangat mudah untuk menambah metrik anda sendiri
• Banyak pemalam di luar kotak
• Mengumpul log

Memandangkan metrik tolak diperlukan untuk kami, semua kelebihan lain adalah lebih daripada penambahan yang menyenangkan.

Pengumpulan log oleh ejen itu sendiri juga sangat mudah, kerana tidak perlu menyambungkan utiliti tambahan untuk log pembalakan.

Influx menawarkan pengalaman yang paling mudah untuk bekerja dengan log jika anda menggunakan syslog.

Telegraf biasanya merupakan ejen yang hebat untuk mengumpul metrik, walaupun anda tidak menggunakan baki ICK yang lain.

Ramai orang menyeberanginya dengan ELK dan pelbagai pangkalan data siri masa lain untuk kemudahan, kerana ia boleh menulis metrik hampir di mana-mana sahaja.

InfluxDB

InfluxDB ialah teras utama timbunan TICK, iaitu pangkalan data siri masa untuk metrik.
Sebagai tambahan kepada metrik, Influx juga boleh menyimpan log, walaupun, pada dasarnya, log untuknya hanyalah metrik yang sama, hanya sebagai ganti penunjuk berangka biasa, fungsi utama dijalankan oleh baris teks log.

InfluxDB juga ditulis dalam Go dan nampaknya berjalan lebih pantas berbanding ELK pada kelompok (bukan yang paling berkuasa) kami.

Salah satu kelebihan hebat Influx juga termasuk API yang sangat mudah dan kaya untuk pertanyaan data, yang kami gunakan dengan sangat aktif.

Kelemahan - $$$ atau penskalaan?

Tindanan TICK hanya mempunyai satu kelemahan yang kami temui - ia sayang. Lebih lagi.

Apakah versi berbayar yang tiada pada versi percuma?

Setakat yang kami dapat fahami, satu-satunya perbezaan antara versi berbayar timbunan TICK dan yang percuma ialah keupayaan penskalaan.

Iaitu, anda boleh menaikkan kluster dengan ketersediaan Tinggi hanya dalam Versi perusahaan.

Jika anda mahukan HA sepenuhnya, anda perlu membayar atau menggunakan beberapa tongkat. Terdapat beberapa penyelesaian komuniti - sebagai contoh influxdb-ha kelihatan seperti penyelesaian yang cekap, tetapi ia ditulis bahawa ia tidak sesuai untuk pengeluaran, serta
influx-spout - penyelesaian mudah dengan mengepam data melalui NATS (ia juga perlu diskalakan, tetapi ini boleh diselesaikan).

Sayang sekali, tetapi kedua-duanya seolah-olah ditinggalkan - tidak ada komitmen baru, saya menganggap bahawa isunya ialah keluaran versi baharu Influx 2.0 yang dijangka tidak lama lagi, di mana banyak perkara akan berbeza (tiada maklumat tentang skala di dalamnya lagi).

Secara rasmi terdapat versi percuma relay - sebenarnya, ini HA primitif, tetapi hanya melalui pengimbangan,
kerana semua data akan ditulis kepada semua kejadian InfluxDB di belakang pengimbang beban.
Dia ada beberapa kelemahan seperti potensi masalah dengan mata ganti dan keperluan untuk mencipta asas untuk metrik terlebih dahulu
(yang berlaku secara automatik semasa kerja biasa dengan InfluxDB).

Selain itu sharding tidak disokong, ini bermakna overhed tambahan untuk metrik pendua (kedua-dua pemprosesan dan storan) yang mungkin anda tidak perlukan, tetapi tiada cara untuk memisahkannya.

Victoria Metrics?

Akibatnya, walaupun pada hakikatnya kami berpuas hati sepenuhnya dengan timbunan TICK dalam segala-galanya selain penskalaan berbayar, kami memutuskan untuk melihat sama ada terdapat sebarang penyelesaian percuma yang boleh menggantikan pangkalan data InfluxDB, sambil meninggalkan komponen T_CK yang tinggal.

Terdapat banyak pangkalan data siri masa, tetapi yang paling menjanjikan ialah Victoria Metrics, ia mempunyai beberapa kelebihan:

• Cepat dan mudah, sekurang-kurangnya mengikut keputusan tanda aras
• Terdapat versi kluster, yang mana terdapat ulasan yang baik sekarang
  • Dia boleh serpihan
• Menyokong protokol InfluxDB

Kami tidak bercadang untuk membina tindanan tersuai sepenuhnya berdasarkan Victoria dan harapan utama ialah kami boleh menggunakannya sebagai pengganti drop-in untuk InfluxDB.

Malangnya, ini tidak mungkin, walaupun pada hakikatnya protokol InfluxDB disokong, ia hanya berfungsi untuk merekodkan metrik - hanya Prometheus API yang tersedia "di luar", yang bermaksud ia tidak mungkin untuk menetapkan Chronograf padanya.

Selain itu, hanya nilai angka yang disokong untuk metrik (kami menggunakan nilai rentetan untuk metrik tersuai - lebih lanjut mengenainya dalam bahagian kawasan admin).

Jelas sekali, atas sebab yang sama, VM tidak boleh menyimpan log seperti yang dilakukan oleh Influx.

Juga, perlu diperhatikan bahawa pada masa mencari penyelesaian optimum, Victoria Metrics belum begitu popular, dokumentasinya jauh lebih kecil dan fungsinya lebih lemah
(Saya tidak ingat penerangan terperinci tentang versi kluster dan sharding).

Pemilihan asas

Akibatnya, telah diputuskan bahawa untuk juruterbang kami masih akan mengehadkan diri kami kepada satu nod InfluxDB.

Terdapat beberapa sebab utama untuk pilihan ini:

• Kami sangat menyukai keseluruhan fungsi timbunan TICK
• Kami sudah berjaya menggunakannya dan ia berfungsi dengan baik
• Tarikh akhir hampir habis dan tidak banyak masa lagi untuk menguji pilihan lain.
• Kami tidak menjangkakan beban yang begitu berat

Kami tidak mempunyai banyak skuter untuk fasa pertama perintis, dan ujian semasa pembangunan tidak mendedahkan sebarang isu prestasi.

Oleh itu, kami memutuskan bahawa untuk projek ini satu nod Influx akan mencukupi untuk kami tanpa memerlukan penskalaan (lihat kesimpulan di penghujung).

Kami telah memutuskan timbunan dan pangkalan - kini mengenai baki komponen timbunan TICK.

Kapasitor

Kapacitor ialah sebahagian daripada timbunan TICK, perkhidmatan yang boleh memantau metrik yang memasuki pangkalan data dalam masa nyata dan melakukan pelbagai tindakan berdasarkan peraturan.

Secara umum, ia diletakkan sebagai alat untuk penjejakan anomali dan pembelajaran mesin yang berpotensi (saya tidak pasti bahawa fungsi ini dalam permintaan), tetapi kes penggunaannya yang paling popular adalah lebih biasa - memberi amaran.

Begitulah cara kami menggunakannya untuk pemberitahuan. Kami menyediakan makluman Slack apabila skuter tertentu pergi ke luar talian, dan perkara yang sama dilakukan untuk pengecas pintar dan komponen infrastruktur penting.

Ini membolehkan anda bertindak balas dengan cepat kepada masalah, serta menerima pemberitahuan bahawa semuanya kembali normal.

Contoh mudah: bateri tambahan untuk menghidupkan "kotak" kami telah rosak atau atas sebab tertentu telah kehabisan kuasa; hanya dengan memasang yang baharu, selepas beberapa ketika kami akan menerima pemberitahuan bahawa kefungsian skuter telah dipulihkan.

Dalam Influx 2.0 Kapacitor menjadi sebahagian daripada DB

Chronograph

Saya telah melihat banyak penyelesaian UI yang berbeza untuk pemantauan, tetapi saya boleh mengatakan bahawa dari segi fungsi dan UX, tiada apa yang setanding dengan Chronograf.

Kami mula menggunakan timbunan TICK, anehnya, dengan Grafan sebagai antara muka web.
Saya tidak akan menerangkan fungsinya; semua orang tahu kemungkinan luasnya untuk menyediakan apa-apa.

Walau bagaimanapun, Grafana masih merupakan instrumen universal sepenuhnya, manakala Chronograf direka terutamanya untuk digunakan dengan Influx.

Dan sudah tentu, terima kasih kepada ini, Chronograf mampu memiliki fungsi yang lebih bijak atau mudah.

Mungkin kemudahan utama bekerja dengan Chronograf ialah anda boleh melihat bahagian dalam InfluxDB anda melalui Explore.

Nampaknya Grafana mempunyai fungsi yang hampir sama, tetapi pada hakikatnya, menyediakan papan pemuka dalam Chronograf boleh dilakukan dengan beberapa klik tetikus (pada masa yang sama melihat visualisasi di sana), manakala dalam Grafana anda akan tetap mempunyai untuk mengedit konfigurasi JSON (sudah tentu Chronograf membenarkan muat naik dasha yang dikonfigurasikan tangan anda dan mengeditnya sebagai JSON jika perlu - tetapi saya tidak perlu menyentuhnya selepas menciptanya pada UI).

Kibana mempunyai keupayaan yang lebih kaya untuk mencipta papan pemuka dan kawalan untuknya, tetapi UX untuk operasi sedemikian adalah sangat kompleks.

Ia akan mengambil sedikit pemahaman yang baik untuk mencipta papan pemuka yang mudah. Dan walaupun kefungsian papan pemuka Chronograf adalah kurang, membuat dan menyesuaikannya adalah lebih mudah.

Papan pemuka itu sendiri, selain daripada gaya visual yang menarik, sebenarnya tidak berbeza dengan papan pemuka di Grafana atau Kibana:

Inilah rupa tetingkap pertanyaan:

Adalah penting untuk ambil perhatian, antara lain, bahawa mengetahui jenis medan dalam pangkalan data InfluxDB, kronograf itu sendiri kadangkala boleh membantu anda secara automatik dengan menulis Pertanyaan atau memilih fungsi pengagregatan yang betul seperti min.

Dan sudah tentu, Chronograf adalah semudah mungkin untuk melihat log. Ia kelihatan seperti ini:

Secara lalai, log Influx disesuaikan untuk menggunakan syslog dan oleh itu ia mempunyai parameter penting - keterukan.

Graf di bahagian atas amat berguna; padanya anda boleh melihat ralat yang berlaku dan warna serta-merta menunjukkan dengan jelas jika keterukan lebih tinggi.

Beberapa kali kami menangkap pepijat penting dengan cara ini, akan melihat log untuk minggu lepas dan melihat lonjakan merah.

Sudah tentu, idealnya adalah untuk menyediakan makluman untuk ralat sedemikian, kerana kami sudah mempunyai segala-galanya untuk ini.

Kami juga menghidupkan ini untuk seketika, tetapi dalam proses menyediakan juruterbang ternyata kami mendapat banyak ralat (termasuk ralat sistem seperti ketiadaan rangkaian LTE), yang "membuat spam" saluran Slack juga banyak, tanpa menyebabkan sebarang masalah. faedah yang besar.

Penyelesaian yang betul ialah mengendalikan kebanyakan jenis ralat ini, melaraskan keterukan ralat tersebut, dan hanya kemudian membolehkan amaran.

Dengan cara ini, hanya ralat baharu atau penting akan disiarkan ke Slack. Tiada masa yang cukup untuk persediaan sedemikian memandangkan tarikh akhir yang ketat.

Pengesahan

Perlu juga disebut bahawa Chronograf menyokong OAuth dan OIDC sebagai pengesahan.

Ini sangat mudah, kerana ia membolehkan anda dengan mudah melampirkannya pada pelayan anda dan mencipta SSO sepenuhnya.

Dalam kes kami, pelayan adalah Jubah kunci — ia digunakan untuk menyambung kepada pemantauan, tetapi pelayan yang sama juga digunakan untuk mengesahkan skuter dan permintaan ke bahagian belakang.

“Pentadbir”

Komponen terakhir yang saya akan terangkan ialah "panel pentadbir" yang ditulis sendiri dalam Vue.
Pada asasnya ia hanyalah perkhidmatan kendiri yang memaparkan maklumat skuter daripada pangkalan data, perkhidmatan mikro dan data metrik kami sendiri daripada InfluxDB secara serentak.

Selain itu, banyak fungsi pentadbiran telah dialihkan ke sana, seperti but semula kecemasan atau membuka kunci dari jauh untuk pasukan sokongan.

Terdapat juga peta. Saya telah menyebut bahawa kita bermula dengan Grafana dan bukannya Chronograf - kerana untuk peta Grafana tersedia dalam bentuk pemalam, di mana kita boleh melihat koordinat skuter. Malangnya, keupayaan widget peta untuk Grafana adalah sangat terhad, dan akibatnya, lebih mudah untuk menulis aplikasi web anda sendiri dengan peta dalam beberapa hari, untuk bukan sahaja melihat koordinat pada masa ini, tetapi juga memaparkan laluan yang diambil oleh skuter, dapat menapis data pada peta, dsb. (semua fungsi yang tidak dapat kami konfigurasikan dalam papan pemuka mudah).

Salah satu kelebihan Influx yang telah disebutkan ialah keupayaan untuk mencipta metrik anda sendiri dengan mudah.
Ini membolehkan ia digunakan untuk pelbagai jenis senario.

Kami cuba merekodkan semua maklumat berguna di sana: cas bateri, status kunci, prestasi penderia, bluetooth, GPS dan banyak pemeriksaan kesihatan lain.
Kami memaparkan semua ini pada panel pentadbir.

Sudah tentu, kriteria yang paling penting bagi kami ialah keadaan operasi skuter - sebenarnya, Influx menyemak ini sendiri dan menunjukkannya dengan "lampu hijau" di bahagian Nod.

Ini dilakukan oleh fungsi orang mati — kami menggunakannya untuk memahami prestasi kotak kami dan menghantar makluman yang sama kepada Slack.

Ngomong-ngomong, kami menamakan skuter itu sempena nama watak dari The Simpsons - sangat mudah untuk membezakannya antara satu sama lain

Dan secara umum ia lebih menyeronokkan dengan cara ini. Frasa seperti "Guys, Smithers is dead!" sentiasa didengari.

Metrik rentetan

Adalah penting bahawa InfluxDB membenarkan anda menyimpan bukan sahaja nilai angka, seperti halnya dengan Victoria Metrics.

Nampaknya ini tidak begitu penting - lagipun, selain daripada log, sebarang metrik boleh disimpan dalam bentuk nombor (hanya tambahkan pemetaan untuk keadaan yang diketahui - sejenis enum)?

Dalam kes kami, terdapat sekurang-kurangnya satu senario di mana metrik rentetan sangat berguna.
Kebetulan pembekal "pengecas pintar" kami adalah pihak ketiga, kami tidak mempunyai kawalan ke atas proses pembangunan dan maklumat yang boleh dibekalkan oleh pengecas ini.

Akibatnya, API pengecasan adalah jauh dari ideal, tetapi masalah utama ialah kami tidak selalu dapat memahami keadaan mereka.

Di sinilah Influx datang untuk menyelamatkan. Kami hanya menulis status rentetan yang datang kepada kami ke dalam medan pangkalan data InfluxDB tanpa perubahan.

Untuk beberapa waktu, hanya nilai seperti "dalam talian" dan "luar talian" yang sampai di sana, berdasarkan maklumat yang dipaparkan dalam panel pentadbir kami, dan pemberitahuan dihantar ke Slack. Walau bagaimanapun, pada satu ketika, nilai seperti "terputus" juga mula muncul di sana.

Seperti yang ternyata kemudian, status ini dihantar sekali selepas kehilangan sambungan, jika pengecas tidak dapat mewujudkan sambungan dengan pelayan selepas beberapa percubaan.

Oleh itu, jika kami hanya menggunakan set nilai tetap, kami mungkin tidak melihat perubahan ini dalam perisian tegar pada masa yang betul.

Dan secara umum, metrik rentetan menyediakan lebih banyak kemungkinan untuk digunakan; anda boleh merekodkan hampir sebarang maklumat di dalamnya. Walaupun, sudah tentu, anda juga perlu menggunakan alat ini dengan berhati-hati.

Sebagai tambahan kepada metrik biasa, kami juga merekodkan maklumat lokasi GPS dalam InfluxDB. Ini amat berguna untuk memantau lokasi skuter dalam panel pentadbir kami.
Malah, kami sentiasa tahu di mana dan skuter yang mana pada masa yang kami perlukan.

Ini sangat berguna kepada kami semasa kami mencari skuter (lihat kesimpulan di bahagian akhir).

Pemantauan infrastruktur

Sebagai tambahan kepada skuter itu sendiri, kami perlu memantau keseluruhan infrastruktur kami (agak luas).

Seni bina yang sangat umum kelihatan seperti ini:

Jika kita menyerlahkan timbunan pemantauan tulen, ia kelihatan seperti ini:

Perkara yang ingin kami periksa dalam awan ialah:

• Pangkalan data
• Jubah kunci
• Perkhidmatan mikro

Memandangkan semua perkhidmatan awan kami terletak di Kubernetes, adalah baik untuk mengumpul maklumat tentang keadaannya.

Nasib baik, Telegraf di luar kotak boleh mengumpul sejumlah besar metrik tentang keadaan gugusan Kubernetes, dan Chronograf segera menawarkan papan pemuka yang cantik untuk ini.

Kami terutamanya memantau prestasi pod dan penggunaan memori. Sekiranya berlaku kejatuhan, makluman dalam Slack.

Terdapat dua cara untuk menjejak pod dalam Kubernetes: DaemonSet dan Sidecar.
Kedua-dua kaedah diterangkan secara terperinci dalam catatan blog ini.

Kami menggunakan Telegraf Sidecar dan, sebagai tambahan kepada metrik, mengumpul log pod.

Dalam kes kami, kami terpaksa bermain-main dengan balak. Walaupun fakta bahawa Telegraf boleh menarik log daripada API Docker, kami mahu mempunyai koleksi log yang seragam dengan peranti akhir kami dan mengkonfigurasikan syslog untuk bekas untuk ini. Mungkin penyelesaian ini tidak cantik, tetapi tiada aduan tentang kerjanya dan log dipaparkan dengan baik dalam Chronograf.

Pantau pemantauan???

Pada akhirnya, persoalan lama mengenai sistem pemantauan pemantauan timbul, tetapi mujurlah, atau malangnya, kami tidak mempunyai masa yang cukup untuk ini.

Walaupun Telegraf boleh menghantar metrik sendiri dengan mudah atau mengumpul metrik daripada pangkalan data InfluxDB untuk menghantar sama ada ke Influx yang sama atau ke tempat lain.

Penemuan

Apakah kesimpulan yang kami buat daripada keputusan juruterbang?

Bagaimana anda boleh melakukan pemantauan?

Pertama sekali, timbunan TICK memenuhi sepenuhnya jangkaan kami dan memberi kami lebih banyak peluang daripada yang kami jangkakan pada mulanya.

Semua fungsi yang kami perlukan hadir. Semua yang kami lakukan dengannya berfungsi tanpa masalah.

Produktiviti

Masalah utama dengan timbunan TICK dalam versi percuma ialah kekurangan keupayaan penskalaan. Ini tidak menjadi masalah bagi kami.

Kami tidak mengumpul data/angka muatan yang tepat, tetapi kami mengumpul data daripada kira-kira 30 skuter pada satu masa.

Setiap daripada mereka mengumpul lebih daripada tiga dozen metrik. Pada masa yang sama, log dari peranti telah dikumpulkan. Pengumpulan dan penghantaran data berlaku setiap 10 saat.

Adalah penting untuk ambil perhatian bahawa selepas seminggu setengah juruterbang, apabila sebahagian besar "masalah zaman kanak-kanak" telah diperbetulkan dan masalah yang paling penting telah diselesaikan, kami terpaksa mengurangkan kekerapan menghantar data ke pelayan untuk 30 saat. Ini menjadi perlu kerana trafik pada kad SIM LTE kami mula hilang dengan cepat.

Sebahagian besar trafik telah digunakan oleh log; metrik itu sendiri, walaupun dengan selang 10 saat, boleh dikatakan tidak membazirkannya.

Akibatnya, selepas beberapa lama kami melumpuhkan sepenuhnya pengumpulan log pada peranti, kerana masalah tertentu sudah jelas walaupun tanpa pengumpulan berterusan.

Dalam sesetengah kes, jika melihat log masih diperlukan, kami hanya menyambung melalui WireGuard melalui VPN.

Saya juga akan menambah bahawa setiap persekitaran yang berasingan telah diasingkan antara satu sama lain, dan beban yang diterangkan di atas adalah berkaitan hanya untuk persekitaran pengeluaran.

Dalam persekitaran pembangunan, kami membangkitkan contoh InfluxDB yang berasingan yang terus mengumpul data setiap 10 saat dan kami tidak menghadapi sebarang masalah prestasi.

TICK - sesuai untuk projek kecil hingga sederhana

Berdasarkan maklumat ini, saya akan membuat kesimpulan bahawa timbunan TICK sesuai untuk projek atau projek yang agak kecil yang pastinya tidak mengharapkan sebarang HighLoad.

Jika anda tidak mempunyai beribu-ribu pod atau beratus-ratus mesin, walaupun satu contoh InfluxDB akan mengendalikan beban dengan baik.

Dalam sesetengah kes, anda mungkin berpuas hati dengan Influx Relay sebagai penyelesaian Ketersediaan Tinggi primitif.

Dan, sudah tentu, tiada siapa yang menghalang anda daripada menyediakan penskalaan "menegak" dan hanya memperuntukkan pelayan yang berbeza untuk jenis metrik yang berbeza.

Jika anda tidak pasti tentang beban yang dijangkakan pada perkhidmatan pemantauan, atau anda dijamin mempunyai/akan mempunyai seni bina yang sangat "berat", saya tidak akan mengesyorkan menggunakan versi percuma timbunan TICK.

Sudah tentu, penyelesaian mudah adalah dengan membeli InfluxDB Enterprise - tetapi di sini saya tidak boleh mengulas entah bagaimana, kerana saya sendiri tidak biasa dengan kehalusan. Selain itu ia sangat mahal dan pastinya tidak sesuai untuk syarikat kecil.

Dalam kes ini, hari ini, saya akan mengesyorkan melihat ke arah mengumpul metrik melalui Victoria Metrics dan log menggunakan Loki.

Benar, saya sekali lagi akan membuat tempahan bahawa Loki/Grafana adalah lebih kurang selesa (disebabkan oleh fleksibiliti yang lebih besar) daripada TICK yang sudah siap, tetapi ia percuma.

Ia adalah penting: semua maklumat yang diterangkan di sini adalah berkaitan untuk versi Influx 1.8, pada masa ini Influx 2.0 akan dikeluarkan.

Walaupun saya tidak mempunyai peluang untuk mencubanya dalam keadaan pertempuran dan sukar untuk membuat kesimpulan tentang penambahbaikan, antara muka pasti menjadi lebih baik, seni bina telah dipermudahkan (tanpa kapacitor dan chronograf),
templat muncul (“ciri pembunuh” - anda boleh menjejaki pemain dalam Fortnite dan menerima pemberitahuan apabila pemain kegemaran anda memenangi sesuatu permainan). Tetapi, malangnya, pada masa ini, versi 2 tidak mempunyai perkara utama yang kami pilih versi pertama - tiada koleksi log.

Fungsi ini juga akan muncul dalam Influx 2.0, tetapi kami tidak menemui sebarang tarikh akhir, walaupun anggarannya.

Bagaimana untuk tidak membuat platform IoT (sekarang)

Akhirnya, setelah melancarkan juruterbang, kami sendiri memasang timbunan IoT kami sendiri, tanpa adanya alternatif yang sesuai dengan piawaian kami.

Walau bagaimanapun, baru-baru ini ia tersedia dalam versi Beta OpenBalena — Sayang sekali dia tidak berada di sana semasa kami mula membuat projek itu.

Kami benar-benar berpuas hati dengan hasil akhir dan platform berdasarkan Ansible + TICK + WireGuard yang kami pasang sendiri. Tetapi hari ini, saya akan mengesyorkan melihat Balena dengan lebih dekat sebelum cuba membina sendiri platform IoT anda.

Kerana akhirnya ia boleh melakukan kebanyakan perkara yang kami lakukan, dan OpenBalena adalah percuma dan sumber terbuka.

Ia sudah tahu bagaimana untuk bukan sahaja menghantar kemas kini, tetapi juga VPN telah dibina dan disesuaikan untuk digunakan dalam persekitaran IoT.

Dan baru-baru ini, mereka juga mengeluarkan mereka perkakasan, yang mudah berhubung dengan ekosistem mereka.

Hei, bagaimana dengan skuter yang hilang?

Jadi skuter, "Ralph", hilang tanpa jejak.

Kami segera berlari untuk melihat peta dalam "panel pentadbir" kami, dengan data metrik GPS daripada InfluxDB.

Terima kasih kepada data pemantauan, kami dengan mudah menentukan bahawa skuter itu meninggalkan tempat letak kereta sekitar jam 21:00 hari lepas, memandu kira-kira setengah jam ke beberapa kawasan dan diletakkan sehingga jam 5 pagi di sebelah beberapa rumah Jerman.

Selepas jam 5 pagi, tiada data pemantauan diterima—ini bermakna sama ada bateri tambahan telah dinyahcas sepenuhnya atau penyerang akhirnya mengetahui cara untuk mengalih keluar perkakasan pintar daripada skuter.
Walaupun begitu, polis masih dipanggil ke alamat di mana skuter itu berada. Skuter itu tiada di situ.

Bagaimanapun, pemilik rumah itu turut terkejut dengan perkara ini kerana dia sebenarnya menaiki skuter ini pulang dari pejabat malam tadi.

Ternyata, salah seorang pekerja sokongan tiba awal pagi dan mengambil skuter itu, melihat bateri tambahannya telah dinyahcas sepenuhnya dan membawanya (berjalan kaki) ke tempat letak kereta. Dan bateri tambahan gagal kerana kelembapan.

Kami mencuri skuter itu daripada diri kami sendiri. Ngomong-ngomong, saya tidak tahu bagaimana dan siapa yang kemudian menyelesaikan isu dengan kes polis, tetapi pemantauan berfungsi dengan sempurna...

Sumber: www.habr.com