Zabbix 8.0 LTS: o que muda e como planejar a migração

Resumo executivo: o Zabbix 8.0 LTS está previsto para o terceiro trimestre de 2026 e traz mudanças estruturais — correlação avançada de eventos, novo backend de histórico e melhorias de dashboard. Quem opera 6.0 LTS precisa se mover; quem opera 7.0 LTS tem folga até 2027, mas deve planejar agora.

O contexto do ciclo de vida

O que é LTS. LTS (Long Term Support) é a linha de suporte estendido do Zabbix: recebe correções por anos, enquanto as versões padrão têm janela curta. Em produção corporativa, LTS é praticamente sempre a escolha certa.

Versão	Lançamento	Suporte completo até	Suporte limitado até	Tipo
Zabbix 6.0 LTS	fev/2022	fev/2025 (encerrado)	fev/2027	LTS
Zabbix 7.0 LTS	jun/2024	jun/2027	jun/2029	LTS
Zabbix 7.4	jul/2025	até o 8.0 LTS	Q4/2026	Padrão
Zabbix 8.0 LTS	previsto Q3/2026	Q3/2029	Q3/2031	LTS

Leitura prática da tabela. Ambiente em 6.0 LTS já está fora do suporte completo — correções funcionais não chegam mais, apenas o essencial. Ambiente em 7.4 tem janela curta e deve migrar para o 8.0. Ambiente em 7.0 LTS pode planejar com calma até meados de 2027.

O que muda no Zabbix 8.0

Correlação avançada de eventos (CEP)

O que é. CEP (Complex Event Processing) é a capacidade de avaliar relações entre múltiplos eventos em vez de tratar cada problema isoladamente.

Por que importa. É a resposta ao problema mais comum de operação madura: a tempestade de alertas. Quando um link cai, chegam 200 avisos de host inacessível. Com correlação, o operador recebe a causa e não os sintomas.

Onde aplicar primeiro. Dependência de rede (switch de borda → servidores), dependência de serviço (banco → aplicação) e janelas de manutenção.

Suporte a ClickHouse para histórico

O que é. ClickHouse é um banco colunar orientado a análise de grandes volumes. Passa a ser opção de armazenamento de histórico, ao lado de PostgreSQL e Elasticsearch.

Por que importa. Em ambientes com milhares de itens coletados por minuto, o histórico é o gargalo de custo e de desempenho. Um backend colunar melhora compressão e consulta de séries longas.

Cuidado. Adotar um segundo banco significa mais um componente para operar, monitorar e fazer backup. Só faz sentido acima de determinado volume.

Dashboards e visualização

Widget de dispersão (scatter plot). Permite cruzar duas métricas em eixos X e Y e identificar correlação ou anomalia visualmente — útil para capacidade, por exemplo, relacionando uso de CPU e latência.

Importação e exportação de dashboards pela interface. Resolve uma dor antiga: replicar painel entre ambientes sem depender de mapeamento manual de identificadores.

Agrupamento em GeoMap. Facilita operações com muitos sites geograficamente distribuídos.

Outros pontos relevantes

Armazenamento de dados em formato JSON nativo, ampliando o que pode ser coletado sem pré-processamento pesado.
Certificados SAML persistidos em banco, simplificando ambientes com múltiplos frontends.
Indicação de tags herdadas, o que reduz erro de configuração em templates.

Plano de migração: Objetivo → Ação → Resultado → Como validar

Etapa 1 — Inventário do ambiente atual

Objetivo: saber exatamente o que será migrado.
Ação: levantar versão de servidor, proxies, frontend e agentes; quantidade de hosts, itens, triggers e NVPS (novos valores por segundo); tamanho e crescimento do banco; customizações e scripts próprios.
Resultado esperado: documento com o retrato do ambiente e a lista de riscos.
Como validar: conferir os números com os painéis internos de desempenho do próprio Zabbix.

Etapa 2 — Ambiente de homologação

Objetivo: testar a migração sem risco.
Ação: restaurar uma cópia do banco de produção em ambiente isolado e executar a atualização completa, cronometrando o tempo de upgrade do banco.
Resultado esperado: tempo de janela conhecido e problemas identificados antes da produção.
Como validar: frontend abre, dados históricos aparecem e as triggers críticas disparam em teste controlado.

Etapa 3 — Compatibilidade de proxies e agentes

Objetivo: evitar perda de coleta.
Ação: confirmar a matriz de compatibilidade da versão-alvo e planejar a ordem de atualização — servidor, depois proxies, depois agentes.
Resultado esperado: nenhuma janela sem coleta em host crítico.
Como validar: relatório de itens sem dado recente logo após cada etapa.

Etapa 4 — Corte e observação

Objetivo: reduzir o tempo de exposição a falha.
Ação: executar em janela com backup íntegro e plano de retorno testado; manter observação reforçada por 72 horas.
Resultado esperado: operação estável, com volume de alertas equivalente ao período anterior.
Como validar: comparar contagem de problemas abertos por dia antes e depois.

Aproveite a migração para corrigir vícios de configuração

Templates duplicados. Ambientes antigos acumulam variações do mesmo template criadas para resolver exceções pontuais. Consolide antes de migrar — a manutenção futura agradece.

