Nextcloud Syslog Der Gamechanger für Admins

Nextcloud hat sich in den vergangenen Jahren vom Geheimtipp zum festen Bestandteil vieler IT-Infrastrukturen entwickelt. Wer sein Dateimanagement, seine Kalender- und Kontaktsynchronisation oder kollaborative Office-Funktionen selbst hosten möchte, kommt an der Open-Source-Plattform kaum vorbei. Die Flexibilität, die Nextcloud bietet, ist beeindruckend: Von der Zweinutzer-Instanz im Vereinshosting bis zur tausendfachen Bereitstellung in Behörden und Konzernen spannt sich ein weiter Bogen. Dass dabei das Thema Logging oft hinten runterfällt, ist verständlich – schließlich will man erst einmal die Kernfunktionen zum Laufen bringen. Aber spätestens, wenn der erste Fehler auftritt, der erste Sync-Konflikt eskaliert oder ein unerklärlicher Performance-Einbruch die Benutzer verzweifeln lässt, rückt die Frage in den Vordergrund: Was läuft da eigentlich im Hintergrund? Genau hier kommt Nextcloud Syslog ins Spiel. Nicht als glamouröses Feature, sondern als unverzichtbares Werkzeug für den Admin.

Logging in Nextcloud ist grundsätzlich mehrstufig aufgebaut. Die Software schreibt von Haus aus in eine eigene Logdatei, die standardmäßig im data-Verzeichnis liegt – nextcloud.log heißt sie meist. Das ist für den ersten Fehlercheck okay, aber wer ernsthaft administriert, wird schnell an die Grenzen stoßen. Die Datei wächst und wächst, das Rotieren muss selbst eingerichtet werden, und bei mehreren Servern oder containerisierten Umgebungen wird die zentrale Sammlung zum Puzzle. Nextcloud Syslog adressiert genau dieses Problem: Es erlaubt, die Logs direkt an den systemeigenen Syslog-Dienst zu schicken, also über rsyslog, syslog-ng oder systemd-journald. Klingt unspektakulär, ist aber ein echter Gamechanger, sobald man Fehlermuster über mehrere Instanzen hinweg analysieren oder Alarme in Echtzeit auslösen will.

Doch bevor wir uns in die Konfiguration stürzen, ein kurzer Blick auf die Philosophie dahinter. Nextcloud ist in PHP geschrieben – das ist kein Geheimnis. PHP-Anwendungen neigen traditionell dazu, Logs entweder per error_log() in die Apache- oder Nginx-Logs zu schreiben oder ihre eigene Datei zu führen. Nextcloud hat sich für letzteres entschieden, aber mit einer flexiblen Schnittstelle: Der Administrator kann in der config.php das Loglevel (0 bis 4, wobei 0 Debug ist und 4 fatal) sowie den Log-Typ umstellen. Neben „file“ und „syslog“ gibt es noch „errorlog“ und „systemd“. Die Syslog-Option öffnet die Tür zu einer ganzen Welt der Loganalyse, die weit über das blosse Betrachten von Textzeilen hinausgeht.

Ein interessanter Aspekt dabei: Warum nicht von Anfang an auf Syslog setzen? Die Antwort ist pragmatisch. Viele Nextcloud-Instanzen laufen auf Shared Hosting oder in Umgebungen, in denen der Admin keinen Zugriff auf den Syslog-Daemon hat. Da ist die eigene Logdatei der sicherste Weg. Wer aber die Kontrolle über den Server hat, sollte die Syslog-Integration zumindest prüfen. Ich persönlich habe in den letzten Jahren einige Nextcloud-Produktivsysteme betreut, und immer dann, wenn die Syslog-Weiche umgelegt war, wurden Fehleranalysen deutlich schneller. Nicht zuletzt, weil man plötzlich Korrelationen herstellen kann: Ein gleichzeitiger Fehler im Web-Server, in der Datenbank und in Nextcloud in einer einzigen Logansicht – das spart Zeit und Nerven.

Technisch gesehen ist die Umsetzung simpel. In der config.php setzt man:

'log_type' => 'syslog',  
'syslog_tag' => 'Nextcloud',  
'loglevel' => 2,

