OTOBO / Znuny – Ottimizzazione delle prestazioni

In questo approfondito manuale trattiamo tutti i livelli rilevanti per un'installazione OTOBO e Znuny scalabile e performante:

1. Moduli di indice per le code dei ticket
2. Ricerca full-text e di documenti (interna e Elasticsearch)
3. Backend di archiviazione degli articoli (DB vs. FS)
4. Archiviazione dei ticket
5. Cache (Redis, Ramdisk)
6. Ottimizzazione del database (MySQL/MariaDB)
7. Hardware e infrastruttura
8. Automatizzazione (Cron, script di Docker-Compose)
9. Monitoraggio e avvisi

1. Modulo di indice del ticket

1.1 RuntimeDB (Standard)

• Modulo: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Funzionamento: Query dinamiche dirette sulla tabella ticket
• Ambito di utilizzo: Fino a ~60k ticket aperti senza latenza percepibile
• Metrica: Tempo di query ∝ Numero di ticket ➔ aumento lineare

1.2 StaticDB (High-Scale)

• Modulo: Kernel::System::Ticket::IndexAccelerator::StaticDB

• Funzionamento: Tabella ticket_index precompilata con colonne di token (Oggetto, Stato, Proprietario, ecc.)

• Ambito di utilizzo: >80k ticket aperti, tempi di query costanti

• Indicizzazione iniziale:

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

• Esempio di Cron: Rebuild giornaliero alle 02:30

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

• Suggerimenti di ottimizzazione:

  • Rebuild parziale automatico solo per le code modificate (opzione SysConfig)
  • Monitoraggio del tempo di esecuzione: misurazione tramite comando time

2. Ricerca full-text e di documenti

2.1 Indice full-text interno

• Comando per il rebuild:

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

• SysConfig consigliata:

  Impostazione	Valore	Scopo
  Ticket::SearchIndex::IndexArchivedTickets	0 (disattivato)	Escludere i ticket archiviati
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indicizzare i primi 1000 parole
  Ticket::SearchIndex::Filters	Standard	Filtro regex per caratteri speciali
  Ticket::SearchIndex::StopWords###Custom	it, en	Aggiungere parole di stop personalizzate

• Esempio di filtro (SysConfig sotto Filters):

  s#[,\&<>?"!*\|;\[\]()\+\$\^=]# #g   # Rimuovere caratteri speciali
  s#\b\S{1,2}\b##g                       # Rimuovere parole <3 caratteri

2.2 Elasticsearch (opzionale)

Per grandi quantità di dati (>10M articoli) si consiglia Elasticsearch.

2.2.1 Dimensione del heap JVM

# jvm.options
-Xms4g
-Xmx4g

• Impostare Min = Max per minimizzare le pause GC
• Max ≤ 50% della RAM fisica

2.2.2 Segnalatori di disco

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

• low/high per l'allocazione dei shard
• flood_stage imposta gli indici in sola lettura

2.2.3 Ottimizzazioni del mapping

• keyword-tipo per campi raramente modificati (ad es. ID dei ticket)
• text + analyzer per testo libero

3. Backend di archiviazione degli articoli

Backend	Posizione di archiviazione	Utilizzo
DB	MySQL/MariaDB	< 10k allegati, server singolo
FS	file system locale / NFS / SAN	≥ 10k allegati, multi-server, alta IOPS

3.1 Cambio DB ↔ FS

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

• Verificare /opt/otobo/var/log/article_storage.log
• Prestare attenzione alle autorizzazioni: utente otobo (UID 1000)

4. Archiviazione dei ticket

Riduce i record del database attivamente indicizzati.

1. SysConfig: Ticket::ArchiveSystem = 1

2. Lavoro di GenericAgent:

   • Limite: massimo 5000 ticket per esecuzione
   • Filtro: Stato = chiuso E Modificato < ora-6mes

3. Cron (settimanalmente, lunedì alle 4:00):

   0 4 * * 1 /opt/otobo/bin/otobo.Console.pl Maint::Ticket::Archive --criteria Stato:chiuso,Modificato:-6m >> /var/log/otobo/archive.log

5. Cache

5.1 Cache Redis

1. Installazione:

   yum install redis
   systemctl enable --now redis

2. Modulo 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 per /opt/otobo/var/tmp

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

6. Ottimizzazione del database (MySQL/MariaDB)

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

[mysqld]
innodb_buffer_pool_size = 12G        # 60% di 20G RAM
innodb_log_file_size    = 1G         # grandi transazioni
innodb_flush_log_at_trx_commit = 2   # Bilanciamento prestazioni/OCR
max_connections         = 500       # agenti e API attesi
thread_cache_size       = 50        # riutilizzo thread
query_cache_type        = 0         # disattivato (deprecato)

• Benchmark: TPC-C o sysbench per test di carico

7. Hardware e infrastruttura

• CPU: ≥ 8 core per parallelismo
• RAM: Sufficiente per pool di database + JVM + cache
• Storage: SSD NVMe in RAID10 (≥ 10k IOPS)
• Rete: 10 GbE tra frontend e database
• Load Balancer: HAProxy o NGINX con controlli di salute

8. Automatizzazione e script di backup

8.1 Backup di Docker-Compose

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

#!/usr/bin/env bash
set -euo pipefail
DATA=$(date +"%Y%m%d_%H%M%S")
COMPOSE_FILE=/opt/otobo-docker/compose.yml
# Fermare per coerenza
docker compose -f "$COMPOSE_FILE" down
# Volume e dump del database
tar -czf "/backups/volumes_$DATA.tar.gz" /var/lib/docker/volumes
mysqldump --single-transaction --quick --user=otobo --password="\$OTC_DB_PASS" otobo > "/backups/db_$DATA.sql"
# Avviare
docker compose -f "$COMPOSE_FILE" up -d
echo "Backup $DATA completato"

Cron (orario):

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

8.2 Pulizia dei backup obsoleti

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

Cron: giornaliero alle 1:00

9. Monitoraggio e avvisi

• Prometheus Exporter: metriche di otobo-agent (Tempo di risposta, Profondità della coda)

• Dashboard di Grafana:

  • Latenza della query (95° percentile)
  • Hit e miss della cache Redis
  • Utilizzo del pool di buffer InnoDB
  • Stato degli shard Elasticsearch

• Regole di avviso:

  • Query lente > 200 ms per > 5 min
  • Segnalatori di disco > 90%
  • Pausa del heap > 100 ms
  • Connessioni al database > 80% di max_connections

Conclusione

Con questo piano di ottimizzazione delle prestazioni completo su livelli di indice, ricerca, archiviazione, cache, database e infrastruttura, raggiungerai in OTOBO/Znuny una piattaforma stabile e veloce, che scala senza problemi anche con milioni di ticket e articoli.