Sie wollen mehr?
Weitere Artikel im Archiv
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.
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.
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:
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.
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. |
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. |
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.
*) 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.
Unsere Spezialisten kontaktieren Sie gern!
Rocco Gagliardi
Rocco Gagliardi
Rocco Gagliardi
Rocco Gagliardi
Unsere Spezialisten kontaktieren Sie gern!