Wo früher der Mailserver als das eine geschäftskritische System galt, dessen Ausfall sofort einen Krisenstab nach sich zog, sind es heute mindestens drei oder vier Dienste, denen eine vergleichbare Relevanz zukommt. Setzen IT-Teams auf Open Source, zählen dazu gewiss Nextcloud für Dateien und Zusammenarbeit, Mattermost für die Echtzeitkommunikation, BigBlueButton (ab Seite 64) oder Jitsi für Videokonferenzen, dazu noch ein Wiki und vielleicht ein Projektmanagement-Werkzeug. Wer eines dieser Systeme abschaltet, hat innerhalb von Minuten genervte Mitarbeiter am Apparat. Stürzt gar ein Dienst dieser Gewichtsklasse ungeplant ab, ist Chaos im Unternehmen vorprogrammiert.

Trotzdem hinkt das Monitoring dieser Dienste in der Praxis häufig hinterher. Für Webserver, Datenbanken und Reverse-Proxys hat jeder erfahrene Admin sein bewährtes Dashboard in der Schublade. Bei Diensten wie Nextcloud oder Jitsi fängt die Recherche oft erst dann an, wenn die ersten genervten Nachrichten von Benutzern eintrudeln. Das liegt nur zum Teil an Bequemlichkeit – und viel eher daran, dass die Hersteller die Monitoringaspekte ihrer Produkte mit höchst unterschiedlicher Sorgfalt entwickelt haben. Drei Beispiele verdeutlichen das schnell: Nextcloud ist solide ausgestattet, Mattermost bietet einen nativen Prometheus-Endpoint, der aber nur in der kostenpflichtigen Edition wirklich zugänglich ist, und BigBlueButton verlässt sich vollständig auf Community-Exporter.

Wir zeigen anhand der drei genannten Dienste, wie Admins trotz dieser Asymmetrien ein zentrales Monitoring aufbauen – mit Prometheus und Grafana als bewährter Basis, mit aussagekräftigen Metriken pro Dienst und mit wirklich relevanten Alarmen statt lästigem Grundrauschen. Auch wenn die Open-Source-Welt groß und umfangreich ist, so lassen sich die gewonnenen Erkenntnisse doch zumindest sinngemäß auf andere Kollaborationswerkzeuge anwenden.

Bevor es an die spezifischen Dienste geht, lohnt sich ein konzeptioneller Überblick. Ein vollständiges Monitoring eines Collaboration-Diensts besteht aus vier Ebenen, die jeweils auf eine andere Art von Frage Antwort geben. Wer eine Ebene weglässt, hat blinde Flecken – und darin versteckt sich oft schon das nächste Problem.

Die erste Ebene ist die Infrastrukturebene: CPU-Last, RAM, Plattenfüllstände, Netzwerk-I/O, alles was der "node_exporter" brav alle 15 Sekunden in den Cluster pumpt. Diese Ebene ist Pflicht, für sich allein aber wertlos – wer nur auf die CPU schaut, übersieht jeden Datenbank-Deadlock und jeden vollgelaufenen Worker-Pool. Die zweite Ebene ist die Anwendungsebene mit den dienstspezifischen Metriken aus dem "/metrics"-Endpoint oder einem vorgeschalteten Exporter: Antwortzeiten, Cache-Hit-Raten, Worker-Auslastung, Queue-Längen, Fehlerraten. Hier zeigen sich Probleme oft schon, bevor Nutzer sie merken.

Die dritte Ebene ist die Nutzungsebene: aktive User, gleichzeitige Sessions, durchschnittliche Meetinggrößen, hochgeladene Datenmengen. Weniger akut alarmrelevant, aber entscheidend für die Kapazitätsplanung. Die vierte Ebene ist die Blackbox-Ebene: Funktioniert der Dienst aus Nutzersicht überhaupt? Ein "blackbox_exporter", der alle 30 Sekunden eine Loginsequenz durchspielt oder einen Upload simuliert, fängt Probleme ab, die alle anderen Ebenen übersehen – etwa wenn die Anwendung läuft, aber der vorgelagerte Reverse-Proxy einen Konfigurationsfehler hat oder das TLS-Zertifikat abgelaufen ist. Monitoring dieser Art, oft auch als "Synthetisches Monitoring" bezeichnet, ist die unbestechliche Außenperspektive, die alle internen Werkzeuge übertrumpft und korrigiert.

