Der Matomo Cronjob

Wenn du dich für diese Variante interessierst, gehe ich davon aus, dass du Erfahrung mit SSH und der Kommandozeile auf Unix/Linux-Servern hast. Der Crontab-Eintrag sollte mindestens einmal stündlich ausgeführt werden und muss natürlich den Pfad zum PHP-Interpreter und dann den absoluten Pfad bis zum Matomo-Verzeichnis und darin das Script "console" ausführen. Wie du vielleicht bei den vorherigen Beispielen gesehen hast, müssen dann noch der Befehl "core:archive" und der Domainname deiner Matomo-Installation folgen. Alles in allem könnte der Befehl für die crontab wie folgt aussehen:

5 * * * * www-data /usr/bin/php /path/to/matomo/console core:archive --matomo-domain=data.example.org

Anstelle von www-data musst du bitte den User verwenden, der auch für die Ausführung über den Webserver verwendet wird. Andernfalls kann es zu Fehlern in den Zugriffsrechten kommen, denn bei der Archivierung werden verschiedene Templates erneuert und auch ggf. der Matomo-Tag-Manager-Code neu geschrieben. Wenn das mit den falschen Zugriffsrechten passiert, wirst du regelmäßig Fehler in Matomo sehen.

Die Angabe /usr/bin/php muss durch den korrekten PHP-Interpreter mit der gleichen Version ersetzt werden, unter der auch der Webserver läuft.

Und die Angabe /path/to/matomo/console muss der vollständige Pfad zum Verzeichnis von Matomo incl. der ausführbaren Dateien "console" sein.

Die nachfolgenden Parameter hast du bereits weiter oben kennengelernt. Diese Angaben sind ebenfalls nur als Mindestangaben anzusehen und können durch viele weitere Parameter ergänzt werden.

Tipp: Wenn du dir unsicher mit den Pfaden bist, dann schau mal am Ende der Seite! Dort habe ich ein PHP-Skript zur Ermittlung deiner Cronjob-Details bereitgestellt.

Wenn der Cronjob keinen lokalen Befehl ausführen kann, bleibt häufig nur der Gedanke an einen Web-Cronjob mit einem Authentifizierungstoken (Access-Token) aus Matomo. Aber das ist nicht notwendig. Du kannst ein simples PHP-Skript erstellen, welches den Befehl lokal ausführt. Damit erspart man sich das Sicherheitsrisiko des Access-Tokens und kann entspannt die Archivierung durchführen lassen.

Leider hat diese Variante auch seine Schattenseiten. Diese liegen in den möglichen Begrenzungen des Providers hinsichtlich der Ausführungszeit von PHP-Seiten. Es kommt also im Fall der Fälle auf einen Versuch an. Bei All-Inkl.com habe ich mit dieser Lösung bislang gute Erfahrungen gemacht.

Das PHP-Script sieht wie folgt aus:

<?php

$cmd = "/usr/bin/php83 /www/htdocs/example/matomo/console core:archive --matomo-domain=data.example.org";
system($cmd);

Hinweis: Der Codeblock ist breiter, als er angezeigt wird.

Kopiere den gesamten Code in eine Text-Datei und speichere diese unter dem Namen "cronjob.php" oder "matomo-archivierung.php" ab. Diese Datei musst du dann auf deinen Webserver übertragen und kannst diese sodann über einen normalen Webseiten-Aufruf ausführen lassen.

Vorher musst du aber noch ein paar Änderungen vornehmen:

Der Teil /usr/bin/php83 gibt den Pfad und den PHP-Interpreter aus. Hier musst du ggf. bei deinem Provider die Angabe prüfen.

Der Teil /www/htdocs/example/matomo/console ist der Pfad bis zum Programm "console". Auch diesen Pfad musst du entsprechend anpassen. Wenn du nicht weißt, wo sich deine Matomo-Installation befindet, schau mal am Ende der Seite in die Tipps & Tricks. Dort findest du ein PHP-Skript, das dir bei diesen Angaben hilft.

Hinter dem Wort "console" müssen dann zumindest die folgenden Angaben ergänzt werden.

core:archive --matomo-domain=data.example.org

Bitte ersetze data.example.org durch den Hostnamen deiner Matomo-Installation. Hier siehst du nur die notwendigen Angaben. Es gibt noch viele weitere Argumente, die weiter unten vorgestellt werden.

