description: > Técnicas completas y mejores prácticas para la optimización del rendimiento de su instalación de OTOBO y Znuny: Configuración, índices, módulos de almacenamiento, caché, ajuste de bases de datos y hardware, automatización y monitorización.

OTOBO / Znuny – Optimización del Rendimiento

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

1. Módulos de Índice para colas de tickets
2. Búsqueda de texto completo y de documentos (interna y Elasticsearch)
3. Backends de almacenamiento de artículos (DB vs. FS)
4. Archivo de tickets
5. Caché (Redis, Ramdisk)
6. Ajuste de la base de datos (MySQL/MariaDB)
7. Hardware e Infraestructura
8. Automatización (Scripts de Cron, Docker-Compose)
9. Monitorización 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 directamente en la tabla ticket
• Ámbito de uso: Hasta ~60k tickets abiertos sin latencia perceptible
• Métrica: Tiempo de consulta ∝ Número de tickets ➔ aumento lineal

1.2 StaticDB (Alto Rendimiento)

• 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: Reconstrucción diaria a las 02:30

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

• Consejos de optimización:

  • Reconstrucciones parciales automáticas solo para colas modificadas (opción SysConfig)
  • Monitorización del tiempo de ejecución: medir con el comando time

2. Búsqueda de Texto Completo y de Documentos

2.1 Índice de Texto Completo Interno

• Comando para Reconstrucción:

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

• SysConfig Recomendado:

  Configuración	Valor	Propósito
  Ticket::SearchIndex::IndexArchivedTickets	0 (off)	Excluir tickets archivados
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indexar las primeras 1000 palabras
  Ticket::SearchIndex::Filters	Standard	Filtros Regex para caracteres especiales
  Ticket::SearchIndex::StopWords###Custom	de, en	Añadir palabras vacías personalizadas

• 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)

Se recomienda Elasticsearch para grandes volúmenes de datos (>10M de artículos).

2.2.1 Tamaño del Heap de la JVM

# jvm.options
-Xms4g
-Xmx4g

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

2.2.2 Marcas de Agua del 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 los índices en modo de solo lectura

2.2.3 Optimizaciones de Mapeo

• Tipo keyword para campos que cambian raramente (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 adjuntos, servidor único
FS	FS local / NFS / SAN	≥ 10k adjuntos, multi-servidor, IOPS altos

3.1 Cambio DB ↔ FS

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

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

4. Archivo de Tickets

Reduce los registros indexados activamente.

1. SysConfig: Ticket::ArchiveSystem = 1

2. Configurar un trabajo de GenericAgent:

   • Límite: máximo 5000 tickets por ejecución
   • Filtro: State = close Y Changed < now-6mon

3. Cron (semanalmente Lunes 4:00 AM):

   0 4 * * 1 /opt/otobo/bin/otobo.Console.pl Maint::Ticket::Archive --criteria State:close,Changed:-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 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
# Añadir a /etc/fstab:
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 RAM
innodb_log_file_size    = 1G         # transacciones grandes
innodb_flush_log_at_trx_commit = 2   # Equilibrio rendimiento/OCR
max_connections         = 500       # Agentes + API esperados
thread_cache_size       = 50        # Reutilización de hilos
query_cache_type        = 0         # desactivado (obsoleto)

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

7. Hardware e Infraestructura

• CPU: ≥ 8 Cores para paralelismo
• RAM: Suficiente para pool de DB + JVM + cachés
• Almacenamiento: SSD NVMe en RAID10 (≥ 10k IOPS)
• Red: 10 GbE entre frontend y DB
• Balanceador de Carga: HAProxy o NGINX con comprobaciones de estado

8. Automatización y Scripts de Copia de Seguridad

8.1 Copia de Seguridad con 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
# Detener para consistencia
docker compose -f "$COMPOSE_FILE" down
# Volúmenes y volcado de 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"
# Iniciar
docker compose -f "$COMPOSE_FILE" up -d
echo "Copia de seguridad $DATE completada"

Cron (cada hora):

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

8.2 Limpieza de Copias de Seguridad Antiguas

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

Cron: diariamente a la 1:00 AM

9. Monitorización y Alertas

• Exportador de Prometheus: Métricas de otobo-agent (ResponseTime, QueueDepth)

• Panel de Grafana:

  • Latencia de consulta (percentil 95)
  • Hits vs. Fallos de caché de Redis
  • Uso del Buffer Pool de InnoDB
  • Estado de Shard de Elasticsearch

• Reglas de Alerta:

  • Consultas lentas > 200 ms durante > 5 min
  • Marca de agua del disco > 90%
  • Pausas de Heap > 100 ms
  • Conexiones a la DB > 80% de max_connections

Conclusión

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