OTOBO / Znuny – Otimização de Desempenho

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

1. Módulos de Índice para filas de tickets
2. Pesquisa de texto completo e de 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 (Cron, Scripts de 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
• Funcionamento: Consultas dinâmicas diretamente na tabela ticket
• Área de atuação: Até ~60k tickets abertos sem latência perceptível
• Métrica: Tempo de consulta ∝ Número de tickets ➔ aumento linear

1.2 StaticDB (Escala Alta)

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

• Funcionamento: Tabela ticket_index pré-compilada com colunas de token (Assunto, Status, Proprietário, etc.)

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

• Índice 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 automáticos parciais apenas para filas alteradas (Opção de SysConfig)
  • Monitoramento do tempo de execução: medir via comando time

2. Pesquisa de Texto Completo e de Documentos

2.1 Índice de Texto Completo Interno

• Comando para Rebuild:

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

• SysConfig Recomendada:

  Configuração	Valor	Propósito
  Ticket::SearchIndex::IndexArchivedTickets	0 (desligado)	Excluir tickets arquivados
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indexar os primeiros 1000 palavras
  Ticket::SearchIndex::Filters	Padrão	Filtro de regex para caracteres especiais
  Ticket::SearchIndex::StopWords###Custom	pt, en	Adicionar stopwords personalizados

• Exemplo de Filtro (SysConfig em Filters):

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

2.2 Elasticsearch (opcional)

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

2.2.1 Tamanho do Heap da JVM

# jvm.options
-Xms4g
-Xmx4g

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

2.2.2 Marcadores de Água do 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 shard
• flood_stage define índices somente leitura

2.2.3 Otimizações de Mapeamento

• keyword-tipo para campos raramente alterados (por exemplo, IDs de tickets)
• text + analyzer para texto livre

3. Backends de Armazenamento de Artigos

Backend	Local de Armazenamento	Uso
DB	MySQL/MariaDB	< 10k anexos, servidor único
FS	FS local / NFS / SAN	≥ 10k anexos, multi-servidor, alta IOPS

3.1 Troca DB FS

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

• Verifique /opt/otobo/var/log/article_storage.log
• Atente para permissões: usuário otobo (UID 1000)

4. Arquivamento de Tickets

Reduz os registros de dados indexados ativos.

1. SysConfig: Ticket::ArchiveSystem = 1

2. Trabalho do Agente Genérico configurado:

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

3. Cron (semanal, segunda-feira, 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 do 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
# /etc/fstab adicionar:
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   # Balanceamento de desempenho/OCR
max_connections         = 500       # agentes e 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 núcleos para paralelismo
• RAM: Suficiente para pool de banco de dados + JVM + caches
• Armazenamento: NVMe-SSDs em RAID10 (≥ 10k IOPS)
• Rede: 10 GbE entre frontend e banco de dados
• Balanceador de Carga: HAProxy ou NGINX com verificações de integridade

8. Automação e Scripts de Backup

8.1 Backup do 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
# Parar para consistência
docker compose -f "$COMPOSE_FILE" down
# Volumes e dump do banco de dados
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"
# Iniciar
docker compose -f "$COMPOSE_FILE" up -d
echo "Backup $DATA concluído"

Cron (a cada hora):

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, 1:00

9. Monitoramento e Alertas

• Exportador do Prometheus: métricas do otobo-agent (Tempo de Resposta, Profundidade da Fila)

• Painel do Grafana:

  • Latência de consulta (percentil 95)
  • Cache do Redis - acertos vs. erros
  • Uso do pool de buffers do InnoDB
  • Status do shard do Elasticsearch

• Regras de Alerta:

  • Consultas lentas > 200 ms por > 5 minutos
  • Marca d'água do disco > 90%
  • Pausas do heap > 100 ms
  • Conexões de banco de dados > 80% de max_connections

Conclusão

Com este plano abrangente de otimização de desempenho em 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, escalonável mesmo com milhões de tickets e artigos.