Diese vier Ebenen ziehen sich als roter Faden durch diesen Workshop. Hinzu kommt ein Grundprinzip aus dem kleinen Einmaleins des Site Reliability Engineerings, kurz SRE: Symptome statt Ursachen. Alarme lösen idealerweise bei Problemen aus, die die Nutzer unmittelbar betreffen, statt an einer beliebig definierten technischen Eigenschaft, die in der Momentaufnahme möglicherweise ungewöhnlich erscheint. Der manchem Altvorderen noch bekannte Parameter der Systemlast ist dafür ein gutes Beispiel: Noch immer werden manche Admins heute nervös, wenn ein System eine Last von 20 Prozent anzeigt. Hat das System aber 128 physische CPU-Kerne, langweilt die Maschine sich trotzdem.

Nextcloud ist seit dem 2016 vollzogenen Fork von ownCloud eine ausgewachsene Plattform geworden, die heute deutlich mehr ist als ein Filesync-Dienst – Kalender, Kontakte, Office-Integration und Videokonferenzen über das hauseigene Talk-Plug-in gehören zur Standardausstattung.

Was das Monitoring betrifft, hat Nextcloud eine Schnittstelle, die jeder Admin kennen sollte: das Server-Info-API unter "/ocs/v2.php/apps/serverinfo/api/v1/info". Dieses liefert einen reichen XML- oder JSON-Datensatz mit Informationen zur Instanz – aktive Nutzer der letzten fünf Minuten, der letzten Stunde und der letzten 24 Stunden, Anzahl der Dateien und Shares, belegter und freier Speicher, Datenbankgröße, installierte PHP-Version sowie geladene Apps sind davon nur einige. Der Zugriff erforderte in älteren Versionen einen Admin-Account; seit Nextcloud 22 lässt sich ein dedizierter Token erzeugen, der ausschließlich dem Monitoringzugriff dient. Dies ist die deutlich modernere und sauberere Variante, weil keine echten User-Credentials in der Exporter-Konfiguration landen. Kommt der Token abhanden, erhalten Angreifer höchstens Details über den laufenden Dienst, aber keinen eskalierenden Zugriff auf diesen.

Den Brückenschlag zu Prometheus übernimmt der "nextcloud-exporter" [1]. Er ist in Go verfasst, kommt als einzelnes Binary oder Container-Image, lauscht standardmäßig auf Port 9205 und übersetzt die Serverinformationen in Prometheus-Metriken: "nextcloud_active_users" mit Labels für die Zeitspanne, "nextcloud_files_total", "nextcloud_free_space_bytes", "nextcloud_database_size_bytes". Eine Eigenheit: Bei jeder Prometheus-Abfrage ruft der Exporter das Server-Info-API auf, was bei Standardintervallen von 15 Sekunden in großen Installationen bald merkliche Last erzeugt. Hier empfiehlt sich ein angepasstes "scrape_ interval" von 60 oder 90 Sekunden – die genannten Metriken ändern sich ohnehin nicht so schnell, dass ein engerer Takt echten Mehrwert böte.

Soweit die gute Nachricht. Die weniger gute: Was das Server-Info-API liefert, ist nur ein kleiner Ausschnitt dessen, was Systemverwalter eigentlich wissen müssen. Detaillierte Performancemetriken pro Request, etwa Antwortzeiten der einzelnen Endpunkte oder Wartezeiten in der Datenbank, sind nicht enthalten. Die Auslastung des "php-fpm"-Pools – also der Worker-Prozesse, die jede einzelne PHP-Anfrage bearbeiten – ebenfalls nicht. Die Hit-Rate des Redis-Caches, der bei jedem nennenswerten Nextcloud-Setup zwischengeschaltet ist? Fehlanzeige. Datenbankquery-Latenzen, langsame Querys, Connection-Pool-Auslastung? Leider nein. Das API für Metrikdaten von Nextcloud fällt entsprechend in die Kategorie "gute Grundlage". Wer Nextcloud aber vollständig überwachen möchte, muss mehr tun, als sich blind auf die feilgebotenen Informationen von dort zu verlassen.

