Logging des Internet of Things - Vernetzte Kraftwerke verlangen neue Paradigmen

Logging des Internet of Things

Vernetzte Kraftwerke verlangen neue Paradigmen

Rocco Gagliardi
von Rocco Gagliardi
am 04. August 2016
Lesezeit: 11 Minuten

Keypoints

  • IoT verändert das Log-Paradigma
  • Die bestehende Infrastruktur ist massgeblich davon tangiert
  • Eine Reihe von Produkten kommen auf den Markt
  • Die angestrebte Lösung muss sorgfältig geplant werden

Das Log wurde geschaffen, um Menschen über einen Status eines spezifischen Systems zu informieren. Zum Beispiel bei Problemen, um nachvollziehen zu können, was passiert ist. Manchmal – xen_netfront: xennet: skb rides the rocket: 21 slots ist ein gutes Beispiel – klingen die Log-Nachrichten wie ein schlechter Scherz.

In der wundervollen Welt von SIEM (Security Information and Event Management) werden durch verschiedene Komponenten eine Reihe von Nachrichten generiert und korreliert. Damit der Mensch sie benutzen kann, werden sie durch eine Maschine verarbeitet bzw. vorbereitet.

Im Zeitalter von IoT (Internet of Things) beobachten wir einen grundlegenden Wandel dieses Paradigmas: Die generierten Nachrichten werden nicht mehr durch Menschen verarbeitet, sondern durch andere Maschinen.

Das Netzwerk ist der Computer

Ich bin nicht sicher, an was John Cage genau dachte, als er seinen berühmten Satz The Network is the computer formulierte. Ich bin jedoch ziemlich sicher, dass es nichts mit dem heutigen IoT zu tun hatte. Bei IoT handelt es sich um einen Verbund miteinander vernetzter Geräte, die mit sehr wenig menschlicher Interaktion funktionieren. Wir installieren diese Geräte bei uns zu Hause, tragen sie während dem Sporttraining, einige kommen mit auf eine Reise, manche informieren uns über die Position des Goldfisches und den Zustand des Kühlschranks zu Hause.

Im Industriebereich wird IoT eingesetzt, um den Status komplexer Installationen zu überwachen. Tausende von Sensoren sammeln Millionen von Samples, wodurch viel Geld gespart werden kann. Die durch diese Komponenten gesammelten Daten können herangezogen werden, um zukünftiges Verhalten zu berechnen und damit zukünftige Versionen zu optimieren.

Klassisches Logging vs. IoT Logging

Wie verändert sich nun das klassische Log im Zeitalter von IoT?

Datenpunkt Klassisch IoT
Durchschnittliche Anzahl Logs/[s] niedrig hoch
Durchschnittliche Länge von Logs [bytes] hoch niedrig
Zeitfenster für Nutzung Minuten bis Tage Microsekunden bis Sekunden
Inhalt der Datensätze Statusänderungen Telemetrie
Hauptziel des Logs Historisierung Voraussagen
Beziehung der Kommunikation Maschine ⇒ Mensch Maschine ⇒ Maschine

Nehmen wir als Beispiel die Monitoring-Anforderungen eines Kraftwerks. Es ergeben sich zum Beispiel einige Vorteile im beständigen Überwachen der Parameter von komplexen Elementen, wie zum Beispiel einer Gasturbine:

Mögliche Konsequenzen:

Diese Idee kann auf eine Vielzahl anderer Komponenten erweitert werden, wodurch plötzlich eine hohe Anzahl Sensoren überwacht werden muss:

Parameter Wert
Sensor Analog: 30’000, Digital: 20’000
Sampling Rate Analog: 50ms, Digital: 1s
Datentyp Analog: Float, Digital: Short-Int
History 1 – 3 Jahre

Die zu diesem Zweck erforderliche Infrastruktur, sie muss schliesslich viele verschiedene Quellen bewältigen, weicht von der klassischen Herangehensweise ab. Denn sie muss zusätzlich gewährleisten:

Aufstrebende Lösungen

Neben den Möglichkeiten für das klassische Logging drängen verschiedene Lösungen zwecks Telemetrie auf den Markt. Dabei wird sich nicht wirklich an einem Standard orientiert, wobei die Daten lediglich aus k→v Tupel bestehen. Betreffend des Kommunikationsprotokolls hat man sich weitestgehend auf IP geeinigt. Darauf aufbauen kann man hauptsächlich zwischen MQTT, XMPP und CoAP wählen.

