Zabbix 8.0 LTS: Novidades e Caminho de Migração
O Zabbix 8.0 LTS está a chegar: a tabela oficial de ciclo de vida aponta o lançamento no Q4 de 2026 (previsão do ciclo de vida, não uma data fixa), com suporte até Q4 de 2029 mais dois anos limitados. O primeiro release candidate (8.0.0rc1) foi publicado a 1 de Outubro. Para quem corre o Zabbix 7.0 LTS, este é o ciclo de upgrade que convém planear — com particular atenção às novas versões mínimas de base de dados e ao TLS por omissão.
Neste artigo
O que muda de dentro para fora
O que a documentação oficial What’s new enumera para a 8.0:
- ClickHouse como backend — para quem tem histórico pesado, o ClickHouse entra como base de dados para armazenar item value history, com setup próprio documentado
- JSON nativo — items podem agora guardar JSON como data type próprio. Antes, JSON via items de texto com limite de 64KB. Agora são valores nativos até 128 MiB, com rejeição de JSON inválido. Em TimescaleDB é preciso criar a hypertable
history_jsonmanualmente - Failover de PostgreSQL — a lista de hosts PostgreSQL aceita múltiplos
host:portseparados por vírgula — o Zabbix tenta pela ordem até conseguir leitura-escrita, no frontend e noDBHostdo server - SNMPv3 EngineID caching — mappings EngineID-IP ficam em cache e reutilizáveis entre checks, menos tráfego de probe — se um EngineID não responder, há fallback e purga de entradas antigas
- DNS com c-ares — build com
--with-arestraz cache de queries DNS e failover de resolver (c-ares 1.26 ou posterior) - Certificados SAML importáveis — super admins importam certificado + chave directamente na interface de SSO, sem tocar no filesystem
- AllowKeyRegexp/DenyKeyRegexp — expressões regulares nos parâmetros de controlo de chaves do agent e agent 2
- Zabbix Cloud proxies — o Administration > Proxies leva um botão Create proxy in Cloud, que abre o Zabbix Cloud para deploy sem instalar em infraestrutura própria
- Templates novos — Microsoft Hyper-V Failover Cluster e Hyper-V Standalone por SSH, GLPI por HTTP
Breaking changes — o que obriga a replanear
O upgrade para um LTS sempre carrega requisitos. Os que se aplicam a quase todas as instalações PME:
| Componente | Mínimo na 8.0 | Antes (7.4) |
|---|---|---|
| MySQL/Percona | 8.4.0 | 8.0.30 |
| MariaDB | 10.11.00 | 10.5.00 |
| PostgreSQL | 15.0 | 13.0 |
| TimescaleDB | 2.20.0 | 2.13.0 |
| PHP (frontend) | 8.2.0 | 8.0.0 |
⚠️ Atenção
quem corre MariaDB 10.5 ou PostgreSQL 13 vai precisar de um upgrade de base de dados ANTES do upgrade Zabbix — a 8.0 não arranca com as versões mínimas antigas.
Outras mudanças que partem configurações existentes:
- TLS verificado por omissão — templates e media types HTTP actualizados passam a verificar o certificado TLS nos endpoints HTTPS. Afeta os templates cloud/API (Claude API, Cloudflare, Kubernetes Cluster by HTTP) e os webhooks (Slack, Jira, Telegram). No upgrade os templates e media types NÃO são actualizados automaticamente (a regra evita sobrepor personalizações) — aplica-se quando os importas ou actualizas manualmente. O comportamento ajusta-se com a macro
{$HTTP.TLS.VERIFY}(ver o README de cada template/webhook) - Agentes pré-1.6 deixam de ser suportados — os protocolos legacy plain-text/XML saíram do server/proxy trapper
- Ceph plugin passa a loadable plugin, com passos de instalação adicionais no agent 2
- Templates Kubernetes antigos deprecados — substituídos pelo Kubernetes Cluster by HTTP — os antigos ficam, mas há migração a planear
- Macros antigas caíram —
{STATUS}→{TRIGGER.STATUS},{USER.ALIAS}→{USER.USERNAME},{PROFILE.*}→{INVENTORY.*}, entre outras da lista oficial (mais de 10 substituições) - Items internos de proxy restritos — os internal items
zabbix[proxy,*]ezabbix[proxy group,*]deixam de ser suportados em hosts monitorizados por um proxy ou grupo de proxies - Filtros de frontend personalizados — alguns parâmetros de filtro saíram do separador de filtro para as opções de coluna — tabs guardados que os usem reiniciam: em Hosts (Show suppressed problems), Latest data e Problems (Show tags, Tag name, Tag display priority, Show details…)
- MS Teams webhook legado morto — o conector Office 365 da Microsoft foi retirado a 22/05/2026. O tipo de media MS Teams baseado neles deixou de funcionar. O caminho é o MS Teams Workflow webhook media type
Plano de upgrade típico numa PME
- Inventory do ambiente corrente: versões de base de dados, PHP do frontend, agentes (< 1.6?), templates com macros antigas
- Upgrade de base de dados para os mínimos (PostgreSQL 15, MySQL 8.4/MariaDB 10.11, TimescaleDB 2.20). Se a base MySQL foi criada com
utf8mb3/utf8mb3_bin, converter parautf8mb4/utf8mb4_binANTES do upgrade (forte recomendação da documentação — ver a página Repairing Zabbix database character set and collation) - Teste do upgrade numa instância secundária ou VM de staging, com backup da base antes
- No upgrade: verificar os logs de migração e reconfigurar os filtros de frontend que reiniciaram
- Validação pós-upgrade: SNMPv3 e c-ares a render o esperado, templates cloud no novo regime TLS, MS Teams via Workflow
Nota
a 8.0.0rc1 não é versão de produção. Instalar rc para validar o upgrade ao ambiente, não para operar. Na GA (prevista para Q4 2026), os requisitos e o procedimento volvem a confirmar na documentação estável — a doc da 8.0 está hoje marcada como versão em desenvolvimento e pode estar incompleta.
Erros Comuns
- Upgrade de versões antigas sem ler as notas intermédias — o upgrade directo para 8.0.x é suportado desde a 2.0.x. Não é obrigatório instalar as versões intermédias, mas é preciso cumprir os requisitos da 8.0 e ler as upgrade notes de TODAS as versões atravessadas (a tabela oficial da documentação lista versão a versão)
- Webhooks que param silenciosamente — se a infraestrutura interna usa certificados self-signed nos endpoints de webhook, o novo TLS verification por omissão os quebra. Ou se introduz um certificado válido, ou ajusta a macro
{$HTTP.TLS.VERIFY} - TimescaleDB esquecido — o
history_jsonhypertable tem de ser criado manualmente em quem usa TimescaleDB - Macros antigas em notificações — depois do upgrade, triggers com
{STATUS}ou aliases antigos deixam de expandir — revisar notificações
Checklist
- Inventário de versões: MySQL/MariaDB/PostgreSQL/TimescaleDB/PHP
- Backup da base de dados e do zabbix.conf.php
- Staging do upgrade com os dados de produção
- Lista de webhooks/templates cloud com TLS self-signed
- Plano de migração dos templates Kubernetes antigos para Kubernetes Cluster by HTTP
Artigos Relacionados
- Zabbix: Monitorização Open-Source para PMEs em 2026
- Zabbix vs PRTG vs Nagios em 2026: Monitorização para PME
- Monitorização de Infraestrutura com Zabbix ou PRTG em PME