Caretaker - TYPO3 Monitoring vom Feinsten

CARETAKER - TYPO3 MONITORING VOM FEINSTEN

Als TYPO3 Agentur haben wir im Laufe der Jahr eine Menge Webseiten umgesetzt, die wir auch weiterhin warten, pflegen, erweitern und regelmäßig aktualisieren dürfen. Solange die Anzahl der TYPO3 Instanzen sich noch im zweistelligen Bereich einpendelt, kann es zwar schwer fallen die Übersicht zu behalten, ist aber meist noch machbar. Wer diese Grenze überschritten hat oder sich enorm viel Zeit sparen möchte, greift am Besten zum Caretaker (unser Tipp!).

Test wie "läuft der Server noch?" oder "antwortet er auch schnell genug?" können recht simpel im Auge behalten werden. Geht es um die Pflege von TYPO3 Instanzen wird es schon deutlich schwieriger. Hier kommen üblicherweise diverse Extensions zum Einsatz, die ab und an mal aktualisiert werden müssen um Bugfixes einzuspielen oder gar Sicherheitslücken zu schließen. Aber:

  • In welchen der vielen Instanzen habe ich eine solche Extension im Einsatz?
  • Welche sind überhaupt im Einsatz?
  • Und woher weiß ich überhaupt, welche Extension aktualisiert werden sollte?

Genau hier kommt der Caretaker zum Einsatz!

Während die Grundinstallation gut dokumentiert ist und auch die simple Benachrichtigung per Email an einen Administrator gleich eingerichtet ist, findet man im Netz kaum Informationen über die Konfiguration sogenannter "Advanced Notifications". In einem Beispielszenario zu dem Bild gehe ich nun auf diese ein:

Unser Kunde Mc Bömmelds (fiktiv) hat sich zwei TYPO3-Instanzen für seine öffentliche Webseite und das Intranet erstellen lassen. Dafür sind zwei Mitarbeiter als Verantwortliche abgestellt worden: Anton für die öffentliche Webseite und Bärbel das Intranet. Diese Mitarbeiter sollen informiert werden, falls den Instanzen zugewiesene Tests (nicht auf dem Bild dargestellt) fehlschlagen. Natürlich müssen auch wir auf dem Laufenden gehalten werden und setzen unseren Kontakt "Christoph" mit der Rolle "Admin" in die übergeordnete Instanzgruppe ein. Über eine entsprechende Ausstiegsstrategie legen wir fest, in welchem Fall eine Benachrichtigung ausgelöst werden soll. Hier ein Beispiel mit ein wenig Beschreibung zur Ausstiegsstrategie:

In unserer Beispielkonfiguration sind zwei Regeln für die Benachrichtigung festgelegt, "instanceError" und "instanceSuccess", die jeweils einen Exit Point ansprechen, der beispielsweise eine Email versendet. An wen, entscheidet dabei zum einen die Regel anhand der "roles" (welche Rollen benachrichtigt werden sollen) und zum anderen die Kontakte, die in der Instanz (oder auch in der Instanzgruppe) hinterlegt wurden. Beim Anlegen der Kontakte in der Instanz(-gruppe) kann die Rolle, die der Kontakt für eben DIESE Instanz(-gruppe) ausgewählt werden, wodurch sich viele Möglichkeiten der Konfiguration ergeben. So kann Kontakt Christoph der Admin für diese Instanzgruppe sein, während er bei einer anderen Instanzgruppe nur mit der Rolle des Kunden hinterlegt ist.

