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?

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:

• Kontrolle der Nutzung innerhalb der Vorgaben des Herstellers
• Identifikation von möglichen Problemen, bevor diese negative Auswirkungen haben können

Mögliche Konsequenzen:

• Der Hersteller hat geringere Kosten bei Ausfällen aufgrund falscher Handhabung innerhalb der Garantiefristen
• Die Versicherungsprämien sind geringer, da mit genaueren Modellen gearbeitet werden kann
• Der Betreiber kann die Wartungen besser in Bezug auf Rücksichtnahme des SLA koordinieren

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

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:

• Speichermöglichkeiten: Nicht nur Speicherplatz, sondern auch Flexibilität und Zugriffsgeschwindigkeiten.
• Sehr niedrige Latenz: Die Lebensdauer der Gültigkeit eines Signals reduziert sich auf Microsekunden; nicht nur das Netzwerk muss diese Performance gewährleisten können, sondern auch alle anderen Komponenten.
• Hohe Rechenleistung: Die grossen Datenmengen verlangen ein hohes Mass an CPU-Leistung, um die Interpretation und Korrelation vorantreiben zu können. Egal ob Langzeitberechnungen oder die Ermittlung des Medians von PH-Werten bei verschiedenen Temperaturen: Hochgeschwindgkeitsrechner sind erforderlich.

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.

• MQTT/MQTT-S ist ein Publish/Subscribe Messaging Protokoll, welches ursprüngilch von IBM für simple M2M-Kommunikationen entwickelt wurde
• XMPP (eXtensible Messaging and Presence Protocol) stammt ursprünglich aus dem Instant Messaging Bereich und wird für gross angelegtes Management von Konsumgütern verwendet.
• CoAP (Constrained Application Protocol) wird über UDP betrieben und wird vorzugsweise von ressourcenschonenden und mit niedriger Energie gespeisten Sensoren in Lossy Networks verwendet. Gerade wenn eine sehr hohe Anzahl an Sensoren zum Einsatz kommt, wird es bevorzugt.

Nachfolgend eine Liste mit den Eigenschaften der einzelnen Protokolle:

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.

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 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 Security Frameworks, Routing, Firewalling und Log Management.

Links

• http://cacti.net/
• http://collectd.org/
• http://fluentbit.io/
• http://oss.oetiker.ch/rrdtool/
• http://postscapes.com/what-exactly-is-the-internet-of-things-infographic/
• http://redis.io/
• http://www.brendangregg.com/blog/2014-09-11/perf-kernel-line-tracing.html
• http://www.gereports.com/big-data-industrial-internet-can-help-southwest-save-100-million-fuel/
• http://www.makeuseof.com/tag/internet-things-10-useful-products-must-try-2016/
• http://www.memcached.org/
• http://www.rabbitmq.com/
• http://www.rsyslog.com/
• http://www.thruk.org/
• https://grafana.org/
• https://hadoop.apache.org/
• https://influxdata.com/
• https://influxdata.com/time-series-platform/chronograf/
• https://influxdata.com/time-series-platform/kapacitor/
• https://influxdata.com/time-series-platform/telegraf/
• https://prometheus.io/
• https://www.elastic.co/products/beats
• https://www.elastic.co/products/elasticsearch
• https://www.elastic.co/products/kibana
• https://www.elastic.co/products/logstash
• https://www.graylog.org/