OTOBO / Znuny – Optimisation des performances

Dans ce guide approfondi, nous abordons tous les niveaux pertinents pour une installation OTOBO ou Znuny évolutive et performante :

1. Module d'indexation pour les files d'attente de tickets
2. Recherche de texte intégral et de documents (interne et Elasticsearch)
3. Backends de stockage d'articles (base de données vs système de fichiers)
4. Archivage de tickets
5. Mise en cache (Redis, Ramdisk)
6. Réglage de la base de données (MySQL/MariaDB)
7. Matériel et infrastructure
8. Automatisation (Cron, scripts Docker-Compose)
9. Surveillance et alertes

1. Module d'indexation de ticket

1.1 RuntimeDB (standard)

• Module : Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Fonctionnement : Requêtes dynamiques directes sur la table ticket
• Domaine d'utilisation : Jusqu'à environ 60 000 tickets ouverts sans latence notable
• Métrique : Temps de requête ∝ Nombre de tickets ➔ augmentation linéaire

1.2 StaticDB (haute échelle)

• Module : Kernel::System::Ticket::IndexAccelerator::StaticDB

• Fonctionnement : Table ticket_index précompilée avec des colonnes de jetons (objet, statut, propriétaire, etc.)

• Domaine d'utilisation : Plus de 80 000 tickets ouverts, temps de requête constants

• Indexation initiale :

  /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild

• Exemple de Cron : Reconstruction quotidienne à 02h30

  30 2 * * * /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild --force >> /var/log/otobo/queueindex.log 2>&1

• Conseils d'optimisation :

  • Reconstructions de parties automatiques uniquement pour les files d'attente modifiées (option SysConfig)
  • Surveillance de la durée d'exécution : mesure via la commande time

2. Recherche de texte intégral et de documents

2.1 Index de texte intégral interne

• Commande de reconstruction :

  /opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndex --rebuild

• SysConfig recommandée :

  Paramètre	Valeur	Objectif
  Ticket::SearchIndex::IndexArchivedTickets	0 (désactivé)	Exclure les tickets archivés
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indexer les 1000 premiers mots
  Ticket::SearchIndex::Filters	Standard	Filtre Regex pour les caractères spéciaux
  Ticket::SearchIndex::StopWords###Custom	fr, en	Ajouter des mots vides personnalisés

• Exemple de filtre (SysConfig sous Filters) :

  s#[,\&<>?"!*\|;\[\]()\+\$\^=]# #g   # Supprimer les caractères spéciaux
  s#\b\S{1,2}\b##g                       # Supprimer les mots de moins de 3 caractères

2.2 Elasticsearch (optionnel)

