2.8 KiB

Raw Blame History

MANUAL TÉCNICO - PLANEJAMENTO DE INFRAESTRUTURA E SIZING - ZAMMAD

Código: ITGENG 0001/26 | Classificação: INTERNO Responsável: João Pedro Toledo Gonçalves | Data: {{DATA_ATUAL}}

1. HISTÓRICO DE REVISÃO

Data	Versão	Descrição	Autor
{{DATA_ATUAL}}	1.0	Criação Inicial	João Pedro Toledo Gonçalves

2. OBJETIVO

Definir especificações de hardware e ajustes de kernel para garantir performance do Zammad (particularmente do Elasticsearch e PostgreSQL).

3. PRÉ-REQUISITOS

Conhecimento de Virtualização ou Docker.

4. DADOS TÉCNICOS E SIZING

Tabela de Sizing (Recomendação iT Guys)

Usuários Simultâneos	Tickets/Dia	CPU (vCores)	RAM (Total)	RAM (Elastic)	Disco (NVMe)
Pequeno (Até 5)	< 50	2 vCores	6 GB	1 GB	40 GB
Médio (Até 20)	50-200	4 vCores	8 GB	2 GB	80 GB
Grande (Até 50)	200-1000	8 vCores	16 GB	4 GB	160 GB
Enterprise (> 50)	> 1000	16 vCores	32 GB	8 GB	500 GB

!!! warning "Atenção: Elasticsearch é Faminto" O Zammad pode rodar com 4GB, mas sofrerá OOM Kills se o Elastic não for limitado.

Ajustes Críticos de Kernel (Host)

Para qualquer instalação (Docker ou Package), o Host deve ter:

# Aumentar contagem de mapas de memória (Obrigatório para Elastic)
sysctl -w vm.max_map_count=262144

# Aumentar limite de conexões
sysctl -w net.core.somaxconn=1024

Configuração de Postgres (Tuning)

Em ambientes com muitos agentes, o padrão de conexões (100) pode esgotar.

Arquivo: postgresql.conf
Parâmetro: max_connections
Cálculo: Agentes x 3 + Scheduler + Webserver
- Recomendado: 200 para ambientes Médios.

5. SOLUÇÃO DE PROBLEMAS (TROUBLESHOOTING)

!!! warning "Pânico: Lentidão Extrema" O sistema não cai, mas demora 10s para abrir um ticket.

Problema 1: CPU em 100% constante (Indexing)

Causa: O Elasticsearch está reconstruindo o índice ou sofrendo GC (Garbage Collection).
Diagnóstico:
```
curl localhost:9200/_cluster/health?pretty
```
Se estiver red, ele está falhando. Se yellow com relocating_shards, está trabalhando.

Problema 2: Zammad lento na busca

Causa: Disco magnético (HDD).
Solução: O Zammad EXIGE Baixa Latência de IO. Mova para SSD/NVMe.

Problema 3: Erro 502 frequente

Causa: O Puma (Rails Server) está reiniciando por falta de RAM.
Log: dmesg | grep -i kill (Procure por OOMKiller).
Solução: Adicione Swap ou aumente a RAM da VM.

6. VALIDAÇÃO DE PERFORMANCE

O tempo de carregamento do Dashboard é < 2 segundos?
A busca de tickets retorna resultados em < 1 segundo?

2.8 KiB Raw Blame History