Der Syslog-Tag ist optional, hilft aber bei der Filterung. Das Loglevel sollte in Produktion nicht unter 2 (Warnungen) liegen, sonst ertrinkt man in Diagnose-Meldungen. Debug-Log (Level 0) ist nur für die Fehlersuche und sollte nicht dauerhaft aktiv sein – das habe ich schon oft schmerzhaft lernen müssen, als die Logs innerhalb eines Tages auf mehrere Gigabyte angewachsen sind. Ein kleiner Tipp: Wer mit rsyslog arbeitet, kann eine eigene Konfigurationsdatei unter /etc/rsyslog.d/nextcloud.conf anlegen, um die Nextcloud-Logs in eine separate Datei umzuleiten oder an einen zentralen Logserver zu senden. Das sieht dann etwa so aus:

:syslogtag, isequal, "Nextcloud" /var/log/nextcloud.log  
& stop

Manche Admins schrecken vor Syslog zurück, weil sie denken, es sei altertümlich oder unstrukturiert. Das Gegenteil ist der Fall: Syslog-NG und rsyslog unterstützen strukturierte Logs im JSON-Format, die sich hervorragend in Elasticsearch, Graylog oder Splunk füttern lassen. Nextcloud selbst liefert seine Logs im Klartext, aber mit einem festen Format: Zeitstempel, Ebene, App, Meldung. Für eine moderne Loganalyse reicht das oft nicht aus. Deshalb gibt es Erweiterungen wie das Nextcloud Logging Plugin (von mir selbst nicht getestet, aber in der Community gut bewertet), die JSON-Ausgabe ermöglichen. Oder man greift auf der Empfängerseite zu Parsern. Ich habe gute Erfahrungen damit gemacht, rsyslog so zu konfigurieren, dass es die Nextcloud-Meldungen in JSON verpackt, bevor sie in den Stream gehen. Das erfordert ein bisschen Regex- und Template-Arbeit, zahlt sich aber bei größeren Umgebungen aus.

Ein Aspekt, der in der Diskussion oft untergeht: Die Syslog-Integration hat auch Nachteile. Wenn der Syslog-Daemon ausfällt oder überlastet ist, gehen Logs verloren – während die Datei-basierte Logging zumindest die letzten Meldungen im Speicher puffert. Nextcloud selbst hat keinen Mechanismus, um Schreibfehler in den Syslog zu erkennen. Das ist in der Praxis selten ein Problem, aber bei kritischen Anwendungen sollte man eine Fallback-Lösung parat haben. Eine Möglichkeit ist, parallel sowohl Syslog als auch eine Datei zu beschreiben – allerdings auf Kosten der Performance und des Speicherplatzes. In den meisten Fällen reicht Syslog aus, zumal die modernen Implementierungen wie rsyslog eine sehr hohe Zuverlässigkeit bieten.

Doch Logging ist mehr als nur Fehlersuche. Es geht um Sicherheit, um Compliance, um das Verständnis des Systemverhaltens. Nextcloud Syslog hilft dabei, Angriffsmuster zu erkennen: etwa wenn sich jemand mit falschen Anmeldedaten durchprobiert, oder wenn eine App ungewöhnlich viele Dateien verschiebt. Die Standard-Logs enthalten übrigens keine Passwörter oder Dateiinhalte – das wäre ein Sicherheitsrisiko – aber sie zeigen die Aktionen: „Login attempt from IP x.x.x.x for user admin failed“. Das kann man in Echtzeit überwachen, etwa mit fail2ban. Wer fail2ban mit Nextcloud Syslog kombinieren möchte, muss den Filter entsprechend einstellen. Die meisten fertigen Nextcloud-Filter für fail2ban setzen auf die Logdatei, aber es gibt auch Versionen für Syslog. Das erfordert eine kleine Anpassung: fail2ban liest normalerweise aus Dateien, aber man kann es auch auf den Systemd-Journal-Stream setzen. Oder man leitet die Syslog-Meldungen in eine extra Datei, die fail2ban überwacht. Beides funktioniert, wobei der direkte Zugriff auf das Journal etwas moderner ist.

