Retenção, banco e performance

Performance começa na modelagem

O maior ganho costuma vir de não coletar, não processar e não armazenar o que não será utilizado. Dez mil itens inúteis custam coleta, preprocessing, cache, banco, housekeeping, frontend e backup. Antes de tunar processos, revise o desenho.

History guarda detalhe

History mantém cada valor coletado durante o período definido no item ou sobrescrito globalmente pelo housekeeping. É a fonte para troubleshooting detalhado e funções de histórico. Quanto menor o intervalo e maior a retenção, maior o volume de linhas gerado.

Trends guardam memória de longo prazo com menor custo

Para itens numéricos, trends armazenam agregações horárias e consomem menos recursos que history. Por isso, a documentação recomenda manter history pelo menor período realmente necessário e trends por períodos maiores. Gráficos antigos podem usar trends quando history já expirou.

History=0 muda mais do que armazenamento

Se history estiver configurado como “não armazenar”, o item continua podendo alimentar dependent items e inventário, porém funções de trigger baseadas em history não são avaliadas para aquele item. Essa decisão deve ser usada com consciência, especialmente em master items.

Retenção deve responder ao caso de uso

Pergunte: por quanto tempo preciso investigar incidentes com granularidade completa? quanto tempo preciso analisar tendência? existe requisito regulatório? qual resolução é necessária? Um modelo comum pode manter semanas de history e anos de trends, mas não existe número universal.

Housekeeping executa a política de expiração

O housekeeper remove dados cujo período de retenção expirou. Alterar uma política de 365 dias para 30 dias não significa que centenas de milhões de linhas desaparecerão instantaneamente sem custo. Exclusão massiva pode gerar carga de I/O e banco; mudanças grandes precisam ser planejadas.

Administração pode sobrescrever retenções dos itens

Configurações globais de housekeeping podem substituir períodos de history e trends definidos individualmente. Isso facilita governança em ambientes grandes, mas significa que olhar apenas para o item não basta: confirme se existe override global ativo.

Particionamento temporal pode mudar a estratégia de escala

O Zabbix suporta TimescaleDB no Server como extensão do PostgreSQL. TimescaleDB particiona automaticamente dados por tempo e pode oferecer compressão e housekeeping por chunks. O Zabbix Proxy não suporta TimescaleDB como banco de proxy.

Particionamento exige configuração coerente

No TimescaleDB, o script oficial configura opções de housekeeping e pode habilitar compressão. Para remover corretamente chunks comprimidos, overrides globais de history/trends precisam estar configurados de forma compatível. Configuração inconsistente gera avisos e impede remoção esperada de dados comprimidos.

Compressão economiza espaço, mas não elimina necessidade de retenção

Compressão do TimescaleDB reduz custo de armazenamento de dados antigos, porém não transforma retenção infinita em boa prática. Mais dados continuam significando backup maior, consultas longas e maior superfície operacional.

O caminho até o banco passa por memória

Valores processados entram no history cache e são posteriormente sincronizados com o banco pelos history syncers. Se itens específicos bloqueiam o cache ou se o banco não acompanha a taxa de escrita, o cache pode encher e atrasar o sistema.

O 7.4 adicionou mecanismos de diagnóstico e limpeza

Zabbix 7.4 introduziu runtime control para limpar history cache de um item específico, limpeza automática de cache ao desabilitar item/host e diagnóstico mais visível quando o cache enche. Esses recursos ajudam a identificar itens que acumulam quantidade anormal de valores.

Syncer conecta memória e persistência

History syncers normalizam valores e os escrevem no banco. Estatísticas de transação nos títulos dos processos ajudam a observar throughput e comportamento. Se syncers permanecem muito ocupados, investigue banco, I/O, transações e volume antes de apenas aumentar processos.

Triggers não deveriam consultar o banco a toda hora

Value cache mantém valores históricos em memória para acelerar expressões de trigger, calculated items e algumas macros. Quando o valor necessário não está em cache, o Server consulta o banco e atualiza o cache. ValueCacheSize precisa ser dimensionado conforme expressões e janelas de dados utilizadas.

Pouca memória pode gerar carga SQL indireta

