Vor einem Jahr haben wir eine Pilotversion eines Werbeprojekts gestartet .
Ursprünglich hieß das Projekt Road-To-Barcelona, später wurde es Road-To-Berlin (daher R2B in den Screenshots) und schließlich hieß es xRide.
Die Hauptidee des Projekts war folgende: Anstelle eines zentralisierten Auto- oder Motorroller-Vermietungsdienstes (wir sprechen hier von Motorrollern, also elektrischen Motorrädern, nicht von Kickscootern/Scootern) wollten wir eine Plattform für die dezentrale Vermietung schaffen. Über die Schwierigkeiten, auf die wir gestoßen sind .
Ursprünglich konzentrierte sich das Projekt auf Autos, aber aufgrund von Fristen, extrem langen Kommunikationen mit den Herstellern und einer Vielzahl von Sicherheitsbeschränkungen wurden Elektroroller für den Piloten ausgewählt.
Der Benutzer installierte eine iOS- oder Android-Anwendung auf dem Telefon, näherte sich dem Roller, der ihm gefiel, woraufhin das Telefon und der Roller eine Peer-to-Peer-Verbindung herstellten, ETH ausgetauscht wurde und der Benutzer die Fahrt beginnen konnte, indem er den Roller über einschaltete das Telefon. Am Ende der Reise war es auch möglich, die Reise mit Ethereum aus dem Wallet des Nutzers am Telefon zu bezahlen.
Neben Motorrollern sah der Nutzer in der Anwendung auch „intelligente Ladegeräte“, über die der Nutzer den aktuellen Akku bei niedrigem Ladezustand selbst wechseln konnte.
So sah im Großen und Ganzen unser Pilotprojekt aus, das im September letzten Jahres in zwei deutschen Städten gestartet wurde: Bonn und Berlin.
Und dann, eines Tages, wurde in Bonn frühmorgens unser Support-Team (das vor Ort war, um die Motorroller funktionstüchtig zu halten) alarmiert: Einer der Roller war spurlos verschwunden.
Wie finde ich es und gebe es zurück?
In diesem Artikel werde ich darüber sprechen, aber zuerst darüber, wie wir unsere eigene IoT-Plattform aufgebaut und wie wir sie überwacht haben.
Was und warum überwachen: Roller, Infrastruktur, Ladestationen?
Was wollten wir also in unserem Projekt überwachen?
Das sind zunächst einmal die Roller selbst – Elektroroller selbst sind ziemlich teuer, man kann ein solches Projekt nicht starten, ohne ausreichend vorbereitet zu sein; wenn möglich, möchte man möglichst viele Informationen über die Roller sammeln: über ihren Standort, Ladezustand , usw.
Darüber hinaus möchte ich den Zustand unserer eigenen IT-Infrastruktur überwachen – Datenbanken, Dienste und alles, was sie zum Funktionieren benötigen. Es war auch notwendig, den Status der „intelligenten Ladegeräte“ zu überwachen, falls diese ausfielen oder die Batterien leer waren.
Roller
Was waren unsere Roller und was wollten wir über sie wissen?
Das erste und wichtigste sind die GPS-Koordinaten, denn dank ihnen können wir verstehen, wo sie sich befinden und wohin sie sich bewegen.
Als nächstes folgt die Batterieladung, dank derer wir feststellen können, dass der Ladevorgang der Roller zu Ende geht und einen Entsafter senden oder den Benutzer zumindest warnen können.
Natürlich ist es auch notwendig zu prüfen, was mit unseren Hardware-Komponenten passiert:
- Funktioniert Bluetooth?
- Funktioniert das GPS-Modul selbst?
- Wir hatten auch ein Problem damit, dass das GPS falsche Koordinaten senden und stecken bleiben konnte, was nur durch zusätzliche Kontrollen am Roller festgestellt werden konnte,
und benachrichtigen Sie den Support so schnell wie möglich, um das Problem zu beheben
- Wir hatten auch ein Problem damit, dass das GPS falsche Koordinaten senden und stecken bleiben konnte, was nur durch zusätzliche Kontrollen am Roller festgestellt werden konnte,
Und schließlich: Überprüfungen der Software, beginnend mit dem Betriebssystem und Prozessor, der Netzwerk- und Festplattenlast, bis hin zu Überprüfungen unserer eigenen Module, die spezifischer für uns sind (, ).
Hardware
Was war unser „eiserner“ Teil?
Unter Berücksichtigung des kürzestmöglichen Zeitrahmens und der Notwendigkeit eines schnellen Prototypings haben wir uns für die einfachste Option für die Implementierung und Auswahl der Komponenten entschieden – Raspberry Pi.
Zusätzlich zum RPI selbst hatten wir eine maßgeschneiderte Platine (die wir selbst entwickelt und in China bestellt hatten, um den Montageprozess der endgültigen Lösung zu beschleunigen) und eine Reihe von Komponenten – ein Relais (zum Ein-/Ausschalten des Rollers), ein Batterieladegerät, ein Modem, Antennen. Das Ganze kompakt verpackt in einer speziellen „xRide-Box“.
Zu beachten ist auch, dass die gesamte Box über eine zusätzliche Powerbank mit Strom versorgt wurde, die wiederum über den Hauptakku des Rollers mit Strom versorgt wurde.
Dadurch war es möglich, die Überwachung zu nutzen und den Roller auch nach dem Ende der Fahrt einzuschalten, da die Hauptbatterie sofort nach dem Drehen des Zündschlüssels in die Position „Aus“ ausgeschaltet wurde.
Docker? Einfaches Linux? und Bereitstellung
Kommen wir zurück zur Überwachung, also Raspberry – was haben wir?
Eines der ersten Dinge, die wir nutzen wollten, um den Prozess der Bereitstellung, Aktualisierung und Bereitstellung von Komponenten auf physischen Geräten zu beschleunigen, war Docker.
Leider wurde schnell klar, dass Docker auf RPi zwar funktioniert, aber einen hohen Overhead verursacht, insbesondere im Hinblick auf den Energieverbrauch.
Der Unterschied bei Verwendung des „nativen“ Betriebssystems war zwar nicht so groß, reichte aber dennoch aus, um uns vor einem möglichen zu schnellen Ladeverlust zu warnen.
Der zweite Grund war eine unserer Partnerbibliotheken auf Node.js (sic!) – die einzige Komponente des Systems, die nicht in Go/C/C++ geschrieben wurde.
Die Autoren der Bibliothek hatten keine Zeit, eine funktionierende Version in einer der „Muttersprachen“ bereitzustellen.
Der Knoten selbst ist nicht nur nicht die eleganteste Lösung für Geräte mit geringer Leistung, auch die Bibliothek selbst war sehr ressourcenintensiv.
Uns wurde klar, dass die Verwendung von Docker für uns zu viel Aufwand bedeuten würde, selbst wenn wir es wollten. Die Wahl fiel auf das native Betriebssystem und die Arbeit direkt darunter.
OS
Aus diesem Grund haben wir uns erneut für die einfachste Variante als Betriebssystem entschieden und Raspbian (Debian-Build für Pi) verwendet.
Wir schreiben unsere gesamte Software in Go, also haben wir auch das Haupt-Hardware-Agent-Modul in unserem System in Go geschrieben.
Er ist für die Arbeit mit GPS, Bluetooth, das Ablesen des Ladezustands, das Einschalten des Rollers usw. verantwortlich.
Einsetzen
Es stellte sich sofort die Frage nach der Notwendigkeit, einen Mechanismus zur Bereitstellung von Updates für Geräte (OTA) zu implementieren – sowohl Updates für unseren Agenten/unsere Anwendung selbst als auch Updates für das Betriebssystem/die Firmware selbst (da neue Versionen des Agenten Aktualisierungen des Kernels erfordern könnten). oder Systemkomponenten, Bibliotheken usw.).
Nach einer längeren Marktanalyse stellte sich heraus, dass es eine ganze Reihe von Lösungen gibt, um Updates auf das Gerät auszuliefern.
Von relativ einfachen, meist Update-/Dual-Boot-orientierten Dienstprogrammen wie swupd/SWUpdate/OSTree bis hin zu vollwertigen Plattformen wie Mender und Balena.
Zunächst haben wir entschieden, dass wir an End-to-End-Lösungen interessiert sind, und so fiel die Wahl sofort auf Plattformen.
Selbst wurde aufgrund der Tatsache ausgeschlossen, dass es tatsächlich denselben Docker in seiner balenaEngine verwendet.
Aber ich stelle fest, dass wir ihr Produkt trotzdem ständig verwendet haben für Flash-Firmware auf SD-Karten – ein einfaches und äußerst praktisches Dienstprogramm dafür.
Daher fiel die Wahl am Ende auf . Mender ist eine vollständige Plattform zum Zusammenstellen, Bereitstellen und Installieren von Firmware.
Insgesamt sieht die Plattform großartig aus, aber wir haben etwa anderthalb Wochen gebraucht, um mit dem Mender Builder die richtige Version unserer Firmware zu erstellen.
Und je mehr wir uns in die Feinheiten seiner Verwendung vertieften, desto klarer wurde uns, dass wir für den vollständigen Einsatz viel mehr Zeit benötigen würden, als uns zur Verfügung stand.
Leider waren wir aufgrund unserer knappen Fristen gezwungen, auf Mender zu verzichten und uns für ein noch einfacheres Modell zu entscheiden.
Ansible
Die einfachste Lösung in unserer Situation war die Verwendung von Ansible. Ein paar Playbooks reichten für den Anfang.
Ihr Kern bestand darin, dass wir uns einfach vom Host (CI-Server) über SSH mit unseren Himbeeren verbunden und Updates an sie verteilt haben.
Ganz am Anfang war alles einfach – man musste mit den Geräten im selben Netzwerk sein, das Ausgießen erfolgte über WLAN.
Im Büro waren lediglich ein Dutzend Test-Himbeeren mit demselben Netzwerk verbunden, jedes Gerät hatte eine statische IP-Adresse, die ebenfalls in Ansible Inventory angegeben war.
Es war Ansible, das unseren Überwachungsagenten an die Endgeräte lieferte
X
Leider konnte dieser Anwendungsfall für Ansible nur im Entwicklungsmodus funktionieren, bevor wir echte Scooter hatten.
Denn wie Sie wissen, sind Roller nicht mit einem WLAN-Router verbunden und warten ständig auf Updates über das Netzwerk.
In Wirklichkeit können Roller überhaupt keine andere Verbindung als mobiles 3G/LTE haben (und selbst dann nicht ständig).
Dies bringt sofort viele Probleme und Einschränkungen mit sich, wie z. B. eine niedrige Verbindungsgeschwindigkeit und eine instabile Kommunikation.
Aber das Wichtigste ist, dass wir uns in einem 3G/LTE-Netzwerk nicht einfach auf eine dem Netzwerk zugewiesene statische IP verlassen können.
Dies wird teilweise von einigen SIM-Kartenanbietern gelöst; es gibt sogar spezielle SIM-Karten, die für IoT-Geräte mit statischen IP-Adressen konzipiert sind. Aber wir hatten keinen Zugriff auf solche SIM-Karten und konnten keine IP-Adressen nutzen.
Natürlich gab es Ideen, eine Art Registrierung von IP-Adressen, auch Service Discovery genannt, irgendwo wie Consul durchzuführen, aber wir mussten solche Ideen aufgeben, da sich die IP-Adresse in unseren Tests zu oft ändern konnte, was zu großer Instabilität führte.
Aus diesem Grund wäre die bequemste Verwendung für die Bereitstellung von Metriken nicht die Verwendung des Pull-Modells, bei dem wir die erforderlichen Metriken von Geräten abrufen würden, sondern die Verwendung von Push, bei dem die Metriken vom Gerät direkt an den Server übermittelt werden
VPN
Als Lösung für dieses Problem haben wir uns gezielt für VPN entschieden .
Clients (Scooter) stellten beim Start des Systems eine Verbindung zum VPN-Server her und konnten sich mit diesen verbinden. Dieser Tunnel wurde zur Bereitstellung von Updates verwendet.
Theoretisch könnte derselbe Tunnel zur Überwachung genutzt werden, allerdings war eine solche Verbindung komplizierter und weniger zuverlässig als eine einfache Push-Verbindung.
Cloud-Ressourcen
Schließlich ist es notwendig, unsere Cloud-Dienste und Datenbanken zu überwachen, da wir für sie Kubernetes verwenden, idealerweise, damit die Bereitstellung der Überwachung im Cluster so einfach wie möglich ist. Idealerweise mit , da wir es in den meisten Fällen für die Bereitstellung verwenden. Und natürlich muss man zur Überwachung der Cloud die gleichen Lösungen nutzen wie für die Roller selbst.
Gegeben
Puh, wir scheinen die Beschreibung geklärt zu haben, machen wir am Ende eine Liste mit dem, was wir brauchten:
- Eine schnelle Lösung, da bereits während des Entwicklungsprozesses eine Überwachung erforderlich ist
- Volumen/Menge – viele Messwerte erforderlich
- Eine Protokollerfassung ist erforderlich
- Zuverlässigkeit – Daten sind entscheidend für den Erfolg einer Markteinführung
- Sie können das Pull-Modell nicht verwenden, Sie benötigen Push
- Wir brauchen eine einheitliche Überwachung nicht nur der Hardware, sondern auch der Cloud
Das endgültige Bild sah ungefähr so aus
Stapelauswahl
Wir standen also vor der Frage, welchen Monitoring-Stack wir wählen sollten.
Zunächst waren wir auf der Suche nach einer möglichst umfassenden Komplettlösung, die gleichzeitig alle unsere Anforderungen abdeckt, gleichzeitig aber flexibel genug ist, um den Einsatz individuell an unsere Bedürfnisse anzupassen. Dennoch gab es viele Einschränkungen, die uns durch Hardware, Architektur und Fristen auferlegt wurden.
Es gibt eine große Vielfalt an Überwachungslösungen, angefangen bei vollwertigen Systemen wie , oder und endet mit vorgefertigten Lösungen für das Flottenmanagement.
Letzteres schien uns zunächst eine ideale Lösung zu sein, aber einige verfügten nicht über eine vollständige Überwachung, andere hatten stark eingeschränkte Funktionen der kostenlosen Versionen und wieder andere deckten einfach nicht unsere „Wünsche“ ab oder waren nicht flexibel genug, um sich an unsere Szenarien anzupassen. Manche sind einfach veraltet.
Nachdem wir eine Reihe ähnlicher Lösungen analysiert hatten, kamen wir schnell zu dem Schluss, dass es einfacher und schneller wäre, einen ähnlichen Stack selbst zusammenzustellen. Ja, es wird etwas komplizierter sein als die Bereitstellung einer vollständig vorgefertigten Flottenmanagementplattform, aber wir müssen keine Kompromisse eingehen.
Mit ziemlicher Sicherheit gibt es in der riesigen Fülle an Lösungen bereits eine fertige Lösung, die vollkommen zu uns passt, aber in unserem Fall war es viel schneller, einen bestimmten Stapel selbst zusammenzustellen und „für uns selbst“ anzupassen, als Testen von fertigen Produkten.
Bei all dem haben wir nicht versucht, eine komplette Überwachungsplattform selbst zusammenzustellen, sondern waren auf der Suche nach den funktionalsten „fertigen“ Stacks, die nur flexibel konfiguriert werden können.
(B)ELCH?
Die erste Lösung, die tatsächlich in Betracht gezogen wurde, war der bekannte ELK-Stack.
Eigentlich sollte es BELK heißen, denn alles beginnt mit Beats -
ELK ist natürlich eine der bekanntesten und leistungsstärksten Lösungen im Bereich Monitoring und noch mehr im Bereich der Protokollerfassung und -verarbeitung.
Wir hatten vor, ELK zum Sammeln von Protokollen und zur langfristigen Speicherung der von Prometheus erhaltenen Metriken zu verwenden.
Zur Visualisierung können Sie Grafan verwenden.
Tatsächlich kann der neue ELK-Stack Metriken unabhängig erfassen (Metricbeat) und Kibana kann sie auch anzeigen.
Dennoch ist ELK ursprünglich aus Protokollen entstanden und die Funktionalität der Metriken weist bisher eine Reihe gravierender Nachteile auf:
- Deutlich langsamer als Prometheus
- Lässt sich an weitaus weniger Orten integrieren als Prometheus
- Es ist schwierig, Benachrichtigungen für sie einzurichten
- Metriken nehmen viel Platz ein
- Das Einrichten von Dashboards mit Metriken ist in Kiban deutlich komplizierter als in Grafan
Im Allgemeinen sind die Metriken in ELK umfangreich und noch nicht so komfortabel wie in anderen Lösungen, von denen es mittlerweile viel mehr als nur Prometheus gibt: TSDB, Victoria Metrics, Cortex usw. usw. Natürlich hätte ich am liebsten gleich eine vollwertige Komplettlösung, aber im Fall von metricbeat gab es zu viele Kompromisse.
Und der ELK-Stack selbst hat eine Reihe schwieriger Momente:
- Es ist schwer, manchmal sogar sehr schwer, wenn Sie eine ziemlich große Datenmenge sammeln
- Sie müssen „wissen, wie man es kocht“ – Sie müssen es skalieren, aber das ist nicht trivial
- Reduzierte kostenlose Version – die kostenlose Version verfügt nicht über normale Benachrichtigungen und zum Zeitpunkt der Auswahl gab es keine Authentifizierung
Ich muss sagen, dass der letzte Punkt in letzter Zeit besser geworden ist und darüber hinaus (einschließlich Authentifizierung) begann sich das Preismodell selbst zu ändern.
Doch zu dem Zeitpunkt, als wir diese Lösung einsetzen wollten, gab es überhaupt keine Alarmierung.
Vielleicht hätten wir versuchen können, mit ElastAlert oder anderen Community-Lösungen etwas zu erstellen, aber wir haben uns dennoch entschieden, andere Alternativen in Betracht zu ziehen.
Loki – Grafana – Prometheus
Im Moment könnte eine gute Lösung darin bestehen, einen Überwachungsstapel aufzubauen, der ausschließlich auf Prometheus als Metrikanbieter und Loki für Protokolle basiert. Für die Visualisierung können Sie dasselbe Grafana verwenden.
Leider befand sich Loki zum Zeitpunkt des Starts des Verkaufspiloten des Projekts (September-Oktober 19) noch in der Beta-Version 0.3-0.4 und konnte zum Zeitpunkt des Entwicklungsstarts nicht als Produktionslösung betrachtet werden überhaupt.
Ich habe noch keine Erfahrung mit der tatsächlichen Verwendung von Loki in ernsthaften Projekten, aber ich kann sagen, dass Promtail (ein Agent zum Sammeln von Protokollen) sowohl für Bare-Metal als auch für Pods in Kubernetes hervorragend funktioniert.
TICK
Die vielleicht würdigste (die einzige?) voll funktionsfähige Alternative zum ELK-Stack kann jetzt nur noch als TICK-Stack bezeichnet werden – Telegraf, InfluxDB, Chronograf, Kapacitor.
Im Folgenden beschreibe ich alle Komponenten detaillierter, aber die Grundidee ist folgende:
- Telegraf – Agent zum Sammeln von Metriken
- InfluxDB – Metrikdatenbank
- Kapacitor – Echtzeit-Metrikprozessor für Alarmierung
- Chronograf - Webpanel zur Visualisierung
Für InfluxDB, Kapacitor und Chronograf gibt es offizielle Helm-Charts, die wir für deren Bereitstellung verwendet haben.
Es ist zu beachten, dass Kapacitor und Chronograf in der neuesten Version von Influx 2.0 (Beta) Teil von InfluxDB wurden und nicht mehr separat existieren
Telegraph
ist ein sehr leichter Agent zum Sammeln von Metriken auf einer Zustandsmaschine.
Er kann eine große Menge von allem überwachen, von auf
Server .
Es hat eine Reihe cooler Vorteile:
- Schnell und leicht (in Go geschrieben)
- Isst eine minimale Menge an Ressourcen
- Push-Metriken standardmäßig
- Sammelt alle notwendigen Kennzahlen
- Systemmetriken ohne Einstellungen
- Hardware-Metriken wie Informationen von Sensoren
- Es ist sehr einfach, eigene Metriken hinzuzufügen
- Viele Plugins sofort einsatzbereit
- Sammelt Protokolle
Da Push-Metriken für uns notwendig waren, waren alle anderen Vorteile mehr als erfreuliche Ergänzungen.
Auch das Sammeln von Protokollen durch den Agenten selbst ist sehr praktisch, da keine zusätzlichen Dienstprogramme zum Protokollieren angeschlossen werden müssen.
Influx bietet die bequemste Erfahrung für die Arbeit mit Protokollen, wenn Sie es verwenden .
Telegraf ist im Allgemeinen ein großartiger Agent zum Sammeln von Metriken, auch wenn Sie den Rest des ICK-Stacks nicht verwenden.
Viele Leute kreuzen es der Einfachheit halber mit ELK und verschiedenen anderen Zeitreihendatenbanken, da es fast überall Metriken schreiben kann.
InfluxDB
InfluxDB ist der Hauptkern des TICK-Stacks, nämlich eine Zeitreihendatenbank für Metriken.
Neben Metriken kann Influx auch Protokolle speichern, obwohl es sich bei den Protokollen dafür im Wesentlichen um dieselben Metriken handelt, nur dass anstelle der üblichen numerischen Indikatoren die Hauptfunktion durch eine Zeile Protokolltext ausgeführt wird.
InfluxDB ist ebenfalls in Go geschrieben und scheint auf unserem (nicht dem leistungsstärksten) Cluster viel schneller zu laufen als ELK.
Zu den coolen Vorteilen von Influx gehört auch eine sehr praktische und umfangreiche API für Datenabfragen, die wir sehr aktiv genutzt haben.
Nachteile – $$$ oder Skalierung?
Der TICK-Stack hat nur einen Nachteil, den wir entdeckt haben – ihn Liebling. Sogar mehr.
Was hat die kostenpflichtige Version, was die kostenlose Version nicht hat?
Soweit wir verstehen konnten, besteht der einzige Unterschied zwischen der kostenpflichtigen Version des TICK-Stacks und der kostenlosen Version in den Skalierungsmöglichkeiten.
Das heißt, Sie können einen Cluster mit hoher Verfügbarkeit nur in erstellen .
Wenn Sie vollwertige HA wünschen, müssen Sie entweder bezahlen oder Krücken benutzen. Es gibt zum Beispiel einige Community-Lösungen sieht nach einer kompetenten Lösung aus, aber es steht geschrieben, dass sie nicht für die Produktion geeignet ist
- eine einfache Lösung mit Datenpumpen über NATS (es muss auch skaliert werden, aber das kann gelöst werden).
Schade, aber beide scheinen aufgegeben zu sein - es gibt keine neuen Commits, ich gehe davon aus, dass das Problem die bald erwartete Veröffentlichung der neuen Version von Influx 2.0 ist, in der viele Dinge anders sein werden (es gibt keine Informationen darüber). Skalierung darin noch).
Offiziell gibt es eine kostenlose Version - Tatsächlich ist dies eine primitive HA, aber nur durch Ausbalancieren,
da alle Daten in alle InfluxDB-Instanzen hinter dem Load Balancer geschrieben werden.
Er hat welche B. potenzielle Probleme beim Überschreiben von Punkten und die Notwendigkeit, im Voraus Grundlagen für Metriken zu erstellen
(was bei der normalen Arbeit mit InfluxDB automatisch geschieht).
Neben Dies bedeutet zusätzlichen Aufwand für doppelte Metriken (sowohl Verarbeitung als auch Speicherung), die Sie möglicherweise nicht benötigen, es gibt jedoch keine Möglichkeit, sie zu trennen.
Victoria-Metriken?
Obwohl wir mit dem TICK-Stack in allen anderen Bereichen als der kostenpflichtigen Skalierung völlig zufrieden waren, haben wir uns daher entschlossen, nach kostenlosen Lösungen zu suchen, die die InfluxDB-Datenbank ersetzen und die verbleibenden T_CK-Komponenten belassen könnten.
Es gibt viele Zeitreihendatenbanken, aber die vielversprechendste ist Victoria Metrics, sie bietet eine Reihe von Vorteilen:
- Schnell und einfach, zumindest den Ergebnissen zufolge
- Es gibt eine Cluster-Version, zu der es mittlerweile sogar gute Rezensionen gibt
- Sie kann splittern
- Unterstützt das InfluxDB-Protokoll
Wir hatten nicht vor, einen vollständig benutzerdefinierten Stack auf Basis von Victoria zu erstellen, sondern hofften vor allem, dass wir ihn als Ersatz für InfluxDB verwenden könnten.
Leider ist dies nicht möglich, obwohl das InfluxDB-Protokoll unterstützt wird, es funktioniert nur zum Aufzeichnen von Metriken – nur die Prometheus-API ist „außerhalb“ verfügbar, was bedeutet, dass es nicht möglich sein wird, Chronograf darauf zu setzen.
Darüber hinaus werden für Metriken nur numerische Werte unterstützt (wir haben String-Werte für benutzerdefinierte Metriken verwendet – mehr dazu im Abschnitt). ).
Offensichtlich kann die VM aus demselben Grund keine Protokolle speichern, wie dies bei Influx der Fall ist.
Außerdem ist zu beachten, dass Victoria Metrics zum Zeitpunkt der Suche nach der optimalen Lösung noch nicht so beliebt war, die Dokumentation viel kleiner und die Funktionalität schwächer war
(Ich erinnere mich nicht an eine detaillierte Beschreibung der Cluster-Version und des Shardings.)
Basisauswahl
Aus diesem Grund wurde beschlossen, dass wir uns für das Pilotprojekt weiterhin auf einen einzelnen InfluxDB-Knoten beschränken würden.
Für diese Wahl gab es mehrere Hauptgründe:
- Die gesamte Funktionalität des TICK-Stacks hat uns sehr gut gefallen
- Wir haben es bereits geschafft, es bereitzustellen, und es hat großartig funktioniert
- Die Fristen wurden knapp und es blieb nicht mehr viel Zeit, andere Optionen zu testen.
- Mit einer so hohen Belastung hatten wir nicht gerechnet
Für die erste Phase des Pilotprojekts hatten wir nicht viele Roller und Tests während der Entwicklung ergaben keine Leistungsprobleme.
Daher haben wir entschieden, dass für dieses Projekt ein Influx-Knoten ausreichen würde, ohne dass eine Skalierung erforderlich wäre (siehe Schlussfolgerungen am Ende).
Wir haben uns für den Stapel und die Basis entschieden – nun geht es um die restlichen Komponenten des TICK-Stacks.
Kondensator
Kapacitor ist Teil des TICK-Stacks, eines Dienstes, der in Echtzeit in die Datenbank eingegebene Metriken überwachen und auf der Grundlage von Regeln verschiedene Aktionen ausführen kann.
Im Allgemeinen wird es als Werkzeug zur potenziellen Anomalieverfolgung und zum maschinellen Lernen positioniert (ich bin nicht sicher, ob diese Funktionen gefragt sind), aber der beliebteste Anwendungsfall ist die Alarmierung.
So haben wir es für Benachrichtigungen verwendet. Wir haben Slack-Benachrichtigungen eingerichtet, wenn ein bestimmter Roller offline ging, und das Gleiche wurde für intelligente Ladegeräte und wichtige Infrastrukturkomponenten durchgeführt.
Dadurch war es möglich, schnell auf Probleme zu reagieren und Benachrichtigungen zu erhalten, dass alles wieder normal war.
Ein einfaches Beispiel: Eine zusätzliche Batterie, die unsere „Box“ mit Strom versorgt, ist kaputt oder hat aus irgendeinem Grund keinen Strom mehr. Wenn wir einfach eine neue einbauen, sollten wir nach einer Weile eine Benachrichtigung erhalten, dass die Funktionsfähigkeit des Rollers wiederhergestellt wurde.
Mit Influx 2.0 wurde Kapacitor Teil der DB
Chronograph
Ich habe viele verschiedene UI-Lösungen für die Überwachung gesehen, aber ich kann sagen, dass es in Bezug auf Funktionalität und UX nichts Vergleichbares zu Chronograf gibt.
Wir haben seltsamerweise angefangen, den TICK-Stack mit Grafan als Webschnittstelle zu verwenden.
Ich werde seine Funktionalität nicht beschreiben; jeder kennt seine vielfältigen Möglichkeiten, alles einzurichten.
Allerdings ist Grafana immer noch ein völlig universelles Instrument, während Chronograf hauptsächlich für den Einsatz mit Influx konzipiert ist.
Und natürlich kann sich Chronograf dadurch viel mehr clevere oder komfortablere Funktionen leisten.
Der vielleicht größte Vorteil bei der Arbeit mit Chronograf besteht darin, dass Sie das Innere Ihrer InfluxDB über Explore anzeigen können.
Es scheint, dass Grafana fast die gleiche Funktionalität hat, aber in Wirklichkeit kann das Einrichten eines Dashboards in Chronograf mit ein paar Mausklicks erfolgen (und gleichzeitig die dortige Visualisierung betrachten), während Sie in Grafana früher oder später immer noch darüber verfügen werden um die JSON-Konfiguration zu bearbeiten (natürlich ermöglicht Chronograf das Hochladen Ihrer handkonfigurierten Dashas und deren Bearbeitung als JSON bei Bedarf – aber ich musste sie nie anfassen, nachdem ich sie auf der Benutzeroberfläche erstellt hatte).
Kibana verfügt über viel umfassendere Möglichkeiten zum Erstellen von Dashboards und Steuerelementen, aber die Benutzeroberfläche für solche Vorgänge ist sehr komplex.
Um ein praktisches Dashboard zu erstellen, ist ein gewisses Verständnis erforderlich. Und obwohl die Funktionalität von Chronograf-Dashboards geringer ist, ist deren Erstellung und Anpassung viel einfacher.
Die Dashboards selbst unterscheiden sich, abgesehen vom angenehmen visuellen Stil, eigentlich nicht von den Dashboards in Grafana oder Kibana:
So sieht das Abfragefenster aus:
Es ist unter anderem wichtig zu beachten, dass der Chronograph selbst Ihnen manchmal automatisch beim Schreiben einer Abfrage oder bei der Auswahl der richtigen Aggregationsfunktion wie Mittelwert helfen kann, wenn er die Feldtypen in der InfluxDB-Datenbank kennt.
Und natürlich ist Chronograf so bequem wie möglich zum Anzeigen von Protokollen. Es sieht aus wie das:
Standardmäßig sind Influx-Protokolle auf die Verwendung von Syslog zugeschnitten und verfügen daher über einen wichtigen Parameter – den Schweregrad.
Besonders praktisch ist die Grafik oben, auf der man die aufgetretenen Fehler sieht und anhand der Farbe sofort erkennt, ob der Schweregrad höher ist.
Ein paar Mal sind uns auf diese Weise wichtige Fehler aufgefallen, als wir die Protokolle der letzten Woche durchgesehen haben und eine rote Spitze gesehen haben.
Ideal wäre es natürlich, Benachrichtigungen für solche Fehler einzurichten, da wir dafür bereits alles hatten.
Wir haben dies sogar eine Zeit lang aktiviert, aber während der Vorbereitung des Pilotprojekts stellte sich heraus, dass wir ziemlich viele Fehler bekamen (einschließlich Systemfehlern wie der Nichtverfügbarkeit des LTE-Netzwerks), die auch den Slack-Kanal „spammten“. viel, ohne irgendwelche Probleme zu verursachen. großer Nutzen.
Die richtige Lösung wäre, die meisten dieser Fehlertypen zu behandeln, ihren Schweregrad anzupassen und erst dann die Alarmierung zu aktivieren.
Auf diese Weise würden nur neue oder wichtige Fehler in Slack gepostet. Aufgrund der knappen Fristen war einfach nicht genug Zeit für einen solchen Aufbau.
Authentifizierung
Erwähnenswert ist auch, dass Chronograf OAuth und OIDC als Authentifizierung unterstützt.
Dies ist sehr praktisch, da Sie es einfach an Ihren Server anschließen und ein vollwertiges SSO erstellen können.
In unserem Fall war es der Server — Er wurde verwendet, um eine Verbindung zur Überwachung herzustellen, aber derselbe Server wurde auch zur Authentifizierung von Rollern und Anfragen an das Back-End verwendet.
"Administrator"
Die letzte Komponente, die ich beschreiben werde, ist unser selbst geschriebenes „Admin-Panel“ in Vue.
Im Grunde handelt es sich nur um einen eigenständigen Dienst, der gleichzeitig Scooter-Informationen aus unseren eigenen Datenbanken, Microservices und Metrikdaten von InfluxDB anzeigt.
Darüber hinaus wurden viele Verwaltungsfunktionen dorthin verlagert, etwa ein Notfall-Neustart oder das Öffnen eines Schlosses aus der Ferne für das Support-Team.
Es gab auch Karten. Ich habe bereits erwähnt, dass wir mit Grafana statt mit Chronograf angefangen haben – denn für Grafana gibt es Karten in Form von Plugins, auf denen wir die Koordinaten von Rollern anzeigen können. Leider sind die Fähigkeiten von Karten-Widgets für Grafana sehr begrenzt, und dadurch war es viel einfacher, in wenigen Tagen eine eigene Webanwendung mit Karten zu schreiben, um die Koordinaten nicht nur im Moment zu sehen, sondern auch anzuzeigen B. die vom Roller zurückgelegte Route, die Möglichkeit, die Daten auf der Karte zu filtern usw. (all diese Funktionen, die wir in einem einfachen Dashboard nicht konfigurieren konnten).
Einer der bereits erwähnten Vorteile von Influx ist die Möglichkeit, ganz einfach eigene Metriken zu erstellen.
Dadurch ist der Einsatz für verschiedenste Szenarien möglich.
Wir haben versucht, alle nützlichen Informationen dort aufzuzeichnen: Akkuladung, Sperrstatus, Sensorleistung, Bluetooth, GPS und viele andere Gesundheitschecks.
Wir haben dies alles im Admin-Panel angezeigt.
Das wichtigste Kriterium für uns war natürlich der Betriebszustand des Rollers – tatsächlich prüft Influx diesen selbst und zeigt ihn mit „grünen Lichtern“ im Abschnitt „Knoten“ an.
Dies erledigt die Funktion — Wir haben es verwendet, um die Leistung unserer Box zu verstehen und dieselben Benachrichtigungen an Slack zu senden.
Übrigens haben wir die Roller nach den Namen von Charakteren aus den Simpsons benannt – es war so praktisch, sie voneinander zu unterscheiden
Und im Allgemeinen hat es so mehr Spaß gemacht. Sätze wie „Leute, Smithers ist tot!“ waren ständig zu hören.
String-Metriken
Wichtig ist, dass Sie mit InfluxDB nicht nur numerische Werte speichern können, wie es bei Victoria Metrics der Fall ist.
Es scheint, dass dies nicht so wichtig ist – schließlich können außer Protokollen alle Metriken in Form von Zahlen gespeichert werden (fügen Sie einfach eine Zuordnung für bekannte Zustände hinzu – eine Art Aufzählung)?
In unserem Fall gab es mindestens ein Szenario, in dem String-Metriken sehr nützlich waren.
Zufälligerweise war der Lieferant unserer „intelligenten Ladegeräte“ ein Dritter und wir hatten keine Kontrolle über den Entwicklungsprozess und die Informationen, die diese Ladegeräte liefern konnten.
Infolgedessen war die Lade-API alles andere als ideal, aber das Hauptproblem bestand darin, dass wir ihren Zustand nicht immer verstehen konnten.
Hier kam Influx zur Rettung. Wir haben einfach den String-Status, der zu uns kam, ohne Änderungen in das InfluxDB-Datenbankfeld geschrieben.
Eine Zeit lang gelangten dort nur Werte wie „online“ und „offline“, basierend darauf, welche Informationen in unserem Admin-Panel angezeigt und Benachrichtigungen an Slack gesendet wurden. Allerdings tauchten dort irgendwann auch Werte wie „abgekoppelt“ auf.
Wie sich später herausstellte, wurde dieser Status einmalig nach einem Verbindungsverlust gesendet, wenn das Ladegerät nach einer bestimmten Anzahl von Versuchen keine Verbindung zum Server herstellen konnte.
Wenn wir also nur einen festen Wertesatz verwenden würden, könnten wir diese Änderungen in der Firmware möglicherweise nicht zum richtigen Zeitpunkt sehen.
Und im Allgemeinen bieten String-Metriken viel mehr Einsatzmöglichkeiten; Sie können praktisch jede Information darin aufzeichnen. Allerdings müssen Sie dieses Tool natürlich auch sorgfältig verwenden.
Zusätzlich zu den üblichen Metriken haben wir auch GPS-Standortinformationen in InfluxDB aufgezeichnet. Dies war unglaublich nützlich, um den Standort von Rollern in unserem Admin-Panel zu überwachen.
Tatsächlich wussten wir immer, wo und welcher Roller sich gerade befand, wenn wir ihn brauchten.
Das war für uns bei der Suche nach einem Roller sehr nützlich (siehe Fazit am Ende).
Überwachung der Infrastruktur
Zusätzlich zu den Rollern selbst mussten wir auch unsere gesamte (ziemlich umfangreiche) Infrastruktur überwachen.
Eine sehr allgemeine Architektur sah etwa so aus:
Wenn wir einen reinen Monitoring-Stack hervorheben, sieht dieser so aus:
Was wir in der Cloud überprüfen möchten, ist:
- Datenbanken
- Schlüsselumhang
- Mikrodienste
Da sich alle unsere Cloud-Dienste in Kubernetes befinden, wäre es schön, Informationen über ihren Zustand zu sammeln.
Glücklicherweise kann Telegraf sofort eine große Anzahl von Metriken über den Zustand des Kubernetes-Clusters sammeln, und Chronograf bietet dafür sofort schöne Dashboards.
Wir haben hauptsächlich die Leistung der Pods und den Speicherverbrauch überwacht. Im Falle eines Sturzes gibt es Benachrichtigungen in Slack.
Es gibt zwei Möglichkeiten, Pods in Kubernetes zu verfolgen: DaemonSet und Sidecar.
Beide Methoden werden ausführlich beschrieben .
Wir haben Telegraf Sidecar verwendet und zusätzlich zu den Metriken Pod-Protokolle gesammelt.
In unserem Fall mussten wir an den Protokollen herumbasteln. Trotz der Tatsache, dass Telegraf Logs aus der Docker-API ziehen kann, wollten wir eine einheitliche Sammlung von Logs mit unseren Endgeräten haben und haben dafür Syslog für Container konfiguriert. Vielleicht war diese Lösung nicht schön, aber es gab keine Beschwerden über ihre Arbeit und die Protokolle wurden in Chronograf gut angezeigt.
Monitorüberwachung???
Am Ende stellte sich die uralte Frage nach der Überwachung von Überwachungssystemen, aber glücklicherweise oder leider fehlte uns dafür einfach die Zeit.
Obwohl Telegraf problemlos seine eigenen Metriken senden oder Metriken aus der InfluxDB-Datenbank sammeln kann, um sie entweder an denselben Influx oder an einen anderen Ort zu senden.
Befund
Welche Schlussfolgerungen haben wir aus den Ergebnissen des Piloten gezogen?
Wie können Sie eine Überwachung durchführen?
Erstens hat der TICK-Stack unsere Erwartungen voll und ganz erfüllt und uns noch mehr Möglichkeiten geboten, als wir ursprünglich erwartet hatten.
Alle von uns benötigten Funktionen waren vorhanden. Alles, was wir damit gemacht haben, hat ohne Probleme funktioniert.
Leistung
Das Hauptproblem des TICK-Stacks in der kostenlosen Version ist die fehlende Skalierbarkeit. Für uns war das kein Problem.
Wir haben keine genauen Belastungsdaten/Zahlen gesammelt, aber wir haben Daten von etwa 30 Rollern gleichzeitig gesammelt.
Jeder von ihnen sammelte mehr als drei Dutzend Messwerte. Gleichzeitig wurden Protokolle der Geräte erfasst. Die Datenerfassung und -sendung erfolgte alle 10 Sekunden.
Es ist wichtig anzumerken, dass wir nach anderthalb Wochen des Pilotprojekts, als der Großteil der „Kindheitswunden“ behoben und die wichtigsten Probleme bereits gelöst waren, die Häufigkeit des Sendens von Daten an den Server reduzieren mussten 30 Sekunden. Dies wurde notwendig, da der Verkehr auf unseren LTE-SIM-Karten schnell zu verschwinden begann.
Der Großteil des Datenverkehrs wurde durch Protokolle verbraucht; die Metriken selbst verschwendeten praktisch keinen Datenverkehr, selbst bei einem 10-Sekunden-Intervall.
Infolgedessen haben wir nach einiger Zeit die Sammlung von Protokollen auf Geräten vollständig deaktiviert, da bestimmte Probleme auch ohne ständige Sammlung bereits offensichtlich waren.
In einigen Fällen, wenn die Einsicht in die Protokolle dennoch notwendig war, haben wir uns einfach über WireGuard per VPN verbunden.
Ich füge außerdem hinzu, dass die einzelnen Umgebungen voneinander getrennt waren und die oben beschriebene Belastung nur für die Produktionsumgebung relevant war.
In der Entwicklungsumgebung haben wir eine separate InfluxDB-Instanz erstellt, die weiterhin alle 10 Sekunden Daten sammelte, und es traten keine Leistungsprobleme auf.
TICK – ideal für kleine bis mittlere Projekte
Aufgrund dieser Informationen würde ich zu dem Schluss kommen, dass der TICK-Stack ideal für relativ kleine Projekte oder Projekte ist, bei denen definitiv kein HighLoad erwartet wird.
Wenn Sie nicht über Tausende von Pods oder Hunderte von Maschinen verfügen, kann sogar eine InfluxDB-Instanz die Last problemlos bewältigen.
In einigen Fällen sind Sie möglicherweise mit Influx Relay als primitiver Hochverfügbarkeitslösung zufrieden.
Und natürlich hindert Sie niemand daran, eine „vertikale“ Skalierung einzurichten und einfach verschiedene Server für verschiedene Arten von Metriken zuzuweisen.
Wenn Sie sich über die erwartete Belastung der Überwachungsdienste nicht sicher sind oder garantiert eine sehr „schwere“ Architektur haben/haben werden, würde ich Ihnen nicht empfehlen, die kostenlose Version des TICK-Stacks zu verwenden.
Eine einfache Lösung wäre natürlich der Kauf - hier kann ich mich aber irgendwie nicht äußern, da ich selbst mit den Feinheiten nicht vertraut bin. Abgesehen davon, dass es sehr teuer und definitiv nicht für kleine Unternehmen geeignet ist.
In diesem Fall würde ich heute empfehlen, Metriken über Victoria Metrics und Protokolle mit Loki zu sammeln.
Zwar möchte ich erneut einen Vorbehalt anbringen, dass Loki/Grafana (aufgrund ihrer größeren Vielseitigkeit) viel weniger praktisch sind als der vorgefertigte TICK, aber sie sind kostenlos.
Es ist wichtig,: Alle hier beschriebenen Informationen sind für die Version Influx 1.8 relevant, derzeit steht Influx 2.0 kurz vor der Veröffentlichung.
Obwohl ich noch keine Gelegenheit hatte, es unter Kampfbedingungen auszuprobieren, und es schwierig ist, Rückschlüsse auf Verbesserungen zu ziehen, ist die Benutzeroberfläche definitiv noch besser geworden, die Architektur wurde vereinfacht (ohne Kondensator und Chronograf),
Vorlagen erschienen („Killer-Feature“ - ). Aber leider verfügt Version 2 im Moment nicht über den entscheidenden Punkt, für den wir uns für die erste Version entschieden haben – es gibt keine Protokollsammlung.
Diese Funktionalität wird auch in Influx 2.0 enthalten sein, wir konnten jedoch keine Fristen finden, nicht einmal ungefähre.
Wie man (jetzt) keine IoT-Plattformen erstellt
Am Ende haben wir nach dem Start des Pilotprojekts selbst unseren eigenen vollwertigen IoT-Stack zusammengestellt, da es keine für unsere Verhältnisse geeignete Alternative gab.
Seit Kurzem ist es jedoch in der Beta-Version verfügbar — Schade, dass sie nicht dabei war, als wir mit der Umsetzung des Projekts begannen.
Wir sind mit dem Endergebnis und der von uns selbst zusammengestellten Plattform auf Basis von Ansible + TICK + WireGuard rundum zufrieden. Aber heute würde ich empfehlen, sich Balena genauer anzusehen, bevor man versucht, selbst eine eigene IoT-Plattform aufzubauen.
Denn letztendlich kann es das meiste von dem tun, was wir getan haben, und OpenBalena ist kostenlos und Open Source.
Es weiß bereits, wie man nicht nur Updates sendet, sondern auch ein VPN ist bereits integriert und auf den Einsatz in einer IoT-Umgebung zugeschnitten.
Und erst kürzlich haben sie sogar ihre veröffentlicht , die sich leicht mit ihrem Ökosystem verbinden lässt.
Hey, was ist mit dem fehlenden Roller?
So verschwand der Roller „Ralph“ spurlos.
Wir rannten sofort los, um uns die Karte in unserem „Admin-Panel“ anzusehen, mit GPS-Metrikdaten von InfluxDB.
Dank der Überwachungsdaten konnten wir leicht feststellen, dass der Roller letzten Tag gegen 21:00 Uhr den Parkplatz verließ, etwa eine halbe Stunde zu einem bestimmten Ort fuhr und bis 5 Uhr morgens neben einem deutschen Haus geparkt war.
Nach 5 Uhr morgens wurden keine Überwachungsdaten mehr empfangen – das bedeutete, dass entweder die Zusatzbatterie vollständig entladen war oder der Angreifer endlich herausgefunden hatte, wie er die Smart-Hardware aus dem Roller entfernen konnte.
Trotzdem wurde die Polizei an die Adresse gerufen, an der sich der Roller befand. Der Roller war nicht da.
Allerdings war davon auch der Hausbesitzer überrascht, da er gestern Abend tatsächlich mit diesem Roller vom Büro nach Hause gefahren ist.
Wie sich herausstellte, kam einer der Support-Mitarbeiter frühmorgens an, holte den Roller ab, stellte fest, dass die Zusatzbatterie völlig entladen war, und brachte ihn (zu Fuß) zum Parkplatz. Und die Zusatzbatterie ist aufgrund von Feuchtigkeit ausgefallen.
Wir haben uns den Roller gestohlen. Ich weiß übrigens nicht, wie und wer das Problem mit dem Polizeifall dann gelöst hat, aber die Überwachung hat einwandfrei funktioniert...
Source: habr.com