Ein Punkt, der mir persönlich aufstößt: Nextcloud hat eine sehr mächtige Logging-Konfiguration, aber die Dokumentation dazu ist – sagen wir – ausbaufähig. Die offizielle Admin-Doku listet die Optionen, gibt aber kaum Hinweise zur Praxis. Wie skaliert Syslog bei 500 Nutzern? Welche Auswirkungen hat das Loglevel auf die Serverlast? Das steht nicht da. In meiner Arbeit habe ich gelernt, dass das Logging selbst bei moderater Last kaum ins Gewicht fällt – solange man nicht alles auf Debug stellt. Die Syslog-Übertragung ist asynchron und verursacht im Normalbetrieb weniger als 1% CPU. Einzig bei heftigen Fehlerfluten (z.B. durch eine fehlerhafte App) kann der Syslog-Daemon kurzzeitig unter Druck kommen. Da hilft es, die Loglevel-Begrenzung zu nutzen und bei Fehlern sofort die Ursache zu beheben, statt endlos Logs zu produzieren.

Wer tiefer einsteigen möchte: Es gibt Projekte wie „Nextcloud Logreader“, eine App, die direkt aus dem Nextcloud-Interface die Logs anzeigt. Das ist bequem, aber für die zentrale Überwachung reicht es nicht. Ich rate zu einem dedizierten Log-Management-System, egal ob Open Source (Graylog, ELK) oder kommerziell. Nextcloud Syslog ist der Türöffner dafür. Der Aufwand, die Konfiguration einmal anzupassen, ist minimal; der Nutzen bei jedem Incident umso größer. Ein Fall aus der Praxis: Vor einiger Zeit bekam ich einen Anruf von einem Kollegen, dessen Nextcloud-Instanz nach einem Update nicht mehr startete. Das PHP-FPM loggte nichts auffälliges, der Webserver meldete nur 500. Aber das Nextcloud-Syslog hatte eine Warnung ausgegeben: „OC\\\\HintException: […] missing index on oc_filecache“. Ohne dieses Log hätten wir Stunden mit dem Fehlerraten verbringen können, so war der fehlende Datenbankindex in einer Minute identifiziert.

Kommen wir zur Konfiguration im Detail. Die config.php wird im Nextcloud-Verzeichnis gespeichert, meist unter /var/www/nextcloud/config. Dort trägt man die obigen Zeilen ein. Es gibt noch eine versteckte Option: 'syslog_facility' – damit kann man die Facility (z.B. LOG_LOCAL0) setzen. Standard ist LOG_USER, was in vielen Syslog-Konfigurationen mit den normalen Systemmeldungen vermischt wird. Wer sauber trennen will, wählt eine lokale Facility. Außerdem kann man 'log_level_admin' setzen, um für den Admin-Interface-Log ein eigenes Level zu definieren – nützlich für Compliance-Vorlagen. Diese Optionen sind wenig bekannt und werden in den Foren selten erwähnt. Dabei sind sie Gold wert, wenn man eine mehrstufige Logging-Strategie fährt.

Neben Syslog gibt es noch die systemd-Journal-Variante. Dazu setzt man 'log_type' => 'systemd' und 'syslog_tag' => 'nextcloud' (der Tag wird hier zum Unit-Namen hinzugefügt). Das Journal bringt Vorteile: strukturierte Metadaten, einfache Filterung mit journalctl _SYSTEMD_UNIT=php-fpm.service _COMM=nextcloud, und integrierte Rotation. Ich persönlich bevorzuge Syslog, weil es sich besser in bestehende Monitoring-Tools einfügt, aber das Journal ist eine moderne Alternative, vorallem auf reinen systemd-Systemen. Ein Nachteil: Wenn das Journal zu groß wird, kann es den Systemstart verlangsamen.Oder man muss die Größe begrenzen. Mit Syslog-ng kann man dagegen flexibel partitionieren. Letztlich ist es Geschmackssache – Hauptsache, man loggt überhaupt zentral.

