Erstellen eines Überwachungs- und Analysesystems für Ihre eingebetteten IoT-Geräte

Dieser Beitrag beschreibt ein Kochbuch, mit dem wir ein Überwachungssystem für ein verbundenes eingebettetes System erstellt haben. Wir haben damit ein Gerät erstellt, mit dem alle Arten von Geräten überwacht werden können (auch Bare-Metal- und RTOS-Geräte), und wir hielten es für sinnvoll, andere beim Aufbau ähnlicher Systeme zu unterstützen. Mit diesem Kochbuch können Sie problemlos die Betriebsdaten des Geräts sowie Ihre tatsächlichen Anwendungsdaten überwachen. Nach der Bereitstellung eines IoT-Systems müssen Sie sicherstellen, dass alles ordnungsgemäß funktioniert, und eine Rückkopplungsschleife vor Ort schließen. Wir zeigen Ihnen, wie Sie eine kostenlose Version mit Open Source-Tools erstellen können. Wir haben auch einen Beitrag, der die Notwendigkeit eines solchen Systems umreißt (Check It Out).

Konzentrieren wir uns auf drei Dinge:

  1. Geräte- und Gateway-Code, der Daten an ein zentrales Backend überträgt.
  2. Backend und Datenbank zur Verarbeitung und Speicherung der Daten.
  3. Frontend zur Anzeige der Daten.

Sobald diese drei Bausteine ​​vorhanden sind, ist es relativ einfach, auf die überwachten Daten zu reagieren und sie mit Ihren Betriebsprozessen zu verbinden.

1. Tool zur Geräte- und Gateway-Protokollierung

Wenn Sie an ein Protokollierungsdienstprogramm denken, das auf Ihren Endgeräten und Gateways gehostet wird, werden folgende Dinge angezeigt:

  • Es muss einen kleinen Platzbedarf haben.
  • Mein Gerät niemals zum Absturz bringen.
  • Verbrauchen Sie wenig Strom.
  • Nicht störend für den Anwendungscode.

Ihre Geräte sind Ihr Code. Es ist schwierig, dieses Thema zu verallgemeinern, da es von dem Kommunikationskanal abhängt, über den eine Verbindung zum Internet hergestellt wird. Wir haben ein Open-Source-Protokollierungstool, das Ereignisse von Ihren Endgeräten protokolliert und an Ihr Gateway / Backend sendet. Wenn Sie nRF52 mit BLE GATT und einem Gateway verwenden, stellen wir Ihnen auch ein Muster zur Verfügung, das sofort funktioniert. Besuchen Sie unseren GitHub, um loszulegen.

1. jumper-ulogger - ist ein Protokollierungsframework mit weniger als 500B Speicherbedarf, das Sie in Ihr Endgerät integrieren (mit Beispielen für die Portierung auf ein nRF52-Gerät und CC3200).
2. Jumper-Logging-Agent - ist der Dienst, der auf dem Gateway ausgeführt wird.
3. Jumper-Ble-Logger - ist ein Beispiel für einen Logging Agent-Dienst für ein BLE GW.

Wenn Sie irgendwelche Probleme oder Fragen haben, senden Sie uns eine Nachricht an info@jumper.io.

2. Backend und Datenbank

Hier sollten Sie genauer hinschauen, da es hier einige gute Dinge gibt :-) Ich empfehle, die folgenden Toolsets zu verwenden, damit dies funktioniert:

  • Eine Schlüsselwert-Datenbank zum Speichern eines aktuellen Schnappschusses des Gerätezustands (wir haben die Firebase von Google und die DynamoDB von Amazon getestet). Dies ist Ihr Schattengerät.
  • Eine Zeitreihendatenbank zum Speichern historischer Gerätedaten und Abfragen von Berichten und Grafiken (wir haben InfluxDB getestet).
  • Eine serverlose Infrastruktur der Wahl für minimalen Verarbeitungsaufwand (wir haben AWS Lambda und Google Cloud-Funktionen mit dem serverlosen Framework verwendet).

Lassen Sie es uns anhand eines Beispiels aufschlüsseln. Angenommen, Sie verwalten eine Flotte von 10.000 Geräten und möchten die Akkulaufzeit und die Signalstärke des Geräts überwachen. Wenn Sie nicht auf Bandbreite und Stromverbrauch achten, können Sie die Gerätedaten so oft wie möglich an das Backend senden. Eine Datennachricht an den Server sieht folgendermaßen aus: (Zeit, Batteriestand, Signalstärke). Wenn Sie sich mit der Bandbreite befassen, die wir als sehr verbreitet erachtet haben, können Sie die Nachrichten zwischen Akkulaufzeit und Signalstärke aufteilen, um zu verhindern, dass doppelte Daten an das Backend gesendet werden. Möglicherweise senden Sie sogar nicht die Uhrzeit des Ereignisses, da Sie die Uhrzeit automatisch im Backend markieren können.

