Πριν από ένα χρόνο ξεκινήσαμε μια πιλοτική έκδοση ενός διαφημιστικού έργου για .
Αρχικά, το έργο ονομάστηκε Road-To-Barcelona, αργότερα έγινε Road-To-Berlin (εξ ου και R2B στα στιγμιότυπα οθόνης) και στο τέλος ονομάστηκε xRide.
Η βασική ιδέα του έργου ήταν η εξής: αντί να έχουμε μια κεντρική υπηρεσία ενοικίασης αυτοκινήτου ή σκούτερ (μιλάμε για σκούτερ γνωστά ως ηλεκτρικές μοτοσυκλέτες, όχι kickscooter/scooter) θέλαμε να δημιουργήσουμε μια πλατφόρμα για αποκεντρωμένη ενοικίαση. Για τις δυσκολίες που συναντήσαμε .
Αρχικά, το έργο επικεντρώθηκε στα αυτοκίνητα, αλλά λόγω των προθεσμιών, της εξαιρετικά μακράς επικοινωνίας με τους κατασκευαστές και ενός τεράστιου αριθμού περιορισμών ασφαλείας, επιλέχθηκαν ηλεκτρικά σκούτερ για τον πιλότο.
Ο χρήστης εγκατέστησε μια εφαρμογή iOS ή Android στο τηλέφωνο, πλησίασε το σκούτερ που του άρεσε, μετά το οποίο το τηλέφωνο και το σκούτερ δημιούργησαν μια peer-to-peer σύνδεση, το ETH ανταλλάχθηκε και ο χρήστης μπορούσε να ξεκινήσει τη βόλτα ενεργοποιώντας το σκούτερ μέσω το ΤΗΛΕΦΩΝΟ. Στο τέλος του ταξιδιού, ήταν επίσης δυνατή η πληρωμή για το ταξίδι χρησιμοποιώντας το Ethereum από το πορτοφόλι του χρήστη στο τηλέφωνο.
Εκτός από τα σκούτερ, ο χρήστης είδε «έξυπνους φορτιστές» στην εφαρμογή, επισκεπτόμενος τους οποίους ο χρήστης μπορούσε να αλλάξει μόνος του την τρέχουσα μπαταρία αν ήταν χαμηλή.
Έτσι ήταν γενικά ο πιλότος μας, ο οποίος ξεκίνησε τον Σεπτέμβριο του περασμένου έτους σε δύο γερμανικές πόλεις: τη Βόννη και το Βερολίνο.
Και τότε, μια μέρα, στη Βόννη, νωρίς το πρωί, η ομάδα υποστήριξής μας (που βρισκόταν στο χώρο για να διατηρεί τα σκούτερ σε κατάσταση λειτουργίας) ειδοποιήθηκε: ένα από τα σκούτερ είχε εξαφανιστεί χωρίς ίχνος.
Πώς να το βρείτε και να το επιστρέψετε;
Σε αυτό το άρθρο θα μιλήσω για αυτό, αλλά πρώτα - για το πώς δημιουργήσαμε τη δική μας πλατφόρμα IoT και πώς την παρακολουθούσαμε.
Τι και γιατί να παρακολουθείτε: σκούτερ, υποδομές, σταθμούς φόρτισης;
Λοιπόν, τι θέλαμε να παρακολουθήσουμε στο έργο μας;
Πρώτα απ 'όλα, αυτά είναι τα ίδια τα σκούτερ - τα ίδια τα ηλεκτρικά σκούτερ είναι αρκετά ακριβά, δεν μπορείτε να ξεκινήσετε ένα τέτοιο έργο χωρίς να είστε επαρκώς προετοιμασμένοι· εάν είναι δυνατόν, θέλετε να συλλέξετε όσο το δυνατόν περισσότερες πληροφορίες για τα σκούτερ: για τη θέση τους, το επίπεδο φόρτισης , και τα λοιπά.
Επιπλέον, θα ήθελα να παρακολουθώ την κατάσταση της δικής μας υποδομής πληροφορικής - βάσεις δεδομένων, υπηρεσίες και όλα όσα χρειάζονται για να λειτουργήσουν. Ήταν επίσης απαραίτητο να παρακολουθείται η κατάσταση των «έξυπνων φορτιστών», σε περίπτωση που χαλάσουν ή εξαντληθούν οι μπαταρίες.
σκούτερ
Τι ήταν τα σκούτερ μας και τι θέλαμε να μάθουμε για αυτά;
Το πρώτο και σημαντικότερο είναι οι συντεταγμένες GPS, αφού χάρη σε αυτές μπορούμε να καταλάβουμε πού βρίσκονται και πού κινούνται.
Ακολουθεί η φόρτιση της μπαταρίας, χάρη στην οποία μπορούμε να διαπιστώσουμε ότι η φόρτιση των σκούτερ τελειώνει και να στείλουμε έναν αποχυμωτή ή τουλάχιστον να προειδοποιήσουμε τον χρήστη.
Φυσικά, είναι επίσης απαραίτητο να ελέγξουμε τι συμβαίνει με τα στοιχεία υλικού μας:
- λειτουργεί το bluetooth;
- λειτουργεί η ίδια η μονάδα GPS;
- Είχαμε επίσης πρόβλημα με το γεγονός ότι το GPS μπορούσε να στείλει λανθασμένες συντεταγμένες και να κολλήσει, και αυτό μπορούσε να προσδιοριστεί μόνο με πρόσθετους ελέγχους στο σκούτερ,
και ειδοποιήστε την υποστήριξη το συντομότερο δυνατό για την επίλυση του προβλήματος
- Είχαμε επίσης πρόβλημα με το γεγονός ότι το GPS μπορούσε να στείλει λανθασμένες συντεταγμένες και να κολλήσει, και αυτό μπορούσε να προσδιοριστεί μόνο με πρόσθετους ελέγχους στο σκούτερ,
Και τέλος: έλεγχοι του λογισμικού, ξεκινώντας από το λειτουργικό σύστημα και τον επεξεργαστή, το δίκτυο και τη φόρτωση δίσκου, που τελειώνουν με ελέγχους των δικών μας μονάδων που είναι πιο συγκεκριμένα για εμάς (, ).
υλικού
Ποιο ήταν το «σιδερένιο» μέρος μας;
Λαμβάνοντας υπόψη το συντομότερο δυνατό χρονικό πλαίσιο και την ανάγκη για γρήγορη δημιουργία πρωτοτύπων, επιλέξαμε την ευκολότερη επιλογή για υλοποίηση και επιλογή εξαρτημάτων - το Raspberry Pi.
Εκτός από το ίδιο το Rpi, είχαμε μια προσαρμοσμένη πλακέτα (την οποία εμείς οι ίδιοι αναπτύξαμε και παραγγείλαμε από την Κίνα για να επιταχύνουμε τη διαδικασία συναρμολόγησης της τελικής λύσης) και ένα σύνολο εξαρτημάτων - ένα ρελέ (για την ενεργοποίηση/απενεργοποίηση του σκούτερ), συσκευή ανάγνωσης φόρτισης μπαταρίας, μόντεμ, κεραίες. Όλα αυτά συσκευάστηκαν συμπαγή σε ένα ειδικό κουτί xRide.
Να σημειωθεί επίσης ότι ολόκληρο το κιβώτιο τροφοδοτείτο από ένα επιπλέον power bank, το οποίο με τη σειρά του τροφοδοτείτο από την κύρια μπαταρία του σκούτερ.
Αυτό κατέστησε δυνατή τη χρήση παρακολούθησης και την ενεργοποίηση του σκούτερ ακόμη και μετά το τέλος του ταξιδιού, καθώς η κύρια μπαταρία απενεργοποιήθηκε αμέσως μετά το γύρισμα του κλειδιού της μίζας στη θέση "off".
Λιμενεργάτης? Απλό Linux; και ανάπτυξη
Ας επιστρέψουμε στην παρακολούθηση, οπότε Raspberry - τι έχουμε;
Ένα από τα πρώτα πράγματα που θέλαμε να χρησιμοποιήσουμε για να επιταχύνουμε τη διαδικασία ανάπτυξης, ενημέρωσης και παράδοσης στοιχείων σε φυσικές συσκευές ήταν το Docker.
Δυστυχώς, γρήγορα έγινε σαφές ότι το Docker on RPi, αν και λειτουργεί, έχει πολλά γενικά έξοδα, ιδιαίτερα όσον αφορά την κατανάλωση ενέργειας.
Η διαφορά με τη χρήση του «εγγενούς» λειτουργικού συστήματος, αν και όχι τόσο ισχυρή, ήταν αρκετή για να είμαστε επιφυλακτικοί σχετικά με την πιθανότητα απώλειας φόρτισης πολύ γρήγορα.
Ο δεύτερος λόγος ήταν μια από τις βιβλιοθήκες συνεργατών μας στο Node.js (sic!) - το μόνο στοιχείο του συστήματος που δεν ήταν γραμμένο σε Go/C/C++.
Οι συγγραφείς της βιβλιοθήκης δεν είχαν χρόνο να παράσχουν μια λειτουργική έκδοση σε καμία από τις «μητρικές» γλώσσες.
Όχι μόνο ο ίδιος ο κόμβος δεν είναι η πιο κομψή λύση για συσκευές χαμηλής απόδοσης, αλλά και η ίδια η βιβλιοθήκη ήταν πολύ διψασμένη για πόρους.
Συνειδητοποιήσαμε ότι, ακόμα κι αν το θέλαμε, η χρήση του Docker θα ήταν υπερβολικό κόστος για εμάς. Η επιλογή έγινε υπέρ του εγγενούς λειτουργικού συστήματος και εργασίας απευθείας κάτω από αυτό.
OS
Ως αποτέλεσμα, επιλέξαμε ξανά την απλούστερη επιλογή ως λειτουργικό σύστημα και χρησιμοποιήσαμε το Raspbian (Debian build για Pi).
Γράφουμε όλο το λογισμικό μας στο Go, επομένως γράψαμε και την κύρια μονάδα υλικού πράκτορα στο σύστημά μας στο Go.
Είναι αυτός που είναι υπεύθυνος για την εργασία με το GPS, το Bluetooth, την ανάγνωση της φόρτισης, την ενεργοποίηση του σκούτερ κ.λπ.
Αναπτύσσω
Αμέσως προέκυψε το ερώτημα σχετικά με την ανάγκη εφαρμογής ενός μηχανισμού για την παροχή ενημερώσεων σε συσκευές (OTA) - τόσο ενημερώσεις στον ίδιο τον παράγοντα/εφαρμογή μας όσο και ενημερώσεις στο ίδιο το λειτουργικό σύστημα/υλικολογισμικό (καθώς οι νέες εκδόσεις του παράγοντα ενδέχεται να απαιτούν ενημερώσεις στον πυρήνα ή στοιχεία συστήματος, βιβλιοθήκες, κ.λπ.) .
Μετά από αρκετά μεγάλη ανάλυση της αγοράς, αποδείχθηκε ότι υπάρχουν πολλές λύσεις για την παροχή ενημερώσεων στη συσκευή.
Από σχετικά απλά βοηθητικά προγράμματα που προσανατολίζονται κυρίως στην ενημέρωση/διπλή εκκίνηση όπως το swupd/SWUpdate/OSTree έως πλήρεις πλατφόρμες όπως η Mender και η Balena.
Πρώτα απ 'όλα, αποφασίσαμε ότι μας ενδιέφεραν λύσεις από άκρο σε άκρο, οπότε η επιλογή έπεσε αμέσως στις πλατφόρμες.
Το πολύ αποκλείστηκε λόγω του γεγονότος ότι χρησιμοποιεί πραγματικά το ίδιο Docker μέσα στο balenaEngine του.
Σημειώνω όμως ότι παρόλα αυτά, καταλήξαμε να χρησιμοποιούμε συνεχώς το προϊόν τους για υλικολογισμικό flash σε κάρτες SD - ένα απλό και εξαιρετικά βολικό βοηθητικό πρόγραμμα για αυτό.
Ως εκ τούτου, στο τέλος η επιλογή έπεσε . Το Mender είναι μια πλήρης πλατφόρμα για τη συναρμολόγηση, την παράδοση και την εγκατάσταση υλικολογισμικού.
Συνολικά, η πλατφόρμα φαίνεται υπέροχη, αλλά μας πήρε περίπου μιάμιση εβδομάδα μόνο για να δημιουργήσουμε τη σωστή έκδοση του υλικολογισμικού μας χρησιμοποιώντας το πρόγραμμα δημιουργίας mender.
Και όσο περισσότερο βυθιζόμασταν στις περιπλοκές της χρήσης του, τόσο περισσότερο γινόταν σαφές ότι για να το αναπτύξουμε πλήρως θα χρειαζόμασταν πολύ περισσότερο χρόνο από ό,τι είχαμε.
Αλίμονο, οι στενές προθεσμίες μας σήμαιναν ότι αναγκαστήκαμε να εγκαταλείψουμε τη χρήση του Mender και να επιλέξουμε ένα ακόμα πιο απλό.
Πιθανό
Η απλούστερη λύση στην περίπτωσή μας ήταν να χρησιμοποιήσουμε το Ansible. Μερικά βιβλία ήταν αρκετά για να ξεκινήσετε.
Η ουσία τους ήταν ότι απλώς συνδεθήκαμε από τον κεντρικό υπολογιστή (διακομιστής CI) μέσω ssh στα rasberries μας και τους μοιράζαμε ενημερώσεις.
Στην αρχή, όλα ήταν απλά - έπρεπε να είσαι στο ίδιο δίκτυο με τις συσκευές, η έκχυση γινόταν μέσω Wi-Fi.
Στο γραφείο υπήρχαν απλώς μια ντουζίνα δοκιμαστικά βατόμουρα συνδεδεμένα στο ίδιο δίκτυο, κάθε συσκευή είχε μια στατική διεύθυνση IP που προσδιορίστηκε επίσης στο Ansible Inventory.
Ήταν η Ansible που παρέδωσε τον παράγοντα παρακολούθησης στις τελικές συσκευές
3G / LTE
Δυστυχώς, αυτή η περίπτωση χρήσης για το Ansible μπορούσε να λειτουργήσει μόνο σε λειτουργία ανάπτυξης προτού είχαμε πραγματικά σκούτερ.
Επειδή τα σκούτερ, όπως καταλαβαίνετε, δεν κάθονται συνδεδεμένα σε έναν δρομολογητή Wi-Fi, περιμένοντας συνεχώς ενημερώσεις μέσω του δικτύου.
Στην πραγματικότητα, τα σκούτερ δεν μπορούν να έχουν καμία άλλη σύνδεση εκτός από το κινητό 3G/LTE (και ακόμη και τότε όχι όλη την ώρα).
Αυτό αμέσως επιβάλλει πολλά προβλήματα και περιορισμούς, όπως χαμηλή ταχύτητα σύνδεσης και ασταθή επικοινωνία.
Το πιο σημαντικό όμως είναι ότι σε ένα δίκτυο 3G/LTE δεν μπορούμε απλώς να βασιζόμαστε σε μια στατική IP που έχει εκχωρηθεί στο δίκτυο.
Αυτό επιλύεται εν μέρει από ορισμένους παρόχους καρτών SIM· υπάρχουν ακόμη και ειδικές κάρτες SIM που έχουν σχεδιαστεί για συσκευές IoT με στατικές διευθύνσεις IP. Αλλά δεν είχαμε πρόσβαση σε τέτοιες κάρτες SIM και δεν μπορούσαμε να χρησιμοποιήσουμε διευθύνσεις IP.
Φυσικά, υπήρχαν ιδέες να κάνουμε κάποιου είδους καταχώριση διευθύνσεων IP aka service discovery κάπου όπως το Consul, αλλά έπρεπε να εγκαταλείψουμε τέτοιες ιδέες, καθώς στις δοκιμές μας η διεύθυνση IP μπορούσε να αλλάξει πολύ συχνά, γεγονός που οδήγησε σε μεγάλη αστάθεια.
Για αυτόν τον λόγο, η πιο βολική χρήση για την παράδοση μετρήσεων δεν θα ήταν η χρήση του μοντέλου έλξης, όπου θα πηγαίναμε σε συσκευές για τις απαραίτητες μετρήσεις, αλλά θα ωθήσουμε, παραδίδοντας μετρήσεις από τη συσκευή απευθείας στον διακομιστή
VPN
Ως λύση σε αυτό το πρόβλημα, επιλέξαμε το VPN - συγκεκριμένα .
Οι πελάτες (σκούτερ) στην αρχή του συστήματος συνδέθηκαν στον διακομιστή VPN και μπόρεσαν να συνδεθούν μαζί τους. Αυτή η σήραγγα χρησιμοποιήθηκε για την παροχή ενημερώσεων.
Θεωρητικά, η ίδια σήραγγα θα μπορούσε να χρησιμοποιηθεί για παρακολούθηση, αλλά μια τέτοια σύνδεση ήταν πιο περίπλοκη και λιγότερο αξιόπιστη από την απλή ώθηση.
Πόροι στο σύννεφο
Τέλος, είναι απαραίτητο να παρακολουθούμε τις υπηρεσίες cloud και τις βάσεις δεδομένων μας, αφού χρησιμοποιούμε το Kubernetes για αυτές, ιδανικά, ώστε η ανάπτυξη της παρακολούθησης στο σύμπλεγμα να είναι όσο το δυνατόν πιο απλή. Ιδανικά, χρησιμοποιώντας , αφού για ανάπτυξη, το χρησιμοποιούμε στις περισσότερες περιπτώσεις. Και, φυσικά, για την παρακολούθηση του νέφους πρέπει να χρησιμοποιήσετε τις ίδιες λύσεις όπως και για τα ίδια τα σκούτερ.
Δεδομένος
Φευ, φαίνεται ότι έχουμε τακτοποιήσει την περιγραφή, ας κάνουμε μια λίστα με αυτά που χρειαζόμασταν στο τέλος:
- Μια γρήγορη λύση, αφού η παρακολούθηση είναι απαραίτητη ήδη κατά τη διαδικασία ανάπτυξης
- Όγκος/ποσότητα – απαιτούνται πολλές μετρήσεις
- Απαιτείται συλλογή αρχείων καταγραφής
- Αξιοπιστία - τα δεδομένα είναι κρίσιμα για την επιτυχία της εκκίνησης
- Δεν μπορείτε να χρησιμοποιήσετε το μοντέλο έλξης - χρειάζεστε ώθηση
- Χρειαζόμαστε ενοποιημένη παρακολούθηση όχι μόνο του υλικού, αλλά και του cloud
Η τελική εικόνα έμοιαζε κάπως έτσι
Επιλογή στοίβας
Έτσι, βρεθήκαμε αντιμέτωποι με το ζήτημα της επιλογής μιας στοίβας παρακολούθησης.
Πρώτα απ 'όλα, αναζητούσαμε την πιο ολοκληρωμένη λύση all-in-one που θα κάλυπτε ταυτόχρονα όλες τις απαιτήσεις μας, αλλά ταυτόχρονα θα ήταν αρκετά ευέλικτη ώστε να προσαρμόζει τη χρήση της στις ανάγκες μας. Ωστόσο, είχαμε πολλούς περιορισμούς που μας επιβλήθηκαν από υλικό, αρχιτεκτονική και προθεσμίες.
Υπάρχει μια τεράστια ποικιλία λύσεων παρακολούθησης, ξεκινώντας από ολοκληρωμένα συστήματα όπως , ή και τελειώνει με έτοιμες λύσεις διαχείρισης στόλου.
Αρχικά, το τελευταίο φαινόταν ιδανική λύση για εμάς, αλλά κάποιοι δεν είχαν πλήρη παρακολούθηση, άλλοι είχαν σοβαρά περιορισμένες δυνατότητες των δωρεάν εκδόσεων και άλλοι απλά δεν κάλυπταν τα «θέλω» μας ή δεν ήταν αρκετά ευέλικτοι για να ταιριάζουν στα σενάρια μας. Μερικά είναι απλά ξεπερασμένα.
Αφού αναλύσαμε μια σειρά από παρόμοιες λύσεις, καταλήξαμε γρήγορα στο συμπέρασμα ότι θα ήταν ευκολότερο και πιο γρήγορο να συναρμολογήσουμε μόνοι μας μια παρόμοια στοίβα. Ναι, θα είναι λίγο πιο περίπλοκο από την ανάπτυξη μιας εντελώς έτοιμης πλατφόρμας διαχείρισης στόλου, αλλά δεν θα χρειαστεί να κάνουμε συμβιβασμούς.
Σχεδόν σίγουρα, σε όλη την τεράστια αφθονία λύσεων, υπάρχει ήδη μια έτοιμη που θα μας ταίριαζε απόλυτα, αλλά στην περίπτωσή μας ήταν πολύ πιο γρήγορο να συναρμολογήσουμε μια συγκεκριμένη στοίβα μόνοι μας και να την προσαρμόσουμε "για τον εαυτό μας" παρά δοκιμή έτοιμων προϊόντων.
Με όλα αυτά, δεν προσπαθήσαμε να συγκεντρώσουμε μόνοι μας μια ολόκληρη πλατφόρμα παρακολούθησης, αλλά αναζητούσαμε τις πιο λειτουργικές «έτοιμες» στοίβες, μόνο με τη δυνατότητα να τις διαμορφώσουμε με ευελιξία.
(Β)ΕΛΚ;
Η πρώτη λύση που ουσιαστικά εξετάστηκε ήταν η γνωστή στοίβα ELK.
Μάλιστα, θα έπρεπε να λέγεται BELK, γιατί όλα ξεκινούν από το Beats -
Φυσικά, το ELK είναι μια από τις πιο διάσημες και ισχυρές λύσεις στον τομέα της παρακολούθησης και ακόμη περισσότερο στη συλλογή και επεξεργασία κορμών.
Σκοπεύαμε ότι το ELK θα χρησιμοποιηθεί για τη συλλογή αρχείων καταγραφής και καθώς και για τη μακροπρόθεσμη αποθήκευση των μετρήσεων που λαμβάνονται από τον Prometheus.
Για οπτικοποίηση μπορείτε να χρησιμοποιήσετε το Grafan.
Στην πραγματικότητα, η νέα στοίβα ELK μπορεί να συλλέξει μετρήσεις ανεξάρτητα (metricbeat) και η Kibana μπορεί επίσης να τις εμφανίσει.
Ωστόσο, το ELK αρχικά μεγάλωσε από αρχεία καταγραφής και μέχρι στιγμής η λειτουργικότητα των μετρήσεων έχει ορισμένα σοβαρά μειονεκτήματα:
- Σημαντικά πιο αργός από τον Προμηθέα
- Ενσωματώνεται σε πολύ λιγότερα μέρη από τον Προμηθέα
- Είναι δύσκολο να ρυθμίσετε ειδοποιήσεις για αυτούς
- Οι μετρήσεις καταλαμβάνουν πολύ χώρο
- Η ρύθμιση πινάκων εργαλείων με μετρήσεις στο Kiban είναι πολύ πιο περίπλοκη από ό,τι στο Grafan
Σε γενικές γραμμές, οι μετρήσεις στο ELK είναι βαριές και δεν είναι ακόμα τόσο βολικές όσο σε άλλες λύσεις, από τις οποίες πλέον υπάρχουν πολλά περισσότερα από τον Prometheus: TSDB, Victoria Metrics, Cortex, κ.λπ., κ.λπ. Φυσικά, θα ήθελα πολύ να έχω μια ολοκληρωμένη λύση all-in-one αμέσως, αλλά στην περίπτωση του metricbeat υπήρχαν πάρα πολλοί συμβιβασμούς.
Και η ίδια η στοίβα ELK έχει πολλές δύσκολες στιγμές:
- Είναι βαρύ, μερικές φορές ακόμη και πολύ βαρύ αν συλλέγετε αρκετά μεγάλο όγκο δεδομένων
- Πρέπει να «ξέρετε πώς να το μαγειρεύετε» - πρέπει να το κλιμακώσετε, αλλά αυτό δεν είναι ασήμαντο να το κάνετε
- Απογυμνωμένη δωρεάν έκδοση - η δωρεάν έκδοση δεν έχει κανονική ειδοποίηση και κατά τη στιγμή της επιλογής δεν υπήρχε έλεγχος ταυτότητας
Πρέπει να πω ότι πρόσφατα το τελευταίο σημείο έχει γίνει καλύτερο και επιπλέον (συμπεριλαμβανομένου του ελέγχου ταυτότητας) το ίδιο το μοντέλο τιμολόγησης άρχισε να αλλάζει.
Αλλά τη στιγμή που επρόκειτο να αναπτύξουμε αυτή τη λύση, δεν υπήρχε καμία ειδοποίηση.
Ίσως θα μπορούσαμε να είχαμε προσπαθήσει να δημιουργήσουμε κάτι χρησιμοποιώντας το ElastAlert ή άλλες λύσεις κοινότητας, αλλά και πάλι αποφασίσαμε να εξετάσουμε άλλες εναλλακτικές λύσεις.
Λόκι - Γραφάνα - Προμηθέας
Προς το παρόν, μια καλή λύση μπορεί να είναι η δημιουργία μιας στοίβας παρακολούθησης που βασίζεται αποκλειστικά στον Προμηθέα ως πάροχο μετρήσεων, το Loki για αρχεία καταγραφής και για οπτικοποίηση μπορείτε να χρησιμοποιήσετε το ίδιο Grafana.
Δυστυχώς, κατά την έναρξη του πιλότου πωλήσεων του έργου (Σεπτέμβριος-Οκτώβριος 19), το Loki ήταν ακόμα σε beta έκδοση 0.3-0.4 και κατά την έναρξη της ανάπτυξης δεν μπορούσε να θεωρηθεί ως λύση παραγωγής καθόλου.
Δεν έχω ακόμη εμπειρία στη χρήση του Loki σε σοβαρά έργα, αλλά μπορώ να πω ότι το Promtail (ένας πράκτορας συλλογής κορμών) λειτουργεί εξαιρετικά τόσο για bare-metal όσο και για pods στα kubernetes.
ΤΣΙΜΠΟΥΡΙ
Ίσως η πιο άξια (η μόνη;) πλήρης εναλλακτική λύση στη στοίβα ELK μπορεί πλέον να ονομάζεται μόνο στοίβα TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Θα περιγράψω όλα τα στοιχεία παρακάτω με περισσότερες λεπτομέρειες, αλλά η γενική ιδέα είναι η εξής:
- Telegraf - πράκτορας συλλογής μετρήσεων
- InfluxDB - βάση δεδομένων μετρήσεων
- Kapacitor - επεξεργαστής μετρήσεων σε πραγματικό χρόνο για ειδοποίηση
- Chronograf - web panel για οπτικοποίηση
Για το InfluxDB, το Kapacitor και το Chronograf υπάρχουν επίσημα γραφήματα πηδαλίου που χρησιμοποιήσαμε για να τα αναπτύξουμε.
Θα πρέπει να σημειωθεί ότι στην τελευταία έκδοση του Influx 2.0 (beta), το Kapacitor και το Chronograf έγιναν μέρος του InfluxDB και δεν υπάρχουν πλέον ξεχωριστά
Τηλεγράφημα
είναι ένας πολύ ελαφρύς παράγοντας για τη συλλογή μετρήσεων σε μια μηχανή κατάστασης.
Μπορεί να παρακολουθεί ένα τεράστιο ποσό από τα πάντα, από να
υπηρέτης .
Έχει μια σειρά από δροσερά πλεονεκτήματα:
- Γρήγορο και ελαφρύ (γραμμένο στο Go)
- Τρώει ένα ελάχιστο ποσό πόρων
- Push metrics από προεπιλογή
- Συλλέγει όλες τις απαραίτητες μετρήσεις
- Μετρήσεις συστήματος χωρίς ρυθμίσεις
- Μετρήσεις υλικού, όπως πληροφορίες από αισθητήρες
- Είναι πολύ εύκολο να προσθέσετε τις δικές σας μετρήσεις
- Πολλά πρόσθετα από το κουτί
- Συλλέγει κορμούς
Δεδομένου ότι οι μετρήσεις ώθησης ήταν απαραίτητες για εμάς, όλα τα άλλα πλεονεκτήματα ήταν κάτι περισσότερο από ευχάριστες προσθήκες.
Η συλλογή αρχείων καταγραφής από τον ίδιο τον πράκτορα είναι επίσης πολύ βολική, καθώς δεν χρειάζεται να συνδέσετε πρόσθετα βοηθητικά προγράμματα για την καταγραφή αρχείων καταγραφής.
Το Influx προσφέρει την πιο βολική εμπειρία για εργασία με αρχεία καταγραφής εάν χρησιμοποιείτε .
Το Telegraf είναι γενικά ένας εξαιρετικός πράκτορας για τη συλλογή μετρήσεων, ακόμα κι αν δεν χρησιμοποιείτε την υπόλοιπη στοίβα του ICK.
Πολλοί το διασταυρώνουν με ELK και διάφορες άλλες βάσεις δεδομένων χρονοσειρών για ευκολία, αφού μπορεί να γράψει μετρήσεις σχεδόν παντού.
InfluxDB
Το InfluxDB είναι ο κύριος πυρήνας της στοίβας TICK, δηλαδή μια βάση δεδομένων χρονοσειρών για μετρήσεις.
Εκτός από τις μετρήσεις, το Influx μπορεί επίσης να αποθηκεύσει αρχεία καταγραφής, αν και, στην ουσία, τα αρχεία καταγραφής για αυτό είναι ακριβώς οι ίδιες μετρήσεις, μόνο που αντί των συνηθισμένων αριθμητικών δεικτών, η κύρια λειτουργία εκτελείται από μια γραμμή κειμένου καταγραφής.
Το InfluxDB είναι επίσης γραμμένο στο Go και φαίνεται να τρέχει πολύ πιο γρήγορα σε σύγκριση με το ELK στο (όχι το πιο ισχυρό) σύμπλεγμα μας.
Ένα από τα συναρπαστικά πλεονεκτήματα του Influx θα περιλαμβάνει επίσης ένα πολύ βολικό και πλούσιο API για ερωτήματα δεδομένων, το οποίο χρησιμοποιήσαμε πολύ ενεργά.
Μειονεκτήματα - $$$ ή κλιμάκωση;
Η στοίβα TICK έχει μόνο ένα μειονέκτημα που ανακαλύψαμε - αυτό αγαπώ. Ακόμα περισσότερο.
Τι έχει η πληρωμένη έκδοση που δεν έχει η δωρεάν έκδοση;
Από όσο καταλάβαμε, η μόνη διαφορά μεταξύ της πληρωμένης έκδοσης της στοίβας TICK και της δωρεάν είναι οι δυνατότητες κλιμάκωσης.
Δηλαδή, μπορείτε να δημιουργήσετε ένα σύμπλεγμα με Υψηλή διαθεσιμότητα μόνο στο .
Εάν θέλετε πλήρες HA, πρέπει είτε να πληρώσετε είτε να χρησιμοποιήσετε μερικές πατερίτσες. Υπάρχουν μερικές κοινοτικές λύσεις - για παράδειγμα μοιάζει με ικανή λύση, αλλά γράφεται ότι δεν είναι κατάλληλο για παραγωγή, καθώς επίσης
- μια απλή λύση με άντληση δεδομένων μέσω NATS (θα πρέπει επίσης να κλιμακωθεί, αλλά αυτό μπορεί να λυθεί).
Είναι κρίμα, αλλά και τα δύο φαίνεται να έχουν εγκαταλειφθεί - δεν υπάρχουν νέες δεσμεύσεις, υποθέτω ότι το θέμα είναι η σύντομα αναμενόμενη κυκλοφορία της νέας έκδοσης του Influx 2.0, στην οποία πολλά πράγματα θα είναι διαφορετικά (δεν υπάρχουν πληροφορίες για κλιμάκωση σε αυτό ακόμα).
Επίσημα υπάρχει μια δωρεάν έκδοση - στην πραγματικότητα, αυτό είναι ένα πρωτόγονο HA, αλλά μόνο μέσω της εξισορρόπησης,
αφού όλα τα δεδομένα θα εγγραφούν σε όλες τις παρουσίες InfluxDB πίσω από το load balancer.
Έχει μερικά όπως πιθανά προβλήματα με την αντικατάσταση σημείων και την ανάγκη δημιουργίας βάσεων για μετρήσεις εκ των προτέρων
(το οποίο συμβαίνει αυτόματα κατά τη διάρκεια της κανονικής εργασίας με το InfluxDB).
Επιπλέον , αυτό σημαίνει πρόσθετο κόστος για διπλότυπες μετρήσεις (τόσο επεξεργασία όσο και αποθήκευση) που μπορεί να μην χρειάζεστε, αλλά δεν υπάρχει τρόπος να τις διαχωρίσετε.
Victoria Metrics;
Ως αποτέλεσμα, παρά το γεγονός ότι ήμασταν απόλυτα ικανοποιημένοι με τη στοίβα TICK σε οτιδήποτε άλλο εκτός από την επί πληρωμή κλιμάκωση, αποφασίσαμε να δούμε αν υπήρχαν δωρεάν λύσεις που θα μπορούσαν να αντικαταστήσουν τη βάση δεδομένων InfluxDB, αφήνοντας τα υπόλοιπα στοιχεία T_CK.
Υπάρχουν πολλές βάσεις δεδομένων χρονοσειρών, αλλά η πιο πολλά υποσχόμενη είναι η Victoria Metrics, έχει μια σειρά από πλεονεκτήματα:
- Γρήγορα και εύκολα, τουλάχιστον σύμφωνα με τα αποτελέσματα
- Υπάρχει μια έκδοση συμπλέγματος, για την οποία υπάρχουν ακόμη και καλές κριτικές τώρα
- Μπορεί να θρυμματίσει
- Υποστηρίζει πρωτόκολλο InfluxDB
Δεν σκοπεύαμε να δημιουργήσουμε μια εντελώς προσαρμοσμένη στοίβα βασισμένη στη Victoria και η βασική ελπίδα ήταν ότι θα μπορούσαμε να τη χρησιμοποιήσουμε ως ένα drop-in αντικατάσταση για το InfluxDB.
Δυστυχώς, αυτό δεν είναι δυνατό, παρά το γεγονός ότι υποστηρίζεται το πρωτόκολλο InfluxDB, λειτουργεί μόνο για την εγγραφή μετρήσεων - μόνο το Prometheus API είναι διαθέσιμο "εξωτερικά", πράγμα που σημαίνει ότι δεν θα είναι δυνατό να ρυθμίσετε το Chronograf σε αυτό.
Επιπλέον, υποστηρίζονται μόνο αριθμητικές τιμές για μετρήσεις (χρησιμοποιήσαμε τιμές συμβολοσειρών για προσαρμοσμένες μετρήσεις - περισσότερα για αυτό στην ενότητα ).
Προφανώς, για τον ίδιο λόγο, το VM δεν μπορεί να αποθηκεύσει αρχεία καταγραφής όπως το Influx.
Επίσης, πρέπει να σημειωθεί ότι τη στιγμή της αναζήτησης της βέλτιστης λύσης, η Victoria Metrics δεν ήταν ακόμη τόσο δημοφιλής, η τεκμηρίωση ήταν πολύ μικρότερη και η λειτουργικότητα ήταν πιο αδύναμη
(Δεν θυμάμαι λεπτομερή περιγραφή της έκδοσης συμπλέγματος και του διαμοιρασμού).
Επιλογή βάσης
Ως αποτέλεσμα, αποφασίστηκε ότι για τον πιλότο θα περιοριστούμε σε έναν μόνο κόμβο InfluxDB.
Υπήρχαν αρκετοί κύριοι λόγοι για αυτήν την επιλογή:
- Μας άρεσε πολύ η όλη λειτουργικότητα της στοίβας TICK
- Ήδη καταφέραμε να το αναπτύξουμε και λειτούργησε εξαιρετικά
- Οι προθεσμίες εξαντλούνταν και δεν υπήρχε πολύς χρόνος για να δοκιμάσετε άλλες επιλογές.
- Δεν περιμέναμε τόσο βαρύ φορτίο
Δεν είχαμε πολλά σκούτερ για την πρώτη φάση του πιλότου και οι δοκιμές κατά την ανάπτυξη δεν αποκάλυψαν προβλήματα απόδοσης.
Ως εκ τούτου, αποφασίσαμε ότι για αυτό το έργο ένας κόμβος εισροής θα μας αρκούσε χωρίς την ανάγκη κλιμάκωσης (βλ. συμπεράσματα στο τέλος).
Αποφασίσαμε για τη στοίβα και τη βάση - τώρα για τα υπόλοιπα στοιχεία της στοίβας TICK.
Πυκνωτής
Το Kapacitor είναι μέρος της στοίβας TICK, μιας υπηρεσίας που μπορεί να παρακολουθεί μετρήσεις που εισέρχονται στη βάση δεδομένων σε πραγματικό χρόνο και να εκτελεί διάφορες ενέργειες με βάση κανόνες.
Γενικά, τοποθετείται ως εργαλείο για την παρακολούθηση πιθανών ανωμαλιών και τη μηχανική εκμάθηση (δεν είμαι σίγουρος ότι αυτές οι λειτουργίες είναι σε ζήτηση), αλλά η πιο δημοφιλής περίπτωση χρήσης του είναι πιο συνηθισμένη - η ειδοποίηση.
Έτσι το χρησιμοποιήσαμε για ειδοποιήσεις. Ρυθμίσαμε ειδοποιήσεις Slack όταν ένα συγκεκριμένο σκούτερ βγήκε εκτός σύνδεσης και το ίδιο έγινε για έξυπνους φορτιστές και σημαντικά εξαρτήματα υποδομής.
Αυτό κατέστησε δυνατή τη γρήγορη απόκριση σε προβλήματα, καθώς και τη λήψη ειδοποιήσεων ότι όλα επέστρεψαν στο κανονικό.
Ένα απλό παράδειγμα: μια πρόσθετη μπαταρία για την τροφοδοσία του «κουτιού» μας έχει χαλάσει ή για κάποιο λόγο έχει εξαντληθεί η ισχύς, απλά τοποθετώντας μια νέα, μετά από λίγο θα λάβουμε μια ειδοποίηση ότι η λειτουργία του σκούτερ έχει αποκατασταθεί.
Στο Influx 2.0, ο Kapacitor έγινε μέρος της DB
Χρονογράφος
Έχω δει πολλές διαφορετικές λύσεις UI για παρακολούθηση, αλλά μπορώ να πω ότι όσον αφορά τη λειτουργικότητα και το UX, τίποτα δεν συγκρίνεται με το Chronograf.
Αρχίσαμε να χρησιμοποιούμε τη στοίβα TICK, παραδόξως, με το Grafan ως διεπαφή ιστού.
Δεν θα περιγράψω τη λειτουργικότητά του· όλοι γνωρίζουν τις ευρείες δυνατότητές του για προσαρμογή οτιδήποτε.
Ωστόσο, το Grafana εξακολουθεί να είναι ένα εντελώς καθολικό όργανο, ενώ το Chronograf έχει σχεδιαστεί κυρίως για χρήση με το Influx.
Και φυσικά, χάρη σε αυτό, το Chronograf μπορεί να αντέξει οικονομικά πολύ πιο έξυπνη ή βολική λειτουργικότητα.
Ίσως η κύρια ευκολία της εργασίας με το Chronograf είναι ότι μπορείτε να προβάλετε το εσωτερικό του InfluxDB σας μέσω του Explore.
Φαίνεται ότι το Grafana έχει σχεδόν την ίδια λειτουργικότητα, αλλά στην πραγματικότητα, η ρύθμιση ενός πίνακα εργαλείων στο Chronograf μπορεί να γίνει με μερικά κλικ του ποντικιού (ταυτόχρονα κοιτάζοντας την οπτικοποίηση εκεί), ενώ στο Grafana θα έχετε ακόμα αργά ή γρήγορα για να επεξεργαστείτε τη διαμόρφωση JSON (φυσικά το Chronograf επιτρέπει τη μεταφόρτωση των dasha που έχετε διαμορφώσει με το χέρι και να τα επεξεργαστείτε ως JSON εάν είναι απαραίτητο - αλλά ποτέ δεν χρειάστηκε να τα αγγίξω αφού τα δημιούργησα στο UI).
Το Kibana έχει πολύ πιο πλούσιες δυνατότητες για τη δημιουργία πινάκων εργαλείων και χειριστηρίων για αυτά, αλλά το UX για τέτοιες λειτουργίες είναι πολύ περίπλοκο.
Θα χρειαστεί κάποια καλή κατανόηση για τη δημιουργία ενός βολικού ταμπλό. Και παρόλο που η λειτουργικότητα των ταμπλό του Chronograf είναι μικρότερη, η κατασκευή και η προσαρμογή τους είναι πολύ πιο απλή.
Τα ίδια τα ταμπλό, εκτός από το ευχάριστο οπτικό στυλ, στην πραγματικότητα δεν διαφέρουν από τα ταμπλό στα Grafana ή Kibana:
Έτσι φαίνεται το παράθυρο ερωτήματος:
Είναι σημαντικό να σημειωθεί, μεταξύ άλλων, ότι γνωρίζοντας τους τύπους πεδίων στη βάση δεδομένων InfluxDB, ο ίδιος ο χρονογράφος μπορεί μερικές φορές να σας βοηθήσει αυτόματα στη σύνταξη ενός ερωτήματος ή στην επιλογή της σωστής συνάρτησης συγκέντρωσης, όπως ο μέσος όρος.
Και φυσικά, το Chronograf είναι όσο το δυνατόν πιο βολικό για την προβολή αρχείων καταγραφής. Μοιάζει με αυτό:
Από προεπιλογή, τα αρχεία καταγραφής εισροής είναι προσαρμοσμένα για χρήση του syslog και επομένως έχουν μια σημαντική παράμετρο - σοβαρότητα.
Το γράφημα στο επάνω μέρος είναι ιδιαίτερα χρήσιμο· σε αυτό μπορείτε να δείτε τα σφάλματα που εμφανίζονται και το χρώμα δείχνει αμέσως καθαρά εάν η σοβαρότητα είναι μεγαλύτερη.
Μερικές φορές πιάσαμε σημαντικά σφάλματα με αυτόν τον τρόπο, πηγαίνοντας να δούμε τα αρχεία καταγραφής για την τελευταία εβδομάδα και είδαμε μια κόκκινη ακίδα.
Φυσικά, ιδανικά θα ήταν να ρυθμίσουμε ειδοποιήσεις για τέτοια σφάλματα, αφού είχαμε ήδη τα πάντα για αυτό.
Το ενεργοποιήσαμε ακόμη και για λίγο, αλλά κατά τη διαδικασία προετοιμασίας του πιλότου αποδείχθηκε ότι λαμβάναμε αρκετά σφάλματα (συμπεριλαμβανομένων των συστημάτων όπως η μη διαθεσιμότητα του δικτύου LTE), τα οποία "σπαμούσαν" και το κανάλι Slack πολύ, χωρίς να προκαλεί κανένα πρόβλημα.μεγάλο όφελος.
Η σωστή λύση θα ήταν να χειριστείτε τα περισσότερα από αυτά τα είδη σφαλμάτων, να προσαρμόσετε τη σοβαρότητά τους και μόνο τότε να ενεργοποιήσετε την ειδοποίηση.
Με αυτόν τον τρόπο, μόνο νέα ή σημαντικά σφάλματα θα δημοσιεύονταν στο Slack. Απλώς δεν υπήρχε αρκετός χρόνος για μια τέτοια ρύθμιση δεδομένων των στενών προθεσμιών.
Έλεγχος ταυτότητας
Αξίζει επίσης να αναφέρουμε ότι το Chronograf υποστηρίζει OAuth και OIDC ως έλεγχο ταυτότητας.
Αυτό είναι πολύ βολικό, καθώς σας επιτρέπει να το προσαρτήσετε εύκολα στον διακομιστή σας και να δημιουργήσετε ένα πλήρες SSO.
Στην περίπτωσή μας, ο διακομιστής ήταν — χρησιμοποιήθηκε για σύνδεση με την παρακολούθηση, αλλά ο ίδιος διακομιστής χρησιμοποιήθηκε επίσης για τον έλεγχο ταυτότητας των σκούτερ και των αιτημάτων στο back-end.
"Διαχειριστής"
Το τελευταίο στοιχείο που θα περιγράψω είναι το "πίνακα διαχείρισης" που γράφουμε μόνοι μας στο Vue.
Βασικά είναι απλώς μια αυτόνομη υπηρεσία που εμφανίζει πληροφορίες για σκούτερ από τις δικές μας βάσεις δεδομένων, μικροϋπηρεσίες και δεδομένα μετρήσεων από το InfluxDB ταυτόχρονα.
Επιπλέον, πολλές διοικητικές λειτουργίες μεταφέρθηκαν εκεί, όπως επανεκκίνηση έκτακτης ανάγκης ή απομακρυσμένο άνοιγμα κλειδαριάς για την ομάδα υποστήριξης.
Υπήρχαν και χάρτες. Ανέφερα ήδη ότι ξεκινήσαμε με το Grafana αντί για το Chronograf - γιατί για το Grafana οι χάρτες είναι διαθέσιμοι με τη μορφή πρόσθετων, στα οποία μπορούσαμε να δούμε τις συντεταγμένες των σκούτερ. Δυστυχώς, οι δυνατότητες των γραφικών στοιχείων χαρτών για το Grafana είναι πολύ περιορισμένες και ως εκ τούτου, ήταν πολύ πιο εύκολο να γράψετε τη δική σας διαδικτυακή εφαρμογή με χάρτες σε λίγες μέρες, ώστε όχι μόνο να βλέπετε τις συντεταγμένες αυτή τη στιγμή, αλλά και να εμφανίζετε τη διαδρομή που ακολουθεί το σκούτερ, να μπορούμε να φιλτράρουμε τα δεδομένα στον χάρτη κλπ. (όλη αυτή η λειτουργικότητα που δεν μπορούσαμε να διαμορφώσουμε σε ένα απλό ταμπλό).
Ένα από τα ήδη αναφερθέντα πλεονεκτήματα του Influx είναι η δυνατότητα να δημιουργείτε εύκολα τις δικές σας μετρήσεις.
Αυτό επιτρέπει τη χρήση του για μια τεράστια ποικιλία σεναρίων.
Προσπαθήσαμε να καταγράψουμε όλες τις χρήσιμες πληροφορίες εκεί: φόρτιση μπαταρίας, κατάσταση κλειδώματος, απόδοση αισθητήρα, bluetooth, GPS και πολλούς άλλους ελέγχους υγείας.
Όλα αυτά τα εμφανίσαμε στον πίνακα διαχείρισης.
Φυσικά, το πιο σημαντικό κριτήριο για εμάς ήταν η κατάσταση λειτουργίας του σκούτερ - στην πραγματικότητα, το Influx το ελέγχει και το δείχνει με "πράσινα φώτα" στην ενότητα "Κόμβοι".
Αυτό γίνεται από τη συνάρτηση — το χρησιμοποιήσαμε για να κατανοήσουμε την απόδοση του κουτιού μας και να στείλουμε τις ίδιες ειδοποιήσεις στο Slack.
Παρεμπιπτόντως, ονομάσαμε τα σκούτερ από τα ονόματα των χαρακτήρων από τους Simpsons - ήταν τόσο βολικό να τα διακρίνουμε μεταξύ τους
Και γενικά ήταν πιο διασκεδαστικό έτσι. Φράσεις όπως «Παιδιά, ο Smithers πέθανε!» ακούγονταν συνεχώς.
Μετρήσεις συμβολοσειρών
Είναι σημαντικό το InfluxDB να σας επιτρέπει να αποθηκεύετε όχι μόνο αριθμητικές τιμές, όπως συμβαίνει με το Victoria Metrics.
Φαίνεται ότι αυτό δεν είναι τόσο σημαντικό - τελικά, εκτός από τα αρχεία καταγραφής, οποιεσδήποτε μετρήσεις μπορούν να αποθηκευτούν με τη μορφή αριθμών (απλώς προσθέστε αντιστοίχιση για γνωστές καταστάσεις - ένα είδος enum);
Στην περίπτωσή μας, υπήρχε τουλάχιστον ένα σενάριο όπου οι μετρήσεις συμβολοσειρών ήταν πολύ χρήσιμες.
Απλώς, ο προμηθευτής των «έξυπνων φορτιστών» μας ήταν τρίτος, δεν είχαμε κανέναν έλεγχο στη διαδικασία ανάπτυξης και στις πληροφορίες που μπορούσαν να παρέχουν αυτοί οι φορτιστές.
Ως αποτέλεσμα, το API φόρτισης απείχε πολύ από το ιδανικό, αλλά το κύριο πρόβλημα ήταν ότι δεν μπορούσαμε πάντα να κατανοήσουμε την κατάστασή τους.
Εδώ βοήθησε το Influx. Απλώς γράψαμε την κατάσταση συμβολοσειράς που μας ήρθε στο πεδίο βάσης δεδομένων InfluxDB χωρίς αλλαγές.
Για κάποιο χρονικό διάστημα, μόνο τιμές όπως "online" και "offline" έφτασαν εκεί, βάσει των οποίων οι πληροφορίες εμφανίζονταν στον πίνακα διαχείρισης και οι ειδοποιήσεις αποστέλλονταν στο Slack. Ωστόσο, σε κάποιο σημείο, άρχισαν να εμφανίζονται και τιμές όπως το "disconnected".
Όπως αποδείχθηκε αργότερα, αυτή η κατάσταση στάλθηκε μία φορά μετά από απώλεια σύνδεσης, εάν ο φορτιστής δεν μπορούσε να δημιουργήσει σύνδεση με τον διακομιστή μετά από έναν ορισμένο αριθμό προσπαθειών.
Επομένως, εάν χρησιμοποιούσαμε μόνο ένα σταθερό σύνολο τιμών, ενδέχεται να μην δούμε αυτές τις αλλαγές στο υλικολογισμικό τη σωστή στιγμή.
Και γενικά, οι μετρήσεις συμβολοσειρών παρέχουν πολύ περισσότερες δυνατότητες χρήσης· μπορείτε να καταγράψετε σχεδόν οποιαδήποτε πληροφορία σε αυτές. Αν και, φυσικά, πρέπει επίσης να χρησιμοποιήσετε αυτό το εργαλείο προσεκτικά.
Εκτός από τις συνήθεις μετρήσεις, καταγράψαμε επίσης πληροφορίες τοποθεσίας GPS στο InfluxDB. Αυτό ήταν απίστευτα χρήσιμο για την παρακολούθηση της θέσης των σκούτερ στον πίνακα διαχείρισης.
Στην πραγματικότητα, πάντα ξέραμε πού και ποιο σκούτερ βρισκόταν τη στιγμή που χρειαζόμασταν.
Αυτό μας ήταν πολύ χρήσιμο όταν ψάχναμε για σκούτερ (βλ. συμπεράσματα στο τέλος).
Παρακολούθηση υποδομής
Εκτός από τα ίδια τα σκούτερ, χρειαζόταν να παρακολουθούμε ολόκληρη την (μάλλον εκτεταμένη) υποδομή μας.
Μια πολύ γενική αρχιτεκτονική έμοιαζε κάπως έτσι:
Εάν επισημάνουμε μια καθαρή στοίβα παρακολούθησης, μοιάζει με αυτό:
Αυτό που θα θέλαμε να ελέγξουμε στο cloud είναι:
- Βάση δεδομένων
- Μπρελόκ
- Μικροϋπηρεσίες
Δεδομένου ότι όλες οι υπηρεσίες cloud μας βρίσκονται στο Kubernetes, θα ήταν ωραίο να συλλέγουμε πληροφορίες για την κατάστασή του.
Ευτυχώς, το Telegraf out of the box μπορεί να συλλέξει έναν τεράστιο αριθμό μετρήσεων σχετικά με την κατάσταση του συμπλέγματος Kubernetes και το Chronograf προσφέρει αμέσως όμορφους πίνακες εργαλείων για αυτό.
Παρακολουθήσαμε κυρίως την απόδοση των pod και την κατανάλωση μνήμης. Σε περίπτωση πτώσης, ειδοποιήσεις στο Slack.
Υπάρχουν δύο τρόποι παρακολούθησης pod στο Kubernetes: DaemonSet και Sidecar.
Και οι δύο μέθοδοι περιγράφονται λεπτομερώς .
Χρησιμοποιήσαμε το Telegraf Sidecar και, εκτός από μετρήσεις, συλλέξαμε αρχεία καταγραφής pod.
Στην περίπτωσή μας, έπρεπε να ασχοληθούμε με τα κούτσουρα. Παρά το γεγονός ότι η Telegraf μπορεί να αντλεί αρχεία καταγραφής από το Docker API, θέλαμε να έχουμε μια ομοιόμορφη συλλογή αρχείων καταγραφής με τις τελικές συσκευές μας και να έχουμε διαμορφώσει το σύστημα καταγραφής για κοντέινερ για αυτό. Ίσως αυτή η λύση να μην ήταν όμορφη, αλλά δεν υπήρχαν παράπονα για τη δουλειά της και τα αρχεία καταγραφής εμφανίζονταν καλά στο Chronograf.
Παρακολούθηση παρακολούθησης;;;
Τελικά, προέκυψε το πανάρχαιο ζήτημα της παρακολούθησης των συστημάτων παρακολούθησης, αλλά ευτυχώς, ή δυστυχώς, απλά δεν είχαμε αρκετό χρόνο για αυτό.
Παρόλο που η Telegraf μπορεί εύκολα να στείλει τις δικές της μετρήσεις ή να συλλέξει μετρήσεις από τη βάση δεδομένων InfluxDB για αποστολή είτε στο ίδιο Influx είτε κάπου αλλού.
Ευρήματα
Τι συμπεράσματα βγάλαμε από τα αποτελέσματα του πιλότου;
Πώς μπορείτε να κάνετε παρακολούθηση;
Πρώτα απ 'όλα, η στοίβα TICK ανταποκρίθηκε πλήρως στις προσδοκίες μας και μας έδωσε ακόμη περισσότερες ευκαιρίες από ό,τι αρχικά περιμέναμε.
Όλη η λειτουργικότητα που χρειαζόμασταν ήταν παρούσα. Ό,τι κάναμε με αυτό λειτούργησε χωρίς προβλήματα.
Παραγωγικότητα
Το κύριο πρόβλημα με τη στοίβα TICK στη δωρεάν έκδοση είναι η έλλειψη δυνατοτήτων κλιμάκωσης. Αυτό δεν ήταν πρόβλημα για εμάς.
Δεν συλλέξαμε ακριβή δεδομένα/αριθμούς φορτίου, αλλά συλλέξαμε δεδομένα από περίπου 30 σκούτερ κάθε φορά.
Κάθε ένα από αυτά συγκέντρωσε περισσότερες από τρεις δωδεκάδες μετρήσεις. Ταυτόχρονα, συγκεντρώθηκαν αρχεία καταγραφής από τις συσκευές. Η συλλογή και η αποστολή δεδομένων γινόταν κάθε 10 δευτερόλεπτα.
Είναι σημαντικό να σημειωθεί ότι μετά από μιάμιση εβδομάδα του πιλότου, όταν το μεγαλύτερο μέρος των «παιδικών προβλημάτων» διορθώθηκαν και τα πιο σημαντικά προβλήματα είχαν ήδη επιλυθεί, έπρεπε να μειώσουμε τη συχνότητα αποστολής δεδομένων στον διακομιστή σε 30 δευτερόλεπτα. Αυτό έγινε απαραίτητο επειδή η κίνηση στις κάρτες SIM LTE άρχισε να εξαφανίζεται γρήγορα.
Το μεγαλύτερο μέρος της κίνησης καταναλώθηκε από τα κούτσουρα· οι ίδιες οι μετρήσεις, ακόμη και με ένα διάστημα 10 δευτερολέπτων, ουσιαστικά δεν το σπαταλούσαν.
Ως αποτέλεσμα, μετά από κάποιο χρονικό διάστημα απενεργοποιήσαμε εντελώς τη συλλογή αρχείων καταγραφής στις συσκευές, καθώς συγκεκριμένα προβλήματα ήταν ήδη εμφανή ακόμη και χωρίς συνεχή συλλογή.
Σε ορισμένες περιπτώσεις, εάν η προβολή των αρχείων καταγραφής ήταν ακόμα απαραίτητη, απλώς συνδεθήκαμε μέσω WireGuard μέσω VPN.
Θα προσθέσω επίσης ότι κάθε ξεχωριστό περιβάλλον ήταν διαχωρισμένο το ένα από το άλλο και το φορτίο που περιγράφεται παραπάνω ήταν σχετικό μόνο για το περιβάλλον παραγωγής.
Στο περιβάλλον ανάπτυξης, δημιουργήσαμε μια ξεχωριστή παρουσία InfluxDB που συνέχισε να συλλέγει δεδομένα κάθε 10 δευτερόλεπτα και δεν αντιμετωπίσαμε κανένα πρόβλημα απόδοσης.
TICK - ιδανικό για μικρά έως μεσαία έργα
Με βάση αυτές τις πληροφορίες, θα συμπέρανα ότι η στοίβα TICK είναι ιδανική για σχετικά μικρά έργα ή έργα που σίγουρα δεν αναμένουν HighLoad.
Εάν δεν έχετε χιλιάδες pods ή εκατοντάδες μηχανήματα, ακόμη και μια παρουσία InfluxDB θα χειριστεί το φορτίο μια χαρά.
Σε ορισμένες περιπτώσεις, μπορεί να είστε ικανοποιημένοι με το Influx Relay ως μια πρωτόγονη λύση υψηλής διαθεσιμότητας.
Και, φυσικά, κανείς δεν σας εμποδίζει να ρυθμίσετε την «κάθετη» κλιμάκωση και απλώς να εκχωρήσετε διαφορετικούς διακομιστές για διαφορετικούς τύπους μετρήσεων.
Εάν δεν είστε σίγουροι για το αναμενόμενο φορτίο στις υπηρεσίες παρακολούθησης ή είναι εγγυημένο ότι έχετε/θα έχετε μια πολύ «βαριά» αρχιτεκτονική, δεν θα συνιστούσα να χρησιμοποιήσετε τη δωρεάν έκδοση της στοίβας TICK.
Φυσικά, μια απλή λύση θα ήταν η αγορά - αλλά εδώ δεν μπορώ να σχολιάσω με κάποιο τρόπο, αφού ο ίδιος δεν είμαι εξοικειωμένος με τις λεπτότητες. Εκτός του ότι είναι πολύ ακριβό και σίγουρα δεν είναι κατάλληλο για μικρές εταιρείες.
Σε αυτήν την περίπτωση, σήμερα, θα συνιστούσα να κοιτάξετε προς τη συλλογή μετρήσεων μέσω της Victoria Metrics και τα αρχεία καταγραφής χρησιμοποιώντας το Loki.
Αλήθεια, θα κάνω πάλι κράτηση ότι τα Loki/Grafana είναι πολύ λιγότερο βολικά (λόγω της μεγαλύτερης ευελιξίας τους) από το έτοιμο TICK, αλλά είναι δωρεάν.
Είναι σημαντικό: όλες οι πληροφορίες που περιγράφονται εδώ είναι σχετικές με την έκδοση Influx 1.8, αυτή τη στιγμή το Influx 2.0 πρόκειται να κυκλοφορήσει.
Αν και δεν είχα την ευκαιρία να το δοκιμάσω σε συνθήκες μάχης και είναι δύσκολο να βγάλω συμπεράσματα για βελτιώσεις, η διεπαφή έχει γίνει σίγουρα ακόμα καλύτερη, η αρχιτεκτονική έχει απλοποιηθεί (χωρίς πυκνωτή και χρονογράφο),
εμφανίστηκαν πρότυπα ("χαρακτηριστικό δολοφονίας" - ). Αλλά, δυστυχώς, αυτή τη στιγμή, η έκδοση 2 δεν έχει το κλειδί για το οποίο επιλέξαμε την πρώτη έκδοση - δεν υπάρχει συλλογή αρχείων καταγραφής.
Αυτή η λειτουργία θα εμφανίζεται επίσης στο Influx 2.0, αλλά δεν μπορέσαμε να βρούμε προθεσμίες, ακόμη και κατά προσέγγιση.
Πώς να μην δημιουργήσετε πλατφόρμες IoT (τώρα)
Στο τέλος, έχοντας ξεκινήσει το πιλοτικό, εμείς οι ίδιοι συγκεντρώσαμε τη δική μας ολοκληρωμένη στοίβα IoT, ελλείψει μιας εναλλακτικής κατάλληλης για τα πρότυπά μας.
Ωστόσο, πρόσφατα είναι διαθέσιμο σε έκδοση Beta — είναι κρίμα που δεν ήταν εκεί όταν ξεκινήσαμε να κάνουμε το έργο.
Είμαστε απόλυτα ικανοποιημένοι με το τελικό αποτέλεσμα και την πλατφόρμα που βασίζεται στο Ansible + TICK + WireGuard που συναρμολογήσαμε μόνοι μας. Αλλά σήμερα, θα συνιστούσα να ρίξετε μια πιο προσεκτική ματιά στο Balena πριν προσπαθήσετε να δημιουργήσετε μόνοι σας τη δική σας πλατφόρμα IoT.
Γιατί τελικά μπορεί να κάνει τα περισσότερα από αυτά που κάναμε και το OpenBalena είναι δωρεάν και ανοιχτού κώδικα.
Ξέρει ήδη πώς όχι μόνο να στέλνει ενημερώσεις, αλλά και ένα VPN είναι ήδη ενσωματωμένο και προσαρμοσμένο για χρήση σε περιβάλλον IoT.
Και μόλις πρόσφατα κυκλοφόρησαν το δικό τους , που συνδέεται εύκολα με το οικοσύστημά τους.
Τι γίνεται με το σκούτερ που λείπει;
Έτσι το σκούτερ, «Ralph», εξαφανίστηκε χωρίς ίχνος.
Αμέσως τρέξαμε να δούμε τον χάρτη στον "πίνακα διαχειριστή", με δεδομένα μετρήσεων GPS από το InfluxDB.
Χάρη στα δεδομένα παρακολούθησης, διαπιστώσαμε εύκολα ότι το σκούτερ έφυγε από το πάρκινγκ γύρω στις 21:00 την προηγούμενη μέρα, οδήγησε περίπου μισή ώρα σε κάποια περιοχή και ήταν σταθμευμένο μέχρι τις 5 το πρωί δίπλα σε κάποιο γερμανικό σπίτι.
Μετά τις 5 π.μ., δεν ελήφθησαν δεδομένα παρακολούθησης—αυτό σήμαινε ότι είτε η πρόσθετη μπαταρία είχε αποφορτιστεί πλήρως ή ο εισβολέας τελικά κατάλαβε πώς να αφαιρέσει το έξυπνο υλικό από το σκούτερ.
Παρόλα αυτά, η αστυνομία κλήθηκε ακόμα στη διεύθυνση όπου βρισκόταν το σκούτερ. Το σκούτερ δεν ήταν εκεί.
Ωστόσο, και ο ιδιοκτήτης του σπιτιού εξεπλάγη από αυτό, αφού όντως οδήγησε αυτό το σκούτερ στο σπίτι από το γραφείο χθες το βράδυ.
Όπως προέκυψε, ένας από τους υπαλλήλους της υποστήριξης έφτασε νωρίς το πρωί και πήρε το σκούτερ, βλέποντας ότι η επιπλέον μπαταρία του ήταν εντελώς αποφορτισμένη και το μετέφερε (με τα πόδια) στο πάρκινγκ. Και η πρόσθετη μπαταρία απέτυχε λόγω υγρασίας.
Κλέψαμε το σκούτερ από τον εαυτό μας. Παρεμπιπτόντως, δεν ξέρω πώς και ποιος έλυσε το θέμα με την υπόθεση της αστυνομίας, αλλά η παρακολούθηση λειτούργησε τέλεια...
Πηγή: www.habr.com