Was machst du eigentlich, Daniel?

Bei meinem Projekt geht es um die Abrechnung der Produktion und Nutzung von Energie im Energienetz. In dem Projekt ist der Netzbetreiber für die Koordination und Kommunikation der verschiedenen Marktpartner zuständig. Auf dem Markt gibt es wiederum auf der einen Seite Energieproduzenten, die Lieferanten, und auf der anderen Seite Energieabnehmer, die Kunden.

Hieran kann festgestellt werden, dass es in dem Projekt unterschiedliche Zuständigkeiten gibt, die den zwei Rollen, nämlich Netzbetreiber und Lieferant, auf dem Markt zugeordnet sind. Ich arbeite in einem themenübergreifenden Team, dem Cross-Team, welches Architektur- und Entwicklungsarbeiten von technischen Lösungen übernimmt. Diese Lösungen können von den verschiedenen Subprojekten – unabhängig der Rollenzuständigkeit – genutzt werden.

Dafür haben wir einen „Business Activity Monitoring“ (BAM) Framework für den Kunden entwickelt, der sich nicht nur auf das technische Monitoring konzentriert, sondern auch verschiedene fachliche Usecases überwacht und löst.

Was ist „Business Activity Monitoring“?

„Business Activity Monitoring“ (BAM) ist eine Sammlung von Analysen und graphischen Darstellungen von zeitrelevanten Geschäftsprozessen in Organisationen. Dieses bietet detaillierte Informationen über den Echtzeitstatus (realtime monitoring) von verschiedensten Operationen, Prozessen und Transaktionen, sodass bestmöglich Geschäftsentscheidungen getroffen und Probleme frühzeitig erkannt und gelöst werden können.

Bei dem Kunden haben wir dafür drei verschiedene Anwendungsfälle implementiert:

1. Technisches Monitoring
2. Fachliche Usecases
3. Track & Trace

Diese drei Anwendungsfälle unterscheidet ihre unterschiedliche Art und Weise, wie Daten zusammenhängen und wie diese einen Sachverhalt darstellen.

Bei dem Technischen Monitoring (I) werden lediglich die Daten aus den Quellen graphisch dargestellt. Wir haben zusätzlich ein Alerting Modul gebaut, in dem die Ergebnisse zu verschiedenen KPIs mit den erwarteten Werten verglichen werden, um überschreitende Schwellenwerte erkennen zu können.

Die fachlichen Usecases (II) werden so aufgebaut, dass anhand fachlicher Schlüssel oder „Business Keys“ die verschiedenen Datenquellen zusammengefügt werden und eine Korrelation erstellt werden kann.

Das Konzept von „Track & Trace” (III) bezieht sich auf einen Vergleich der Zustände „Erwartung” versus „Beobachtung” – expected behavior versus observed behavior. Hierzu werden zuvor Regeln festgelegt, wie die Ereignisse (events) erfolgen sollen und welche Reihenfolge diese haben. Dies wird schließlich mit den tatsächlich geschehenen Events verglichen. Die dabei festgestellten Differenzen oder Abweichungen werden anschließend graphisch dargestellt.

Alle drei Anwendungsfälle nutzen für ihre Abläufe dieselbe Basis an Komponenten und Konzepten, werden aber unterschiedlich genutzt. Im Grunde funktioniert es folgendermaßen:

1. Für die Komponenten, die überwacht werden sollen, werden sogenannte Agents Deren Hauptaufgabe ist es Daten zu sammeln, die das Framework in weiteren Schritten verwenden wird. Dabei können diese Daten aus verschiedenen Quellen stammen, wie zum Beispiel Applikationsservern, Datenbanken, Messaging-Server, usw.
2. Die gesammelten Daten können daraufhin, bei Bedarf, transformiert oder mit zusätzlichen Daten angereichert werden.
3. Anschließend werden die Daten gespeichert.
4. Zum Schluss erfolgt die graphische Darstellung der Daten.

In der folgenden Abbildung kann der Ablauf graphisch nachvollzogen werden:

Wie ist das technische Setup und welche Tools werden verwendet?

Die gesamte Infrastruktur läuft in den Cloud Plattform von Amazon Web Services (AWS), in der wir drei EC2 (Elastic Compute Cloud) – Instanzen als Basis Setup nutzen. Auf diesen Instanzen läuft ein self-managed Kubernetes (k8s) Cluster, worin als sogenannte Container (im Kubernetes Kontext – „pods“ genannt), folgende Applikationen laufen:

• Elasticsearch (Elastic Stack) – hier werden die Daten gespeichert.
• Logstash (Elastic Stack) – hier werden die Daten transformiert.
• Kibana (Elastic Stack) – hier werden die Daten graphisch dargestellt.
• Cassandra (Apache) – hier werden die Regeln für Alerting und „Track & Trace“ gespeichert.
• Kafka (Apache) – dieses wird als Messaging Layer genutzt.

Außerdem gibt es dazu verschiedene Agents, die als Microservices deployt werden und die für verschiedene Zuständigkeiten, u.a. zur Datensammlung, Datenkorrelation und zur Datentransformation, eingesetzt werden. Diese Agents werden entweder in Python oder in Java implementiert.

Des Weiteren gibt es in Logstash verschiedene Plug-ins, wodurch die Applikation in der Lage ist, sich mit verschiedenen Datenbänken (Microsoft SQL, Oracle, PostgreSQL) oder auch mit Messaging Layers wie Apache Kafka, oder TIBCO EMS zu verbinden.

Zusätzlich werden in den Maschinen Agents aus dem Elastic Stack deployt, die wiederum für die Datensammlung in den Servern verantwortlich sind. In diesem Fall ist Metricbeat für die Metriken (CPU, Memory) und Filebeat für die Logdateien zuständig.

Die Implementierung wird in Git versioniert und gespeichert und über Jenkins Pipelines ausgerollt.

Bei uns im Team werden derzeit alle Stages von der Architektur über die Implementierung hin zum Betrieb der Software-Entwicklung geleitet.

Wie man sehen kann, handelt es sich um ein komplexes Projekt mit vielen sehr interessanten Ansätzen, deren Ergebnisse in ähnlichen Projekt-Setups umgesetzt werden können.