OTOBO / Znuny – Optimización del Rendimiento

En esta guía detallada, abordamos todos los niveles relevantes para una instalación de OTOBO o Znuny escalable y de alto rendimiento:

1. Módulos de índice para colas de tickets
2. Búsqueda de texto completo y documentos (interna y Elasticsearch)
3. Backends de almacenamiento de artículos (DB vs. FS)
4. Archivado de tickets
5. Caché (Redis, Ramdisk)
6. Ajuste de la base de datos (MySQL/MariaDB)
7. Hardware e infraestructura
8. Automatización (Cron, scripts de Docker-Compose)
9. Monitoreo y alertas

1. Módulo de índice de tickets

1.1 RuntimeDB (Estándar)

• Módulo: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Funcionamiento: Consultas dinámicas directas en la tabla ticket
• Ámbito de uso: Hasta ~60k tickets abiertos sin latencia apreciable
• Métrica: Tiempo de consulta ∝ Número de tickets ➔ aumento lineal

1.2 StaticDB (Alta escala)

• Módulo: Kernel::System::Ticket::IndexAccelerator::StaticDB

• Funcionamiento: Tabla ticket_index precompilada con columnas de tokens (asunto, estado, propietario, etc.)

• Ámbito de uso: >80k tickets abiertos, tiempos de consulta constantes

• Indexación inicial:

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

• Ejemplo de Cron: Rebuild diario a las 02:30 horas

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

• Consejos de optimización:

  • Rebuilds de parte automática solo para colas modificadas (opción de SysConfig)
  • Monitoreo del tiempo de ejecución: medir mediante el comando time

2. Búsqueda de texto completo y documentos

2.1 Índice de texto completo interno

• Comando para rebuild:

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

• SysConfig recomendada:

  Configuración	Valor	Propósito
  Ticket::SearchIndex::IndexArchivedTickets	0 (desactivado)	Excluir tickets archivados
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indexar los primeros 1000 palabras
  Ticket::SearchIndex::Filters	Estándar	Filtro de regex para caracteres especiales
  Ticket::SearchIndex::StopWords###Custom	de, en	Agregar stopwords personalizados

• Ejemplo de filtro (SysConfig bajo Filters):

  s#[,\&<>?"!*\|;\[\]()\+\$\^=]# #g   # Eliminar caracteres especiales
  s#\b\S{1,2}\b##g                       # Eliminar palabras <3 caracteres

2.2 Elasticsearch (opcional)

Para grandes cantidades de datos (>10M artículos) se recomienda Elasticsearch.

2.2.1 Tamaño de la pila JVM

# jvm.options
-Xms4g
-Xmx4g

• Establecer Min = Max para minimizar pausas de GC
• Max ≤ 50% de la RAM física

2.2.2 Marcas de agua de 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 para la asignación de shards
• flood_stage establece índices en modo de solo lectura

2.2.3 Optimizaciones de mapeo

• Tipo keyword para campos poco modificados (p. ej., IDs de tickets)
• text + analyzer para texto libre

3. Backends de almacenamiento de artículos

Backend	Ubicación de almacenamiento	Uso
DB	MySQL/MariaDB	< 10k archivos adjuntos, servidor único
FS	FS local / NFS / SAN	≥ 10k archivos adjuntos, multi-servidor, alta IOPS

3.1 Cambio DB ↔ FS

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

• Verificar /opt/otobo/var/log/article_storage.log
• Prestar atención a los permisos: usuario otobo (UID 1000)

4. Archivado de tickets

Reduce los registros de datos indexados activos.

1. SysConfig: Ticket::ArchiveSystem = 1

2. Trabajo de GenericAgent:

   • Límite: máximo 5000 tickets por ejecución
   • Filtro: Estado = cerrado Y Modificado < ahora-6meses

3. Cron (semanal, lunes 4:00 horas):

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

5. Caché

5.1 Caché de Redis

1. Instalación:

   yum install redis
   systemctl enable --now redis

2. Módulo de 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 para /opt/otobo/var/tmp

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

6. Ajuste de la base de datos (MySQL/MariaDB)

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

[mysqld]
innodb_buffer_pool_size = 12G        # 60% de 20G de RAM
innodb_log_file_size    = 1G         # transacciones grandes
innodb_flush_log_at_trx_commit = 2   # Equilibrio de rendimiento y OCR
max_connections         = 500       # agentes y API esperados
thread_cache_size       = 50        # Reutilización de hilos
query_cache_type        = 0         # Desactivado (obsoleto)

• Benchmarck: TPC-C o sysbench para pruebas de carga

7. Hardware e infraestructura

• CPU: ≥ 8 núcleos para paralelismo
• RAM: Suficiente para el grupo de bases de datos + JVM + cachés
• Almacenamiento: Discos NVMe-SSD en RAID10 (≥ 10k IOPS)
• Red: 10 GbE entre frontend y base de datos
• Balanceador de carga: HAProxy o NGINX con comprobaciones de estado

8. Automatización y scripts de respaldo

8.1 Respaldo de Docker-Compose

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

#!/usr/bin/env bash
set -euo pipefail
FECHA=$(date +"%Y%m%d_%H%M%S")
COMPOSE_FILE=/opt/otobo-docker/compose.yml
# Detener para consistencia
docker compose -f "$COMPOSE_FILE" down
# Volúmenes y volcado de base de datos
tar -czf "/backups/volumes_$FECHA.tar.gz" /var/lib/docker/volumes
mysqldump --single-transaction --quick --user=otobo --password="\$OTC_DB_PASS" otobo > "/backups/db_$FECHA.sql"
# Iniciar
docker compose -f "$COMPOSE_FILE" up -d
echo "Respaldo $FECHA completado"

Cron (cada hora):

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

8.2 Limpieza de respaldos antiguos

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

Cron: diario a la 1:00 horas

9. Monitoreo y alertas

• Exportador de Prometheus: métricas de otobo-agent (tiempo de respuesta, profundidad de cola)

• Panel de Grafana:

  • Latencia de consulta (percentil 95)
  • Hits de caché de Redis vs. fallos
  • Uso del grupo de buffers de InnoDB
  • Estado de shards de Elasticsearch

• Reglas de alerta:

  • Consultas lentas > 200 ms durante > 5 minutos
  • Marca de agua de disco > 90%
  • Pausas de heap > 100 ms
  • Conexiones de base de datos > 80% de max_connections

Conclusión

Con este plan de optimización de rendimiento integral en los niveles de índice, búsqueda, almacenamiento, caché, base de datos e infraestructura, logra una plataforma OTOBO/Znuny estable y rápida que escala sin problemas incluso con millones de tickets y artículos.