Triggers sem dono. Alerta que dispara e ninguém trata é ruído estrutural. Faça o levantamento das triggers que mais dispararam nos últimos 90 dias e decida, uma a uma: corrigir o limiar, corrigir a causa ou desativar.

Coleta desnecessária. Itens coletados a cada 30 segundos que ninguém consulta inflam banco e desempenho. Reveja intervalos com critério: disponibilidade merece coleta frequente; inventário de software, não.

Ausência de janela de manutenção. Sem períodos de manutenção configurados, cada atualização planejada gera enxurrada de alertas — e treina a equipe a ignorar avisos.

Retenção mal definida. Histórico e tendências com retenção padrão em todos os itens é a causa mais comum de banco gigante. Defina retenção por criticidade do item.

Zabbix na prática: além do “ping no servidor”

Monitoramento de serviço, não só de host. Modelar o serviço de negócio — ERP, faturamento, portal do cliente — permite responder à pergunta que a diretoria realmente faz: “o sistema está disponível para o usuário?”.
Rede e links. Coleta via SNMP em switches, roteadores e firewalls, com acompanhamento de utilização de banda, erros de interface e disponibilidade de link — base para negociar com operadora.
Ambiente físico. Temperatura de sala técnica, nobreak e sensores prediais podem ser integrados, aproximando a operação de TI da operação de facilities.
Certificados e domínios. Vencimento de certificado TLS e de domínio é causa recorrente de indisponibilidade evitável.
Backup e rotinas. Monitorar o sucesso da rotina de backup vale mais do que monitorar o servidor de backup.

Riscos e pontos de atenção

Atualizar por atualizar. Migrar sem revisar templates e triggers apenas leva o ruído atual para a versão nova. A migração é a melhor oportunidade para limpar o que não é usado.
Tempo de upgrade do banco. Em bases grandes, a conversão de esquema pode levar horas. Descobrir isso na madrugada do corte é o cenário clássico de janela estourada.
Requisitos de plataforma. Versões novas costumam elevar o mínimo de sistema operacional, PHP e banco de dados. Verifique antes de agendar.
Personalizações. Scripts de alerta, integrações via API e módulos de terceiros são os itens que mais quebram. Teste cada um em homologação.
Data de disponibilidade. A previsão oficial de lançamento do 8.0 LTS é o terceiro trimestre de 2026; datas de linha de produto podem se deslocar. Confirme na página oficial de ciclo de vida antes de fechar cronograma.
Segurança. Manter versão sem suporte completo significa conviver com correções que não chegam — o oposto do que se espera de um controle de gestão de vulnerabilidades técnicas, tema tratado no controle A.8.8 da ISO/IEC 27001:2022.

Como isso conversa com o Grafana

Divisão de papéis. Zabbix coleta, correlaciona e alerta; Grafana consolida a visualização e cruza fontes diferentes — Zabbix, banco de dados, logs, planilhas de negócio.

Ganho combinado. Com CEP no Zabbix reduzindo o ruído e painéis do Grafana traduzindo indicadores para a diretoria, a operação sai do “está tudo verde” para “o serviço X entregou 99,7% no mês e o gargalo foi o storage”.

Detalhamos essa arquitetura em nossa página de implantação de Zabbix e Grafana.

Checklist de pré-migração

Versão exata de servidor, frontend, banco de dados e PHP documentada.
Quantidade de hosts, itens, triggers e taxa de novos valores por segundo registrada.
Tamanho atual do banco e crescimento mensal medidos.
Lista completa de proxies, com versão de cada um.
Inventário de scripts de alerta, integrações via API e módulos de terceiros.
Backup íntegro, com restauração testada em ambiente separado.
Tempo de atualização do esquema cronometrado em homologação.
Janela aprovada, com plano de retorno escrito e responsável definido.
Comunicação prévia às áreas que recebem alertas.
Critério objetivo de sucesso acordado antes do corte.

Regra simples. Se algum item acima estiver em branco na véspera, adie. Migração de monitoramento feita sem rede de proteção deixa a empresa cega justamente no momento de maior risco de mudança.

Próximos passos práticos

Identifique a versão exata do seu Zabbix hoje e cruze com a tabela de ciclo de vida acima.
Meça o tamanho do banco e a taxa de coleta — são os dois números que definem a complexidade da migração.
Liste customizações e integrações; elas determinam o esforço real do projeto.
Se estiver em 6.0 LTS, trate a migração como prioridade do trimestre, não como melhoria futura.

Precisa de apoio na migração? A Brazuca Informática implanta e mantém ambientes de monitoramento em MT, GO e em todo o Brasil. Fale com nosso time para uma avaliação do seu ambiente.

Premissas assumidas: as datas de ciclo de vida seguem a política oficial publicada pela Zabbix e estão sujeitas a alteração pelo fabricante; a descrição de funcionalidades do 8.0 baseia-se em documentação de pré-lançamento e materiais de parceiros — confirme na documentação oficial da versão final antes de decidir arquitetura; não há garantia de que a data de disponibilidade geral se mantenha no trimestre previsto.