Was die Zustandsänderung und damit auch die Benachrichtigung letztendlich auslöst, kann sehr feingranular eingestellt werden. Die folgenden Tests sind von Haus aus möglich:

  • TYPO3 -> Extension: Darf eine bestimmte Extension installiert sein oder muss sie das sogar? In welcher Version min/max?
  • TYPO3 -> Version: Wie der Name schon sagt z.B. Minimal 7.6.latest oder Maximal 8.7.0 usw.
  • TYPO3 -> Find insecure Extensions: Bietet viele Einstellungsmöglichkeiten, unter anderem eine Extension Key Whitelist und Blacklist
  • TYPO3 -> Find Extension Updates: Auch hier wieder diverse Einstellungsmöglichkeiten wie z.B. das Ignorieren von Versionen, die nicht mit der laufenden TYPO3 version kompatibel sind
  • TYPO3 -> Check backend user accounts: Eine Blacklist mit Namen die nicht vergeben werden dürfen, z.B. admin
  • TYPO3 -> Check be-password blacklist: Überprüft anhand einer Blacklist Benutzerpasswörter und stellt Duplikate fest (nur möglich wenn ext:saltedpasswords nicht installiert ist)
  • TYPO3 -> Check TYPO3_CONF_VARS: Mächtiges Tool um die T3CV nach einem bestimmten (oder durch RegEx auch unbestimmten) Eintrag zu durchsuchen und ggf. ihren Wert zu prüfen
  • FILE -> Check path: Liste von Ordnern und/oder Dateien, die sich auf dem Zielsystem befinden sollen (oder nicht befinden dürfen) und ggf. ein bestimmtes Alter (Zeitstempel Dateisystem) aufweisen sollen
  • DISKSPACE -> wie der Name bereits sagt: Es kann der Speicherplatz einer bestimmten Partition (Pfad) mit Minimumangabe in Prozent(%) oder TB / GB / MB / kB / B geprüft werden
  • PING -> mit Angabe von zwei Toleranzwerten: Warnung ab z.B. 80ms und Error ab z.B. 250ms
  • HTTP -> Mit sehr vielen Einstellungsmöglichkeiten von BasicAuth über Status Code bis hin zu erwarteten HTTP Headern und Regular Expressions
  • Touch -> Es wird eine Datei mit aktuellem Zeitstempel abgelegt

Neben der EXT:caretaker gibt es noch zwei weitere bekannte TYPO3 Extensions, die für denselben Zweck gedacht sind:

  • t3monitor bietet ähnliche Features, hat aber zusätzlich noch eine Updatehistory, die besonders als Nachweis für den Kunden interessant sein könnte, aber (unserer Meinung) den monatlichen Preis nach Anzahl der Domains in keinster Weise rechtfertigt. Auch konnten wir nirgendwo finden, welcher "Teil der Monatsgebühr" an die TYPO3 Association gespendet wird - die wir üblicherweise sehr gern unterstützen.
  • t3monitoring - sie ist ebenfalls frei nutzbar wie der Caretaker. Der Entwickler Georg Ringer spricht lediglich eine Empfehlung zum Beitrag an der Weiterentwicklung aus, was wir eine gute Sache finden. Beim Begutachten der Extension fällt besonders das aufgeräumte und übersichtliche Backend-Modul auf. Es stellt viele Informationen zusammen, die beim Caretaker erst nach mehreren Klicks zu finden sind. Was uns hier noch fehlt ist ein Frontend-Plugin, durch welches der benachrichtigte Kunde auch selbst nachsehen kann, wie es seiner Seite im Detail geht.

Naemon, Icinga, Nagios, OMD Labs (und wie sie alle heißen), haben wir bewusst nicht zum Vergleich herangezogen. Diese Professionellen monitoring Tools bedeuten einen deutlich höheren Aufwand - angefangen bei der Einrichtung bis hin zum Hosting, und bieten nicht so viele detaillierte interne Informationen von TYPO3. Was nicht unerwähnt bleiben sollte: Für Nagios und dessen kompatible Forks gibt es ein TYPO3 Plugin.

rules {
    # frei gewählter Bezeichner 'instanceError', aber vorsicht bei der Schreibweise(!)
    instanceError {
        conditions {
            event = updatedTestResult
            # newState kann z.B. auch 'warning' sein
            newState = error
            # nur wenn der vorherige Zustand 'ok' war, aber nicht z.B. 'warning'
            previousState = ok
            # nur wenn der Zustand sich geändert hat, aber nicht wenn der Zustand weiterhin 'error' ist
            onlyIfStateChanged = 1
        }
        exit {
            # 'einerror' ist der "unique identifier" vom 'Exit Point'
            einerror {
                # 'admin' und 'kunde' sind die "unique identifier" der 'Role'
                roles = admin,kunde
            }
        }
    }
    instanceSuccess {
        conditions {
            event = updatedTestResult
            newState = ok
            previousState = error
            onlyIfStateChanged = 1
        }
        exit {
            allesok {
                roles = admin,kunde
            }
        }
    }
}

Kategorien

TYPO3 Hosting Devblog

Tags

TYPO3

Hat Dir der Artikel gefallen?

werkraum News