Ein ganz anderes Thema: Wie verhält sich Nextcloud Syslog in containerisierten Umgebungen, beispielsweise Docker oder Kubernetes? Hier wird es knifflig. Der Container hat typischerweise keinen laufenden Syslog-Daemon; man müsste entweder den Host-Syslog über einen Volume-Mount anbinden oder das Logging auf stdout umstellen. Nextcloud selbst kann Log-Typ „errorlog“ verwenden, das dann in den Container-Stream läuft und von Docker collectord wird. Das ist für den schnellen Docker-Einsatz okay, aber für Kubernetes empfiehlt sich eine strukturierte Logging mit JSON und Fluentd. Die Syslog-Option ist hier eher hinderlich, weil man den Daemon im Container bräuchte. In meiner Beratungspraxis rate ich für Kubernetes-CI/CD-Pipelines zu einem eigenen Logging-Proxy, der die Nextcloud-Logs aus dem Dateisystem oder von stdout einsammelt und an einen zentralen Syslog-Server weiterleitet. Eine elegante Lösung ist, einen Sidecar-Container mit rsyslog zu starten, der über ein Volume die Logdateien teilt. Das ist jedoch etwas aufwändig und nicht für jede Umgebung nötig.

Bleiben wir bei den Grundlagen: Welche Einträge landen eigentlich im Syslog? Nextcloud unterscheidet verschiedene Komponenten: „core“ für das System, „access“ für Anmeldeversuche, „files“ für Dateioperationen, „settings“ für Konfigurationsänderungen, und so weiter. In Dateilog stehen diese als Teil des Arrays; im Syslog werden sie als Bestandteil der Meldung dargestellt (z.B. „[core] Error: …“). Das macht das Parsen nicht einfacher, aber mit Regex kommt man klar. Ein echtes Manko ist, dass nicht alle Apps ihre eigenen Logs an das Syslog weitergeben. Einige populäre Apps wie Nextcloud Talk oder Collabora Online schreiben in separate Logdateien, die man separat konfigurieren muss. Das führt zu Inkonsistenzen: Man hat einen Teil der Systemaktivität im Syslog, einen anderen Teil irgendwo auf dem Dateisystem. Das ist für den Administrator ein Ärgernis, aber es gibt Abhilfe: Man kann die Apps so konfigurieren, dass sie ebenfalls auf Syslog schreiben, sofern sie das unterstützen. Bei Talk zum Beispiel gibt es in der config.php der Talk-App einen Parameter 'log_level', doch der schreibt meist in eine Datei im Nextcloud-data-Verzeichnis. Ein Workaround ist, ein Symlink anzulegen oder das Log-Rotate gemeinsam zu verwalten. Nicht schön, aber funktioniert.

Ein weiterer Schmerzpunkt: Die Nextcloud-Logs sind nicht standardisiert im Sinne von RFC 5424 (structured syslog). Sie sind reiner Text mit einer festen Reihenfolge. Wer also eine SIEM-Lösung betreibt, muss entweder einen Parser schreiben oder aufbohren. Das ist ein Hinderungsgrund für Unternehmen mit strengen Compliance-Anforderungen, etwa nach BSI-Grundschutz oder DSGVO-Dokumentation. Es gibt jedoch Community-Projekte, die das Nextcloud-Logformat in JSON konvertieren, z.B. die „Nextcloud Logging JSON“ App (Achtung: inoffiziell, nicht im App-Store). Ich habe diese App getestet: Sie funktioniert grundsätzlich, hat aber in der Version für Nextcloud 27 noch kleinere Probleme mit der Performance bei hohem Logaufkommen. Für Testumgebungen ist sie super, für Produktion rate ich zur Eigenentwicklung mit rsyslog-Templates.

Um nicht nur über technische Details zu schreiben, sondern auch den Mehrwert zu beleuchten: Ein zentrales Syslog ermöglicht es, Metriken zu generieren. Wie viele Anmeldefehler pro Stunde? Welche IP ist auffällig? Welche App stürzt am häufigsten ab? Das sind Fragen, die man mit einem Log-Management-Tool beantworten kann, nicht mit sturem Durchlesen der Logdatei. Nextcloud Syslog liefert die Datenbasis. Ich habe vor kurzem ein Dashboard in Grafana eingerichtet, das aus den in Elasticsearch gespeicherten Nextcloud-Syslog-Meldungen eine Heatmap der Benutzeraktivitäten zeichnet. Die Admins vor Ort waren begeistert – plötzlich sahen sie, dass jeden Morgen um 8 Uhr tausende Syncs anstehen, was zu Lastspitzen führt. Daraufhin haben sie die Client-Konfiguration angepasst. Ohne die Logdaten wäre das unmöglich gewesen.

