Vor einem Jahr haben wir die Pilotversion eines Promo-Projekts für .
Ursprünglich hieß das Projekt Road-To-Barcelona, später wurde es in Road-To-Berlin umbenannt (daher die auf Screenshots auftauchenden Abkürzungen R2B) und schließlich in xRide.
Die Grundidee des Projekts bestand darin, statt eines zentralisierten Verleihservices für Autos oder Scooter (es handelt sich um Scooter aka E-Motorräder, nicht um Kick-Scooter) eine Plattform für die dezentrale Vermietung zu schaffen. Über die Herausforderungen, mit denen wir konfrontiert waren, .
Das Projekt war ursprünglich auf Autos ausgerichtet, doch aufgrund der Fristen, der langen Gespräche mit Herstellern und der Vielzahl an Sicherheitsbeschränkungen wurden für das Pilotprojekt elektrische Scooter ausgewählt.
Der Benutzer installierte die iOS- oder Android-Anwendung auf sein Telefon, wählte einen ihm gefallenden Scooter aus, anschließend stellte das Telefon eine peer-to-peer Verbindung zum Scooter her, es fand ein ETH-Austausch statt und der Benutzer konnte die Fahrt starten, indem er den Scooter über das Telefon einschaltete. Nach dem Ende der Fahrt konnte die Zahlung für die Fahrt ebenfalls über Ethereum aus dem Wallet des Benutzers auf dem Telefon erfolgen.
Neben den Scootern konnte der Benutzer in der App "intelligente Ladestationen" sehen, bei denen er die aktuelle Batterie selbst wechseln konnte, wenn sie leer war.
So sah unser Pilotprojekt aus, das im September letzten Jahres in zwei Städten Deutschlands gestartet wurde: Bonn und Berlin.
Eines Morgens in Bonn wurde unser Support-Team (das vor Ort dafür zuständig ist, die Scooter betriebsbereit zu halten) alarmiert: Einer der Scooter war spurlos verschwunden.
Wie können wir ihn finden und zurückbekommen?
In diesem Artikel werde ich darüber berichten, aber zuerst – wie wir unsere eigene IoT-Plattform aufgebaut haben und wie wir deren Monitoring umgesetzt haben.
Was und warum überwachen: Scooter, Infrastruktur, Ladestationen?
Was wollten wir also in unserem Projekt überwachen?
In erster Linie sind es die Roller – Elektroscooter sind an sich ziemlich teuer, und man sollte ein solches Projekt nicht starten, ohne ausreichend vorbereitet zu sein. Es ist wünschenswert, so viele Informationen wie möglich über die Scooter zu sammeln: über ihren Standort, den Ladezustand usw.
Darüber hinaus möchten wir den Zustand unserer eigenen IT-Infrastruktur überwachen – Datenbanken, Dienste und alles, was für deren Betrieb erforderlich ist. Es war notwendig, auch den Zustand der "intelligenten Ladegeräte" zu überwachen, für den Fall, dass sie defekt sind oder die Batterien leer sind.
Scooter
Wie sahen unsere Scooter aus und was wollten wir über sie wissen?
Das Wichtigste sind die GPS-Koordinaten, denn dank dieser können wir nachvollziehen, wo sie sich befinden und wohin sie sich bewegen.
Als Nächstes kommt der Ladezustand der Batterie, denn damit können wir feststellen, dass das Aufladen der Scooter dem Ende entgegengeht, und einen Juicer schicken oder zumindest den Benutzer warnen.
Natürlich müssen wir auch überprüfen, was mit unseren Hardware-Komponenten passiert:
- funktioniert Bluetooth?
- funktioniert das GPS-Modul?
- Wir hatten auch das Problem, dass das GPS falsche Koordinaten senden und "festhängen" konnte, was nur durch zusätzliche Überprüfungen am Roller festgestellt werden konnte.
und die Unterstützung so schnell wie möglich benachrichtigen, um das Problem zu beheben.
- Wir hatten auch das Problem, dass das GPS falsche Koordinaten senden und "festhängen" konnte, was nur durch zusätzliche Überprüfungen am Roller festgestellt werden konnte.
Und zuletzt: Überprüfungen der Software, beginnend mit dem Betriebssystem und der Prozessorlast, dem Netzwerk und der Festplatte, bis hin zu spezifischeren Überprüfungen unserer eigenen Module (, ).
Hardware
Wie sah unser "Hardware"-Teil aus?
Angesichts der sehr engen Fristen und der Notwendigkeit der schnellen Prototypenentwicklung wählten wir eine möglichst einfache und komponentenfreundliche Lösung – Raspberry Pi.
Neben dem RPi hatten wir eine maßgeschneiderte Platine (die wir selbst entwickelt und in China bestellt haben, um den Zusammenbau der Endlösung zu beschleunigen) und ein Set von Komponenten – Relais (zum Ein- und Ausschalten des Scooters), einen Batterielade-Reader, ein Modem, Antennen. All dies war kompakt in einer speziellen Box, der "xRide box", untergebracht.
Es ist auch zu beachten, dass die gesamte Box von einer zusätzlichen Powerbank gespeist wurde, die ihrerseits von der Hauptbatterie des Scooters versorgt wurde.
Dies ermöglichte es, die Überwachung zu nutzen und den Scooter auch nach der Fahrt einzuschalten, da die Hauptbatterie sofort nach dem Drehen des Zündschlüssels in die Position "aus" abgeschaltet wurde.
Docker? Einfaches Linux? und Deployment
Kehren wir zur Überwachung zurück, also Raspberry – was haben wir?
Eine der ersten Dinge, die wir nutzen wollten, um den Prozess des Deployments, der Updates und der Auslieferung von Komponenten auf physische Geräte zu beschleunigen, war Docker.
Leider wurde ziemlich schnell klar, dass Docker auf RPi zwar funktionierte, aber eine ausreichende Menge an Overhead verursachte, insbesondere hinsichtlich des Energieverbrauchs.
Der Unterschied zur Nutzung des "nativen" OS war zwar nicht so stark, aber dennoch ausreichend, um uns vor einer zu schnellen Entladung zu warnen.
Ein weiterer Grund war eine der Bibliotheken unserer Partner in Node.js (sic!) – das einzige Systemelement, das nicht in Go/C/C++ geschrieben wurde.
Die Autoren der Bibliothek hatten nicht rechtzeitig eine funktionierende Version in einer der "nativen" Sprachen bereitgestellt.
Zudem ist der Knoten für leistungsschwache Geräte nicht die eleganteste Lösung, und auch die Bibliothek selbst war ziemlich ressourcenintensiv.
Wir haben festgestellt, dass die Nutzung von Docker für uns trotz aller Bemühungen zu viel Overhead verursachen würde. Die Entscheidung fiel zugunsten eines nativen Betriebssystems und der direkten Arbeit unter diesem.
Betriebssystem
Letztendlich haben wir uns erneut für die einfachste Variante entschieden und Raspbian (eine Debian-Version für den Pi) verwendet.
Unsere gesamte Software schreiben wir in Go, weshalb auch das Hauptmodul des Hardware-Agenten in unserem System in Go geschrieben wurde.
Es ist genau für die Arbeit mit GPS, Bluetooth, das Ablesen des Ladezustands, das Einschalten des Scooters usw. verantwortlich.
Deployment
Hier stellte sich die Frage nach der Notwendigkeit, einen Mechanismus zur Bereitstellung von Updates auf die Geräte (OTA) zu implementieren — sowohl für Updates unserer Agenten/Anwendungen als auch für das Betriebssystem/"Firmware" (da neue Versionen des Agenten möglicherweise Aktualisierungen des Kerns oder Systemkomponenten, Bibliotheken usw. benötigen könnten).
Nach einer ausführlichen Marktanalyse stellte sich heraus, dass es eine Vielzahl von Lösungen für die Bereitstellung von Updates auf das Gerät gibt.
Von relativ einfachen Dienstprogrammen, die größtenteils auf Updates/Dual-Boot ausgerichtet sind, wie swupd/SWUpdate/OSTree, bis hin zu vollwertigen Plattformen wie Mender und Balena.
Zunächst haben wir entschieden, dass uns tatsächlich End-to-End-Lösungen interessieren, daher fiel die Wahl sofort auf die Plattformen.
Die Plattform wurde ausgeschlossen, da sie im Grunde dieselbe Docker-Technologie in ihrem balenaEngine verwendet.
Ich möchte jedoch anmerken, dass wir letztendlich ihr Produkt zum Flashen von Firmware auf SD-Karten ständig verwendet haben – ein einfaches und äußerst praktisches Dienstprogramm dafür.
Daher fiel die finale Wahl auf . Mender ist eine vollwertige Plattform zum Erstellen, Bereitstellen und Installieren von Firmware.
Insgesamt sieht die Plattform einfach großartig aus, aber wir benötigten etwa anderthalb Wochen nur, um die richtige Version unserer Firmware mit dem Mender-Baustein zu erstellen.
Und je mehr wir uns mit den Feinheiten seiner Nutzung beschäftigten, desto klarer wurde, dass wir für eine vollständige Implementierung viel mehr Zeit benötigen würden, als wir zur Verfügung hatten.
Leider haben unsere engen Fristen dazu geführt, dass wir auf die Nutzung von Mender verzichten und einen noch einfacheren Ansatz gewählt haben.
Ansible
Die einfachste Lösung in unserer Situation war die Verwendung von Ansible. Ein paar Playbooks waren für den Anfang völlig ausreichend.
Der Kern bestand darin, dass wir uns einfach von einem Host (CI-Server) per SSH mit unseren Raspberry Pis verbunden haben und Updates auf diese rollten.
Anfangs war alles einfach — man musste sich nur im gleichen Netzwerk wie die Geräte befinden, das Rollout erfolgte über Wi-Fi.
Im Büro standen einfach ein Dutzend Test-Raspberry Pis, die mit demselben Netzwerk verbunden waren, jedes Gerät hatte eine statische IP-Adresse, die auch im Ansible-Inventory angegeben war.
Ansible war es, das unseren Monitoring-Agenten auf die Endgeräte lieferte.
3G/LTE
Leider konnte diese Ansible-Variante nur im Entwicklungsmodus funktionieren, solange wir noch keine echten Scooter hatten.
Denn Scooter, wie Sie verstehen, können nicht ständig mit einem einzigen Wi-Fi-Router verbunden sein, während sie auf Netzwerkupdates warten.
In der Realität können Scooter überhaupt keine Verbindung außer über mobile 3G/LTE haben (und auch das nicht ständig).
Dies führt sofort zu vielen Problemen und Einschränkungen, wie zum Beispiel langsamen Verbindungen und instabilen Netzverhältnissen.
Aber das Wichtigste ist, dass wir in einem 3G/LTE-Netz nicht einfach auf eine statische IP-Adresse in diesem Netz hoffen können.
Einige Anbieter von SIM-Karten bieten teilweise Lösungen an, es gibt sogar spezielle SIM-Karten für IoT-Geräte mit statischen IP-Adressen. Aber wir hatten keinen Zugang zu solchen SIM-Karten und konnten IP-Adressen nicht nutzen.
Natürlich gab es Ideen, eine Art IP-Registrierung oder Service-Discovery wie bei Consul zu implementieren, aber solche Ideen mussten fallen gelassen werden, da sich IP-Adressen während der Tests zu häufig ändern konnten, was zu einer großen Instabilität führte.
Aus diesem Grund wäre die praktischste Nutzung für die Übermittlung von Metriken nicht das Pull-Modell, bei dem wir die benötigten Metriken von den Geräten abrufen, sondern das Push-Modell, bei dem die Metriken direkt vom Gerät auf den Server übermittelt werden.
VPN
Als Lösung für dieses Problem haben wir VPN gewählt — genauer gesagt, .
Die Clients (Scooter) haben sich beim Start des Systems mit dem VPN-Server verbunden und hatten die Möglichkeit, sich mit ihnen zu verbinden. Dieser Tunnel wurde für die Bereitstellung von Updates genutzt.
The same tunnel could theoretically be used for monitoring, but such a connection was more complex and less reliable than simple push.
Cloud resources
Finally, we need to monitor our cloud services and databases, as we use Kubernetes for them. Ideally, the deployment of monitoring within the cluster should be as simple as possible. Ideally — using , as we mostly use it for deployment. And, of course, the same solutions should be used for cloud monitoring as for the scooters themselves.
Gegeben
Phew, it seems we've clarified the description; let's compile a list of what we ultimately needed:
- A quick solution, as monitoring needs to start during the development process
- Volume/quantity — we need numerous metrics
- Log collection is mandatory
- Reliability — data is critically important for the success of the launch
- The pull model cannot be used — a push is required
- A unified monitoring system is needed, not only for hardware but also for the cloud
The final picture looked something like this
Choice of stack
So, we faced the question of choosing a stack for monitoring.
In erster Linie suchten wir nach einer umfassenden All-in-One-Lösung, die alle unsere Anforderungen abdeckt und gleichzeitig flexibel genug ist, um sie an unsere Bedürfnisse anzupassen. Schließlich hatten wir viele Beschränkungen durch die Hardware, die Architektur und die Zeitvorgaben.
Es gibt eine riesige Auswahl an Überwachungslösungen, angefangen von vollwertigen Systemen wie , oder bis hin zu bereits fertigen Lösungen für das Flottenmanagement.
Ursprünglich schienen die letzteren die ideale Lösung für uns zu sein, aber einige boten keine umfassende Überwachung, andere hatten die Möglichkeiten der kostenlosen Versionen stark eingeschränkt, und dritte deckten einfach nicht unsere "Wünsche" ab oder waren nicht flexibel genug, um sie an unsere Szenarien anzupassen. Manche waren einfach veraltet.
Nach der Analyse einer Vielzahl ähnlicher Lösungen 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 einsatzbereiten Flottenmanagement-Plattform, aber wir müssen keine Kompromisse eingehen.
So gut wie sicher gibt es unter der Vielzahl an Lösungen bereits eine, die perfekt zu uns passt, aber in unserem Fall war es deutlich schneller, einen eigenen Stack zusammenzustellen und ihn "anpassbar" zu machen, als fertige Produkte zu testen.
Dabei strebten wir nicht an, eine vollwertige Monitoring-Plattform selbst zu erstellen, sondern suchten nach den funktionalsten "fertigen" Stacks, die sich flexibel anpassen lassen.
(B)ELK?
Die erste Lösung, die wir ernsthaft in Betracht gezogen haben, ist der weithin bekannte ELK-Stack.
Tatsächlich sollte er BELK heißen, denn alles beginnt mit Beats. —
Natürlich ist ELK eine der bekanntesten und leistungsstärksten Lösungen im Bereich Monitoring und ganz besonders in der Erfassung und Verarbeitung von Logs.
Wir gingen davon aus, dass ELK zur Erfassung von Logs verwendet wird und ebenso als langfristiger Speicher für Metriken, die aus Prometheus gewonnen wurden.
Für die Visualisierung kann Grafana verwendet werden.
Tatsächlich kann der aktuelle ELK-Stack auch Metriken selbst erfassen (metricbeat), und Kibana kann diese ebenfalls anzeigen.
Aber nichtsdestotrotz ist der ELK-Stack ursprünglich aus Logs entstanden, und die Funktionalität für Metriken hat noch einige ernsthafte Mängel.
- Deutlich langsamer als Prometheus
- In deutlich weniger Anwendungen integrierbar als Prometheus
- Die Alarmierung ist schwierig einzurichten
- Metriken benötigen viel Speicherplatz
- Das Einrichten von Dashboards mit Metriken in Kibana ist deutlich komplizierter als in Grafana
Insgesamt sind Metriken in ELK schwerfällig und bislang nicht so benutzerfreundlich wie in anderen Lösungen, von denen es tatsächlich deutlich mehr gibt als nur Prometheus: TSDB, Victoria Metrics, Cortex usw. Natürlich würde man sich wünschen, gleich eine vollwertige All-in-One-Lösung zu haben, aber bei Metricbeat gab es einfach zu viele Kompromisse.
Zudem hat der ELK-Stack selbst einige Herausforderungen:
- Er ist ressourcenintensiv, manchmal sogar sehr, wenn Sie eine große Menge an Daten sammeln.
- Er muss "beherrscht" werden — das Skalieren ist notwendig, geschieht jedoch nicht trivial.
- Eingeschränkte kostenlose Version — die kostenlose Version bietet keine angemessene Alarmierung, beim Auswahlzeitpunkt gab es auch keine Authentifizierung.
Es muss gesagt werden, dass es in letzter Zeit mit letzterem Punkt besser geworden ist und zusätzlich zur (einschließlich Authentifizierung) begann sich auch das Preismodell zu ändern.
Aber zu dem Zeitpunkt, als wir dieses System implementieren wollten, gab es überhaupt keine Alerting-Funktion.
Vielleicht hätte man versuchen können, etwas mit ElastAlert oder anderen Community-Lösungen zusammenzustellen, aber wir haben uns dennoch entschieden, andere Alternativen in Betracht zu ziehen.
Loki — Grafana — Prometheus
Derzeit könnte eine gute Lösung darin bestehen, einen Monitoring-Stack basierend auf reinem Prometheus als Metrikanbieter, Loki für Logs und Grafana für die Visualisierung aufzubauen.
Leider befand sich Loki zum Zeitpunkt des Verkaufsstarts des Pilotprojekts (September-Oktober 2019) noch in der Beta-Version 0.3-0.4 und konnte zum Zeitpunkt des Entwicklungsstarts überhaupt nicht als Produktionslösung betrachtet werden.
Ich habe bisher keine Erfahrung mit der realen Nutzung von Loki in größeren Projekten, kann aber sagen, dass Promtail (der Agent zum Sammeln von Logs) sowohl für Bare-Metal-Server als auch für Pods in Kubernetes hervorragend funktioniert.
TICK
Vielleicht ist der derzeit einzig ernstzunehmende (und voll funktionsfähige) Ersatz für den ELK-Stack der TICK-Stack — Telegraf, InfluxDB, Chronograf, Kapacitor.
Ich werde alle Komponenten weiter unten ausführlicher beschreiben, aber die grundlegende Idee ist folgende:
- Telegraf — ein Agent zur Erfassung von Metriken
- InfluxDB — eine Datenbank für Metriken
- Kapacitor — Echtzeit-Metrik-Handler für Alarme
- Chronograf — Web-Oberfläche zur Visualisierung
Für InfluxDB, Kapacitor und Chronograf gibt es offizielle Helm-Charts, die wir für die Bereitstellung verwendet haben.
Es ist zu beachten, dass in der aktuellen Version Influx 2.0 (Beta) Kapacitor und Chronograf Teil von InfluxDB geworden sind und nicht mehr separat existieren.
Telegraf
ist ein sehr leichter Agent zur Sammlung von Metriken auf der Endmaschine.
Er kann eine Vielzahl von Dingen überwachen, von bis zu
Server .
Er bietet eine Reihe von coolen Vorteilen:
- Schnell und leicht (in Go geschrieben)
- Verbraucht minimale Ressourcen
- Push-Metriken standardmäßig
- Sammelt alle notwendigen Metriken
- Systemmetriken ohne jegliche Konfiguration
- Hardwaremetriken wie Informationen von Sensoren
- Sehr einfache Möglichkeit, eigene Metriken hinzuzufügen
- Viele Plugins "out of the box"
- Sammelt Logs
Da Push-Metriken für uns erforderlich waren, waren all die anderen Vorteile mehr als willkommene Ergänzungen.
Die Sammlung von Logs durch denselben Agenten ist ebenfalls sehr praktisch, da keine zusätzlichen Tools zum Verfolgen der Logs erforderlich sind.
Influx bietet ein äußerst benutzerfreundliches Erlebnis mit Logs, wenn Sie .
Telegraf ist ein hervorragender Agent zum Sammeln von Metriken, selbst wenn Sie den Rest des ICK-Stacks nicht nutzen.
Viele kombinieren ihn mit ELK und verschiedenen anderen Zeitreihendatenbanken aufgrund der Benutzerfreundlichkeit, da er in der Lage ist, Metriken fast überall zu schreiben.
InfluxDB
InfluxDB ist das zentrale Kernstück des TICK-Stacks und dient als Zeitreihendatenbank für Metriken.
Neben Metriken kann Influx auch Protokolle speichern, wobei Protokolle im Grunde genommen nur ähnliche Metriken sind, wobei anstelle gewöhnlicher numerischer Werte der Hauptfokus auf einer Textzeile im Protokoll liegt.
InfluxDB ist ebenfalls in Go geschrieben und scheint signifikant schneller zu laufen als ELK auf unserem (nicht sehr leistungsstarken) Cluster.
Zu den großartigen Vorteilen von Influx zählt zudem eine sehr benutzerfreundliche und umfassende API für Datenanfragen, die wir sehr aktiv genutzt haben.
Nachteile — $$$ oder Skalierung?
Der TICK-Stack hat nur einen Mangel festgestellt — er ist teuer. Sehr teuer.
Was ist in der kostenpflichtigen Version enthalten, was in der kostenlosen fehlt?
Soweit wir verstehen konnten, ist der einzige Unterschied zwischen der kostenpflichtigen und der kostenlosen Version des TICK-Stacks die Skalierbarkeit.
Genau — einen Cluster mit hoher Verfügbarkeit kann man nur in .
Wenn Sie vollständiges HA wünschen, müssen Sie entweder bezahlen oder irgendwelche Workarounds entwickeln. Es gibt ein paar Community-Lösungen — zum Beispiel scheint eine durchdachte Lösung zu sein, aber es steht geschrieben, dass sie nicht für die Produktion geeignet ist, ebenso wie
— eine einfache Lösung für den Datentransfer über NATS (das muss auch skaliert werden, aber das ist machbar).
Leider scheinen beide aufgegeben zu sein — es gibt keine neuen Commits, ich vermute, dass es mit der bald erwarteten Veröffentlichung der neuen Version Influx 2.0 zusammenhängt, in der vieles anders sein wird (bislang gibt es keine Informationen zur Skalierung darin).
Offiziell gibt es für die kostenlose Version — das ist im Grunde primitive HA, aber nur durch Lastverteilung,
da alle Daten an alle InfluxDB-Instanzen hinter dem Lastenverteiler geschrieben werden.
Es hat einige wie mögliche Probleme mit dem Überschreiben von Punkten und die Notwendigkeit, Datenbanken für Metriken im Voraus zu erstellen,
(was bei normalem Betrieb mit InfluxDB automatisch geschieht).
Außerdem , das bedeutet zusätzliche Kosten für duplizierte Metriken (sowie deren Verarbeitung und Speicherung), die möglicherweise nicht benötigt werden, aber deren Möglichkeiten nicht aufgeteilt werden können.
Victoria Metrics?
Letztendlich, obwohl uns der gesamte TICK-Stack abgesehen von der kostenpflichtigen Skalierung vollkommen zusagte, entschieden wir uns, nach kostenlosen Lösungen zu suchen, die die InfluxDB-Datenbank ersetzen könnten, während wir die anderen T_CK-Komponenten beibehielten.
Es gibt viele Zeitreihendatenbanken, aber die vielversprechendste ist Victoria Metrics, die eine Reihe von Vorteilen bietet:
- Schnell und einfach, zumindest laut den Ergebnissen
- Es gibt eine Cluster-Version, über die es sogar gute Rezensionen gibt
- Sie kann sharded werden
- Unterstützt das InfluxDB-Protokoll
Wir hatten nicht vor, einen vollständig benutzerdefinierten Stack auf Basis von Victoria zu bauen, und die Haupthoffnung war, dass wir sie als Drop-in-Ersatz für InfluxDB nutzen könnten.
Leider ist dies nicht möglich, obwohl das InfluxDB-Protokoll unterstützt wird, funktioniert es nur für das Schreiben von Metriken – nach "außen" ist nur die Prometheus-API verfügbar, daher kann Chronograf nicht darauf gerichtet werden.
Darüber hinaus werden für Metriken nur numerische Werte unterstützt (für benutzerdefinierte Metriken haben wir Zeichenfolgenwerte verwendet — dazu mehr im Abschnitt ).
Offensichtlich kann die VM aus demselben Grund keine Protokolle speichern wie Influx.
Zudem sollte erwähnt werden, dass Victoria Metrics zum Zeitpunkt der Suche nach der optimalen Lösung noch nicht so populär war, die Dokumentation deutlich geringer war und die Funktionalität schwächer war
(ich kann mich nicht an eine detaillierte Beschreibung der Cluster-Version und Shardierung erinnern).
Wahl der Datenbank
Infolgedessen wurde entschieden, dass wir für den Pilotversuch vorerst mit einem einzelnen Knoten InfluxDB auskommen.
Es gab mehrere Hauptgründe für diese Wahl:
- Wir waren mit der Funktionalität des gesamten TICK-Stacks sehr zufrieden
- Wir hatten es bereits implementiert, und es funktionierte hervorragend
- Die Fristen drängten, und wir hatten nicht viel Zeit, um andere Optionen zu testen
- Wir erwarteten nicht eine so hohe Last
Für die erste Phase des Piloten hatten wir nicht viele Scooter, und das Testen während der Entwicklung hatte keine Leistungsprobleme aufgezeigt.
Daher haben wir entschieden, dass für dieses Projekt ein einzelner Knoten Influx ohne Skalierungsbedarf völlig ausreichend ist (siehe die Schlussfolgerungen am Ende).
Mit dem Stack und der Basis haben wir entschieden – jetzt geht es um die anderen Komponenten des TICK-Stacks.
Kapacitor
Kapacitor ist ein Teil des TICK-Stacks, ein Dienst, der in Echtzeit die in die Datenbank eintreffenden Metriken überwachen und basierend auf Regeln verschiedene Aktionen ausführen kann.
Im Allgemeinen wird es als Werkzeug zur potenziellen Anomalieüberwachung und maschinellem Lernen positioniert (ich bin mir nicht sicher, ob diese Funktionen wirklich gefragt sind), aber der am häufigsten genutzte Anwendungsfall ist viel banaler – es dient zur Alarmierung.
So haben wir es auch für Benachrichtigungen verwendet. Wir haben Slack-Benachrichtigungen eingerichtet, um zu informieren, wenn ein bestimmter Scooter abgeschaltet wurde; dasselbe wurde für intelligente Ladegeräte und wichtige Komponenten der Infrastruktur durchgeführt.
Das ermöglichte eine schnelle Reaktion auf Probleme und eine Benachrichtigung darüber, dass alles wieder in Ordnung war.
Ein einfaches Beispiel – wenn die zusätzliche Batterie für die Stromversorgung unserer "Box" kaputt ist oder aus irgendeinem Grund leer wurde, sollten wir nach dem Austausch durch eine neue nach einiger Zeit eine Benachrichtigung über die Wiederherstellung der Funktionalität des Scooters erhalten.
In Influx 2.0 wurde Kapacitor Teil der DB
Chronograf
Ich habe viele verschiedene UI-Lösungen für das Monitoring gesehen, aber ich kann sagen, dass nichts in Bezug auf Funktionalität und UX mit Chronograf vergleichbar ist.
Wir haben mit dem TICK-Stack begonnen, überraschenderweise mit Grafana als Weboberfläche.
Ich werde ihre Funktionalität nicht beschreiben, jeder kennt ihre umfangreichen Anpassungsmöglichkeiten.
Grafana ist jedoch ein ziemlich universelles Werkzeug, während Chronograf hauptsächlich für die Verwendung mit Influx optimiert ist.
Und natürlich ermöglicht es Chronograf, viel raffiniertere oder komfortablere Funktionen zu bieten.
Die Hauptnützlichkeit von Chronograf besteht darin, dass Sie die inneren Abläufe Ihrer InfluxDB über Explore einsehen können.
Es scheint, dass Grafana fast identische Funktionalitäten bietet, aber in Wirklichkeit kann das Dashboard in Chronograf mit nur wenigen Mausklicks eingerichtet werden (während man die Visualisierung dabei sieht), während Sie in Grafana früher oder später die JSON-Konfiguration bearbeiten müssen (natürlich erlaubt Chronograf, Ihre manuell erstellten Dashboards zu exportieren und bei Bedarf als JSON zu bearbeiten – aber ich musste sie nach der Erstellung über die UI nie anfassen).
In Kibana gibt es deutlich umfangreichere Möglichkeiten zur Erstellung von Dashboards und deren Steuerung, jedoch ist das UX für solche Aufgaben sehr komplex.
Es erfordert ein gewisses Verständnis, um ein benutzerfreundliches Dashboard zu erstellen. Obwohl die Funktionalität der Dashboards in Chronograf geringer ist, sind sie viel einfacher zu erstellen und anzupassen.
Die Dashboards selbst unterscheiden sich, abgesehen von ihrem ansprechenden visuellen Stil, eigentlich nicht von den Dashboards in Grafana oder Kibana:
So sieht das Anforderungsfenster aus:
Es ist wichtig zu erwähnen, dass Chronograf hin und wieder automatisch beim Schreiben von Abfragen oder der Auswahl der richtigen Aggregationsfunktion wie dem Durchschnitt helfen kann, wenn man die Datentypen in der InfluxDB kennt.
Natürlich ist Chronograf auch maximal benutzerfreundlich für die Anzeige von Logs. So sieht es aus:
Standardmäßig sind die Influx-Logs für die Verwendung mit syslog optimiert, weshalb sie einen wichtigen Parameter — severity — enthalten.
Besonders hilfreich ist das oberste Diagramm, in dem man auftretende Fehler sehen kann und die Farbe sofort deutlich zeigt, wenn die Schwere höher ist.
Auf diese Weise haben wir ein paar Mal wichtige Bugs entdeckt, indem wir die Logansicht der letzten Woche überprüft und einen roten Spike gesehen haben.
Natürlich wäre es ideal, eine Alarmierung für solche Fehler einzurichten, zumal wir dafür bereits alles bereit hatten.
Wir hatten es sogar eine Zeit lang aktiviert, aber während der Vorbereitung des Piloten stellte sich heraus, dass viele Fehler auftraten (einschließlich systembedingter wie die Nichtverfügbarkeit des LTE-Netzwerks), die die Slack-Kanäle zu sehr "spammten", ohne dabei großen Nutzen zu bieten.
Die richtige Lösung wäre gewesen, die meisten dieser Fehlerarten zu verarbeiten, deren Schweregrad einzustellen und erst danach die Alarmierung zu aktivieren.
Auf diese Weise würden in Slack nur neue oder wichtige Fehler gelangen. Für ein solches Setup fehlte einfach die Zeit angesichts der engen Fristen.
Authentifizierung
Es ist erwähnenswert, dass Chronograf OAuth und OIDC als Authentifizierung unterstützt.
Das ist sehr praktisch, da es einfach ist, es an Ihren Server anzudocken und ein vollständiges SSO zu ermöglichen.
In unserem Fall war der Server — er wurde zur Verbindung mit der Überwachung verwendet, aber derselbe Server wurde auch zur Authentifizierung der Scooter und Anfragen an das Backend genutzt.
„Adminbereich“
Die letzte Komponente, die ich beschreiben möchte, ist unser selbstgebauter "Adminbereich" auf Vue.
Im Grunde genommen handelt es sich einfach um einen separaten Dienst, der Informationen über die Scooter gleichzeitig aus unseren eigenen Datenbanken, Mikrodiensten und Metrikdaten aus InfluxDB anzeigt.
Außerdem wurden viele Verwaltungsfunktionen wie die Notfallneustart oder das remote Öffnen des Schlosses für das Support-Team dort integriert.
Dort gab es auch Karten. Ich hatte bereits erwähnt, dass wir mit Grafana anstelle von Chronograf begonnen haben — denn für Grafana sind Plugins verfügbar, die Karten anzeigen, auf denen man die Koordinaten der Scooter sehen konnte. Leider sind die Möglichkeiten der Karten-Widgets für Grafana sehr eingeschränkt, und es war daher wesentlich einfacher, in wenigen Tagen eine eigene Webanwendung mit Karten zu erstellen, um nicht nur die aktuellen Koordinaten anzuzeigen, sondern auch die zurückgelegte Route des Scooters darzustellen, Daten auf der Karte filtern zu können usw. (alle Funktionen, die wir in einem einfachen Dashboard nicht einrichten konnten).
Einer der bereits erwähnten Vorteile von Influx ist die Möglichkeit, eigene Metriken einfach zu erstellen.
Das ermöglicht die Nutzung für eine riesige Vielzahl von Szenarien.
Wir haben versucht, dort alle nützlichen Informationen zu speichern: den Batteriestand, den Zustand des Schlosses, die Funktionsfähigkeit der Sensoren, Bluetooth, GPS und viele andere Gesundheitschecks.
All das haben wir im Admin-Panel dargestellt.
Natürlich war das wichtigste Kriterium für uns der Betriebszustand des Scooters — tatsächlich überprüft Influx dies selbst und zeigt es im Abschnitt Nodes mit "grünen Lichtern" an.
Dies erfolgt durch die Funktion — wir haben diese ebenfalls verwendet, um die Funktionsfähigkeit unseres Kästchens zu verstehen und die entsprechenden Alarme an Slack zu senden.
Übrigens haben wir die Scooter nach Charakteren aus den Simpsons benannt — so konnten wir sie leicht voneinander unterscheiden.
Und überhaupt war es so lustiger. Es fielen ständig Sätze wie "Leute — Smithers ist tot!"
String-Metriken
Es ist wichtig, dass InfluxDB nicht nur numerische Werte speichert, wie es bei Victoria Metrics der Fall ist.
Man könnte denken, das sei nicht so wichtig — schließlich kann man, abgesehen von Logs, alle Metriken als Zahlen speichern (man muss nur ein Mapping für bekannte Zustände hinzufügen — eine Art Enum)?
In unserem Fall gab es mindestens ein Szenario, in dem stringbasierte Metriken sehr nützlich waren.
Es stellte sich heraus, dass der Anbieter unserer "intelligenten Ladegeräte" extern war, und wir keine Kontrolle über den Entwicklungsprozess und die Informationen hatten, die diese Ladegeräte liefern konnten.
Infolgedessen war die API der Ladegeräte alles andere als ideal, aber das Hauptproblem war, dass wir nicht immer ihren Status verstehen konnten.
Hier kam Influx ins Spiel. Wir haben einfach den ankommenden String-Status unverändert in das InfluxDB-Feld aufgezeichnet.
Eine Zeit lang kamen dort nur Werte wie "online" und "offline" an, auf deren Basis die Informationen in unserem Admin-Bereich angezeigt und Benachrichtigungen in Slack gesendet wurden. Doch irgendwann wurden auch Werte wie "disconnected" erfasst.
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.
So hätten wir, wenn wir nur eine feste Menge von Werten verwendet hätten, diese Änderungen in der Firmware zur richtigen Zeit möglicherweise nicht gesehen.
Und im Allgemeinen bieten zeilenbasierte Metriken wesentlich mehr Verwendungsmöglichkeiten, da man praktisch jede Art von Informationen darin speichern kann. Natürlich sollte man dieses Werkzeug auch mit Bedacht einsetzen.
Neben den gewöhnlichen Metriken haben wir auch GPS-Standortinformationen in InfluxDB aufgezeichnet. Das war unglaublich praktisch, um den Standort der Scooter in unserem Admin-Panel zu überwachen.
So wussten wir immer, wo sich welcher Scooter zu einem bestimmten Zeitpunkt befand.
Das war besonders hilfreich, als wir einen Scooter gesucht haben (siehe die Ergebnisse am Ende).
Überwachung der Infrastruktur
Neben den Scootern war es notwendig, auch unsere (recht umfangreiche) Infrastruktur zu überwachen.
Eine sehr allgemeine Architektur sah ungefähr so aus:
Wenn wir nur den reinen Überwachungs-Stack betrachten, sieht er folgendermaßen aus:
Was wir in der Cloud überprüfen möchten, ist:
- Datenbanken
- Keycloak
- Mikroservices
Da sich all unsere Cloud-Dienste in Kubernetes befinden, wäre es nützlich, auch Informationen über dessen Zustand zu sammeln.
Glücklicherweise kann Telegraf "out of the box" eine riesige Menge an Metriken zum Zustand des Kubernetes-Clusters sammeln, und Chronograf bietet sofort schöne Dashboards dafür an.
Wir haben hauptsächlich die Funktionsfähigkeit der Pods und den Speicherverbrauch überwacht. Im Falle eines Ausfalls gab es Alerts in Slack.
Für die Überwachung von Pods in Kubernetes gibt es zwei Möglichkeiten: DaemonSet und Sidecar.
Beide Methoden sind ausführlich beschrieben .
Wir haben Telegraf Sidecar verwendet und neben Metriken auch die Logs der Pods gesammelt.
In unserem Fall mussten wir mit den Logs etwas mühen. Obwohl Telegraf in der Lage ist, Logs aus der Docker-API zu ziehen, wollten wir eine einheitliche Log-Sammlung mit unseren Endgeräten und haben dafür Syslog für die Container konfiguriert. Vielleicht war diese Lösung nicht elegant, aber es gab keine Beschwerden über ihre Funktionsweise und die Logs wurden gut in Chronograf angezeigt.
Monitoring des Monitorings???
Letztendlich stand die ewige Frage der Überwachung von Überwachungssystemen, aber glücklicherweise oder leider hatten wir einfach nicht die Zeit dafür.
Obwohl Telegraf leicht seine eigenen Metriken senden oder Metriken aus der InfluxDB-Datenbank sammeln kann, um sie entweder in dasselbe Influx oder irgendwo anders zu senden.
Fazit
Welche Schlussfolgerungen haben wir aus dem Pilotprojekt gezogen?
Wie kann Monitoring durchgeführt werden?
In erster Linie hat der TICK-Stack unsere Erwartungen vollkommen erfüllt und uns sogar mehr Möglichkeiten gegeben, als wir ursprünglich erwartet hatten.
Alle Funktionen, die wir benötigten, waren vorhanden. Alles, was wir damit gemacht haben, funktionierte problemlos.
Leistung
Das Hauptproblem des TICK-Stacks in der kostenlosen Version ist das Fehlen von Skalierungsmöglichkeiten. Für uns stellte das jedoch kein Problem dar.
Wir haben keine genauen Daten/Zahlen zur Last gesammelt, aber wir haben Daten von etwa 30 Scootern gleichzeitig gesammelt.
Jeder von ihnen sammelte mehr als drei Dutzend Metriken. Gleichzeitig wurden Protokolle von den Geräten gesammelt. Die Daten wurden alle 10 Sekunden erfasst und gesendet.
Es ist wichtig zu erwähnen, dass wir nach anderthalb Wochen des Pilotprojekts, als die meisten "Kinderkrankheiten" behoben waren und die wichtigsten Probleme bereits gelöst wurden, die Häufigkeit der Datenübertragung an den Server auf 30 Sekunden verringern mussten. Dies wurde notwendig, da der Datenverkehr auf unseren LTE-SIM-Karten schnell abnahm.
Der Großteil des Traffics wurde von Logs erzeugt, die eigentlichen Metriken haben selbst mit einem Intervall von 10 Sekunden praktisch keinen Traffic verbraucht.
Schließlich haben wir nach einiger Zeit die Protokollerfassung auf den Geräten komplett deaktiviert, da die konkreten Probleme bereits ohne die ständige Erfassung offensichtlich waren.
In einigen Fällen, in denen das Überprüfen der Logs dennoch notwendig war, haben wir uns einfach über WireGuard per VPN verbunden.
Ich füge hinzu, dass jede einzelne Umgebung bei uns voneinander getrennt war und die oben beschriebene Last nur für die Produktionsumgebung relevant war.
In der Entwicklerumgebung hatten wir eine separate Instanz von InfluxDB eingerichtet, die alle 10 Sekunden weiterhin Daten sammelte, und wir stießen auf keine Leistungsprobleme.
TICK — ideal für kleine bis mittlere Projekte.
Basierend auf diesen Informationen würde ich zu dem Schluss kommen, dass der TICK-Stack perfekt für relativ kleine Projekte oder Projekte geeignet ist, bei denen kein hoher Lastdruck erwartet wird.
Wenn Sie nicht tausende Pods oder Hunderte Maschinen haben, wird selbst eine Instanz von InfluxDB die Last hervorragend bewältigen.
In einigen Fällen könnte Sie Influx Relay als einfachste Lösung für Hochverfügbarkeit zufriedenstellen.
Und natürlich steht es Ihnen frei, das "vertikale" Scaling einzurichten und einfach verschiedene Server für unterschiedliche Metrik-Typen bereitzustellen.
Sollten Sie jedoch unsicher über die erwartete Last auf den Monitoring-Diensten sein oder eine sehr "schwere" Architektur haben/will haben, würde ich die kostenlose Version des TICK-Stacks nicht empfehlen.
Natürlich wäre eine einfache Lösung der Kauf von — aber dabei kann ich nichts zur Notwendigkeit sagen, da ich mit den Feinheiten nicht vertraut bin. Zumal es sehr teuer ist und wahrscheinlich nicht für kleine Unternehmen geeignet ist.
In diesem Fall würde ich derzeit empfehlen, sich auf die Sammlung von Metriken über Victoria Metrics und Logs mit Loki zu konzentrieren.
Allerdings möchte ich wieder betonen, dass Loki/Grafana erheblich weniger benutzerfreundlich sind (aufgrund ihrer größeren Universalisierbarkeit) als der fertige TICK-Stack, aber sie sind kostenlos.
Wichtig: Alle hier beschriebenen Informationen sind aktuell für die Version Influx 1.8, derzeit sollte Influx 2.0 bald veröffentlicht werden.
Ich hatte bisher nicht die Gelegenheit, es im Produktionsumfeld auszuprobieren, und es ist schwierig, fundierte Aussagen über Verbesserungen zu machen, aber die Benutzeroberfläche ist definitiv besser geworden und die Architektur hat sich vereinfacht (ohne kapacitor und chronograf).
Es sind Templates erschienen ("Killer-Feature" — ). Aber leider fehlt in der Version 2 der entscheidende Punkt, wegen dem wir uns für die erste Version entschieden haben — es gibt kein Log-Management.
Diese Funktion wird auch in Influx 2.0 verfügbar sein, aber es konnten keine Fristen, nicht einmal ungefähre, gefunden werden.
Wie man IoT-Plattformen nicht machen sollte (jetzt)
Letztendlich haben wir, nachdem wir das Pilotprojekt gestartet haben, unser eigenes umfassendes IoT-Stack aufgebaut, da es keine passende Alternative nach unserem Ermessen gab.
Allerdings ist seit kurzem in der Beta-Version verfügbar — schade, dass es nicht verfügbar war, als wir mit dem Projekt begonnen haben.
Das Endresultat und die Plattform, die wir basierend auf Ansible + TICK + WireGuard selbst zusammengestellt haben, sind voll und ganz zufriedenstellend. Aber bis heute würde ich empfehlen, OpenBalena näher ins Auge zu fassen, bevor man versucht, seine eigene IoT-Plattform selbst zu erstellen.
Denn schließlich kann es den Großteil dessen, was wir gemacht haben, umsetzen, und OpenBalena ist kostenlos und der Code ist offen.
Es kann nicht nur Updates versenden, sondern auch einen VPN ist bereits integriert und für die Nutzung in IoT-Umgebungen optimiert.
Und ganz neu — sie haben sogar ihre , die sich leicht in ihr Ökosystem integrieren lässt.
Hey, was ist mit dem verschwundenen Scooter?
Der Scooter, "Ralph", ist spurlos verschwunden.
Wir sind sofort losgerannt, um die Karte in unserem "Admin-Panel" mit den GPS-Daten aus InfluxDB zu überprüfen.
Dank der Überwachungsdaten konnten wir leicht feststellen, dass der Scooter die Parkzone gegen 21:00 Uhr am Vortag verlassen hat, ungefähr eine halbe Stunde in ein bestimmtes Viertel gefahren ist und bis 5 Uhr morgens neben einem deutschen Haus geparkt war.
Nach 5 Uhr morgens sind keine Überwachungsdaten mehr eingegangen — das bedeutete entweder einen kompletten Ausfall der zusätzlichen Batterie oder dass ein Unbekannter tatsächlich die intelligente Technik aus dem Scooter entfernt hatte.
Trotzdem wurde an der Adresse, an der sich der Scooter befand, die Polizei gerufen. Der Scooter war dort nicht.
Der Hausbesitzer war jedoch ebenfalls überrascht, da er tatsächlich gestern Abend mit diesem Scooter von seinem Büro nach Hause gefahren war.
Wie sich herausstellte, kam einer der Support-Mitarbeiter früh am Morgen und holte den Scooter ab, weil die zusätzliche Batterie komplett entladen war, und brachte ihn (zu Fuß) zur Parkzone. Die zusätzliche Batterie war aufgrund von Feuchtigkeit defekt.
Wir haben den Scooter selbst gestohlen. Ich weiß übrigens nicht, wie und von wem das Problem mit der Polizei später gelöst wurde, aber die Überwachung hat hervorragend funktioniert...
Quelle: habr.com