Pour de grandes quantités de données (> 10 millions d'articles), Elasticsearch est recommandé.

2.2.1 Taille de la mémoire JVM

# jvm.options
-Xms4g
-Xmx4g

• Définir Min = Max pour minimiser les pauses GC
• Max ≤ 50% de la mémoire physique

2.2.2 Marques de niveau d'eau disque

cluster.routing.allocation.disk.watermark.low: "85%"
cluster.routing.allocation.disk.watermark.high: "90%"
cluster.routing.allocation.disk.watermark.flood_stage: "95%"

• low/high pour l'allocation de shard
• flood_stage définissant les index en lecture seule

2.2.3 Optimisations de mappage

• Type keyword pour les champs rarement modifiés (par exemple, ID de ticket)
• text + analyzer pour le texte libre

3. Backends de stockage d'articles

Backend	Emplacement de stockage	Utilisation
Base de données	MySQL/MariaDB	< 10 000 pièces jointes, serveur unique
Système de fichiers	système de fichiers local / NFS / SAN	≥ 10 000 pièces jointes, serveur multiple, IOPS élevés

3.1 Changement de base de données vers système de fichiers

/opt/otobo/bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS

• Vérifiez /opt/otobo/var/log/article_storage.log
• Attention aux autorisations : utilisateur otobo (UID 1000)

4. Archivage de tickets

Réduit les enregistrements de données indexés actifs.

1. SysConfig : Ticket::ArchiveSystem = 1

2. Tâche de l'agent générique :

   • Limite : maximum 5000 tickets par exécution
   • Filtre : État = fermé ET Modifié < maintenant - 6 mois

3. Cron (hebdomadaire, lundi 04h00) :

   0 4 * * 1 /opt/otobo/bin/otobo.Console.pl Maint::Ticket::Archive --criteria État:fermé,Modifié:-6m >> /var/log/otobo/archive.log

5. Mise en cache

5.1 Cache Redis

1. Installation :

   yum install redis
   systemctl enable --now redis

2. Module Perl : cpan install Redis::Fast

3. SysConfig :

   Cache::Module: Redis
   Cache::Redis###Server: 127.0.0.1:6379
   Cache::Redis###DatabaseNumber: 0
   Cache::Redis###RedisFast: 1

5.2 Ramdisk pour /opt/otobo/var/tmp

mount -t tmpfs -o size=8G tmpfs /opt/otobo/var/tmp
# /etc/fstab ajouter :
tmpfs /opt/otobo/var/tmp tmpfs nodev,nosuid,noexec,size=8G 0 0

6. Réglage de la base de données (MySQL/MariaDB)

Modifiez /etc/my.cnf.d/otobo.cnf :

[mysqld]
innodb_buffer_pool_size = 12G        # 60% de 20G de RAM
innodb_log_file_size    = 1G         # grandes transactions
innodb_flush_log_at_trx_commit = 2   # équilibre performances/OCR
max_connections         = 500       # agents et API attendus
thread_cache_size       = 50        # réutilisation de threads
query_cache_type        = 0         # désactivé (déprécié)

• Benchmarks : TPC-C ou sysbench pour les tests de charge

7. Matériel et infrastructure

• CPU : ≥ 8 cœurs pour la parallélisation
• RAM : Suffisante pour le pool de bases de données + JVM + caches
• Stockage : Disques SSD NVMe en RAID10 (≥ 10 000 IOPS)
• Réseau : 10 GbE entre le frontend et la base de données
• Load-Balancer : HAProxy ou NGINX avec des vérifications de santé

8. Automatisation et scripts de sauvegarde

8.1 Sauvegarde Docker-Compose

Script : /usr/local/bin/otobo_backup.sh

#!/usr/bin/env bash
set -euo pipefail
DATE=$(date +"%Y%m%d_%H%M%S")
COMPOSE_FILE=/opt/otobo-docker/compose.yml
# Arrêter pour la cohérence
docker compose -f "$COMPOSE_FILE" down
# Volumes et dump de base de données
tar -czf "/backups/volumes_$DATE.tar.gz" /var/lib/docker/volumes
mysqldump --single-transaction --quick --user=otobo --password="\$OTC_DB_PASS" otobo > "/backups/db_$DATE.sql"
# Démarrer
docker compose -f "$COMPOSE_FILE" up -d
echo "Sauvegarde $DATE terminée"

Cron (toutes les heures) :

0 * * * * /usr/local/bin/otobo_backup.sh >> /var/log/otobo/backup.log 2>&1

8.2 Nettoyage des anciennes sauvegardes

#!/usr/bin/env bash
find /backups -type f -mtime +7 -delete

Cron : tous les jours à 01h00

9. Surveillance et alertes

• Exportateur Prometheus : métriques otobo-agent (temps de réponse, profondeur de file d'attente)

• Tableau de bord Grafana :

  • Latence des requêtes (centile 95)
  • Hits et misses de cache Redis
  • Utilisation du pool de buffers InnoDB
  • État des shards Elasticsearch

• Règles d'alerte :

  • Requêtes lentes > 200 ms pendant > 5 minutes
  • Marque d'eau disque > 90%
  • Pausages de heap > 100 ms
  • Connexions de base de données > 80% de max_connections

Conclusion

Avec ce plan d'optimisation des performances complet sur les niveaux d'indexation, de recherche, de stockage, de mise en cache, de base de données et d'infrastructure, vous atteignez une plateforme OTOBO/Znuny stable et rapide, capable de gérer des millions de tickets et d'articles sans problème.