Im ersten Fall, in dem Sie ständig alle Daten vom Gerät an das Backend senden, benötigen Sie den Schlüsselwert-DB nicht. Sie speichern die Nachricht einfach direkt in der Zeitreihendatenbank.

Im zweiten Fall senden Sie Daten in Teilnachrichten, die eine Teilmenge der Daten enthalten, die Sie überwachen. Hier setzt der Schlüsselwert-DB an. Der Schlüsselwert-DB gibt den aktuellen Status Ihres Geräts wieder. Jedes Mal, wenn eine Teilnachricht empfangen wird, werden ihre Daten in den Schlüsselwert-DB aktualisiert. Der aktualisierte Gerätezustand wird dann aus dem Schlüsselwert-DB abgerufen und in der Zeitreihendatenbank gespeichert. Wir empfehlen diese Architektur, da sie mit größerer Wahrscheinlichkeit skaliert als nur mit einer Zeitreihen-DB. Zeitreihen-DB sind wirklich gut darin, Daten einzufügen und komplexe Abfragen zu bearbeiten. Es ist nicht so gut skalierbar, wenn viele kleine Abfragen ausgeführt werden sollen. Schlüsselwert-DBs hingegen sind wirklich großartig.

Wir haben Google Firebase aus mehreren Gründen für den Schlüsselwertspeicher verwendet. Wir haben die gesamte Anwendungs-Engine, die Authentifizierung und die Datenbank darauf basierend erstellt, sodass die Verwendung für die Gerätedaten eine einfache Wahl war.

Für die Zeitreihen-Datenbank haben wir InfluxDB verwendet, das für 160 US-Dollar pro Monat auf InfluxData-Servern gehostet wird. Nicht besonders günstig, aber skalierbar auf bis zu 10.000 Geräte (unabhängig von der Datenlast). Das sind weniger als 0,25 US-Dollar pro Jahr und Gerät. Süss! Der Nachteil von InfluxDB ist, dass Sie wirklich vorsichtig mit den Datenfeldern sein müssen, die Sie als Indizes definieren. Die Datenbank kann aufgrund der Überindizierung leicht unter Leistungsproblemen leiden.

Wir haben auch Keen.io ausprobiert. Keen ist überlegen, wenn es um die Abfrage von Daten geht. Der Nachteil ist die Preisgestaltung. Ich muss darauf hinweisen, dass wir mehrere Preisprobleme besprochen haben, die auf Fehler beim Einfügen von Daten in Keen zurückzuführen waren, und das Support-Team sehr reaktionsschnell und fair war.

Der Klebstoff, der alles zusammenfügt, ist der Back-End-Code, der für die Authentifizierung und das Speichern von Datenbanken verwendet wird. Wir sind sehr erfahren, wenn es um die Skalierung von Back-End-Systemen geht. Unsere Empfehlung ist einfach: Erstellen Sie keine Backend-Systeme. Verwenden Sie serverlose Optionen. Wir haben einen einfachen Mikrodienst entwickelt, der eine Nachricht von einem Gerät empfängt, die aktuellen Gerätedaten im Schlüsselwert-DB und die vollständigen Daten im Zeitreihen-DB speichert. Ja, es ist teurer als die Verwaltung Ihrer eigenen Infrastruktur. Die Zeit, die Sie in die Wartung von Servern investieren, wenn Sie sogar 3.000 Geräte erreichen, wird die Kosten für eine serverlose Architektur ausgleichen.

Vorderes Ende

Auch hier muss das Rad nicht erfunden werden. Keen bietet ein Frontend zum Generieren und Einbetten von Grafiken in andere Websites. Wir haben Grafana als Frontend-Plattform verwendet, da es im InfluxDB-Paket für 160 USD / Mio. enthalten ist. Grafana hat auch eine weitere gute Wahl für Ihre längerfristige DB - Elasticsearch getroffen.

Ausführliches Systemdiagramm

Zusammenfassung

Die Entscheidung für verwaltete und serverlose Optionen hat uns geholfen, ein System zu entwickeln, das eine Last von bis zu 10.000 Geräten bewältigen kann. Wenn Sie von dort aus nach oben skalieren, müssen Sie nur weitere Datenbankinstanzen hinzufügen. Wenn Sie auf der Suche nach einer noch einfacheren Wahl sind, wählen Sie die Version elasticsearch, die als Service von Amazon bereitgestellt wird.

Machen Sie mit Jumper Virtual Lab einen Testlauf

Wenn Ihnen die Produktqualität wichtig ist und Sie Probleme beim Testen Ihrer eingebetteten IoT-Systemsoftware haben, schauen Sie sich Jumper Virtual Lab an. Jumper Virtual Lab ist ein Virtual Production-Klon, mit dem Sie mit virtuellen Geräten problemlos kontinuierliche Integrationsprozesse auf Ihrem Embedded-System entwickeln, testen und implementieren können. Starten Sie Jumper jetzt kostenlos.

Teile deine Gedanken

Teilen Sie uns Ihre Gedanken mit und kontaktieren Sie uns im Kommentarbereich oder unter feedback@jumper.io.