Logging vs. Monitoring

“Logging schaut in die Vergangenheit, mit Monitoring kann man in die Zukunft sehen.”

Diesen Satz habe ich zum ersten Mal von meinem Kollegen Thomas Schissler (http://www.agilemax.de/) in einem seiner Trainings gehört.

Zuerst habe ich das nicht verstanden. Für mich als Softwareentwickler war Logging ein Bestandteil von Monitoring. Ich habe mich während der Entwicklung wenig bis gar nicht damit beschäftigt, wie meine Lösung sich im Produktivbetrieb verhält. Ich habe an für mich geeigneten Stellen Log-Ausgaben erzeugt - reicht ja, um einen Einblick zu bekommen, was in der Anwendung passiert. Oder?

Was ist Logging?

Bei Gesprächen mit Kollegen aus Softwareentwicklung und -betrieb habe ich meine Sicht der Dinge revidiert. Log-Dateien geben einen Einblick in die Vergangenheit. Wir sehen, was in der Anwendung bis zum aktuellen Zeitpunkt passiert ist. Leider sehen wir nur den Ausschnitt, den die Entwickler wichtig genug fanden, um eine Log-Ausgabe zu erzeugen. In den meisten meiner Projekte war das zum größten Teil eine individuelle Entscheidung des Entwicklers, der am Code gearbeitet hat. Selten gab es ein Logging-Konzept, in dem beschrieben war, welche Ereignisse in welchem Log-Level auf welche Art zu loggen sind.

Und Monitoring?

Monitoring hingegen ermöglicht es, im Betrieb einer Anwendung Daten zum aktuellen Zustand der Anwendung zu bekommen. Dabei ist es wichtig, nicht nur eine Momentaufnahme des Zustands zu erhalten, sondern seine Entwicklung über die Zeit. So ist die Speicherauslastung zu einem bestimmten Zeitpunkt interessant. Spannender ist es jedoch, zu erfahren, ob sie über einen Zeitraum gleich bleibt oder ansteigt. Zusammen mit anderen Daten können wir dann aus diesen Werten Informationen zum Zustand der Anwendung ableiten. Das ist nicht nur für die Betrachtung des aktuellen Zustands des Systems interessant, sondern erlaubt auch eine Prognose in die Zukunft. Ein stetig steigender Speicherverbrauch kann z.B. auf ein Speicherleck hindeuten. Ich kann wiederkehrende Trends erkennen und darauf reagieren. Vielleicht besuchen die meisten Leute meine Website am Montag vor 10.00 Uhr. Dann möchte ich vermutlich in diesem Zeitraum zusätzliche Rechen- und Speicherkapazität zur Verfügung stellen, um die Last abzufedern.

Ist Logging jetzt überflüssig?

Jetzt könnte man vermuten, dass wir nur noch Monitoring brauchen. Aus meiner Sicht ist das nicht korrekt. Es bleibt eine gute Idee, relevante Daten aus dem Betriebsablauf meiner Systeme in Log-Dateien zu speichern und ggf. weiter zu verarbeiten. Wichtig finde ich, dass dieses Logging einer Strategie folgt und für verschiedene Lesergruppen Relevanz hat.

Wir sollten uns deshalb folgende Dinge überlegen:

• Welche Zielgruppen werden unsere Log-Ausgaben lesen?
• Welche Ereignisse sind für diese Zielgruppen relevant?
• Welche Gründe gibt es, ein Log zu lesen (Fehlerfall, Debugging, allgemeine Information, Sicherheit)?
• Wie wird das Log gespeichert und ggf. weiter verarbeitet?

Daraus ergibt sich dann ein (hoffentlich schlankes) Logging-Konzept. Dort beschreiben wir, auf welchen Log-Leveln wir welche Arten von Ereignissen in welcher Form speichern. Das Ganze lässt sich kurz im Wiki oder auf wenigen DIN A4 Seiten beschreiben und dient dem Entwicklungsteam dann zur Orientierung.

Wie fange ich an?

Die spannende Frage ist jetzt, wie fange ich an, Monitoring nicht nur als mittelspannendes und arbeitsintensives Anhängsel der Softwareentwicklung zu sehen? Und wie sorge ich dafür, dass wir das Thema im Team ernst nehmen und anfangen, Monitoring von Beginn an vorzusehen und einzubauen? Meist reicht es, zu verstehen, was Monitoring mir als Entwickler bringt und warum es deshalb für mich relevant ist.

Durch Monitoring bin ich bereits zur Entwicklungszeit in der Lage, quasi in die Anwendung zu sehen und wichtige Daten zum Zustand des Systems zu erhalten. Dies erleichtert mir die Fehlersuche und ich bin eher gewillt, Schnittstellen für Monitoring Werkzeuge zu integrieren. Ich sollte mir also zunächst überlegen, welche Daten und Informationen für mich schon während der Entwicklung relevant sind. Wenn ich dann schon dabei bin, kann ich mich auch mit den Leuten unterhalten, die später für den Betrieb des Systems verantwortlich sind. Diese können mir erzählen, was für sie wichtig ist und wie ich sie unterstützen kann.

Gleichzeitig kann ich die jetzt vorliegenden Daten in meiner lokalen Entwicklungsumgebung nutzen. Ich kann mir schon während der Entwicklung ansehen, welche Auswirkungen meine Änderungen auf den Zustand des Systems haben. Zusätzlich nutze ich die Informationen im Continuous Integration System bis hin zu Tests in verschiedenen Stages, um mehr über die Qualität meines Systems zu erfahren. Das erhöht die Nützlichkeit des Monitorings und sorgt für mehr Routine und Vertrautheit im Umgang mit den Informationen und Werkzeugen. Hier hat es sich bewährt, über alle Phasen der Entwicklung und des Betriebs hinweg die gleichen Werkzeuge zu verwenden, um keine Brüche oder Inkompatibilitäten zu erzeugen.

Was fehlt?

Habt Ihr weitere Ideen zum Thema Monitoring, auf die ich nicht eingegangen bin? Schickt mir doch bitte Euer Feedback an peter@flowdaptic.de. Ich freue mich darauf, von Euren Erfahrungen lernen zu können.