Praktisch kommen Sie deshalb um ein Stapeln mehrerer zusätzlicher Exporter nicht herum. Der "node_exporter" für die Infrastrukturebene ist ohnehin gesetzt. Hinzu kommen der "php-fpm-exporter" [2], der die Statusseite des FPM-Pools ausliest und Werte wie aktive Prozesse, Wartezeiten und Listen-Queue-Tiefe liefert. Der "redis_exporter" [3] liefert Metrikdaten zu Redis wie die Cache-Statistiken inklusive Hit-Rate und genutztem Speicher. Und schließlich darf der passende Datenbankexporter nicht fehlen – "postgres_exporter" für PostgreSQL oder "mysqld_exporter" für MySQL/MariaDB. Das hängt freilich von der Frage ab, für welches Backend man sich in Nextcloud entschieden hat.

Erst aus der Kombination etlicher Exporter entsteht mithin ein vollständiges Bild. Die klassischen Praxisprobleme einer Nextcloud-Instanz lassen sich nur so erkennen: Stehende Background-Jobs, weil Cron nicht läuft, erkennt man etwa am Nextcloud-eigenen Wert "nextcloud_last_cron_run_seconds_since" – wenn der über 600 Sekunden klettert, hat Cron den Dienst quittiert. Stöhnen Redis oder die genutzte Datenbank unter der anliegenden Last, ist Nextcloud erst einmal nur langsam, vermag selbst aber den Grund dafür nicht zu verraten. Ein vollgelaufener Worker-Pool im "php-fpm" führt dazu, dass neue Requests in eine Warteschlange rutschen, was Nutzer als "Nextcloud reagiert nicht mehr" wahrnehmen – sichtbar im FPM-Exporter, eher schwierig zu erkennen im Nextcloud-Exporter. Und das Ende der Fahnenstange ist damit noch immer nicht erreicht. Ein langsam werdendes Speicherbackend (etwa ein überlasteter S3-Storage) zeigt sich in den WebDAV-Antwortzeiten, die nur ein Blackbox-Test einfängt. Prometheus liefert hierfür das eigene "Blackbox"-API mit, das sich über HTTP- und ICMP-Anweisungen dazu bringen lässt, sich als externer Client gegenüber einer Seite auszugeben.

Sinnvolle Alerts sind entsprechend obligatorisch und kombinieren die verschiedenen Ereignisquellen miteinander: "Cron seit über 15 Minuten nicht gelaufen" ist ein Critical-Alert, weil Nextcloud dann seine internen Maintenance-Abläufe nicht einhält und früher oder später abstürzt. Dagegen zeigt "php-fpm-Listen-Queue über zehn Einträge für mehr als fünf Minuten" einen Worker-Engpass, der der dringenden Handlung bedarf. "Freier Speicher unter zehn Prozent" hingegen ist eine Warnung, um die sich die Frühschicht auch am nächsten Morgen noch kümmern kann. Sparen kann man sich wie beschrieben Alerts auf einzelne CPU-Spitzen oder die Anzahl aktiver Nutzer – beides sind keine Symptome, sondern bestenfalls Ursachen für mögliche spätere Probleme.

Mattermost ist seit seiner Gründung 2015 als Open-Source-Slack-Alternative angetreten und hat sich zu einer der populärsten selbst gehosteten Messenger-Plattformen entwickelt – gerade im DACH-Raum mit seinem ausgeprägten Wunsch nach Datenhoheit. Die Software gibt es in einer kostenfreien Team-Edition und mehreren kommerziellen Versionen. An genau dieser Lizenzgrenze trennt sich auch die Monitoringwelt.

Mattermost bringt einen nativen Prometheus-Endpunkt mit, der mittels eines konfigurierbaren Ports erreichbar ist. Sie aktivieren den Exporter in der Systemkonsole unter "Environment / Performance Monitoring" über "MetricsSettings.Enable" und eine "MetricsSettings.ListenAddress" (typischerweise ":8067"). Was die Software ausliefert, kann sich sehen lassen: Dazu gehören die HTTP-Request-Latenzen pro API-Endpunkt mit Histogramm-Granularität ("mattermost_api_time"), aktive WebSocket-Verbindungen, Datenbankquery-Latenzen und -Durchsatz ("mattermost_db_*"), der Cluster-Status bei HA-Setups, Plug-in-Ladezeiten, Posts pro Sekunde und Cache-Hit-Raten. Obendrauf gibt es die kompletten Go-Runtime-Metriken, die Mattermost als Go-Applikation ohnehin ständig mitschreibt.

Der Haken dabei: Eine Lizenz der kostenpflichtigen Versionen ist nötig, um das "/metrics"-API überhaupt nutzen zu können. In der Team-Edition lässt sich der Schalter zwar aktivieren, das API antwortet aber mit einem HTTP-404-Fehler. Getarnt als Konfigurationsdetail stoßen Sie hier faktisch auf eine harte Grenze des Lizenzierungsmodells. Diese Lücke füllen Community-Exporter wie der "mattermost_exporter" [4], der über das Admin-API zumindest ein paar grundlegende Werte rekonstruiert, wie etwa User-Zahlen, Channel-Zahlen und Statusinformationen zur Datenbank. Die internen Latenz-Histogramme, Cache-Statistiken oder WebSocket-Detailzahlen bleiben dem Administrator jedoch verborgen.

Verfügen Sie hingegen über eine Lizenz, profitieren Sie von einer hervorragend dokumentierten Metrikenliste. Besonders aussagekräftig sind in der Praxis drei Werte: Die Latenz bei "mattermost_api_time" zeigt im "p99"-Stil, ob die langsamsten ein Prozent der Anfragen noch in akzeptablen Zeiten beantwortet werden, also das 99. Perzentil aller Antwortzeiten. Das ist sehr viel ehrlicher als der beruhigend wirkende Durchschnitt. Die Rate der WebSocket-Verbindungsabbrüche zeigt, ob die Echtzeitkommunikation noch funktioniert; verlieren Clients alle paar Sekunden die Verbindung, ist das ein Frühwarnzeichen für überlastete Datenbankverbindungen oder ein fehlerhaftes Reverse-Proxy-Setup. Die Datenbankquery-Latenz aus den "mattermost_db_*"-Metriken ist fast immer der eigentliche Engpass, wenn Mattermost zäh wird – die Anwendung selbst ist schlank, hängt aber sehr direkt an der Performance der PostgreSQL-Instanz darunter.

Sinnvolle Alerts sind entsprechend die p99-API-Latenz über einer Sekunde für mehr als fünf Minuten (ein Anzeichen für eine klare Performance-Degradation), die Rate der WebSocket-Reconnects über einem Schwellenwert (Zeichen für mangelnde Verbindungsstabilität) oder nicht erreichbare Cluster-Knoten in einem HA-Setup. Denn hier ist bestenfalls ein Node abgestürzt, schlimmstenfalls hat aber ein Split-Brain stattgefunden, weil der Cluster schon vorher überlastet war. Der Administrator ergänzt all diese Faktoren idealerweise um typische System-Exporter und im Fall von Mattermost auch um den PostgreSQL-Exporter.

Wir sehen: Nicht alles, was sich Open Source nennt, ist auch "offen" einsehbar, mit Mattermost als Negativbeispiel. Dennoch muss der Admin natürlich nicht im Dunkeln tappen. Teil 2 zeigt praxisnahe Dashboards und sinnvolles Altering mit Grafana und Prometheus.

(jp)