Nachfolgend findest du ein paar Tipps & Tricks rund um die automatische Archivierung für Matomo. Wenn du etwas vermisst, dann schreib mir gerne eine E-Mail. Ich werde diese Liste sicherlich immer wieder mal erweitern.

In allen oben genannten Einstellungen fehlt eine möglicherweise wichtige Ergänzung!

Während der Archivierung erzeugt Matomo hilfreiche Debug-Ausgaben. Daher solltest du überlegen, die Ausgaben der Archivierung in einer Logdatei zu speichern. Wenn es Probleme bei der Archivierung gibt, kannst du dann hervorragend aus dieser Logdatei wichtige Informationen erhalten.

Warum habe ich das aber in den Beispielen oben unterschlagen, wenn es doch so wichtig ist? Naja: bei den allermeisten Installationen wird nie in das Logdatei geschaut und Probleme damit gar nicht erst gesehen. Und wenn man dann das Logfile bei jeder stündlichen Ausführung einfach überschreibt, dann sieht man nur die Fehler bei der letzten Ausführung. Was ist aber mit den Fehlern, die vor 5 oder vor 36 Stunden aufgetreten sind? Sind diese egal? Nope. Auch die können sehr wichtig sein.

Daher solltest du die Archivierung immer konsequent in deine Prozesse einbeziehen und die Logdatei immer fortschreiben, aber dann auch eine automatische Prüfung der Inhalte des Logfiles etablieren.

Wenn das alles für dich gerade böhmische Dörfer sind, dann lass es. Ignoriere diesen Hinweis und bleib einfach bei den Einstellungen, die ich oben beschrieben habe. Wenn du aber wirklich Wert auf deine Daten in Matomo legst, dann solltest du die Ausgabe mit >> an eine Datei leiten. Diese beiden Zeichen >>, an die obigen Parameter angehängt und mit dem Namen der Logdatei (natürlich dem kompletten Pfad) ergänzt, bewirkt, dass die Datei immer weiter ergänzt wird. Aber Achtung: Diese Datei wird nach kurzer Zeit einige MB groß und kann schnell auch die Grenze von 1 GB überschreiten! Daher muss diese Logdatei auch regelmäßig rotiert werden.

P.S. Wenn du auf diesen ganzen Kram keine Lust hast, dann sollten wir über meinen Update-Service sprechen. Buche dazu sehr gerne ein unverbindliches Erstgespräch mit mir.

Wenn du auf der Konsole den Befehl:

php console help core:archive

ausführst, dann werden dir viele weitere Parameter, die man im Rahmen der Archivierung verwenden kann, angezeigt.

Erwähnenswert ist die Option "--url", welche häufig anstelle der von mir verwendeten "--matomo-domain" verwendet wird. Seit Matomo 5 wird eher die von mir verwendete Option genutzt. Aber du kannst genauso "--url" verwenden, wenn dir das lieber ist.

Eine weitere wichtige Option kann "--concurrent-archivers" sein. Hiermit kannst du die Anzahl der zeitgleichen Archivierungen beeinflussen. Im Standard ist dieser Wert auf 3 gesetzt. In den meisten Instanzen wird das ausreichen. Bei größeren Installationen mit vielen Tausenden von Zugriffen pro Stunde kann die Archivierung auch mal länger als 60 Minuten dauern, dann hilft ein paralleler Einsatz mehrerer Archivierungsprozesse.

Witzig finde ich, dass bei der Ausgabe der Hilfe weiterhin von Piwik und nicht von Matomo gesprochen wird. Der Namenswechsel ist 2018 erfolgt und noch immer verfolgt uns Piwik auf Schritt und Tritt.

Hier folgt nun die Ausgabe der Hilfe mit dem obigen Befehl. Bitte beachte, dass der folgende Textblock breiter als die Anzeige ist. Du darfst gerne nach rechts scrollen.

Description:
  Runs the CLI archiver. It is an important tool for general maintenance and to keep Piwik very fast.

Usage:
  core:archive [options]

Options:
--url=URL                                                            Forces the value of this option to be used as the URL to Piwik.
                                                                     If your system does not support archiving with CLI processes, you may need to set this in order for the archiving HTTP requests to use the desired URLs.
