Heute stellen wir Dir kurz das Anwendungslog des Reporting Plugins vor, welches sich vor allem in größeren Teams bewährt hat, da hier öfter Fragen auftauchen die das reguläre Aktivitätsprotokoll von Redmine nicht beantworten kann.
Das Reporting Log protokolliert zusätzliche Aktivitäten in deiner Redmine-Instanz und macht sie leichter durchsuchbar, speicherbar und exportierbar, falls nötig.
Was wird protokolliert?
Das Reporting Log erfasst zwei Kategorien von Ereignissen: Authentifizierung und Datenänderungen.
Bei der Authentifizierung werden sowohl erfolgreiche als auch fehlgeschlagene Login-Versuche aufgezeichnet. Das hilft dir dabei, ungewöhnliche Muster zu erkennen - etwa wenn ein Benutzerkonto wiederholt mit falschen Passwörtern angesprochen wird.
Bei Datenänderungen protokolliert das System CRUD-Operationen (Create, Read, Update, Delete) auf den wichtigsten Redmine-Objekten. Wenn jemand ein Ticket erstellt, ein Projekt umbenennt oder einen Benutzer deaktiviert, erscheint ein entsprechender Eintrag im Log. Kategorisiert nach Log Level (Debug, Info, Warning, Error, Fatal, Unknown).
Reporting Log: Funktionsumfang
Hier eine Übersicht der aktuellen Plugin Version 4.3.0 zu den Aktivitäten, die geloggt werden:
| Logging-Funktion | Reporting Anwendungs Log |
|---|---|
| Authentifizierung | |
| Login erfolgreich | Ja |
| Login fehlgeschlagen | Ja |
| Logout | Ja |
| Datenänderungen | |
| Objekt erstellt (Create) | Ja |
| Objekt geändert (Update) | Nur Ereignis |
| Objekt gelöscht (Delete) | Ja |
| Lesezugriffe | |
| Profil angesehen | Nein |
| Ticket angesehen | Nein |
| Anhang heruntergeladen | Nein |
| Datenexporte | |
| CSV/XLSX/PDF-Export | Nein |
| API-Bulk-Abrufe | Nein |
| Berechtigungen | |
| User zu Projekt hinzugefügt | Teilweise |
| Rollenänderungen | Nein |
| Admin-Status geändert | Nein |
| Zugriffsverweigerungen | |
| Fehlgeschlagene Zugriffsversuche | Nein |
| Log-Integrität | |
| Manipulationsschutz (Checksummen) | Nein |
| Kryptografische Verkettung | Nein |
| Weitere Funktionen | |
| Filterbare Query-Oberfläche | Ja |
| Export (CSV, XLSX) | Ja |
| Syslog-Integration | Ja |
| Konfigurierbare Retention | Ja |
| Projekt-basierte Sichtbarkeit | Ja |
Projekt-basierte Sichtbarkeit
Das Reporting Log arbeitet mit Redmines Berechtigungssystem zusammen. Du kannst pro Projekt festlegen, welche Rollen Zugriff auf die Log-Einträge haben.
Das bedeutet konkret, dass beispielsweise ein Projektleiter nur die Aktivitäten in seinen eigenen Projekten sieht. Wohingegend Administratoren projektübergreifend auf alle Einträge zugreifen können. Diese Trennung ist besonders in Umgebungen mit mehreren Kunden oder Abteilungen hilfreich, wo nicht jeder die Aktivitäten der anderen einsehen soll, wenn ihn diese nicht betreffen.
Filtern und Suchen
Wie in Redmine üblich werden auch die Log-Einträge über eine Query-Oberfläche angezeigt, die du auch schon von anderen Redmine-Listen (z.B. Ticketliste) kennst. Du kannst die Einträge daher nach den für dich relevanten Kriterien filtern:
- Zeitraum (von/bis)
- Benutzer
- Projekt
- Art der Aktion (Login, Erstellung, Änderung, Löschung)
- Betroffenes Objekt (Ticket, Projekt, Benutzer etc.)
Die Filter lassen sich kombinieren. Wenn du wissen möchtest, welche Tickets ein bestimmter Benutzer letzte Woche bearbeitet hat, wählst du die entsprechenden Filter und Optionen aus und erhältst eine übersichtliche Liste der geloggten Einträge.
Export für weitere Verarbeitung
Die gefilterten Ergebnisse kannst du bei Bedarf als CSV oder XLSX exportieren. Das ist nützlich, wenn du die Daten in anderen Programmen weiterverarbeiten möchtest - etwa für Berichte oder zur Archivierung.
Der Export enthält alle sichtbaren Spalten und respektiert die gesetzten Filter. Du exportierst also genau das, was du auf dem Bildschirm siehst.
Syslog-Integration
Für Umgebungen mit zentraler Log-Verwaltung bietet das Reporting Log eine Syslog-Integration. Die Einträge werden dann zusätzlich an einen Syslog-Server gesendet, wo sie zusammen mit Logs aus anderen Systemen ausgewertet werden können.
Das ist besonders in größeren IT-Infrastrukturen relevant, wo ein zentrales Log-Management-System (SIEM) im Einsatz ist. Die Redmine-Aktivitäten fügen sich dann nahtlos in das Gesamtbild ein.
Log-Retention konfigurieren
Log-Daten wachsen mit der Zeit. Das Reporting Log bietet eine konfigurierbare Aufbewahrungsdauer (Retention). Du legst fest, wie lange Einträge gespeichert werden sollen, bevor sie gelöscht werden. Für das manuelle Aufräumen steht Dir ein Rake-Task zur Verfügung.
Der Task eignet sich für Cronjobs, wenn du die Retention automatisieren möchtest. Je nach Anforderung kann das ein Monat, 90 Tage, oder ein Jahr sein etc. Die automatische Löschung läuft im Hintergrund und sorgt dafür, dass die Datenbank nicht unnötig wächst.
Einrichtung
Ab der erfolgreichen Installation und Konfiguration des Reporting Plugins funktioniert auch das Log und protokolliert neue Einträge. Wichtig ist, dass du in den Rollen die Berechtigung zum Einsehen der Log-Einträge vergibst.
Bestehende Aktivitäten aus der Vergangenheit werden nicht rückwirkend erfasst - das Log beginnt mit der Aktivierung.
Typische Anwendungsfälle
Das Reporting Log beantwortet Fragen wie:
- Wer hat ein Ticket gelöscht?
- Hat sich jemand außerhalb der Arbeitszeiten eingeloggt?
- Wurden unüblich viele Benutzerkonten geändert?
- Wer hat zuletzt Anpassungen an der Redmine Konfiguration durchgeführt?
Diese Informationen sind im normalen Redmine-Betrieb nicht ohne Weiteres verfügbar. Die Journal-Einträge bei Tickets zeigen zwar Änderungen, aber eine systemweite Übersicht fehlt und Löschvorgänge werden gar nicht protokolliert.
Tipp: Die für dich relevanten Einträge kannst du einfach als benutzerdefinierte Abfrage abspeichern und in einen Dashboard Block integrieren - dann hast du solche Änderungen die einer genaueren Analyse bedürfen immer auf dem Schirm.
Grenzen des Reporting Logs
Das Reporting Log ist kein vollständiger Audit-Trail im Sinne von Compliance-Frameworks. Es protokolliert, dass eine Änderung stattgefunden hat, speichert aber nicht die Vorher/Nachher-Werte. Auch reine Lesezugriffe (wer hat welches Ticket angesehen) werden aktuell nicht erfasst.
Für viele Teams reicht das Reporting Log jedoch aus, um Transparenz über die Systemnutzung zu gewinnen. Wer strengere Anforderungen hat - etwa aus regulatorischen Gründen - sollte prüfen, ob zusätzliche Maßnahmen nötig sind. Diese lassen sich gegebenenfalls mit dem Automation Plugin und der Aktion “Logeintrag hinzufügen” abdecken, wenn dieses zusätzlich im Einsatz ist.
Für wen lohnt sich die Funktion?
Das Reporting Log bringt Transparenz in deine Redmine-Nutzung. Du siehst, wer sich wann einloggt und welche Änderungen vorgenommen werden. Die projekt-basierte Sichtbarkeit, flexible Filter und Export-Funktionen machen es zu einem praktischen Werkzeug für den Alltag mit Redmine.
Besonders profitieren größere Teams und Organisationen mit mehreren Kunden oder Abteilungen, wo Nachvollziehbarkeit und Datentrennung wichtig sind. Projektleiter behalten den Überblick über ihre Projekte, Administratoren können systemweit agieren, und IT-Sicherheitsverantwortliche erkennen ungewöhnliche Login-Muster frühzeitig.
Die hier vorgestellte Funktion ist Teil des Reporting Plugins. Das Reporting Plugin ist einzeln oder als Bestandteil des Enterprise+ Bundles erhältlich und kann auch im Zuge unserer Redmine Hostingangebots genutzt werden. Informationen zu unseren Managed Application Hosting zu Redmine findest Du hier auf der Webseite.