OTOBO / Znuny – Otimização de Desempenho

Neste guia aprofundado, abordaremos todos os níveis relevantes para uma instalação escalável e de alto desempenho do OTOBO ou Znuny:

1. Módulos de Índice para Filas de Tickets
2. Pesquisa de Texto Completo e Documentos (Interna e Elasticsearch)
3. Backends de Armazenamento de Artigos (DB vs. FS)
4. Arquivamento de Tickets
5. Cache (Redis, Ramdisk)
6. Otimização de Banco de Dados (MySQL/MariaDB)
7. Hardware e Infraestrutura
8. Automação (Scripts Cron, Docker-Compose)
9. Monitoramento e Alertas

1. Módulo de Índice de Tickets

1.1 RuntimeDB (Padrão)

• Módulo: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Funcionalidade: Consultas dinâmicas diretamente na tabela ticket
• Área de Aplicação: Até ~60k tickets abertos sem latência perceptível
• Métrica: Tempo de Consulta ∝ Número de Tickets ➔ aumento linear

1.2 StaticDB (Alta Escala)

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

• Funcionalidade: Tabela ticket_index pré-compilada com colunas de token (Assunto, Status, Proprietário e muito mais)

• Área de Aplicação: >80k tickets abertos, tempos de consulta constantes

• Indexação Inicial:

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

• Exemplo de Cron: Rebuild diário às 02:30

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

• Dicas de Otimização:

  • Rebuilds parciais automáticos apenas para filas alteradas (opção SysConfig)
  • Monitoramento do tempo de execução: medir via comando time

2. Pesquisa de Texto Completo e Documentos

2.1 Índice Interno de Texto Completo

• Comando para Rebuild:

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

• SysConfig Recomendado:

  Configuração	Valor	Propósito
  Ticket::SearchIndex::IndexArchivedTickets	0 (desligado)	Excluir tickets arquivados
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indexar as primeiras 1000 palavras
  Ticket::SearchIndex::Filters	Standard	Filtros Regex para caracteres especiais
  Ticket::SearchIndex::StopWords###Custom	de, en	Adicionar Stopwords personalizados

• Exemplo de Filtro (SysConfig em Filters):

  s#[,\&<>?"!*\|;\[\]()\+\$\^=]# #g   # Remover caracteres especiais
  s#\b\S{1,2}\b##g                       # Excluir palavras com <3 caracteres

2.2 Elasticsearch (opcional)

Para grandes volumes de dados (>10M de artigos), o Elasticsearch é recomendado.

2.2.1 Tamanho do Heap da JVM

# jvm.options
-Xms4g
-Xmx4g

• Defina Min = Max para minimizar pausas do GC
• Max ≤ 50% da RAM física

2.2.2 Limiares 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 alocação de shards
• flood_stage define índices como somente leitura

2.2.3 Otimizações de Mapeamento

• Tipo keyword para campos raramente alterados (por exemplo, IDs de ticket)
• text + analyzer para texto livre

3. Backends de Armazenamento de Artigos

Backend	Local de Armazenamento	Aplicação
DB	MySQL/MariaDB	< 10k anexos, Servidor Único
FS	FS local / NFS / SAN	≥ 10k anexos, Multi-Servidor, IOPS altas

3.1 Troca DB ↔ FS

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

• Verifique /opt/otobo/var/log/article_storage.log
• Preste atenção às permissões: usuário otobo (UID 1000)

4. Arquivamento de Tickets

Reduz os conjuntos de dados indexados ativamente.

1. SysConfig: Ticket::ArchiveSystem = 1

2. Configure um Job GenericAgent:

   • Limite: máximo de 5000 tickets por execução
   • Filtro: State = close E Changed < now-6mon

3. Cron (semanalmente Seg 4:00):

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

5. Cache

5.1 Cache Redis

1. Instalação:

   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
# Adicionar ao /etc/fstab:
tmpfs /opt/otobo/var/tmp tmpfs nodev,nosuid,noexec,size=8G 0 0

6. Otimização de Banco de Dados (MySQL/MariaDB)

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

[mysqld]
innodb_buffer_pool_size = 12G        # 60% de 20G de RAM
innodb_log_file_size    = 1G         # transações grandes
innodb_flush_log_at_trx_commit = 2   # Equilíbrio Performance/ACID
max_connections         = 500       # Agentes + API esperados
thread_cache_size       = 50        # Reutilização de threads
query_cache_type        = 0         # desativado (obsoleto)

• Benchmark: TPC-C ou sysbench para testes de carga

7. Hardware e Infraestrutura

• CPU: ≥ 8 Cores para paralelismo
• RAM: Suficiente para pool de DB + JVM + Caches
• Armazenamento: NVMe SSDs em RAID10 (≥ 10k IOPS)
• Rede: 10 GbE entre Frontend e DB
• Balanceador de Carga: HAProxy ou NGINX com Health-Checks

8. Automação e Scripts de Backup

8.1 Backup 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
# Parar para consistência
docker compose -f "$COMPOSE_FILE" down
# Volumes e dump do 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 "Backup $DATE concluído"

Cron (horário):

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

8.2 Limpeza de Backups Antigos

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

Cron: diariamente às 1:00

9. Monitoramento e Alertas

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

• Dashboard Grafana:

  • Latência de Consulta (percentil 95)
  • Acertos vs. Erros do Cache Redis
  • Uso do InnoDB Buffer Pool
  • Status do Shard Elasticsearch

• Regras de Alerta:

  • Consultas Lentas > 200 ms por > 5 min
  • Limiar de Disco > 90%
  • Pausas de Heap > 100 ms
  • Conexões de DB > 80% de max_connections

Conclusão

Com este plano abrangente de otimização de desempenho nos níveis de índice, pesquisa, armazenamento, cache, banco de dados e infraestrutura, você alcançará uma plataforma estável e rápida no OTOBO/Znuny, que escala suavemente mesmo com milhões de tickets e artigos.