Se value cache não consegue manter dados necessários, expressões podem depender mais do banco. O próprio Zabbix oferece itens internos e diaginfo=valuecache para observar uso e comportamento. Um trigger mal projetado com janelas grandes pode consumir cache de forma significativa.

Análises de tendência também possuem cache dedicado

Funções trendavg, trendmax, trendmin, trendcount e similares usam dados agregados e seus resultados podem ser armazenados no Trend Function Cache. TrendFunctionCacheSize controla esse cache, reduzindo consultas repetidas para os mesmos parâmetros.

Trigger baseada apenas em trends não precisa ser reavaliada a cada segundo

Quando uma expressão usa somente funções de trend, a avaliação acontece conforme o menor período temporal usado na expressão. Isso torna trends adequadas para verificações de longo prazo, capacidade e comportamento histórico sem exigir processamento equivalente a triggers de alta frequência.

Queue mostra atraso, não causa

Fila de itens indica checks que deveriam ter ocorrido e estão atrasados. Ela pode apontar saturação de pollers, dispositivos lentos, timeout, Proxy, conectividade ou outro gargalo. Queue é sintoma operacional; diagnóstico exige separar por tipo de check e domínio.

Processo ocupado é uma pista

Server e Proxy expõem métricas internas de processos ocupados. Pollers, preprocessors, history syncers, discoverers, alerters e outros podem saturar independentemente. Aumente processos somente quando a métrica e o fluxo confirmarem que aquele estágio é limitante.

Payload eficiente reduz trabalho antes do banco

Master/dependent items, JSONPath, SNMP walk e throttling reduzem requests e gravações. Porém preprocessing complexo, JavaScript excessivo e grandes payloads também podem saturar workers. Otimização deve considerar custo de coleta e custo de transformação.

Item quebrado também consome operação

Itens unsupported geram retry, logs e trabalho de diagnóstico. Templates com OIDs inexistentes, endpoints removidos ou parsing incorreto podem manter ruído permanente. Monitore e elimine unsupported crônicos em vez de aceitá-los como “normal”.

Itens de log podem dominar volume

Log monitoring pode produzir bursts enormes. Parâmetros de linhas por segundo, tamanho, rotação e filtros precisam ser desenhados para impedir que um único arquivo inunde history cache e banco. Logs exigem capacity planning diferente de métricas numéricas periódicas.

Banco é parte do Zabbix, não infraestrutura invisível

Monitore IOPS, latência, CPU, memória, cache/buffer pool, locks, conexões, crescimento, tamanho de tabelas e tempo de queries. Um Zabbix com Server saudável e banco saturado continua sendo um Zabbix lento.

IOPS e latência importam mais que “ter muito disco”

History envolve alta taxa de escrita e housekeeping pode causar exclusões significativas. Storage com baixa latência e I/O previsível é essencial. Capacidade em TB sem IOPS adequados não resolve workloads de séries temporais.

Backup precisa considerar volume e RTO

Quanto maior o banco, maior o tempo de backup, restore e validação. Retenção excessiva aumenta não apenas storage online, mas também janela de backup e tempo de recuperação. Estratégia de retenção faz parte de disaster recovery.

O banco precisa de manutenção específica à engine

PostgreSQL, MySQL/MariaDB e TimescaleDB possuem mecanismos diferentes de manutenção, estatísticas e gerenciamento de espaço. Siga práticas da engine utilizada. Não aplique tuning copiado de outra engine apenas porque ambos rodam Zabbix.

Consultas pesadas aparecem como “Zabbix lento”

Problems, Latest data, gráficos e relatórios consultam dados armazenados. Filtros amplos sobre grande histórico podem pressionar banco/frontend. Performance percebida pelo usuário depende tanto de escrita quanto de leitura.

Cálculo também é carga

Calculated items podem agregar hosts, grupos e métricas, mas expressões complexas e frequentes adicionam processamento. Se um cálculo é usado apenas para relatório mensal, não precisa necessariamente ser executado a cada minuto.

Retenção pode ser governada por macros quando apropriado

User macros podem ser usadas em períodos suportados, permitindo definir políticas por template ou host. Isso facilita padronização e exceções controladas, desde que a governança impeça centenas de valores arbitrários difíceis de auditar.