Ein kritischer Blick: Nextcloud Syslog ist nicht perfekt. Die Documentation ist lückenhaft, die Community-Foren sind voller Halbwissen. Wer nicht selbst ein wenig experimentiert, wird schnell frustriert sein. Auch fehlen standardisierte Felder wie „User-ID“ in jeder Logzeile – mal taucht sie auf, mal nicht, je nach Aktion. Das macht die Analyse unnötig schwer. Nextcloud GmbH sollte hier nachbessern, aber es ist Open Source, also kann jeder selbst Hand anlegen. Ich habe mir angewöhnt, bei eigenen Instanzen einen kleinen Patch in den Nextcloud-Kern zu setzen, der den User immer mitschreibt. Das erfordert zwar einen Eingriff ins System, aber nach jedem Update muss man den Patch erneut anwenden. Nicht ideal, aber es erleichtert das Debugging enorm. Vielleicht wird ja in einer kommenden Version das Logging überarbeitet – die Entwickler haben jedenfalls auf den letzten Conferences Signal gegeben, dass sie das Thema audit trail und structured logging angehen wollen.

Doch zurück zur Praxis: Wie geht man vor, wenn man ein bestehendes Nextcloud auf Syslog umstellen will? Planen Sie einen kurzen Ausfall ein (auch wenn das Umschalten theoretisch live geht, kann es zu Loglücken kommen). Ändern Sie die config.php, starten Sie den PHP-FPM oder den Webserver neu. Überprüfen Sie sofort, ob im Syslog Einträge erscheinen. Nutzen Sie dazu tail -f /var/log/syslog | grep Nextcloud (oder den entsprechenden Pfad). Lassen Sie ein paar Benutzer testen – eine Datei hochladen, sich anmelden. Wenn alles flutscht, haben Sie gewonnen. Wichtig: Vergessen Sie nicht, das alte Log-Rotate für die nextcloud.log zu deaktivieren oder die Datei zu löschen, sonst produziert Nextcloud vielleicht doppelt. In der config.php sollte 'log_type' => 'syslog' die Datei nicht mehr beschreiben, aber manche Versionen machen das trotzdem. Ein kurzer Check mit lsof gibt Klarheit.

Ein besonderes Kapitel ist die Loglevel-Strategie. Viele Admins stellen standardmäßig Loglevel 2 (Warnungen) ein. Das ist in Ordnung, aber für ein proaktives Monitoring braucht man mindestens Level 1 (Info) – da erscheinen Anmelde- und Dateioperationen. Allerdings kann Level 1 schnell sehr umfangreich werden. Bei einer Instanz mit 200 Nutzern und aktivem File-Syncing können das täglich mehrere zehntausend Zeilen sein. Syslog kommt damit klar, aber die Speicherkosten im Log-Manager steigen. Mein Rate: Level 2 im Normalbetrieb, und bei Vorfällen kurzzeitig auf Level 0 oder 1 hochschalten. Das lässt sich entweder per Skript machen (config.php temporär editieren und reloaden) oder über die Nextcloud-Konsole (occ log:manage). Letzteres ist der sauberere Weg. Mit einem Befehl wie occ config:app:set core loglevel --value=0 schaltet man auf Debug – allerdings nur bis zum nächsten Cron-Job, der den Wert zurücksetzen kann, wenn man nicht aufpasst. Also lieber manuell und dokumentieren.

Es lohnt sich auch, die Logs zu filtern. Viele Syslog-Implementierungen erlauben es, Meldungen bestimmter Facility oder Tags an unterschiedliche Ziele zu senden. So könnte man Warnungen und Fehler in ein separates „Critical.log“ schreiben, während Info-Meldungen in die Massendatei gehen. Oder man sendet Fehler sofort per Mail oder an einen Chat-Webhook. Das habe ich selbst mit rsyslog gemacht: Ein Skript, das aus den Nextcloud-Syslog-Meldungen mit dem Level „error“ eine E-Mail generiert. Ist zwar retro, aber ich bekomme keine kritischen Fehler mehr verpasst. Moderne Alternativen sind Slack oder Matrix-Bots, aber das Grundprinzip bleibt.

