OTOBO / Znuny – Optimisation des Performances

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

1. Modules d'index pour les files d'attente de tickets
2. Recherche plein texte et documentaire (interne & Elasticsearch)
3. Backends de stockage d'articles (DB vs FS)
4. Archivage des tickets
5. Mise en cache (Redis, Ramdisk)
6. Optimisation de la base de données (MySQL/MariaDB)
7. Matériel & Infrastructure
8. Automatisation (Scripts Cron, Docker-Compose)
9. Surveillance & Alertes

1. Module d'index de tickets

1.1 RuntimeDB (Standard)

• Module : Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Fonctionnement : Requêtes dynamiques directement sur la table ticket
• Domaine d'application : Jusqu'à ~60k 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 (Sujet, Statut, Propriétaire, etc.)

• Domaine d'application : >80k tickets ouverts, temps de requête constants

• Indexation initiale :

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

• Exemple Cron : Rebuild quotidien à 02:30

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

• Conseils d'optimisation :

  • Rebuilds partiels automatiques uniquement pour les files d'attente modifiées (option SysConfig)
  • Surveillance du temps d'exécution : mesure via la commande time

2. Recherche plein texte & documentaire

2.1 Index plein texte interne

• Commande pour Rebuild :

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

• SysConfig recommandé :

  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	Filtres Regex pour caractères spéciaux
  Ticket::SearchIndex::StopWords###Custom	de, 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 <3 caractères

2.2 Elasticsearch (optionnel)

Pour de grands volumes de données (>10M d'articles), Elasticsearch est recommandé.

2.2.1 Taille du tas JVM

# jvm.options
-Xms4g
-Xmx4g

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

2.2.2 Marqueurs d'eau du 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 des shards
• flood_stage met les index en lecture seule

2.2.3 Optimisations de mapping

• Type keyword pour les champs rarement modifiés (par ex. IDs de tickets)
• text + analyzer pour le texte libre

3. Backends de stockage d'articles

Backend	Emplacement de stockage	Utilisation
DB	MySQL/MariaDB	< 10k pièces jointes, serveur unique
FS	FS local / NFS / SAN	≥ 10k pièces jointes, multi-serveurs, IOPS élevés

3.1 Changement DB ↔ FS

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

• Vérifier /opt/otobo/var/log/article_storage.log
• Faire attention aux permissions : utilisateur otobo (UID 1000)

4. Archivage des tickets

Réduit le nombre d'enregistrements activement indexés.

1. SysConfig : Ticket::ArchiveSystem = 1

2. Configurer un job GenericAgent :

   • Limite : max. 5000 tickets par exécution
   • Filtre : State = close ET Changed < now-6mon

3. Cron (hebdomadaire Lun 4:00) :

   0 4 * * 1 /opt/otobo/bin/otobo.Console.pl Maint::Ticket::Archive --criteria State:close,Changed:-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
# Ajouter dans /etc/fstab :
tmpfs /opt/otobo/var/tmp tmpfs nodev,nosuid,noexec,size=8G 0 0

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

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

[mysqld]
innodb_buffer_pool_size = 12G        # 60% de 20G RAM
innodb_log_file_size    = 1G         # transactions volumineuses
innodb_flush_log_at_trx_commit = 2   # Équilibre performance/durabilité
max_connections         = 500       # Agents + API attendus
thread_cache_size       = 50        # Réutilisation des threads
query_cache_type        = 0         # désactivé (obsolète)

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

7. Matériel & Infrastructure

• CPU : ≥ 8 cœurs pour la parallélisation
• RAM : Suffisante pour le pool DB + JVM + caches
• Stockage : SSD NVMe en RAID10 (≥ 10k IOPS)
• Réseau : 10 GbE entre le frontend et la DB
• Équilibreur de charge : HAProxy ou NGINX avec Health-Checks

8. Automatisation & Scripts de sauvegarde

8.1 Docker-Compose-Backup

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êt pour la cohérence
docker compose -f "$COMPOSE_FILE" down
# Volumes & dump de la DB
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émarrage
docker compose -f "$COMPOSE_FILE" up -d
echo "Sauvegarde $DATE terminée"

Cron (horaire) :

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 : quotidien à 1h00

9. Surveillance & Alertes

• Exportateur Prometheus : Métriques otobo-agent (ResponseTime, QueueDepth)

• Tableau de bord Grafana :

  • Latence des requêtes (95ème percentile)
  • Hits vs Misses du cache Redis
  • Utilisation du buffer pool InnoDB
  • État des shards Elasticsearch

• Règles d'alerte :

  • Requêtes lentes > 200 ms pendant > 5 min
  • Marqueur d'eau du disque > 90%
  • Pauses Heap > 100 ms
  • Connexions DB > 80% de max_connections

Conclusion

Avec ce plan complet d'optimisation des performances aux niveaux index, recherche, stockage, cache, base de données et infrastructure, vous obtiendrez une plateforme OTOBO/Znuny stable et rapide, qui évolue sans problème même avec des millions de tickets et d'articles.