--skip-idsites[=SKIP-IDSITES]                                        If specified, archiving will be skipped for these websites (in case these website ids would have been archived).
--skip-all-segments                                                  If specified, all segments will be skipped during archiving.
--force-idsites[=FORCE-IDSITES]                                      If specified, archiving will be processed only for these Sites Ids (comma separated)
--skip-segments-today                                                If specified, segments will be only archived for yesterday, but not today. If the segment was created or changed recently, then it will still be archived for today and the setting will be ignored for this segment.
--force-periods[=FORCE-PERIODS]                                      If specified, archiving will be processed only for these Periods (comma separated eg. day,week,month,year,range)
--force-date-last-n[=FORCE-DATE-LAST-N]                              Deprecated. Please use the "process_new_segments_from" INI configuration option instead.
--force-date-range[=FORCE-DATE-RANGE]                                If specified, archiving will be processed only for periods included in this date range. Format: YYYY-MM-DD,YYYY-MM-DD
--force-idsegments=FORCE-IDSEGMENTS                                  If specified, only these segments will be processed (if the segment should be applied to a site in the first place).
                                                                     Specify stored segment IDs, not the segments themselves, eg, 1,2,3.
                                                                     Note: if identical segments exist w/ different IDs, they will both be skipped, even if you only supply one ID.
--concurrent-requests-per-website[=CONCURRENT-REQUESTS-PER-WEBSITE]  When processing a website and its segments, number of requests to process in parallel [default: 3]
--concurrent-archivers[=CONCURRENT-ARCHIVERS]                        The number of max archivers to run in parallel. Depending on how you start the archiver as a cronjob, you may need to double the amount of archivers allowed if the same process appears twice in the `ps ex` output. [default: 3]
--max-websites-to-process=MAX-WEBSITES-TO-PROCESS                    Maximum number of websites to process during a single execution of the archiver. Can be used to limit the process lifetime e.g. to avoid increasing memory usage.
--max-archives-to-process=MAX-ARCHIVES-TO-PROCESS                    Maximum number of archives to process during a single execution of the archiver. Can be used to limit the process lifetime e.g. to avoid increasing memory usage.
--stop-processing-after[=STOP-PROCESSING-AFTER]                      Number of seconds how long a job is allowed to start new archiving processes. When limit is reached job will wrap up after finishing current processes. [default: 86400]
--disable-scheduled-tasks                                            Skips executing Scheduled tasks (sending scheduled reports, db optimization, etc.).
--accept-invalid-ssl-certificate                                     It is _NOT_ recommended to use this argument. Instead, you should use a valid SSL certificate! 

Wie heißt es so schön: kein Backup, kein Mitleid!

Wenn du bereits dabei bist, einen automatisierten Prozess anzulegen, dann solltest du dir auch gleich Gedanken über das Backup deiner Datenbank machen.
Ich hatte gerade erst vor kurzem wieder den Fall, dass man sich auf das Backup des Providers verlassen hat, und dieses dann leider doch nicht funktionierte.

Von einer MySQL-Datenbank kann man sehr einfach ein Backup über die Kommandozeile mit dem Befehl mysqldump ausführen. Ich erstelle dafür gerne ein kleines Shellscript, dass ich dann ähnlich die den Cron für Matomo einrichte, aber das nur einmal am Tag.

Der Befehl, den ich verwende, lautet wie folgt:

mysqldump --add-drop-table --lock-tables=false -h localhost -u USER -p'PASS' DBNAME > backupdir/matomo.sql

Natürlich darfst du hier die Angaben USER durch den Datenbanknutzer, das PASS durch das Passwort und DBNAME durch den Namen der Datenbank ersetzen.
Sinnvollerweise ergänzt man das dann noch durch die Komprimierung der SQL-Datei und vielleicht auch durch ein dynamisches Datum, damit man den letzten Dump nicht durch den aktuellen überschreibt.

Die Angabe mit "add-drop-table" nutze ich, damit ich beim Import die alte Datenbank nicht ggf. zuvor löschen muss. Ich bin da etwas faul :-)
Die Angabe "lock-tables" bewirkt, dass während des Backups die Datenbank nicht blockiert wird. Das sollte man aber vorsichtig nutzen, denn dadurch kann das Backup im Zweifelsfall inkonsistent sein. Aber wenn deine Datenbank sehr groß ist, dann kann der Prozess des Backups auch gerne mal 10 oder 20 Minuten dauern. Und in dieser Zeit wird dann Matomo ggf. keine Daten erfassen. Daher denke auch sehr gerne über eine Datenbank-Replikation nach.