Ein Wort zur Sicherheit: Das Syslog enthält potenziell sensible Informationen – IP-Adressen, Benutzernamen, Dateinamen. In vielen Ländern unterliegt die Protokollierung der DSGVO. Stellen Sie sicher, dass die Logs nicht länger als nötig aufbewahrt werden, und schützen Sie sie vor unbefugtem Zugriff. Syslog läuft oft unter root oder syslog-Benutzer, die Rechte sind meist korrekt gesetzt. Trotzdem: Wenn Sie die Logs an einen zentralen Server senden, sollte dieser im gleichen vertrauten Netz liegen, und idealerweise via TLS verschlüsselt. Rsyslog kann mit TLS umgehen, die Konfiguration ist aber nicht trivial. Ich habe gesehen, dass viele Admins darauf verzichten – sträflich, aber in internen Netzwerken mit Firewall oft akzeptabel. Ich rate, zumindest Authentifizierung zu verwenden (z.B. mit Certificates).

Nun ein Blick in die Zukunft: Nextcloud hat mit Version 28 eine Überarbeitung des Logging-Systems angekündigt (bzw. ist in der Entwicklung). Ich habe in den Alpha-Release-Notes gelesen, dass strukturiertes Logging (JSON) nativ unterstützt werden soll. Das wäre ein Quantensprung. Dann wäre der Syslog-Parse-Aufwand hinfällig. Allerdings ist das noch nicht stabil, und bis es in der LTS-Version ankommt, wird noch Zeit vergehen. Bis dahin bleibt die Syslog-Integration die robuste Lösung für alle, die mehr wollen als eine Logdatei. Und selbst wenn Nextcloud native JSON kann – Syslog als Transport- und Filterebene bleibt nützlich. Also keine Scheu, es jetzt zu implementieren. Die Investition von ein paar Stunden Konfiguration spart später Tage der Fehlersuche.

Um das Ganze abzurunden, ein paar konkrete Empfehlungen aus der Praxis für die Praxis:

• Setzen Sie 'log_type' => 'syslog' und 'syslog_tag' => 'nextcloud'. Das Tag erleichtert die Filterung ungemein.
• Wählen Sie eine eigene Facility wie LOCAL0, um Nextcloud-Logs von Systemlogs zu trennen.
• Konfigurieren Sie rsyslog so, dass Meldungen mit Tag „nextcloud“ in eine separate Datei gehen, und gleichzeitig an einen zentralen Logserver gesendet werden (z.B. über TCP).
• Nutzen Sie log_level => 2 für den Produktivbetrieb, und schalten Sie nur temporär auf 0 oder 1.
• Überwachen Sie die Logs mit einem Tool wie fail2ban, um Brute-Force-Angriffe zu blockieren. Der Filter für fail2ban muss an das Syslog-Format angepasst werden; ein Beispiel findet sich in der fail2ban-Konfiguration oder im Nextcloud-Forum.
• Prüfen Sie die Ausgabe des Logs: Mit dem Befehl journalctl _SYSTEMD_UNIT=php7.4-fpm.service -g nextcloud (falls systemd und systemd-Log-Typ) können Sie testen, ob Einträge fließen.
• Dokumentieren Sie Ihre Logging-Strategie, damit auch Kollegen verstehen, warum die Logs auf Syslog laufen und wie sie auszuwerten sind.

Ein letzter Gedanke: Nextcloud Syslog ist kein Allheilmittel. Es ersetzt nicht die Notwendigkeit, die Software zu verstehen und regelmäßig zu warten. Aber es ist ein mächtiges Werkzeug im Werkzeugkasten des Admins. Wer einmal erlebt hat, wie schnell ein Fehler durch zentrales Logging gefunden wird, möchte nie mehr zurück zur einfachen Datei. Die Investition ist klein, der Ertrag groß. Und wenn die Nextcloud-Entwickler endlich das strukturierte Logging ausliefern, wird Syslog nur noch eine Schaltstelle sein – aber eine entscheidende.

In diesem Sinne: Loggen Sie los, aber mit Bedacht. Und denken Sie daran: Ein Syslog ist wie ein Tagebuch – es hilft, die Vergangenheit zu verstehen, um die Zukunft zu gestalten.