Maintenance é supressão controlada durante uma janela conhecida
O Zabbix permite aplicar períodos de manutenção a hosts e grupos de hosts. Com tags, em manutenção com coleta, é possível restringir a supressão a um subconjunto de problemas em vez de silenciar tudo no host.
With data collection x No data collection
| Tipo | Dados | Triggers | Quando usar |
|---|---|---|---|
| With data collection | continuam sendo processados/salvos | continuam sendo avaliadas; problemas podem ficar suprimidos | mudança planejada quando histórico é valioso |
| No data collection | valores podem ser coletados, mas são descartados pelo server | não disparam durante a janela | situações específicas em que você deliberadamente não quer armazenar/processar valores |
“No data collection” não significa que server/proxy deixa de coletar
No Zabbix 7.4, o server ou proxy continua executando a coleta mesmo em manutenção No data collection. O Zabbix server descarta posteriormente os valores para hosts nesse tipo de maintenance.
Problema pode existir e estar suprimido
Durante With data collection, triggers continuam sendo processadas e eventos continuam podendo ser criados. A manutenção marca os problemas correspondentes como suprimidos para que ações possam tratá-los de forma diferente.
No frontend, problemas suprimidos continuam visíveis com indicação de suppression. Isso é melhor que “sumir” com o problema: o NOC preserva contexto.
Maintenance e notificação são conectadas pela Action
Se a Action estiver configurada com Pause operations for suppressed problems, as etapas de escalonamento de problemas suprimidos são pausadas durante a manutenção. Recovery e update operations não são suprimidas da mesma maneira; o comportamento da Action deve ser revisado conscientemente.
Active since/till define a janela de validade; Periods define quando ela acontece
Somente preencher Active since e Active till não ativa uma maintenance. É necessário configurar ao menos um período.
| Campo | Papel |
|---|---|
| Name | nome operacional da janela |
| Maintenance type | com ou sem coleta persistida |
| Active since / Active till | intervalo global em que a definição pode executar |
| Periods | agenda efetiva |
| Hosts / Host groups | escopo |
| Tags | subset de problemas; disponível em With data collection |
| Description | ticket, motivo, responsável e contexto |
Host group economiza trabalho — e aumenta o blast radius
Selecionar um host group aplica maintenance a seus hosts. Grupos pais também incluem grupos aninhados. Em ambientes grandes, confirme a árvore antes de ativar.
A maintenance deve nascer do change
Nome: CHG-2026-0842 - POP Centro - upgrade core
Tipo: With data collection
Início: 2026-08-27 00:00
Fim: 2026-08-27 02:00
Escopo: Core-RTR-01 / Core-RTR-02
Tags: site=pop-centro, component=bgp
Owner: Engenharia
Rollback: documento CHG-2026-0842
- Definir serviço/hosts afetados.
- Definir sintomas esperados.
- Criar maintenance antes do início.
- Confirmar Actions e suppression.
- Executar mudança.
- Monitorar dados durante a janela.
- Executar validação pós-change.
- Encerrar/expirar maintenance.
- Confirmar que novos problemas não ficaram ocultos.
Janela planejada deve aparecer diferente de falha não planejada
O NOC precisa enxergar quais objetos estão em maintenance, qual change os cobre, início/fim, owner e problemas suprimidos. Uma janela sem contexto vira ruído inverso: ninguém sabe se o problema é esperado.
Diária, semanal e mensal precisam ser usadas com cautela
Períodos recorrentes são úteis para jobs programados, reboots mensais ou tarefas de infraestrutura. Mas uma maintenance eterna pode mascarar um serviço que deveria ser redesenhado.
No data collection tem efeito específico após o fim da janela
Quando uma maintenance No data collection termina, triggers que usam nodata() não disparam imediatamente até que ocorra a próxima verificação dentro da janela avaliada pela função.
Esse comportamento evita interpretar a ausência deliberada durante maintenance como problema instantâneo.
Logs possuem semântica especial após No data collection
Se um item de log for criado/adicionado enquanto o host está em manutenção sem coleta persistida, após o fim da janela somente novas entradas desde o término da maintenance serão coletadas.
A fila do frontend exclui itens em No data collection
A Queue calculada pelo Zabbix server não contabiliza itens em manutenção No data collection. Portanto, a fila pode parecer saudável mesmo que esses itens estejam atrasados em relação ao polling normal.
Proxy não conhece a configuração de maintenance
A configuração de maintenance não é sincronizada para proxies. Por isso, internal checks de queue executados no proxy podem reportar itens atrasados que o frontend/server não mostra na Queue durante No data collection.
Automatize maintenance a partir do change
A API 7.4 possui objeto Maintenance e métodos para criar, atualizar, consultar e remover períodos. O campo maintenance_type usa 0 para With data collection e 1 para No data collection.
# fluxo recomendado
Ticket aprovado
↓
resolver hosts/grupos/tags
↓
maintenance.create
↓
validar maintenance.get
↓
executar change
↓
validar serviço
↓
maintenance.delete / expiração
Ativar maintenance também tem custo
Ao entrar em maintenance, os timer processes do Zabbix server leem problemas abertos para decidir quais devem ser suprimidos. Em ambientes com grande volume de problemas, isso pode causar impacto de processamento.
- evite criar centenas de maintenances desnecessárias simultaneamente;
- controle volume de problemas abertos;
- monitore busy timer processes;
- acompanhe DB/cache durante mudanças massivas;
- teste processos automatizados de maintenance em homologação.
Maintenance é alteração operacional
change_id:
maintenance_id:
created_by:
created_at:
hosts/groups:
problem_tags:
type:
active_since:
active_till:
reason:
validation:
closed_at:
Combine Audit log do Zabbix, ticket e logs da automação. Janelas manuais sem descrição e sem owner devem ser tratadas como exceção.
| Erro | Efeito | Correção |
|---|---|---|
| usar No data collection por padrão | perde histórico da mudança | preferir With data collection quando possível |
| maintenance em grupo pai enorme | silencia mais que o esperado | validar escopo/grupos filhos |
| sem tags | todos os problemas do host podem ser suprimidos | usar tags quando o change é parcial |
| esquecer Action | alerta continua chegando | revisar pause operations |
| janela longa demais | incidente real fica suprimido | mínimo necessário + validação |
| maintenance esquecida | supressão prolongada | Active till e auditoria |
| sem ticket/descrição | NOC perde contexto | padronizar naming |
“Criei a maintenance e não funcionou”
- Confirmar Active since / Active till.
- Confirmar que existe Period cobrindo o horário atual.
- Confirmar host ou host group correto.
- Se usar tags, conferir case e operador Contains/Equals.
- Confirmar tipo With/No data collection.
- Esperar sincronização do configuration cache.
- Confirmar se o problema/evento possui tags esperadas.
- Revisar Action e Pause operations for suppressed problems.
- Verificar se o problema está marcado como suppressed no frontend.
- Se houver proxy, não interpretar queue divergente como falha da maintenance.
Quatro cenários obrigatórios
Antes de iniciar a janela
- change aprovado?
- escopo exato confirmado?
- With data collection é suficiente?
- tags podem reduzir o blast radius?
- Actions tratam suppressed problems corretamente?
- Active since/till e Period estão corretos?
- owner e rollback estão descritos?
- NOC conhece a janela?
- validação pós-change está definida?
- há forma de confirmar que maintenance terminou?
Comportamento versionado
Conteúdo estruturado para Zabbix 7.4. O comportamento de Maintenance, tags, queue, proxy, nodata(), log items e API deve ser conferido novamente ao migrar para uma nova major release.
Linha Zabbix 7.4
Maintenance deve suprimir o que foi planejado sem virar esconderijo para problemas. Registre owner, janela, escopo, motivo, validação pós-mudança e rollback.