Setahun yang lalu kami meluncurkan versi percontohan proyek promosi untuk .
Awalnya proyek ini bernama Road-To-Barcelona, kemudian menjadi Road-To-Berlin (karenanya R2B di tangkapan layar), dan pada akhirnya disebut xRide.
Ide utama dari proyek ini adalah: alih-alih memiliki layanan penyewaan mobil atau skuter yang terpusat (kita berbicara tentang skuter alias sepeda motor listrik, bukan kickscooter/skuter) kami ingin membuat platform untuk persewaan yang terdesentralisasi. Tentang kesulitan yang kami temui .
Awalnya, proyek ini berfokus pada mobil, tetapi karena tenggat waktu, komunikasi yang sangat lama dengan produsen, dan banyaknya batasan keselamatan, skuter listrik dipilih sebagai proyek percontohan.
Pengguna menginstal aplikasi iOS atau Android di ponsel, mendekati skuter yang disukainya, setelah itu ponsel dan skuter membuat koneksi peer-to-peer, ETH ditukar dan pengguna dapat memulai perjalanan dengan menyalakan skuter melalui teleponnya. Di akhir perjalanan, pembayaran perjalanan juga dapat dilakukan menggunakan Ethereum dari dompet pengguna di ponsel.
Selain skuter, pengguna melihat “pengisi daya pintar” di aplikasi, dengan mengunjunginya pengguna dapat mengganti sendiri baterai saat ini jika baterai hampir habis.
Secara umum seperti inilah gambaran uji coba kami, yang diluncurkan pada bulan September tahun lalu di dua kota di Jerman: Bonn dan Berlin.
Dan kemudian, suatu hari, di Bonn, pagi-pagi sekali, tim dukungan kami (yang berlokasi di lokasi untuk menjaga skuter agar tetap berfungsi) diberitahu: salah satu skuter telah menghilang tanpa jejak.
Bagaimana cara menemukannya dan mengembalikannya?
Dalam artikel ini saya akan membicarakan hal ini, tetapi pertama-tama - tentang bagaimana kami membangun platform IoT kami sendiri dan bagaimana kami memantaunya.
Apa dan mengapa yang harus dipantau: skuter, infrastruktur, stasiun pengisian daya?
Jadi, apa yang ingin kami pantau dalam proyek kami?
Pertama-tama, ini adalah skuter itu sendiri - skuter listrik itu sendiri cukup mahal, Anda tidak dapat meluncurkan proyek semacam itu tanpa persiapan yang memadai; jika memungkinkan, Anda ingin mengumpulkan informasi sebanyak mungkin tentang skuter: tentang lokasinya, tingkat pengisian dayanya , dll.
Selain itu, saya ingin memantau keadaan infrastruktur TI kami - database, layanan, dan semua yang diperlukan agar berfungsi. Penting juga untuk memantau status “pengisi daya pintar”, jika baterai rusak atau kehabisan baterai penuh.
Skuter
Apa skuter kami dan apa yang ingin kami ketahui tentangnya?
Yang pertama dan terpenting adalah koordinat GPS, karena berkat mereka kita dapat mengetahui di mana mereka berada dan ke mana mereka bergerak.
Berikutnya adalah pengisian daya baterai, berkat itu kami dapat menentukan bahwa pengisian daya skuter akan segera berakhir dan mengirimkan pembuat jus atau setidaknya memperingatkan pengguna.
Tentu saja, kita juga perlu memeriksa apa yang terjadi dengan komponen Perangkat Keras kita:
- работает ли Bluetooth?
- apakah modul GPS itu sendiri berfungsi?
- Kami juga mempunyai masalah dengan fakta bahwa GPS dapat mengirimkan koordinat yang salah dan macet, dan ini hanya dapat ditentukan dengan pemeriksaan tambahan pada skuter,
dan beri tahu dukungan sesegera mungkin untuk mengatasi masalah tersebut
- Kami juga mempunyai masalah dengan fakta bahwa GPS dapat mengirimkan koordinat yang salah dan macet, dan ini hanya dapat ditentukan dengan pemeriksaan tambahan pada skuter,
Dan terakhir: pemeriksaan perangkat lunak, dimulai dengan OS dan prosesor, beban jaringan dan disk, diakhiri dengan pemeriksaan modul kami sendiri yang lebih spesifik untuk kami (, ).
Perangkat keras
Apa bagian “besi” kita?
Учитывая максимально сжатые сроки и необходимость быстрого прототипирования мы выбрали для себя максимально простой для реализации и подбора компонентов вариант — Raspberry Pi.
Selain Rpi itu sendiri, kami memiliki papan khusus (yang kami kembangkan dan pesan sendiri dari Tiongkok untuk mempercepat proses perakitan solusi akhir) dan satu set komponen - relai (untuk menghidupkan/mematikan skuter), pembaca pengisian daya baterai, modem, antena. Semua ini dikemas secara kompak dalam “kotak xRide” khusus.
Perlu juga dicatat bahwa seluruh kotak ditenagai oleh bank daya tambahan, yang pada gilirannya ditenagai oleh baterai utama skuter.
Hal ini memungkinkan untuk menggunakan pemantauan dan menghidupkan skuter bahkan setelah perjalanan berakhir, karena baterai utama dimatikan segera setelah kunci kontak diputar ke posisi "mati".
Buruh pelabuhan? Linux biasa? dan penyebaran
Mari kita kembali ke pemantauan, jadi Raspberry - apa yang kita punya?
Salah satu hal pertama yang ingin kami gunakan untuk mempercepat proses penerapan, pembaruan, dan pengiriman komponen ke perangkat fisik adalah Docker.
Sayangnya, dengan cepat menjadi jelas bahwa Docker di RPi, meskipun berfungsi, memiliki banyak overhead, terutama dalam hal konsumsi energi.
Разница с использованием "нативной" ОС пусть и не была настолько сильной, но все же достаточной чтобы мы опасались возможности слишком быстрой потери заряда.
Alasan kedua adalah salah satu perpustakaan mitra kami di Node.js (sic!) - satu-satunya komponen sistem yang tidak ditulis dalam Go/C/C++.
Penulis perpustakaan tidak punya waktu untuk menyediakan versi yang berfungsi dalam bahasa “asli” mana pun.
Node itu sendiri bukan saja bukan solusi paling elegan untuk perangkat berperforma rendah, namun perpustakaan itu sendiri juga sangat haus sumber daya.
Kami menyadari bahwa, meskipun kami menginginkannya, menggunakan Docker akan terlalu membebani kami. Pilihan dibuat untuk mendukung OS asli dan bekerja langsung di bawahnya.
OS
Hasilnya, kami sekali lagi memilih opsi paling sederhana sebagai OS dan menggunakan Raspbian (Debian build for Pi).
Kami menulis semua perangkat lunak kami di Go, jadi kami juga menulis modul agen perangkat keras utama di sistem kami di Go.
Именно он и отвечает за работу с GPS, Bluetooth, считывание заряда, включение скутера, итд.
Menyebarkan
Pertanyaan segera muncul tentang perlunya menerapkan mekanisme untuk mengirimkan pembaruan ke perangkat (OTA) - baik pembaruan pada agen/aplikasi kami sendiri, maupun pembaruan pada OS/firmware itu sendiri (karena versi baru dari agen mungkin memerlukan pembaruan pada kernel atau komponen sistem, perpustakaan, dll.) .
Setelah melakukan analisa pasar yang cukup panjang, ternyata cukup banyak solusi untuk menghadirkan pembaruan pada perangkat.
Dari yang relatif sederhana, sebagian besar utilitas berorientasi pembaruan/dual-boot seperti swupd/SWUpdate/OSTree hingga platform lengkap seperti Mender dan Balena.
Pertama-tama, kami memutuskan bahwa kami tertarik pada solusi end-to-end, sehingga pilihan langsung jatuh pada platform.
Dirinya sendiri dikecualikan karena fakta bahwa ia sebenarnya menggunakan Docker yang sama di dalam balenaEngine-nya.
Namun saya perhatikan bahwa meskipun demikian, kami akhirnya terus menggunakan produk mereka untuk firmware flash pada kartu SD - utilitas sederhana dan sangat nyaman untuk ini.
Oleh karena itu, pada akhirnya pilihan jatuh pada . Mender adalah platform lengkap untuk merakit, mengirimkan, dan menginstal firmware.
Secara keseluruhan, platform ini terlihat bagus, tetapi kami membutuhkan waktu sekitar satu setengah minggu untuk membuat versi firmware yang benar menggunakan pembuat perbaikan.
Dan semakin kami mendalami seluk-beluk penggunaannya, semakin jelas bahwa untuk menerapkannya sepenuhnya, kami memerlukan lebih banyak waktu daripada yang kami miliki.
Sayangnya, tenggat waktu kami yang ketat membuat kami terpaksa meninggalkan penggunaan Mender dan memilih yang lebih sederhana.
Mungkin
Solusi paling sederhana dalam situasi kami adalah menggunakan Ansible. Beberapa buku pedoman sudah cukup untuk memulai.
Esensinya adalah kami cukup terhubung dari host (server CI) melalui ssh ke raspberry kami dan mendistribusikan pembaruan kepada mereka.
Pada awalnya, semuanya sederhana - Anda harus berada di jaringan yang sama dengan perangkat, penuangan dilakukan melalui Wi-Fi.
Di kantor hanya ada selusin raspberry uji yang terhubung ke jaringan yang sama, setiap perangkat memiliki alamat IP statis yang juga ditentukan dalam Inventaris yang Mungkin.
Ansiblelah yang mengirimkan agen pemantauan kami ke perangkat akhir
3G / LTE
Sayangnya, kasus penggunaan Ansible ini hanya dapat berfungsi dalam mode pengembangan sebelum kami memiliki skuter sebenarnya.
Karena skuter, seperti yang Anda pahami, tidak hanya terhubung ke satu router Wi-Fi, terus-menerus menunggu pembaruan melalui jaringan.
Pada kenyataannya, skuter tidak dapat memiliki koneksi apa pun selain seluler 3G/LTE (itupun tidak setiap saat).
Hal ini segera menimbulkan banyak masalah dan keterbatasan, seperti kecepatan koneksi yang rendah dan komunikasi yang tidak stabil.
Namun yang terpenting adalah dalam jaringan 3G/LTE kita tidak bisa hanya mengandalkan IP statis yang ditetapkan ke jaringan tersebut.
Masalah ini sebagian diatasi oleh beberapa penyedia kartu SIM; bahkan ada kartu SIM khusus yang dirancang untuk perangkat IoT dengan alamat IP statis. Namun kami tidak memiliki akses ke kartu SIM tersebut dan tidak dapat menggunakan alamat IP.
Tentu saja, ada ide untuk melakukan semacam pendaftaran alamat IP alias penemuan layanan di suatu tempat seperti Konsul, tetapi kami harus meninggalkan ide tersebut, karena dalam pengujian kami, alamat IP dapat berubah terlalu sering, sehingga menyebabkan ketidakstabilan yang besar.
Karena alasan ini, penggunaan yang paling nyaman untuk mengirimkan metrik bukanlah menggunakan model tarik, di mana kita akan pergi ke perangkat untuk mendapatkan metrik yang diperlukan, tetapi mendorong, mengirimkan metrik dari perangkat langsung ke server
VPN
Sebagai solusi untuk masalah ini, kami memilih VPN - khususnya .
Klien (skuter) pada awal sistem terhubung ke server VPN dan dapat terhubung ke sana. Terowongan ini digunakan untuk menyampaikan pembaruan.
Secara teori, terowongan yang sama dapat digunakan untuk pemantauan, tetapi sambungan seperti itu lebih rumit dan kurang dapat diandalkan dibandingkan sambungan dorong sederhana.
Sumber daya awan
Terakhir, pemantauan layanan cloud dan database kami perlu dilakukan, karena kami menggunakan Kubernetes untuk layanan tersebut, idealnya agar penerapan pemantauan di cluster menjadi sesederhana mungkin. Idealnya, menggunakan , karena untuk penerapan, kami menggunakannya dalam banyak kasus. Dan, tentu saja, untuk memantau cloud Anda perlu menggunakan solusi yang sama seperti pada skuter itu sendiri.
Diberikan
Fiuh, sepertinya kita sudah memilah uraiannya, mari kita buat daftar apa yang kita butuhkan pada akhirnya:
- Solusi cepat, karena pemantauan sudah diperlukan selama proses pengembangan
- Volume/kuantitas – dibutuhkan banyak metrik
- Pengumpulan log diperlukan
- Keandalan - data sangat penting untuk kesuksesan peluncuran
- Anda tidak dapat menggunakan model tarikan - Anda perlu dorongan
- Kita memerlukan pemantauan terpadu tidak hanya pada perangkat keras, tetapi juga cloud
Gambar akhirnya terlihat seperti ini
Pemilihan tumpukan
Jadi, kami dihadapkan pada pertanyaan memilih tumpukan pemantauan.
Pertama-tama, kami mencari solusi lengkap terlengkap yang secara bersamaan mencakup semua kebutuhan kami, namun pada saat yang sama cukup fleksibel untuk menyesuaikan penggunaannya dengan kebutuhan kami. Namun, kami mempunyai banyak batasan yang dikenakan pada kami karena perangkat keras, arsitektur, dan tenggat waktu.
Ada berbagai macam solusi pemantauan, dimulai dengan sistem lengkap seperti , или dan diakhiri dengan solusi siap pakai untuk manajemen Armada.
Pada awalnya, opsi terakhir tampak seperti solusi ideal bagi kami, namun beberapa tidak memiliki pemantauan penuh, versi gratis lainnya memiliki kemampuan yang sangat terbatas, dan versi gratis lainnya tidak memenuhi “keinginan” kami atau tidak cukup fleksibel untuk disesuaikan dengan skenario kami. Beberapa sudah ketinggalan jaman.
Setelah menganalisis sejumlah solusi serupa, kami dengan cepat sampai pada kesimpulan bahwa akan lebih mudah dan cepat untuk merakit sendiri tumpukan serupa. Ya, ini akan sedikit lebih rumit daripada menerapkan platform manajemen Armada yang sudah jadi, namun kami tidak perlu berkompromi.
Hampir pasti, dalam banyaknya solusi yang ada, sudah ada solusi siap pakai yang benar-benar cocok untuk kita, tetapi dalam kasus kami, jauh lebih cepat untuk mengumpulkan tumpukan tertentu sendiri dan menyesuaikannya "untuk diri kita sendiri" daripada menguji produk jadi.
Dengan semua ini, kami tidak berusaha untuk merakit sendiri seluruh platform pemantauan, tetapi mencari tumpukan “siap pakai” yang paling fungsional, hanya dengan kemampuan untuk mengkonfigurasinya secara fleksibel.
(B)rusa?
Solusi pertama yang benar-benar dipertimbangkan adalah tumpukan ELK yang terkenal.
Malah seharusnya disebut BELK, karena semuanya dimulai dengan Beats -
Конечно, ELK это одно из самых известных и мощных решений в области мониторинга, а уж в сборе и обработке логов, так и самое.
Kami bermaksud agar ELK digunakan untuk mengumpulkan log dan juga penyimpanan metrik jangka panjang yang diperoleh dari Prometheus.
Untuk visualisasi Anda bisa menggunakan Grafan.
Faktanya, tumpukan ELK baru dapat mengumpulkan metrik secara mandiri (metricbeat), dan Kibana juga dapat menampilkannya.
Namun tetap saja, ELK awalnya tumbuh dari log dan sejauh ini fungsi metriknya memiliki sejumlah kelemahan serius:
- Jauh lebih lambat dari Prometheus
- Terintegrasi ke tempat yang jauh lebih sedikit daripada Prometheus
- Сложно настроить алертинг по ним
- Metrik memakan banyak ruang
- Menyiapkan dasbor dengan metrik di Kiban jauh lebih rumit daripada di Grafan
Secara umum, metrik di ELK berat dan belum senyaman solusi lain, yang sekarang ada lebih dari sekadar Prometheus: TSDB, Victoria Metrics, Cortex, dll., Dll. Tentu saja, saya sangat ingin segera mendapatkan solusi lengkap yang lengkap, tetapi dalam kasus metricbeat, ada terlalu banyak kompromi.
Да и у самого ELK стека есть ряд непростых моментов:
- Memang berat, bahkan terkadang sangat berat jika mengumpulkan data dalam jumlah yang cukup besar
- Anda perlu “tahu cara memasaknya” - Anda perlu menskalakannya, tetapi ini bukanlah hal yang sepele untuk dilakukan
- Урезанная бесплатная версия — в бесплатной версии нет нормального алертинга, на момент выбора не было и аутентификации
Saya harus mengatakan bahwa akhir-akhir ini poin terakhir menjadi lebih baik dan sebagai tambahan (termasuk otentikasi) model penetapan harga itu sendiri mulai berubah.
Namun saat kami akan menerapkan solusi ini, tidak ada peringatan sama sekali.
Mungkin kami dapat mencoba membangun sesuatu menggunakan ElastAlert atau solusi komunitas lainnya, namun kami tetap memutuskan untuk mempertimbangkan alternatif lain.
Loki - Grafana - Prometheus
Saat ini, solusi yang baik mungkin dengan membangun tumpukan pemantauan hanya berdasarkan Prometheus sebagai penyedia metrik, Loki untuk log, dan untuk visualisasi Anda dapat menggunakan Grafana yang sama.
Sayangnya, pada saat dimulainya uji coba penjualan proyek (September-Oktober 19), Loki masih dalam versi beta 0.3-0.4, dan pada saat dimulainya pengembangan, Loki belum dapat dianggap sebagai solusi produksi. sama sekali.
Saya belum memiliki pengalaman dalam menggunakan Loki dalam proyek-proyek serius, tetapi saya dapat mengatakan bahwa Promtail (agen pengumpulan log) berfungsi dengan baik untuk bare-metal dan pod di kubernetes.
KUTU
Mungkin alternatif berfitur lengkap yang paling layak (satu-satunya?) untuk tumpukan ELK sekarang hanya dapat disebut tumpukan TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Saya akan menjelaskan semua komponen di bawah ini secara lebih rinci, tetapi gambaran umumnya adalah sebagai berikut:
- Telegraf - agen untuk mengumpulkan metrik
- InfluxDB - basis data metrik
- Kapacitor - pemroses metrik waktu nyata untuk peringatan
- Chronograf - panel web untuk visualisasi
Для InfluxDB, Kapacitor и Chronograf есть официальные helm чарты, которые мы использовали для их разворачивания.
Perlu diperhatikan bahwa pada versi terbaru Influx 2.0 (beta), Kapacitor dan Chronograf menjadi bagian dari InfluxDB dan tidak lagi berdiri sendiri-sendiri.
telegraf
— это очень легковесный агент для сбора метрик на конечной машине.
Dia dapat memantau banyak hal, mulai dari untuk
server .
Ini memiliki sejumlah keunggulan keren:
- Cepat dan ringan (ditulis dalam Go)
- Makan sumber daya dalam jumlah minimum
- Dorong metrik secara default
- Mengumpulkan semua metrik yang diperlukan
- Metrik sistem tanpa pengaturan apa pun
- Metrik perangkat keras seperti informasi dari sensor
- Sangat mudah untuk menambahkan metrik Anda sendiri
- Banyak plugin di luar kotak
- Mengumpulkan log
Karena metrik push diperlukan bagi kami, semua keuntungan lainnya lebih dari sekadar tambahan yang menyenangkan.
Pengumpulan log oleh agen itu sendiri juga sangat mudah, karena tidak perlu menghubungkan utilitas tambahan untuk mencatat log.
Influx предлагает максимально удобный опыт работы с логами если вы используете .
Telegraf umumnya merupakan agen yang hebat untuk mengumpulkan metrik, bahkan jika Anda tidak menggunakan sisa tumpukan ICK.
Banyak orang menggabungkannya dengan ELK dan berbagai database deret waktu lainnya demi kenyamanan, karena database ini dapat menulis metrik hampir di mana saja.
masuknyaDB
InfluxDB adalah inti utama dari tumpukan TICK, yaitu database deret waktu untuk metrik.
Selain metrik, Influx juga dapat menyimpan log, meskipun pada dasarnya log untuk itu hanyalah metrik yang sama, hanya saja alih-alih indikator numerik biasa, fungsi utama dijalankan oleh sebaris teks log.
InfluxDB juga ditulis dalam Go dan tampaknya berjalan jauh lebih cepat dibandingkan dengan ELK di cluster kami (bukan yang paling kuat).
Salah satu keunggulan Influx yang keren juga mencakup API yang sangat nyaman dan kaya untuk kueri data, yang kami gunakan dengan sangat aktif.
Kekurangan - $$$ atau penskalaan?
Tumpukan TICK hanya memiliki satu kelemahan yang kami temukan - yaitu sayang. Terlebih lagi.
Apa kelebihan versi berbayar yang tidak dimiliki versi gratis?
Насколько нам удалось понять, единственное чем отличается платная версия TICK стека от бесплатной — возможности скалирования.
Yaitu, Anda dapat membesarkan cluster dengan ketersediaan Tinggi hanya di .
Jika Anda ingin HA yang lengkap, Anda harus membayar atau menggunakan kruk. Ada beberapa solusi komunitas - misalnya sepertinya solusi yang kompeten, tetapi ada tertulis bahwa itu juga tidak cocok untuk produksi
- solusi sederhana dengan pemompaan data melalui NATS (ini juga harus ditingkatkan, tetapi ini bisa diselesaikan).
Sangat disayangkan, tetapi keduanya tampaknya ditinggalkan - tidak ada komitmen baru, saya berasumsi bahwa masalahnya adalah rilis versi baru Influx 2.0 yang akan segera dirilis, di mana banyak hal akan berbeda (tidak ada informasi tentang belum melakukan penskalaan).
Secara resmi ada versi gratis - sebenarnya, ini adalah HA primitif, tetapi hanya melalui penyeimbangan,
karena semua data akan ditulis ke semua instans InfluxDB di belakang penyeimbang beban.
Dia punya beberapa вроде потенциальных проблем с перезаписью точек и необходимости создавать базы для метрик заранее
(yang terjadi secara otomatis selama pekerjaan normal dengan InfluxDB).
Selain itu , ini berarti overhead tambahan untuk metrik duplikat (pemrosesan dan penyimpanan) yang mungkin tidak Anda perlukan, namun tidak ada cara untuk memisahkannya.
Metrik Victoria?
Akibatnya, meskipun kami benar-benar puas dengan tumpukan TICK dalam segala hal selain penskalaan berbayar, kami memutuskan untuk melihat apakah ada solusi gratis yang dapat menggantikan database InfluxDB, sambil meninggalkan komponen T_CK yang tersisa.
Ada banyak database deret waktu, tetapi yang paling menjanjikan adalah Victoria Metrics, yang memiliki sejumlah keunggulan:
- Cepat dan mudah, setidaknya sesuai dengan hasilnya
- Ada versi cluster, yang bahkan ada ulasan bagus sekarang
- Она можешь шардироваться
- Mendukung protokol InfluxDB
Kami tidak bermaksud untuk membangun tumpukan khusus sepenuhnya berdasarkan Victoria dan harapan utamanya adalah kami dapat menggunakannya sebagai pengganti InfluxDB.
Sayangnya, hal ini tidak mungkin dilakukan, meskipun protokol InfluxDB didukung, protokol ini hanya berfungsi untuk merekam metrik - hanya Prometheus API yang tersedia "di luar", yang berarti Chronograf tidak dapat disetel di dalamnya.
Selain itu, hanya nilai numerik yang didukung untuk metrik (kami menggunakan nilai string untuk metrik khusus - lebih lanjut tentang itu di bagian ini ).
Jelasnya, untuk alasan yang sama, VM tidak dapat menyimpan log seperti yang dilakukan Influx.
Perlu juga dicatat bahwa pada saat mencari solusi optimal, Victoria Metrics belum begitu populer, dokumentasinya jauh lebih kecil dan fungsinya lebih lemah.
(Saya tidak ingat penjelasan detail tentang versi cluster dan sharding).
Pemilihan dasar
Oleh karena itu, diputuskan bahwa untuk uji coba ini kami masih akan membatasi diri pada satu node InfluxDB saja.
Ada beberapa alasan utama pemilihan ini:
- Kami sangat menyukai seluruh fungsi tumpukan TICK
- Kami sudah berhasil menerapkannya dan berfungsi dengan baik
- Tenggat waktunya hampir habis dan tidak banyak waktu tersisa untuk menguji opsi lain.
- Kami tidak menyangka beban seberat itu
Kami tidak memiliki banyak skuter untuk tahap pertama uji coba, dan pengujian selama pengembangan tidak menunjukkan adanya masalah kinerja.
Oleh karena itu, kami memutuskan bahwa untuk proyek ini satu node Influx sudah cukup bagi kami tanpa perlu penskalaan (lihat kesimpulan di bagian akhir).
Kami telah memutuskan tumpukan dan pangkalan - sekarang tentang komponen sisa tumpukan TICK.
Kapasitor
Kapacitor adalah bagian dari TICK stack, sebuah layanan yang dapat memantau metrik yang masuk ke database secara real time dan melakukan berbagai tindakan berdasarkan aturan.
Secara umum, ini diposisikan sebagai alat untuk pelacakan potensi anomali dan pembelajaran mesin (saya tidak yakin fungsi-fungsi ini dibutuhkan), tetapi kasus penggunaannya yang paling populer lebih umum - peringatan.
Так и мы его использовали для нотификаций. Мы настроили Slack оповещения о том, что тот или иной скутер отключился, то же самое было сделано для умных зарядок и важных компонентов инфраструктуры.
Hal ini memungkinkan untuk merespons masalah dengan cepat, serta menerima pemberitahuan bahwa semuanya kembali normal.
Contoh sederhana: baterai tambahan untuk memberi daya pada “kotak” kita telah rusak atau karena alasan tertentu kehabisan daya; cukup dengan memasang yang baru, setelah beberapa saat kita akan menerima pemberitahuan bahwa fungsi skuter telah dipulihkan.
Di Influx 2.0 Kapacitor menjadi bagian dari DB
Kronograf
Saya telah melihat banyak solusi UI yang berbeda untuk pemantauan, tetapi saya dapat mengatakan bahwa dalam hal fungsionalitas dan UX, tidak ada yang sebanding dengan Chronograf.
Anehnya, kami mulai menggunakan tumpukan TICK dengan Grafan sebagai antarmuka web.
Saya tidak akan menjelaskan fungsinya; semua orang tahu kemungkinannya yang luas untuk menyiapkan apa pun.
Namun, Grafana masih merupakan instrumen yang sepenuhnya universal, sedangkan Chronograf terutama dirancang untuk digunakan dengan Influx.
Dan tentu saja, berkat ini, Chronograf mampu memberikan fungsionalitas yang jauh lebih pintar dan nyaman.
Mungkin kenyamanan utama bekerja dengan Chronograf adalah Anda dapat melihat bagian dalam InfluxDB Anda melalui Jelajahi.
Tampaknya Grafana memiliki fungsi yang hampir sama, namun kenyataannya, pengaturan dashboard di Chronograf dapat dilakukan dengan beberapa klik mouse (sekaligus melihat visualisasi di sana), sedangkan di Grafana cepat atau lambat Anda masih akan memilikinya. untuk mengedit konfigurasi JSON (tentu saja Chronograf memungkinkan unggah dasbor yang dikonfigurasi dengan tangan Anda dan edit sebagai JSON jika perlu - tetapi saya tidak pernah perlu menyentuhnya setelah membuatnya di UI).
Kibana memiliki kemampuan yang jauh lebih kaya untuk membuat dasbor dan kontrolnya, namun UX untuk operasi semacam itu sangat kompleks.
Dibutuhkan pemahaman yang baik untuk membuat dasbor yang nyaman. Dan meskipun fungsionalitas dasbor Chronograf lebih sedikit, membuat dan menyesuaikannya jauh lebih sederhana.
Dashboardnya sendiri, selain gaya visualnya yang bagus, sebenarnya tidak ada bedanya dengan dashboard di Grafana atau Kibana:
Seperti inilah tampilan jendela kueri:
Penting untuk dicatat, antara lain, bahwa dengan mengetahui jenis bidang dalam database InfluxDB, kronograf itu sendiri terkadang dapat secara otomatis membantu Anda menulis Kueri atau memilih fungsi agregasi yang benar seperti mean.
Dan tentu saja, Chronograf senyaman mungkin untuk melihat log. Ini terlihat seperti ini:
Secara default, log Influx disesuaikan untuk menggunakan syslog dan oleh karena itu log tersebut memiliki parameter penting - tingkat keparahan.
Grafik di atas sangat berguna; di atasnya Anda dapat melihat kesalahan yang terjadi dan warnanya langsung menunjukkan dengan jelas jika tingkat keparahannya lebih tinggi.
Beberapa kali kami menemukan bug penting dengan cara ini, melihat log selama seminggu terakhir dan melihat lonjakan merah.
Tentu saja, idealnya adalah mengatur peringatan untuk kesalahan seperti itu, karena kami sudah memiliki segalanya untuk ini.
Kami bahkan mengaktifkannya untuk sementara waktu, tetapi dalam proses persiapan uji coba, ternyata kami mendapatkan cukup banyak kesalahan (termasuk kesalahan sistem seperti tidak tersedianya jaringan LTE), yang juga “mengirim spam” ke saluran Slack. banyak, tanpa menimbulkan masalah, manfaatnya besar.
Solusi yang tepat adalah menangani sebagian besar jenis kesalahan ini, menyesuaikan tingkat keparahannya, dan baru kemudian mengaktifkan peringatan.
Dengan cara ini, hanya kesalahan baru atau penting yang akan diposting ke Slack. Waktu yang tersedia tidak cukup untuk melakukan pengaturan seperti itu mengingat tenggat waktu yang ketat.
Otentikasi
Perlu juga disebutkan bahwa Chronograf mendukung OAuth dan OIDC sebagai otentikasi.
Ini sangat nyaman karena memungkinkan Anda dengan mudah melampirkannya ke server Anda dan membuat SSO lengkap.
Dalam kasus kami, servernya adalah — digunakan untuk terhubung ke pemantauan, tetapi server yang sama juga digunakan untuk mengautentikasi skuter dan permintaan ke back-end.
“Admin”
Komponen terakhir yang akan saya jelaskan adalah “panel admin” yang kami tulis sendiri di Vue.
Pada dasarnya ini hanyalah layanan mandiri yang menampilkan informasi skuter dari database kami sendiri, layanan mikro, dan data metrik dari InfluxDB secara bersamaan.
Selain itu, banyak fungsi administratif dipindahkan ke sana, seperti reboot darurat atau membuka kunci dari jarak jauh untuk tim dukungan.
Ada juga peta. Saya telah menyebutkan bahwa kami memulai dengan Grafana, bukan Chronograf - karena untuk peta Grafana tersedia dalam bentuk plugin, di mana kami dapat melihat koordinat skuter. Sayangnya, kemampuan widget peta untuk Grafana sangat terbatas, dan akibatnya, menulis aplikasi web Anda sendiri dengan peta menjadi jauh lebih mudah dalam beberapa hari, agar tidak hanya melihat koordinat saat ini, tetapi juga menampilkan rute yang diambil skuter, dapat memfilter data di peta, dll. (semua fungsi itu tidak dapat kami konfigurasikan di dasbor sederhana).
Salah satu keunggulan Influx yang telah disebutkan adalah kemampuannya untuk membuat metrik Anda sendiri dengan mudah.
Hal ini memungkinkannya digunakan untuk berbagai macam skenario.
Kami mencoba mencatat semua informasi berguna di sana: pengisian daya baterai, status kunci, kinerja sensor, bluetooth, GPS, dan banyak pemeriksaan kesehatan lainnya.
Kami menampilkan semua ini di panel admin.
Tentu saja, kriteria terpenting bagi kami adalah kondisi pengoperasian skuter - faktanya, Influx memeriksanya sendiri dan menunjukkannya dengan “lampu hijau” di bagian Node.
Ini dilakukan oleh fungsinya — kami menggunakannya untuk memahami kinerja kotak kami dan mengirimkan peringatan yang sama ke Slack.
Ngomong-ngomong, kami menamai skuter itu dengan nama karakter dari The Simpsons - sangat mudah untuk membedakannya satu sama lain
Dan secara umum lebih menyenangkan seperti ini. Ungkapan seperti “Teman-teman, Smithers sudah mati!” terus-menerus terdengar.
Metrik string
Важно, что InfluxDB позволяет хранить не только числовые значения, как в случае с Victoria Metrics.
Tampaknya ini tidak begitu penting - lagipula, selain log, metrik apa pun dapat disimpan dalam bentuk angka (cukup tambahkan pemetaan untuk status yang diketahui - semacam enum)?
Dalam kasus kami, setidaknya ada satu skenario di mana metrik string sangat berguna.
Kebetulan pemasok “pengisi daya pintar” kami adalah pihak ketiga, kami tidak memiliki kendali atas proses pengembangan dan informasi yang dapat disediakan oleh pengisi daya ini.
Akibatnya, API pengisian daya jauh dari ideal, namun masalah utamanya adalah kami tidak selalu dapat memahami statusnya.
Di sinilah Influx datang untuk menyelamatkan. Kami cukup menulis status string yang datang kepada kami ke dalam kolom database InfluxDB tanpa perubahan.
Untuk beberapa waktu, hanya nilai seperti "online" dan "offline" yang masuk ke sana, berdasarkan informasi yang ditampilkan di panel admin kami, dan pemberitahuan dikirim ke Slack. Namun, pada titik tertentu, nilai-nilai seperti “terputus” juga mulai muncul di sana.
Ternyata kemudian, status ini dikirim satu kali setelah koneksi terputus, jika pengisi daya tidak dapat membuat koneksi dengan server setelah beberapa kali mencoba.
Jadi, jika kita hanya menggunakan serangkaian nilai tetap, kita mungkin tidak melihat perubahan ini pada firmware pada waktu yang tepat.
Dan secara umum, metrik string memberikan lebih banyak kemungkinan untuk digunakan; Anda dapat merekam hampir semua informasi di dalamnya. Meskipun tentunya Anda juga perlu menggunakan alat ini dengan hati-hati.
Помимо обычных метрик, мы так же записывали в InfluxDB информацию о GPS локации. Это было невероятно удобно для мониторинга местонахождения скутеров в нашей админской панели.
Faktanya, kami selalu tahu di mana dan skuter mana yang kami butuhkan saat itu.
Ini sangat berguna bagi kami ketika kami sedang mencari skuter (lihat kesimpulan di akhir).
Pemantauan infrastruktur
Selain skuter itu sendiri, kami juga perlu memantau seluruh infrastruktur kami (yang cukup luas).
Arsitektur yang sangat umum terlihat seperti ini:
Jika kita menyorot tumpukan pemantauan murni, tampilannya seperti ini:
Yang ingin kami periksa di cloud adalah:
- Database
- gantungan kunci
- Layanan mikro
Karena semua layanan cloud kami berlokasi di Kubernetes, alangkah baiknya jika kami mengumpulkan informasi tentang statusnya.
Untungnya, Telegraf dapat mengumpulkan sejumlah besar metrik tentang status cluster Kubernetes, dan Chronograf segera menawarkan dasbor yang indah untuk ini.
Kami terutama memantau kinerja pod dan konsumsi memori. Jika terjatuh, peringatan di Slack.
Ada dua cara untuk melacak pod di Kubernetes: DaemonSet dan Sidecar.
Kedua metode tersebut dijelaskan secara rinci .
Kami menggunakan Telegraf Sidecar dan, selain metrik, mengumpulkan log pod.
Dalam kasus kami, kami harus mengutak-atik log. Terlepas dari kenyataan bahwa Telegraf dapat menarik log dari Docker API, kami ingin memiliki kumpulan log yang seragam dengan perangkat akhir kami dan mengonfigurasi syslog untuk container untuk ini. Mungkin solusi ini tidak bagus, tetapi tidak ada keluhan tentang kerjanya dan log ditampilkan dengan baik di Chronograf.
Memantau pemantauan???
Pada akhirnya, pertanyaan lama tentang sistem pemantauan pemantauan pun muncul, namun untungnya, atau sayangnya, kita tidak mempunyai cukup waktu untuk hal ini.
Meskipun Telegraf dapat dengan mudah mengirimkan metriknya sendiri atau mengumpulkan metrik dari database InfluxDB untuk dikirim ke Influx yang sama atau ke tempat lain.
Temuan
Kesimpulan apa yang kami ambil dari hasil uji coba ini?
Bagaimana Anda bisa melakukan pemantauan?
Pertama-tama, tumpukan TICK sepenuhnya memenuhi harapan kami dan memberi kami lebih banyak peluang daripada yang kami harapkan sebelumnya.
Semua fungsi yang kami perlukan telah hadir. Semua yang kami lakukan dengannya bekerja tanpa masalah.
Performa
Masalah utama dengan tumpukan TICK dalam versi gratis adalah kurangnya kemampuan penskalaan. Ini bukanlah masalah bagi kami.
Kami tidak mengumpulkan data/angka beban pastinya, namun kami mengumpulkan data dari sekitar 30 skuter sekaligus.
Masing-masing mengumpulkan lebih dari tiga lusin metrik. Pada saat yang sama, log dari perangkat dikumpulkan. Pengumpulan dan pengiriman data terjadi setiap 10 detik.
Penting untuk dicatat bahwa setelah satu setengah minggu uji coba, ketika sebagian besar “masalah masa kecil” telah diperbaiki dan masalah yang paling penting telah diselesaikan, kami harus mengurangi frekuensi pengiriman data ke server menjadi 30 detik. Ini menjadi perlu karena lalu lintas pada kartu SIM LTE kami mulai menghilang dengan cepat.
Sebagian besar lalu lintas dikonsumsi oleh log; metriknya sendiri, bahkan dengan interval 10 detik, praktis tidak menyia-nyiakannya.
Akibatnya, setelah beberapa waktu kami sepenuhnya menonaktifkan pengumpulan log pada perangkat, karena masalah tertentu sudah terlihat jelas bahkan tanpa pengumpulan terus-menerus.
Dalam beberapa kasus, jika melihat log masih diperlukan, kami cukup terhubung melalui WireGuard melalui VPN.
Saya juga akan menambahkan bahwa setiap lingkungan terpisah terpisah satu sama lain, dan beban yang dijelaskan di atas hanya relevan untuk lingkungan produksi.
Di lingkungan pengembangan, kami memunculkan instans InfluxDB terpisah yang terus mengumpulkan data setiap 10 detik dan kami tidak mengalami masalah kinerja apa pun.
CENTANG - ideal untuk proyek kecil hingga menengah
Berdasarkan informasi ini, saya menyimpulkan bahwa tumpukan TICK ideal untuk proyek yang relatif kecil atau proyek yang pastinya tidak memerlukan HighLoad.
Jika Anda tidak memiliki ribuan pod atau ratusan mesin, satu instance InfluxDB saja akan menangani beban tersebut dengan baik.
Dalam beberapa kasus, Anda mungkin puas dengan Influx Relay sebagai solusi Ketersediaan Tinggi yang primitif.
Dan, tentu saja, tidak ada yang menghentikan Anda untuk menyiapkan penskalaan “vertikal” dan mengalokasikan server yang berbeda untuk jenis metrik yang berbeda.
Jika Anda tidak yakin dengan beban yang diharapkan pada layanan pemantauan, atau Anda dijamin memiliki/akan memiliki arsitektur yang sangat “berat”, saya tidak akan merekomendasikan penggunaan versi gratis dari tumpukan TICK.
Tentu saja, solusi sederhananya adalah dengan membeli - tetapi di sini saya tidak dapat berkomentar, karena saya sendiri tidak mengetahui seluk-beluknya. Selain harganya yang sangat mahal dan tentunya tidak cocok untuk perusahaan kecil.
Dalam hal ini, hari ini, saya akan merekomendasikan pengumpulan metrik melalui Metrik Victoria dan log menggunakan Loki.
Benar, sekali lagi saya akan membuat reservasi bahwa Loki/Grafana jauh lebih tidak nyaman (karena keserbagunaannya yang lebih besar) dibandingkan TICK yang sudah jadi, tetapi gratis.
Ini penting: semua informasi yang dijelaskan di sini relevan untuk versi Influx 1.8, saat ini Influx 2.0 akan segera dirilis.
Meskipun saya belum sempat mencobanya dalam kondisi pertempuran dan sulit menarik kesimpulan tentang peningkatannya, antarmukanya pasti menjadi lebih baik, arsitekturnya disederhanakan (tanpa kapasitor dan kronograf),
templat muncul (“fitur mematikan” - ). Namun sayangnya, saat ini, versi 2 tidak memiliki kunci yang kami pilih untuk versi pertama - tidak ada pengumpulan log.
Fungsionalitas ini juga akan muncul di Influx 2.0, tetapi kami tidak dapat menemukan tenggat waktu apa pun, bahkan tenggat waktu perkiraan.
Bagaimana tidak membuat platform IoT (sekarang)
Pada akhirnya, setelah meluncurkan uji coba, kami sendiri yang menyusun tumpukan IoT kami sendiri, karena tidak adanya alternatif yang sesuai dengan standar kami.
Namun, saat ini tersedia dalam versi Beta — sayang sekali dia tidak ada di sana saat kami mulai membuat proyek ini.
Kami sangat puas dengan hasil akhir dan platform berdasarkan Ansible + TICK + WireGuard yang kami rakit sendiri. Namun hari ini, saya akan merekomendasikan untuk melihat lebih dekat Balena sebelum mencoba membangun platform IoT Anda sendiri.
Karena pada akhirnya ia dapat melakukan sebagian besar dari apa yang kami lakukan, dan OpenBalena gratis dan open source.
Ia sudah mengetahui cara tidak hanya mengirim pembaruan, tetapi juga VPN sudah terpasang dan disesuaikan untuk digunakan dalam lingkungan IoT.
Dan baru-baru ini, mereka bahkan merilisnya , yang dengan mudah terhubung ke ekosistemnya.
Hei, bagaimana dengan skuter yang hilang?
Jadi skuter, "Ralph", menghilang tanpa jejak.
Kami segera berlari untuk melihat peta di “panel admin” kami, dengan data metrik GPS dari InfluxDB.
Berkat data pemantauan, kami dengan mudah menentukan bahwa skuter tersebut meninggalkan tempat parkir sekitar pukul 21:00 hari lalu, berkendara sekitar setengah jam ke suatu area dan diparkir hingga jam 5 pagi di samping beberapa rumah di Jerman.
Setelah jam 5 pagi, tidak ada data pemantauan yang diterima—ini berarti baterai tambahan telah benar-benar habis, atau penyerang akhirnya menemukan cara untuk melepaskan perangkat keras pintar dari skuter.
Meski begitu, polisi tetap dipanggil ke alamat lokasi skuter itu berada. Skuter itu tidak ada di sana.
Namun pemilik rumah juga kaget dengan hal tersebut, karena ia sebenarnya mengendarai skuter tersebut pulang dari kantor tadi malam.
Ternyata, salah satu karyawan pendukung datang pagi-pagi sekali dan mengambil skuter tersebut, melihat baterai tambahannya sudah benar-benar habis dan membawanya (berjalan kaki) ke tempat parkir. Dan baterai tambahan rusak karena lembab.
Kami mencuri skuter itu dari diri kami sendiri. Ngomong-ngomong, saya tidak tahu bagaimana dan siapa yang kemudian menyelesaikan masalah kasus polisi tersebut, tetapi pemantauannya bekerja dengan sempurna...
Sumber: www.habr.com