Im Storage-Bereich für Telemetrie gibt es dedizierte Datenbanken (Graphite/InfluxDB/Hadoop) und spezifische Software-Lösungen zur Bereitstellung von Dashboards. Einige altbekannte Parser und Extractors können bisweilen genutzt werden, um Performance-Daten direkt in Telemetrie-Datenbanken zu überführen, wobei ihre ursprüngliche Aufgabe weiterverfolgt werden kann.

Grundlagen der Kommunikation

Die Schlüsselkomponente der Kommunikation ist das IP-Protokoll, wobei vorzugsweise auf die “neue” Version 6 gesetzt wird. Die Batterien für viele Sensoren, gerade die im Umfeld von IEEE802.15.4, müssen teilweise mehrere Monate ihren Dienst verrichten können. Aus diesem Grund sind diese Komponenten nicht ständig online und kommunizieren auch nicht – jedenfalls nicht immer – mit Hochgeschwindigkeit. Diese Art von Netzen wird als LLN (Low-power and Lossy Networks) bezeichnet.

Nachfolgend eine Liste mit den Eigenschaften der einzelnen Protokolle:

Protokoll Vorteil Nachteil
MQTT Entwickelt durch IBM. Subscribed Services (Many2Many). Zweiweg-Kommunikation über instabile Netze. NAT ist nicht problematisch. QoS etabliert (Fire-and-Forget, At-Least-Once und Exactly-Once). Wenig Energieverbrauch, aber nicht geeignet für extrem niedrige Anforderungen. Üblicherweise ständig “online” (adressiert mit MQTT-SN). Lange Topic-Namen, nicht nutzbar im Zusammenhang mit 802.15.4 (adressiert mit MQTT-SN).
CoAP Getrieben durch Cisco. IN erster Linie ein One2One Protokoll. Identifikation von Ressourcen. Interoperabel mit HTTP/REST. Sensor ist typischerweise ein Server, weshalb NAT intelligent etabliert werden muss. Da es auf UDP basiert, ist SSL/TLS nicht möglich. DTLS kann stattdessen eingesetzt werden.
XMPP Ebenso durch Cisco getrieben. Echtzeit. Massive Skalierbarkeit. Sicherheit. Nicht praktikabel über LLNs. Verlangt einen XML-Parser.

Produkte pro Phase

Nachfolgend wird eine Übersicht der Produkte inklusive Referenzen dargestellt. Berücksichtigen Sie das Schema, um den Einsatz und die Verbindung dieser Komponenten zu erkennen. Bedenken Sie, dass ein Prozess oftmals in verschiedenen Arten etabliert werden kann: Setzen Sie am besten jenes Produkt ein, mit dem Sie am besten vertraut sind.

Phase Komponente Zu bedenken
Collect Fluent Bit, Collectd, Telegraf, Beats, rsyslog Systemtyp. Framework schon vorhanden.
Queue Redis, MemCached, RabbitMQ Anpassungen am Routing. Performance. Zustellgarantie.
Parse Fluentd, Logstash, rsyslog, Graylog Input / Output. Parser-Plugins für Nachrichten.
Store InfluxDB, Prometeus, Hadoop, Elasticsearch, RDD Geschwindgkeit. Query Language. Granularität.
Visualise Kibana, Graylog, Chronograf, Grafana, Thruk, Cacti Authentisierung / Autorisierung. Visualisierung. Query Language / Funktionen für Transformation. Dashboard Anpassungsmöglichkeiten.
Act Graylog, Kapacitor Triggering Möglichkeiten. Speicher. Integration.

Einige Mögliche Pfade im Rahmen des Loggings

Zusammenfassung

Das Logging der enormen Datenmenge, die durch die aufstrebende IoT-Infrastruktur anfallen wird, stellt uns vor neue Herausforderungen. Dies wird im Netzwerk, den einzelnen Rechnern und im Rahmen der Software-Entwicklung spürbar sein. Viele neue Lösungen drängen auf den Markt und alle haben ihre Vor- und Nachteile. Jenachdem welche Ziele Sie verfolgen, kann sich eine Kombination verschiedener Technologien anbieten.

Fussnote

*) Dieser “Witz” trat in unserer Xen-Infrastruktur nach einem Upgrade auf. Wir fanden ihn nicht lustig. Für mehr Details siehe Kernel Line Tracing: Linux perf Rides the Rocket.

Über den Autor

Rocco Gagliardi

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Routing, Firewalling und Log Management.

Links

Sie wollen Ihr Log und Monitoring auf das nächste Level bringen?

Unsere Spezialisten kontaktieren Sie gern!

×
Schutz vor Phishing

Schutz vor Phishing

Rocco Gagliardi

Logging

Logging

Rocco Gagliardi

IT Security Policies

IT Security Policies

Rocco Gagliardi

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv