Drupal Monitoring mit DRD

Die arocom GmbH betreibt bereits seit Jahren ihr eigenes Monitoring-System mit Icinga. Obwohl die Arbeit mit Icinga größtenteils die gewünschten Ergebnisse liefert, gibt es doch gewisse Einschränkungen und Nachteile, die sich aus dieser Nutzung ergeben.

Aus diesem Grund wurde sich auf die Suche nach einer Ergänzung bzw. Erweiterung des bestehenden Monitoring-Systems gemacht. Da die arocom GmbH ausschließlich Drupal-Projekte betreibt, fiel die Aufmerksamkeit schnell auf ein bereits existierendes Modul für Drupal 6, 7 und 8, das Drupal Remote Dashboard, oder kurz DRD.

Die Haupt-Features von DRD ließen sich u. a. durch die Dokumentation schnell in Erfahrung bringen, die tatsächlichen Möglichkeiten, die dieses Modul jedoch mit sich brachte, z. B. wie die Möglichkeiten der Erweiterung aussehen oder wie gut sich dieses Modul in das bestehende Monitoring-System der arocom GmbH eingliedern ließ, waren zunächst schwer einzuschätzen.

Trotzdem waren die Vorzeichen vielversprechend genug um die Möglichkeiten eines Drupal Monitoring Systems mit DRD und Icinga im Rahmen einer Bachelorarbeit mit dem Titel “Monitoring, Self-Service und Housekeeping mit dem Drupal Remote Dashboard” zu erörtern.

Ziele der Bachelorarbeit:

• Die Konzeption einer Zusammenarbeit zwischen Icinga und DRD

• Das Aufsetzen einer Drupal 8-Installation mit DRD:

  • Analyse der existierenden Features

  • Grundlagenschaffung für spätere Anbindung von Live-Seiten

• Die Ausarbeitung und die Implementierung eines Rollen- und Berechtigungssystems innerhalb dieser Drupal 8-Installation

• Das Implementieren verschiedener neuer Funktionalitäten sowie das “Contributing” mehrerer dieser Funktionalitäten.

Dieser Artikel fasst im Folgenden die Ergebnisse dieser Arbeit zusammen.

Das Drupal Remote Dashboard

Im Herzen ist DRD, ähnlich zu Icinga, ein Monitoring-Tool. Der Fokus liegt also in erster Linie auf der Darstellung verschiedenster Statusinformationen der überwachten Seite(n). Dabei werden größtenteils keine benutzerdefinierten Informationen eingeholt, sondern stattdessen die Informationen des Drupal Status Reports, des Monitoring-Moduls, sofern eingeschaltet, oder weiterer Quellen ausgelesen.

Aus dem Bereich des klassischen Monitorings bietet DRD, laut dessen Dokumentation, wie bereits erwähnt, aktuell Funktionen wie das Sammeln und Darstellen von Statusinformationen oder eine Übersicht über installierte Module und deren Versionen. Bei Bedarf und entsprechenden Einstellungen, gibt es auch die Möglichkeit diese Module sowie die Seite selbst von DRD aktualisieren zu lassen.

Eine der interessantesten Funktionalitäten sind jedoch die sogenannten “Actions”. “Actions” sind konfigurier- und ausführbare Code-Schnipsel, die auf überwachten Webseiten ausgeführt werden können. Durch diese “Actions” gibt es z. B. die Möglichkeit den Cache einer Seite zu leeren oder das Passwort eines Benutzers zu ändern. Neben dem Monitoring sind also auch die Automatisierung von Prozessen sowie das Steuern der überwachten Seiten elementare Funktionalitäten von DRD.

Möglich gemacht wird dieser Austausch durch ein weiteres Modul: Den DRD Agent. Dieses Modul wird im Gegensatz zu DRD nicht auf der überwachenden, sondern auf der überwachten Seite installiert. Es enthält den kompletten, auf der überwachten Seite benötigten Code, wie z. B. die Logik der einzelnen “Actions”. Bei einer Statusanfrage oder dem Ausführen einer “Action” kontaktiert DRD den DRD Agent der überwachten Seite, der den entsprechenden benötigten Code ausführt und das Ergebnis wiederum an DRD zurücksendet, wo das Ergebnis dargestellt werden kann.

Vorteile von DRD

Der aktuell größte Nachteil bei der Verwendung von Icinga ist dessen Komplexität und Andersartigkeit im Vergleich zu Drupal. Da bei der arocom GmbH ausschließlich mit Drupal entwickelt wird, liegen die Expertisen der Mitarbeiter auch eher in diesem Bereich. Das Einarbeiten in Icinga ist aus diesen Gründen sehr zeitaufwändig und auch Erweiterungen für dieses System zu schreiben, fallen immer den gleichen Mitarbeitern zu, da nur sie sich damit auskennen.

Ein großer Vorteil bei der Verwendung von DRD ist also das gegebene Drupal-Umfeld, mit dessen Regeln und Konventionen die Mitarbeiter sich bereits auskennen und so schneller in der Lage sind mit DRD zu arbeiten, sowie es bei Bedarf zu erweitern.

Auch die Art und Weise wie auf die jeweiligen Informationen zugegriffen wird, vereinfacht sich bei einer Verwendung von DRD immens. Die entsprechende Logik für benötigte Informationen kann unter der Verwendung von sämtlichen drupalinternen Funktionen geschrieben werden, was zu leichter verständlichen und weniger fehleranfälligen Lösungen führt.

Grundsätzlich lässt sich also sagen, dass der tatsächliche Reiz an DRD dessen Verbundenheit mit Drupal ausmacht, da es sämtliche Vorgänge von der Einarbeitung über die Benutzung bis zur Erweiterung vereinfacht.

Ergebnisse

Im Folgenden sollen die Ergebnisse der einzelnen Ziele dieser Arbeit zusammengefasst werden.

Zusammenarbeit von DRD und Icinga:

Die Einführung von DRD als Teil des bestehenden Monitoring-Systems, soll Icinga nicht ersetzen, stattdessen stellt es eher eine Ergänzung und eine damit verbundene Verschiebung von Aufgabenfeldern dar.

Bisher hatte Icinga sämtliche Aufgaben vom Scheduling der entsprechenden Anfragen über das Senden und Ausführen der Request bis zur Rückgabe und Darstellung der Antwort inne. Auch das Eskalieren basierend auf verschiedenen Statusinformationen war ein Teil der Aufgaben von Icinga. Die Idee ist es nun den Teil, der das Senden, das Ausführen und die Rückgabe der Anfrage darstellt, von DRD übernehmen zu lassen. Folgende Abbildung zeigt eine konzeptionelle Grafik, die die Verbindungspunkte zwischen DRD und Icinga näher beschreibt.

Die Informationen, die DRD von seinen registrierten “Hosts”, also Servern, sammelt, werden hier, anstatt direkt in DRD ausgewertet zu werden, an Icinga zurückgesendet. Dort lassen sich diese Informationen auswerten und darstellen.

Die bereits oben angesprochenen Eskalationsroutinen können auch das Ausführen einer Folgeaktion beinhalten, hier der gestrichelte Pfeil, die wiederum an DRD zurücksendet wird.

Der tatsächliche Datenaustausch zwischen DRD und Icinga soll zukünftig über “Drush”-Befehle stattfinden. Jede existierende “Action” und das Einholen der Statusinformationen in DRD lässt sich durch einen “Drush”-Befehl auslösen. Die Rückgabe dieser “Drush”-Befehle auf der DRD-Installation kann konfiguriert und von Icinga wiederum ausgelesen werden. So können alle wichtigen Informationen von Icinga angefordert, in DRD ausgelesen und zurückgesendet sowie in Icinga ausgewertet werden.

Aufsetzen einer Drupal 8-Installation mit DRD:

Das Aufsetzen einer Drupal 8-Installation mit DRD verursachte keine größeren Probleme. Zum Testen der Installation selbst und der gleich näher vorgestellten, implementierten Funktionalitäten wurden hauptsächlich andere lokale Drupal-Installationen benutzt, auf denen der DRD Agent installiert wurde.

Das Ziel war hier nicht die überwachten Live-Seiten bereits anzubinden, sondern die Grundlagen zu schaffen, so dass diese Anbindung zu einem späteren Zeitpunkt geschehen kann.

Die Ergebnisse der Analyse wurden bereits im Kapitel “Drupal Remote Dashboard” behandelt.

Ausarbeitung und Implementierung eines Rollen- und Berechtigungssystems:

Innerhalb des geplanten und in dieser Arbeit konzeptionierten Monitoring-Systems mit Drupal 8 und DRD, werden sich nach der Einführung in den Produktivbetrieb eine Vielzahl von Kunden, Benutzern und Webseiten vorfinden.

Um sicherzustellen, dass hierbei die Richtlinien des Regulariums DSGVO eingehalten werden, muss ein Rollen- und Berechtigungssystem geschaffen werden, welches den Zugriff auf oder das Ändern von Daten nur Personen gestattet, die auch die entsprechenden Berechtigungen vorweisen. Gleichzeitig soll die Konzeption dieses Berechtigungssystems immer die Skalierbarkeit von vorhandenen Benutzern und überwachten Webseiten berücksichtigen, also für verschiedene Mengen dieser Benutzer und Webseiten nicht an Funktionalität, Robustheit oder Usability verlieren.

Nach Analyse der aktuellen Berechtigungen, die DRD erlaubt seinen Benutzern zu verleihen, lassen sich die Punkte an denen nachgebessert werden muss, um die oben beschriebenen Ziele zu erreichen, grundsätzlich in zwei Punkte gliedern.

DRD selbst definiert bereits eine Reihe von Berechtigungen, die aktuell den Zugang zu “Entity Types” wie einer “Domain”, also einer Seite, basierend auf Operationen wie “View” oder “Edit” einschränken.

In DRD gibt es bei diesem Ansatz aktuell zwei Probleme: Zum einen lassen sich diese Berechtigungen nur basierend auf Rollen vergeben. Stellt man sich ein System vor in dem in Zukunft möglicherweise hunderte von Benutzern mit unterschiedlichen Berechtigungen vorzufinden sind, so müsste man im schlimmsten Fall für jeden Benutzer eine neue Rolle definieren, was sowohl in der Verwaltung, wie auch in der Übersichtlichkeit zu großen Problemen führt.

Zum anderen lassen sich diese Berechtigungen nur pro “Entity”, aber nicht pro “Entity Type” einschränken. Ein Benutzer hat also entweder Zugriff auf alle “Domains” einer Seite oder auf gar keine. Da in diesem System zukünftig die Seiten verschiedener Kunden mit jeweils unterschiedlichen Benutzern überwacht werden sollen, muss es eine Möglichkeit geben Benutzern den Zugang nur zu den “Domains” zu erlauben zu denen sie auch Zugriff haben sollten.

Als Lösung für dieses Problem wurde sich letztendlich für das “group”-Modul entschieden. “group” setzt auf sogenannte “Groups”, “Entities” in denen eine Reihe von zusätzlichen “Entities”, z. B. auch Benutzer einer Seite referenziert werden können. Der Zugriff zu den “Entities” einer “Group” ist lediglich den Benutzern gestattet, die auch selbst Mitglied der gleichen "Group" sind. Zusätzlich gibt es innerhalb von “Groups” eine zusätzliche Benutzer- und Berechtigungsverwaltung, die nur für “Entities” innerhalb einer “Group” gilt. Standardmäßig bietet das Modul jedoch keine Funktionalitäten für benutzerdefinierte “Entities”. Die Logik, die den Zugriff auf die “Entities” von DRD wie “Cores” oder “Domains” regelt, musste also noch selbst geschrieben werden. Hierfür mussten die bestehenden “AccessHandler” von DRD teilweise überschrieben werden, da es sonst keine Möglichkeiten gibt, eine eigene Zugangslogik, die auf “Groups” basiert, zu schreiben.

Alle in DRD relevanten Daten, wie die “Domains” selbst, deren einzelne Statusinformationen oder deren Server sind “Entities”. Die Lösung für den Zugang zu diesen “Entities” pro einzelner “Entity” und pro Benutzer sieht also vor, dass eine beliebige Anzahl von Benutzern, solange sie zu den gleichen “Entities” Zugang haben, zusammen mit diesen “Entities” einer “Group” zugewiesen werden. Innerhalb dieser “Group” kann durch die Vergabe von Rollen festgelegt werden welche Berechtigungen Benutzer für die einzelnen “Entities” besitzen. Die entsprechenden “Groups” kann nur der Admin einer Seite erstellen. Durch diesen Ansatz kann sichergestellt werden, dass jeder Benutzer nur Zugriff auf die “Entities” erhält, auf die er auch Zugriff haben sollte.

Die Berechtigungen für “Actions” weisen ein ähnliches Problem wie die Berechtigungen für “Entities” auf: Auch hier lassen sich die Berechtigungen um eine einzelne “Action” auszuführen nur pro Rolle und nicht pro Benutzer definieren, was bei einer großen Anzahl von Benutzern wiederholt zu den bereits oben angesprochenen Problemen führt.

Die Lösung für dieses Problem basiert auf der Tatsache, dass Benutzer innerhalb von Drupal mehrere Rollen erhalten können. Die Berechtigungen der einzelnen Rollen, die ein Benutzer erhält, werden dabei zusammengezählt und dem entsprechenden Benutzer verliehen. Erstellt man also pro existierender “Action” eine neue Rolle mit einer entsprechenden Berechtigung für diese “Action”, kann so jedem Benutzer zusätzlich zu seinen vorhandenen Rollen und Berechtigungen, diese Rolle und damit die Berechtigungen für einzelne “Actions” zugewiesen werden.

Durch das “group”-Modul und den zusätzlichen Rollen für die einzelnen “Actions” kann nun also sichergestellt werden, dass die Vorgaben der DSGVO innerhalb der DRD-Installation gewahrt bleiben.

Implementieren verschiedener neuer Funktionalitäten sowie das “Contributing” mehrerer dieser Funktionalitäten:

Im Rahmen dieser Arbeit wurden eine Reihe von eigenen Funktionalitäten geschrieben und implementiert, von denen einige auch Teil einer “Contribution” waren. Im Folgenden soll auf einige ausgewählte Funktionalitäten eingegangen werden.

Generische Kommandozeilen-Befehle:

Zu Beginn der Arbeit wurde eine Ideensammlung mit sinnvollen umzusetzenden Aufgaben erstellt. Bei einer Analyse dieser verfügbaren Aufgaben fiel auf, dass die Lösung mehrerer Aufgaben auf “Drush”-Befehlen basiert. Anstatt also für jede einzelne Anforderung eine separate “Action” hinzuzufügen, die lediglich einen “Drush”-Befehl ausführt, wurde eine Möglichkeit implementiert, die es einem Benutzer erlaubt beliebige Kommandozeilen-Befehle zu hinterlegen und später auszuführen. Diese Auswahl ist zum Zeitpunkt des Schreibens dieses Artikels jedoch auf “Drush” und “Drupal Console” limitiert. Die folgende Abbildung zeigt das Formular zum Erstellen eines solchen Kommandozeilen-Befehls:

Hierfür wurden DRD Formulare zum Hinzufügen, Editieren und Löschen solcher Kommandozeilen-Befehle sowie eine neue “Action” hinzugefügt. Bei dem Ausführen dieser “Action” erhält man eine Liste von allen existierenden Kommandozeilen-Befehlen von denen einer ausgewählt werden kann, der anschließend ausgeführt werden soll.

Diese Funktionalität ist Teil einer “Contribution”. Die entsprechende Dokumentation finden Sie hier: https://www.drupal.org/project/drd/issues/2930229.

“Action” für die Suche nach Benutzern:

Mehrere Aufgaben, die im Rahmen der Ideensammlung dieser Arbeit gesammelt wurden, benötigen eine Benutzer-ID, um zuverlässig umgesetzt werden zu können. Gerade die ID eines Benutzers ist jedoch nur durch ein Einloggen mit entsprechenden Berechtigungen auf der überwachten Seite einsehbar.

Zum Sparen von Zeit, als Grundlage für zukünftige Implementierungen und für eine generelle Grundlage Informationen über die Benutzer einer Seite einzuholen, wurde eine neue “Action” implementiert, die es einem Benutzer ermöglicht, eine Suche nach Benutzern der überwachten Seite durchzuführen.

Das aktuelle Formular dieser “Action” ist in folgendem Bild dargestellt:

Die einzelnen Felder des Formulars stellen die Suchparameter einer Datenbankabfrage auf der überwachten Seite dar. Das Ergebnis wird anschließend innerhalb der DRD-Installation angezeigt.

Diese Funktionalität ist Teil einer “Contribution”. Die entsprechende Dokumentation finden sie hier: https://www.drupal.org/project/drd/issues/2976230.

