Optimización y escalado del rendimiento de OTOBO

Optimización y escalado del rendimiento de OTOBO

Un sistema de tickets de alto rendimiento es la base para un soporte excelente. OTOBO (especialmente a partir de la versión 11) ofrece numerosos ajustes para mantenerse extremadamente rápido incluso con volúmenes elevados de tickets (> 1 millón de artículos).

[!TIP] Quick Win: Integre OpenTicketAI. Gracias a la clasificación asistida por IA, se elimina la necesidad de mover manualmente los tickets desde la cola “Raw”. Esto no solo reduce la carga de trabajo de los agentes, sino que también evita pérdidas de rendimiento causadas por “colas de recolección” generales.

---

1. Módulos de índice de tickets

El índice determina la rapidez con la que se cargan las vistas de lista (Dashboard, vista de cola).

1.1 RuntimeDB (Estándar para instancias pequeñas)

• Módulo: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Comportamiento: Las consultas se realizan en tiempo real sobre la tabla ticket.
• Límite: Rendimiento óptimo hasta aprox. 50.000 tickets abiertos. Después, la carga aumenta notablemente con cada actualización del Dashboard.

1.2 StaticDB (Recomendado para gran escala)

• Módulo: Kernel::System::Ticket::IndexAccelerator::StaticDB
• Ventaja: Utiliza una tabla dedicada ticket_index. Las operaciones de escritura son mínimamente más lentas, pero los accesos de lectura (listas) son exponencialmente más rápidos y constantes.
• Configuración:
  1. Cambiar en la configuración del sistema.
  2. Crear el índice inicial:

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

---

2. Búsqueda e indexación (Elasticsearch)

Mientras que el índice SQL interno es suficiente para cantidades pequeñas, para grandes volúmenes de datos es indispensable utilizar Elasticsearch.

2.1 Ajuste de Elasticsearch (Contexto de Docker en OTOBO)

Si ejecuta OTOBO en Docker (recomendado para la instalación), preste atención a los ajustes de JVM en su docker-compose.override.yml:

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

• Heap Size: Establezca el Heap en un máximo del 50% de la RAM disponible (máx. 31 GB).
• Disk Watermarks: Elasticsearch cambia los índices a Read-Only cuando el espacio en disco es escaso (< 5% libre). El monitoreo es esencial aquí.

2.2 Índice de texto completo interno (SQL)

Si no utiliza Elasticsearch, limite el alcance:

• WordCountMax: Limitar a 500-1000 palabras (Ticket::SearchIndex::Attribute.WordCountMax).
• Tickets archivados: Excluirlos del índice de búsqueda para mantener el tamaño de la base de datos compacto.

---

3. Almacenamiento de datos y Backends

3.1 Almacenamiento de artículos (FS vs. DB)

De forma predeterminada, OTOBO guarda los archivos adjuntos en la base de datos (ArticleStorageDB).

• A partir de 10.000 tickets o archivos adjuntos grandes: Cambie obligatoriamente a ArticleStorageFS.
• Ventaja: La base de datos permanece pequeña y las copias de seguridad/volcados se ejecutan mucho más rápido.

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

3.2 Archivado de tickets

Archive los tickets cerrados que tengan más de 6-12 meses. Los tickets archivados no se indexan de forma predeterminada, lo que acelera masivamente el trabajo diario.

---

4. Caché y memoria

4.1 Redis (Imprescindible)

Utilice Redis como backend de caché en lugar del sistema de archivos. Redis mantiene las configuraciones y sesiones en la RAM.

• SysConfig: Establecer Cache::Module en Redis.
• Consejo de experto: Utilice Redis::Fast para latencias aún menores en entornos de alto tráfico.

4.2 Ramdisk para /opt/otobo/var/tmp

Si no utiliza Docker, mueva el directorio temporal a la RAM:

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

Acelera la generación de informes PDF y archivos temporales de artículos.

---

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

Para OTOBO 11 recomendamos los siguientes parámetros (con 16 GB+ de RAM):

[mysqld]
innodb_buffer_pool_size = 8G         # aprox. 50-60% de la RAM
innodb_log_file_size    = 1G          # importante para el rendimiento en actualizaciones masivas
innodb_flush_log_at_trx_commit = 2    # compromiso entre velocidad y seguridad de datos
max_connections         = 500

[!IMPORTANT] OTOBO 11 utiliza consultas más eficientes, pero se beneficia enormemente de una E/S rápida. Utilice exclusivamente NVMe-SSDs.

---

6. Especificidades de OTOBO 11 y Docker

OTOBO 11 está optimizado de forma nativa para Docker.

• Imágenes de contenedor: Las imágenes oficiales ya están ajustadas para el rendimiento (optimizaciones a nivel de Perl).
• Rotación de logs: A partir de la versión 11.0.11, OTOBO cuenta con una rotación de logs integrada para otobo.log. Ya no son necesarios scripts externos para este archivo de log.
• Auto-Tuning: Los contenedores suelen reconocer automáticamente los recursos disponibles, sin embargo, se deben establecer límites (mem_limit) en Docker Compose.

---

7. Monitoreo y detección temprana

No hay optimización sin datos. Recomendamos el stack de Prometheus:

1. Metrics: Captura de las métricas de OTOBO vía API.
2. Grafana: Dashboard para:
   • Latencia de peticiones (seguimiento de SLA)
   • Nivel de llenado de colas (detectar cuellos de botella)
   • Tiempos de espera de bloqueo de DB (DB-Lock-Wait-Times)
3. Alerting: Notificación cuando la tasa de aciertos de caché (Cache-Hit-Rate) cae por debajo del 90% o los shards de Elasticsearch se vuelven “amarillos”.

---

Conclusión

La optimización del rendimiento en OTOBO es una combinación de hardware, conversión de procesos (IA) y ajuste técnico fino.

Comience cambiando a Elasticsearch, implemente una estrategia de archivado y descargue a sus agentes con OpenTicketAI. De esta manera, su sistema OTOBO seguirá siendo rápido y estable incluso a medida que crezca el tamaño de su empresa.