Matomo Auto-Hébergé Haute Fréquence : Optimiser MariaDB et Cron Archiving

En France, la CNIL accorde une exemption stricte de consentement aux solutions de mesure d’audience auto-hébergées, à condition que les adresses IP soient anonymisées et qu’aucun identifiant ne soit recoupé entre domaines tiers. Matomo On-Premise est donc devenu le standard incontournable pour les institutions publiques, médias et e-commerçants français.

Cependant, dès que le trafic franchit le cap des 100 000 pages vues par jour, la configuration par défaut de Matomo paralyse les serveurs de base de données : chaque requête de tracking déclenche des écritures synchrones dans MariaDB/MySQL, créant des verrous de tables massifs et un ralentissement critique du site audité.

Ce runbook détaille l’architecture découplée requise pour absorber des millions d’événements sans impacter l’infrastructure.

---

1. Mise en Place du Buffer Asynchrone Redis (QueuedTracking)

Au lieu d’écrire immédiatement dans les tables SQL matomo_log_visit et matomo_log_link_visit_action, le plugin officiel QueuedTracking déverse les hits dans une file d’attente mémoire Redis en microsecondes.

Installez et activez le plugin :

cd /var/www/matomo
php console plugin:activate QueuedTracking

Configurez les paramètres dans config/config.ini.php :

[QueuedTracking]
enabled = 1
notifyQueueAbove = 100000
numQueueWorkers = 4
processDuringTrackingRequest = 0
redisHost = "127.0.0.1"
redisPort = 6379
redisDatabase = 2
redisPassword = "VotreMotDePasseRedisSecurise"

Les requêtes matomo.php répondent désormais en 3ms, libérant immédiatement les connexions clientes de vos visiteurs.

---

2. Déporter le Dépilage de la File vers Systemd

Pour traiter les données accumulées dans Redis et les insérer par lots (bulk insert) dans MariaDB, créez un worker Systemd multi-processus :

# /etc/systemd/system/matomo-queued-tracking.service
[Unit]
Description=Matomo Queued Tracking Worker
After=redis-server.service mariadb.service

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/matomo
ExecStart=/usr/bin/php /var/www/matomo/console queuedtracking:process
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now matomo-queued-tracking.service

---

3. Désactiver l’Archivage Navigateur au Profit du Cron CLI

Par défaut, Matomo recalcule les rapports statistiques lorsqu’un administrateur se connecte à l’interface web (process_summary_reports_during_browser_request = 1). Si un collaborateur ouvre le tableau de bord pendant un pic de vente, MariaDB subit des requêtes d’agrégation titanesques.

Désactivez ce comportement dans config/config.ini.php :

[General]
enable_browser_archiving_triggering = 0

Ajoutez ensuite la tâche d’archivage planifiée dans /etc/cron.d/matomo-archive pour recalculer les rapports toutes les heures en arrière-plan :

# /etc/cron.d/matomo-archive
5 * * * * www-data /usr/bin/php /var/www/matomo/console core:archive --url=https://analytics.votredomaine.fr/ > /var/log/matomo-archive.log 2>&1

---

4. Réglages Noyau MariaDB InnoDB Dédiés

Dans /etc/mysql/mariadb.conf.d/50-server.cnf, adaptez le moteur InnoDB à l’ingestion massive de séries temporelles :

[mysqld]
# Allouer 70% de la RAM dédiée au moteur InnoDB
innodb_buffer_pool_size = 12G
innodb_buffer_pool_instances = 8

# Écritures par lots plus agressives
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 2G
innodb_write_io_threads = 8
innodb_read_io_threads = 8

# Désactiver les verrous inutiles sur les tables de logs
innodb_autoinc_lock_mode = 2
max_connections = 500

Redémarrez MariaDB pour appliquer :

sudo systemctl restart mariadb

---

5. Bilan de Résilience

Avec cette architecture découplée (Frontend HTTP -> Redis Buffer -> Multi-Workers Bulk Insert -> MariaDB -> Cron Archiving CLI) :

• Les serveurs frontaux encaissent plus de 4 000 hits/sec sans saturation.
• L’utilisation CPU de MariaDB passe d’un état oscillant entre 80-100% à une charge lissée inférieure à 15%.
• La conformité CNIL reste absolue grâce à l’anonymisation des adresses IP configurée sur deux octets (192.168.xxx.xxx).

---

🔗 Diagnostics Techniques & Maillage d’Architecture :

Les goulots d’étranglement d’infrastructure ne sont jamais isolés. La latence serveur, les requêtes SQL et le rendu DOM interagissent en continu :

• Schéma JSON-LD SIREN / SIRET pour le Knowledge Graph: Ancrer l’entité légale de l’entreprise dans l’index sémantique de Google.
• Optimisation du Cache Redis et Déverrouillage des Sessions PrestaShop: Résoudre les ralentissements au panier et les erreurs 504 sous fort trafic.
• Navigation à Facettes PrestaShop & Budget de Crawl: Empêcher l’indexation de millions d’URLs combinatoires par Googlebot.