Über Logging denkt man selten nach, solange alles läuft. Und dann sehr intensiv, wenn es das nicht mehr tut.
Logging ist die unspektakulärste Funktion in einer Maschinenapplikation. Sie liefert kein Feature, das man im Lastenheft verkaufen kann, und im Normalbetrieb merkt niemand, dass sie da ist. Ihren Wert zeigt sie in genau einem Moment: wenn jemand wissen muss, was tatsächlich passiert ist – und die Anlage schon seit Jahren im Feld steht.
Der Anruf nach drei Jahren
Das Muster ist immer dasselbe. Eine Anlage läuft seit Jahren zuverlässig. Dann steht sie an einem Dienstagmorgen, und die Frage lautet: Was ist heute Nacht um 03:47 passiert? Der Bediener erinnert sich an eine Meldung, weiß aber nicht mehr, welche. Der Entwickler, der das Projekt damals gemacht hat, ist nicht mehr im Unternehmen.
Ob diese Frage in Stunden oder in Tagen beantwortet wird, entscheidet sich nicht am Dienstagmorgen. Es entscheidet sich Jahre vorher, in der Inbetriebnahme – daran, ob überhaupt jemand daran gedacht hat, dass diese Frage einmal kommt.
Warum „einfach in eine Datei schreiben" nicht reicht
Der naheliegende Reflex ist, im Fehlerfall eine Zeile in eine Datei zu schreiben. In der Praxis führt das zu drei Problemen, die alle erst später auffallen.
Das Schreiben blockiert. Ein Dateizugriff dauert – und wenn er im Zyklus passiert, wartet die Steuerung. Solange das Log nur selten schreibt, fällt das nicht auf. Genau in der Situation, in der man viele Meldungen hat, nämlich im Störungsfall, wird aus dem Diagnosewerkzeug ein Teil des Problems.
Es entsteht eine Textwüste. Freitext ohne Struktur lässt sich später nicht filtern, nicht sortieren und nicht auswerten. Was fehlt, sind nicht mehr Zeilen, sondern verlässliche Felder: Zeitpunkt, Schweregrad, Herkunft, betroffener Auftrag.
Der Kontext fehlt. „Antrieb Fehler" hilft niemandem. Interessant ist, welcher Antrieb, in welchem Zustand, bei welcher Charge, auf welcher Maschine – und das schreibt niemand freiwillig an jeder Stelle im Code mit.
Die Steuerung darf nicht warten
Deshalb ist der erste Punkt eines brauchbaren Logging-Konzepts kein Feature, sondern eine Architekturentscheidung: Der Aufruf im Anwendungscode und das tatsächliche Schreiben müssen voneinander getrennt sein.
Beim AS Logger übergibt der Aufruf die Meldung an eine entkoppelte Queue und kehrt sofort zurück. Das Wegschreiben passiert asynchron dahinter. Für Sie als Entwickler heißt das: Sie dürfen loggen, wo es fachlich sinnvoll ist – nicht nur dort, wo es zeitlich gerade unkritisch erscheint. Das ist ein größerer Unterschied, als es klingt, denn es entscheidet darüber, ob im Ernstfall die interessanten Stellen protokolliert sind oder die unkritischen.
Ein Ereignis, mehrere Ziele
Der zweite Punkt: Ein Log-Ereignis hat nicht ein Ziel, sondern mehrere – und zwar gleichzeitig. Der Bediener an der Maschine braucht die letzten Meldungen sofort in der Visualisierung. Der Servicetechniker schaut ins Log der Steuerung. Und wer mehrere Anlagen betreibt, will die Meldungen zentral auf einem Server sehen, ohne sich auf jede Maschine einzeln aufzuschalten.
Genau das leisten die Ausgabeziele – im AS Logger „Sinks". Verfügbar sind ein Memory-Ringpuffer, der die Visualisierung mit Alarmliste und Historie versorgt, eine Console-Ausgabe, das CODESYS-Log der Steuerung und Syslog nach RFC 5424 über UDP für die zentrale Auswertung. Mehrere davon lassen sich parallel betreiben, jedes mit eigenem Filter. Und wer ein Ziel braucht, das nicht dabei ist, ergänzt es über die offene Schnittstelle ISink, ohne den Rest anzufassen.
Struktur statt Textwüste
Damit später überhaupt etwas auswertbar ist, braucht die Meldung Struktur. Der AS Logger arbeitet mit sechs Log-Leveln – TRACE, DEBUG, INFO, WARN, ERROR und FATAL – und einer Fluent-API, mit der sich eine Meldung in einer Zeile zusammensetzen lässt.
Wichtiger als die Level ist aber der Umgang mit den Werten. Meldungen werden nicht als fertiger Fließtext übergeben, sondern mit {key}-Platzhaltern: die Meldung bleibt eine Vorlage, die Werte bleiben Felder. Das ist der Unterschied zwischen einer Zeile, die man lesen kann, und einer Zeile, nach der man suchen kann.
Den wiederkehrenden Kontext übernehmen Decorators. Zeitstempel sowie Maschinen- und Host-Kontext werden zentral angehängt, statt an jeder Aufrufstelle im Code mitgeschleppt zu werden. Das hält die Aufrufe im Anwendungscode kurz und sorgt dafür, dass der Kontext auch dann vollständig ist, wenn es im Projekt einmal schnell gehen musste.
Was nicht ins Log gehört
Ein Punkt, der in der Praxis regelmäßig zu spät auffällt: Nicht alles, was technisch durch den Logger läuft, darf dauerhaft in einer Datei stehen oder das Werksnetz verlassen. Rezepturwerte, Kundenbezüge, Zugangsdaten – sobald Logs zentral gesammelt oder weitergegeben werden, ist das ein Thema.
Der AS Logger kann sensible Felder maskieren (Redaction) und je Ausgabeziel unterschiedlich filtern – nach Level und nach Alarm-Severity. Praktisch heißt das: In der Visualisierung darf mehr stehen als in dem Log, das zum zentralen Server geht. Diese Trennung nachträglich einzubauen ist unangenehm; sie von Anfang an zu haben, kostet nichts.
Vom Log zum Alarm
Logging und Alarmierung sind verwandt, aber nicht dasselbe: Ein Alarm ist ein Zustand, den jemand quittieren muss, ein Log-Eintrag ist ein Ereignis, das dokumentiert wird. In der Diagnose braucht man beides zusammen – die Alarmhistorie und das, was drumherum passiert ist.
Der AS Logger protokolliert Alarme daher mit Severities und Alarmcodes und lässt sich über eine Listener-Schnittstelle an das Alarmhandling anbinden. Dazu kommen Diagnose-Zähler für die Meldungen selbst: wie viele erzeugt, wie viele geschrieben und wie viele verworfen wurden. Der letzte Wert ist der wichtigste, denn er ist der einzige Weg, überhaupt zu bemerken, dass ein Log nicht vollständig ist – eine Lücke, die man sonst erst im Servicefall entdeckt, also genau dann, wenn sie weh tut.
Was das für Ihr Projekt bedeutet
- Sie dürfen loggen, wo es fachlich passt – das asynchrone Schreiben nimmt die Angst vor der Zykluszeit.
- Eine Meldung, alle Ziele – Visualisierung, CODESYS-Log und Syslog parallel, ohne doppelten Code.
- Auswertbar statt nur lesbar – Level und
{key}-Felder statt Freitext. - Sauber im Umgang mit Daten – Redaction und Filter je Ziel, von Anfang an.
- Erweiterbar – eigene Sinks, Decorators und Filter über offene Schnittstellen.
Nichts davon ist spektakulär. Aber es ist der Unterschied zwischen einem Log, das im Servicefall die Frage beantwortet, und einem, das nur bestätigt, dass irgendwann irgendwas war.
Der AS Logger ist ab sofort im CODESYS Store verfügbar; wie er im Projekt aussieht, zeigen wir im Demo-Video.
— Jürgen Renner, Geschäftsführer, ASKS GmbH