Large Assets Monitoring:

“Assets” stellen die verwendeten Dateien einer Seite in Form von Bildern, Videos, Audio-Dateien oder sonstigen Elementen dar.

Um eine bessere Übersicht über verwendete “Assets” und deren verbrauchten Speicherplatz zu erhalten, wurde eine neue “Action” implementiert, die es einem Benutzer erlaubt, die größten, im Sinne von verbrauchten Speicherplatz, “Assets” einer Seite einzusehen und zu überwachen.

Auch die Logik dieser “Action” basiert auf verschiedenen Parametern, die bei der Auswahl dieser “Action” angegeben werden können. Anschließend wird erneut eine Datenbankabfrage durchgeführt und deren Ergebnis in DRD angezeigt. Die folgende Abbildung zeigt ein beispielhaftes Ergebnis einer solchen Abfrage:

Auch hier steht die Grundlagenschaffung im Vordergrund. Eine Erweiterung dieser Funktionalität könnte z. B. eine Möglichkeit bieten, zu große Dateien zu komprimieren, anstatt sie wie aktuell nur aufzulisten.

Die Dokumentation dieser Arbeit enthält Details zu weiteren umgesetzten Implementierungen, die hier jedoch nicht näher vorgestellt werden.

Fazit

Auch wenn bereits eine Reihe von Funktionalitäten umgesetzt und implementiert wurden, ist das System immer noch mehrere Arbeitswochen von einem funktionierendem Produktivbetrieb entfernt. Gerade im Hinblick auf das bereits existierende Icinga, ist der aktuelle Mehrwert des geschaffenen Monitoring-Systems also sehr übersichtlich.

Das Ziel dieser Arbeit war es jedoch nicht ein funktionales System mit einem Mehrwert gegenüber der Ausgangslage zu schaffen. Das hauptsächliche Ziel ist stattdessen die Schaffung von Grundlagen, d. h. das Definieren und Implementieren einer robusten Basis auf der weiter aufgebaut werden kann.

Viel wichtiger, als ein bereits im Produktivbetrieb befindliches Monitoring-System, sind die Grundlagen und Erfahrungen die geschaffen und gesammelt wurden und auf denen aufbauend weitere Funktionalitäten umgesetzt werden können, die es letztendlich rechtfertigen, dieses System in den Produktivbetrieb zu überführen.

Grundsätzlich lässt sich jedoch sagen, dass die benötigten Grundlagen im Rahmen dieser Arbeit geschaffen wurden. Das Rollen- und Berechtigungssystem hat daran einen großen Anteil, da es die generelle Benutzung des Systems sicherstellt ohne die Auflagen der DSGVO zu verletzen. Auch die Konzeption der Zusammenarbeit zwischen Icinga und DRD steht bereits. Weitere implementierte Grundlagen, die in diesem Artikel nicht behandelt wurden, sind Formulare und Module, die das Hinterlegen von Variablen und Daten ermöglichen sowie eine vereinfachte Möglichkeit bieten neue Statusinformationen hinzuzufügen. Auch Funktionalitäten wie die generischen Kommandozeilen-Befehle bieten einen enormen Mehrwert, da sich mit diesem Ansatz eine ganze Reihe von Problemen angehen und lösen lassen.

Abschließend kann man also feststellen, dass das System als Ganzes zwar noch nicht bereit für den Live-Betrieb ist, die einzelnen benötigten Komponenten jedoch vorhanden sind.

Die Zukunftsfähigkeit dieses Monitoring-Systems steht und fällt somit mit der Robust- und Zuverlässigkeit der einzelnen, im Rahmen dieser Arbeit, implementierten Komponenten. Denn nur innerhalb eines Systems, welches sich durch diese Attribute auszeichnet, können letztendlich Funktionalitäten mit echtem Nutzen und Mehrwert erfolgreich implementiert, verbessert oder erweitert werden.

Interesse geweckt?

Sollte auch nach dem Lesen dieses Artikels Ihr Interesse an dieser Bachelorarbeit und einem Drupal Monitoring System noch nicht gestillt sein, laden wir sie herzlich dazu ein, selbst die komplette Bachelorarbeit zu lesen. Bei weiterem Interesse, technischen Details oder sonstigen Fragen zu dieser Bachelorarbeit können sie sich gerne an info@arocom.de wenden.