Optimisation et mise à l'échelle des performances d'OTOBO

Performance OTOBO

Optimisation et mise à l’échelle des performances d’OTOBO

Un système de tickets performant est la base d’un excellent support. OTOBO (en particulier à partir de la version 11) offre de nombreux leviers pour rester ultra-rapide, même avec des volumes de tickets élevés (> 1 million d’articles).

[!TIP] Quick Win : Intégrez OpenTicketAI. Grâce à la classification assistée par IA, le déplacement manuel des tickets depuis la file d’attente “Raw” n’est plus nécessaire. Cela réduit non seulement la charge de travail des agents, mais évite également les pertes de performance dues aux “files d’attente de collecte” surchargées.

1. Modules d’indexation des tickets

L’index détermine la vitesse de chargement des vues de liste (tableau de bord, vue de file d’attente).

1.1 RuntimeDB (Standard pour les petites instances)

Module : Kernel::System::Ticket::IndexAccelerator::RuntimeDB
Comportement : Les requêtes sont effectuées en direct sur la table ticket.
Limite : Performant jusqu’à environ 50 000 tickets ouverts. Au-delà, la charge augmente sensiblement à chaque rafraîchissement du tableau de bord.

1.2 StaticDB (Recommandé pour les fortes charges)

Module : Kernel::System::Ticket::IndexAccelerator::StaticDB
Avantage : Utilise une table dédiée ticket_index. Les opérations d’écriture sont légèrement plus lentes, mais les accès en lecture (listes) sont nettement plus rapides et constants.
Configuration :
1. Effectuer le changement dans la configuration système.
2. Construire l’index initial :
  Fenêtre de terminal
```
/opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild
```

2. Recherche & Indexation (Elasticsearch)

Alors que l’index SQL interne suffit pour de petits volumes, l’utilisation d’Elasticsearch devient indispensable pour les grands ensembles de données.

2.1 Tuning d’Elasticsearch (Contexte Docker OTOBO)

Si vous utilisez OTOBO dans Docker (recommandé pour l’installation), faites attention aux paramètres JVM dans votre docker-compose.override.yml :

services:
  elasticsearch:
    environment:
      - ES_JAVA_OPTS=-Xms4g -Xmx4g

Heap Size : Réglez le Heap sur un maximum de 50 % de la RAM disponible (max. 31 Go).
Disk Watermarks : Elasticsearch bascule les index en mode Read-Only lorsque l’espace disque devient limité (< 5 % libre). Le monitoring est ici essentiel.

2.2 Index plein texte interne (SQL)

Si vous n’utilisez pas Elasticsearch, limitez la portée :

WordCountMax : Limitez à 500-1000 mots (Ticket::SearchIndex::Attribute.WordCountMax).
Tickets archivés : Excluez-les de l’index de recherche pour garder une taille de base de données compacte.

3. Stockage des données & Backends

3.1 Stockage des articles (FS vs DB)

Par défaut, OTOBO stocke les pièces jointes dans la base de données (ArticleStorageDB).

À partir de 10 000 tickets ou pour des pièces jointes volumineuses : passez impérativement à ArticleStorageFS.
Avantage : La base de données reste petite et les sauvegardes/dumps sont beaucoup plus rapides.

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

3.2 Archivage des tickets

Archivez les tickets fermés datant de plus de 6 à 12 mois. Les tickets archivés ne sont plus indexés par défaut, ce qui accélère considérablement le travail quotidien.

4. Caching & Mémoire

4.1 Redis (Indispensable)

Utilisez Redis comme backend de cache au lieu du système de fichiers. Redis conserve les configurations et les sessions en RAM.

SysConfig : Réglez Cache::Module sur Redis.
Conseil d’expert : Utilisez Redis::Fast pour des latences encore plus faibles dans les environnements à fort trafic.

4.2 Ramdisk pour `/opt/otobo/var/tmp`

Si vous n’utilisez pas Docker, déplacez le répertoire temporaire dans la RAM :

mount -t tmpfs -o size=4G tmpfs /opt/otobo/var/tmp

Accélère la génération de rapports PDF et les fichiers d’articles temporaires.

5. Tuning de la base de données (MariaDB/MySQL)

Pour OTOBO 11, nous recommandons les paramètres suivants (pour 16 Go+ de RAM) :

[mysqld]
innodb_buffer_pool_size = 8G         # env. 50-60 % de la RAM
innodb_log_file_size    = 1G          # important pour les performances lors de mises à jour massives
innodb_flush_log_at_trx_commit = 2    # compromis entre vitesse et sécurité des données
max_connections         = 500

[!IMPORTANT] OTOBO 11 utilise des requêtes plus efficaces, mais bénéficie énormément d’une I/O rapide. Utilisez exclusivement des SSD NVMe.

6. Spécificités d’OTOBO 11 & Docker

OTOBO 11 est optimisé nativement pour Docker.

Images de conteneurs : Les images officielles sont déjà optimisées pour la performance (optimisations au niveau de Perl).
Rotation des logs : À partir de la version 11.0.11, OTOBO dispose d’une rotation de logs intégrée pour otobo.log. Des scripts externes ne sont plus nécessaires pour ce fichier de log.
Auto-Tuning : Les conteneurs détectent souvent automatiquement les ressources disponibles, mais des limites (mem_limit) doivent tout de même être définies dans Docker Compose.

7. Monitoring & Détection précoce

Pas d’optimisation sans données. Nous recommandons la pile Prometheus :

Metrics : Récupération des métriques OTOBO via API.
Grafana : Tableau de bord pour :
- Latence des requêtes (suivi SLA)
- Remplissage des files d’attente (détection des goulots d’étranglement)
- Temps d’attente de verrouillage de la base de données (DB-Lock-Wait-Times)
Alerting : Notification si le taux de succès du cache tombe en dessous de 90 % ou si les shards Elasticsearch deviennent “jaunes”.

Conclusion

L’optimisation des performances dans OTOBO est une combinaison de matériel, de conversion des processus (IA) et de réglages techniques.

Commencez par passer à Elasticsearch, mettez en place un système d’archivage et soulagez vos agents avec OpenTicketAI. Ainsi, votre système OTOBO restera réactif et stable, même avec la croissance de votre entreprise.