Número de hosts é uma métrica fraca de capacidade

Dois ambientes com mil hosts podem diferir por ordens de grandeza. Avalie itens ativos, frequência, NVPS, payload, LLD, logs, preprocessing, trends, triggers e retention. “Quantos hosts o Zabbix suporta?” sem essas dimensões é uma pergunta incompleta.

Values per second aproxima a pressão de ingestão

NVPS ajuda a estimar fluxo de valores, mas não captura sozinho peso de payload, parsing, logs, consultas, triggers e banco. Use-o como eixo central junto de mix de workload e retenção.

Projete crescimento por mês e ano

Observe taxa real de expansão do banco e extrapole. Crescimento de 100 GB/mês significa 1,2 TB/ano antes de índices, backups e margens. Capacity planning deve prever expansão e não reagir somente quando filesystem chega a 90%.

O Zabbix também é um serviço crítico

Defina expectativas para disponibilidade do Server, Proxy, banco e alerting. Se o monitoramento é usado para resposta a incidentes, sua indisponibilidade possui impacto direto no MTTR da organização.

Performance tuning sem baseline é adivinhação

Antes de alterar StartPollers, caches, buffers ou banco, registre baseline: queue, busy %, NVPS, latência do banco, I/O, CPU, cache e tempo de resposta. Faça uma mudança por vez e compare.

A otimização mais barata é reduzir desperdício

Itens sem uso, gráficos duplicados, LLD excessiva, history longo, checks redundantes e payload bruto permanente devem ser revisados antes de comprar hardware. Em sistemas de observabilidade, desperdício cresce silenciosamente com o tempo.

Escolha a resolução pelo tipo de pergunta

Intervalo muda o volume por ordem de grandeza

amostras_por_dia = 86.400 / intervalo

10.000 itens:

30 s
= 2.880 valores/item/dia
= 28.800.000 valores/dia

60 s
= 1.440 valores/item/dia
= 14.400.000 valores/dia

300 s
= 288 valores/item/dia
= 2.880.000 valores/dia

A diferença entre 30 s e 300 s é 10× no número de amostras. Isso não traduz diretamente para bytes, mas traduz diretamente para trabalho de ingestão.

Uma política pode variar por classe de dado

Os períodos são exemplos de engenharia, não recomendações universais do Zabbix.

Do valor processado ao banco

COLETA
  │
  ▼
PREPROCESSING
  │
  ▼
HISTORY CACHE
  │
  ▼
HISTORY SYNCERS
  │
  ├── normalização
  ├── triggers / processamento
  └── escrita
       │
       ▼
     BANCO
   ├─ history
   └─ trends

Menos SQL para expressões repetidas

Trigger:
avg(/host/net.if.in,15m) > limite

Sem valor em cache:
→ Server consulta history no banco
→ carrega dados
→ mantém em Value Cache

Próximas avaliações:
→ usam memória quando dados necessários continuam disponíveis

Use runtime control antes de reiniciar

# Diagnóstico geral
zabbix_server -R diaginfo

# Value cache
zabbix_server -R diaginfo=valuecache

# History cache
zabbix_server -R diaginfo=historycache

# Preprocessing
zabbix_server -R diaginfo=preprocessing

# Zabbix 7.4 — limpar um item específico do history cache
zabbix_server -R history_cache_clear=<ITEM_ID>

Quando séries temporais se tornam o centro da arquitetura

Sintoma → hipótese

Métricas que devem existir antes da crise

Performance ruim por desenho, não por falta de hardware

Revisar um template pelo custo

Valide uma mudança de performance

Antes de chamar o ambiente de escalável

Base factual

Conteúdo desenvolvido a partir da documentação oficial Zabbix 7.4 sobre History, Trends, Housekeeping, Trend Functions, Value Cache, Preprocessing, History Cache, runtime control e TimescaleDB. Os modelos de retenção, cálculos de ingestão, matriz de gargalos, baseline, laboratórios e recomendações operacionais são síntese editorial própria.

Linha Zabbix 7.4

Reconfirme versões suportadas do banco/TimescaleDB antes de upgrades. A documentação current da linha 7.4 já acompanha TimescaleDB 2.29.x, mas compatibilidade depende do patch instalado.