Capacity planning e escala

Quantidade de hosts não é unidade suficiente de capacidade

Um host pode possuir dez itens a cada cinco minutos ou milhares de itens a cada poucos segundos. Dimensionamento precisa partir de itens habilitados, intervalos, tipos de coleta, preprocessing, triggers, history, trends e eventos.

New values per second aproxima a pressão de ingestão

NVPS representa a taxa de novos valores processados pelo Zabbix. É uma das métricas mais úteis para compreender escala, mas não descreve sozinha custo de polling, preprocessing, discovery, trigger evaluation ou consultas ao banco.

Intervalo de atualização transforma itens em taxa

Como aproximação, um item coletado a cada 60 segundos produz 1/60 valor por segundo. Multiplique pelo número de itens equivalentes e some grupos com intervalos diferentes. O resultado ajuda a estimar ingestão antes da implantação.

Média pode esconder picos sincronizados

Se milhares de itens executam no mesmo segundo, a média por minuto parece aceitável enquanto pollers e banco enfrentam burst. Use scheduling, intervalos flexíveis e distribuição natural para evitar sincronização artificial.

Dois itens com o mesmo intervalo podem ter custos muito diferentes

Simple check, SNMP, agent, HTTP agent, script, database monitor, browser item e external check possuem perfis distintos de CPU, rede, latência e concorrência. Capacity planning precisa separar workload por classe.

Processos ocupados indicam gargalo de concorrência

Zabbix utiliza diferentes tipos de processos internos. Quando uma classe permanece muito ocupada, a fila pode crescer mesmo com CPU global aparentemente baixa. Ajuste processos somente depois de identificar qual workload está esperando.

Percentual alto persistente merece investigação

Métricas internas de utilização dos processos ajudam a localizar saturação. Picos curtos podem ser normais; ocupação próxima do limite por períodos prolongados sugere concorrência insuficiente, checks lentos ou dependência externa degradada.

Aumentar processos não cria recursos infinitos

Elevar pollers pode reduzir fila, mas também aumentar conexões simultâneas, CPU, memória e pressão no banco ou nos dispositivos monitorados. Tuning deve observar o sistema inteiro e não apenas fazer um gráfico ficar verde.

Fila é atraso entre o momento esperado e a coleta

A Zabbix queue mostra itens que deveriam ter sido atualizados e estão atrasados. Crescimento contínuo é um dos sinais mais claros de capacidade insuficiente, checks lentos, indisponibilidade de destinos ou configuração incorreta.

Segmentar atraso acelera diagnóstico

Observe se o atraso se concentra em SNMP, agent, simple checks ou outra classe. Uma fila global pode sugerir Server sobrecarregado; fila concentrada em um método normalmente aponta para processo, rede ou tecnologia específica.

Caches reduzem trabalho repetitivo e acesso ao banco

O Server possui caches para diferentes estruturas e fluxos. Quando um cache se aproxima do limite ou fica sem espaço, desempenho pode degradar. Dimensione memória com margem e acompanhe utilização real por métricas internas.

Configuração cresce com hosts, itens e objetos

Configuration cache mantém dados necessários para operação do Server. Ambientes com grande número de itens, triggers, macros e discovery podem exigir aumento do cache. Mudanças estruturais devem ser acompanhadas por tendência de uso.

Value cache acelera funções que consultam valores recentes

Trigger expressions e cálculos podem reutilizar valores recentes. Value cache reduz consultas repetidas ao banco. Pressão elevada ou modo de baixa memória indica que o tamanho precisa ser revisto ou que expressões estão demandando mais histórico recente.

Ingestão precisa absorver valores antes da persistência

Caches ligados a history ajudam a desacoplar recebimento e gravação. Saturação pode aparecer quando banco não acompanha a taxa ou durante picos. A causa pode estar na persistência, não necessariamente na coleta.

Trends também possuem custo de agregação

Valores numéricos podem gerar trends para análise de longo prazo. Isso reduz necessidade de manter history granular por anos, mas adiciona processamento e armazenamento próprios. Planeje history e trends como camadas diferentes.

Na maioria dos ambientes grandes, banco define o teto prático

O banco recebe history, trends, events, audit e configuração. IOPS, latency, cache do SGBD, índices, WAL/binlog, checkpoint e storage influenciam diretamente a capacidade do Zabbix. CPU do Server sozinha não explica desempenho.

Zabbix é intensivo em escrita

History produz fluxo contínuo de inserts. Em alta escala, storage com baixa latência e configuração adequada do SGBD são essenciais. O padrão é diferente de aplicações predominantemente de leitura.

Dashboards e funções também pressionam leitura

Consultas de gráficos, latest data, relatórios, trigger functions e API podem competir com ingestão. Um ambiente pode coletar normalmente e ficar lento para usuários por saturação de leitura ou queries pesadas.

Retenção granular é multiplicador direto de storage

Guardar 90 dias de history consome aproximadamente três vezes o espaço de 30 dias para a mesma taxa, antes de considerar compressão e overhead. Defina retenção pelo uso real e não por hábito.

Longo prazo não precisa necessariamente de granularidade bruta

Trends armazenam agregações horárias de itens numéricos e são adequadas para análise de longo período quando detalhes por amostra não são necessários. Isso permite reduzir history sem perder visão histórica de capacidade.

Remoção de dados também consome recursos

Housekeeping precisa eliminar dados expirados e objetos órfãos conforme configuração. Grandes volumes de exclusão podem causar pressão no banco. Retenção deve ser desenhada antes de o banco crescer, não depois.

Particionamento e compressão podem mudar a economia de retenção

Em PostgreSQL, TimescaleDB é uma opção suportada em cenários documentados e pode oferecer particionamento temporal e compressão. A adoção precisa seguir versões suportadas e configuração oficial; não é substituto automático para bom desenho de retenção.

Partições tornam lifecycle de dados mais previsível

Em bancos e arquiteturas que utilizam particionamento suportado, remover intervalos inteiros pode ser mais eficiente do que milhões de deletes individuais. Porém schema e manutenção precisam seguir práticas compatíveis com Zabbix.

Capacidade em GB não é o mesmo que desempenho

Dois discos com 2 TB podem oferecer latências e IOPS completamente diferentes. Zabbix precisa de espaço e também de desempenho consistente. Observe latency de storage, queue depth, fsync e comportamento durante checkpoints.

Replicação aumenta tráfego de escrita

HA do banco, backups contínuos e replicação geram WAL/binlog adicionais. Capacity planning precisa incluir esse fluxo, principalmente em NVPS alto. Storage do primário e rede de réplica precisam acompanhar.

Janela de backup não pode degradar o monitoramento

Backup lógico ou físico pode aumentar I/O, CPU e tráfego. Meça impacto durante a janela e prefira estratégias compatíveis com o SGBD e o RPO. Backup que derruba ingestão toda madrugada é problema de capacidade.

Transformação de dados possui orçamento computacional

JSONPath, regex, JavaScript, Prometheus preprocessing e outras etapas consomem CPU e processos especializados. Uma resposta grande transformada centenas de vezes por segundo pode ser mais cara que a coleta em si.

Uma coleta master pode reduzir pressão externa

Dependent items permitem consultar uma API, SNMP walk ou payload uma vez e derivar múltiplas métricas. Isso reduz requests aos alvos e pode melhorar escala, embora aumente trabalho de preprocessing local.

Flexibilidade precisa de disciplina

JavaScript em preprocessing e scripts é poderoso, mas lógica complexa executada em alta frequência pode consumir recursos. Prefira operações nativas simples quando suficientes e meça tempo de processamento.

Discovery cria crescimento dinâmico

Low-level discovery pode multiplicar itens, triggers e graphs conforme interfaces, filesystems, VMs ou entidades descobertas. Um template aparentemente pequeno pode gerar milhares de objetos por host. Estime cardinalidade antes de aplicar em massa.

Descobrir tudo é frequentemente desperdício

Filtre interfaces administrativas, filesystems irrelevantes, containers efêmeros ou entidades sem valor operacional. Menor cardinalidade reduz configuração, NVPS, banco e ruído de eventos.

Objetos perdidos também possuem ciclo de vida

Recursos efêmeros desaparecem e podem deixar objetos descobertos por determinado período. Ajuste lifetime conforme dinâmica do ambiente. Retenção longa de entidades que duram minutos pode inflar configuração.

Cada valor pode iniciar avaliação lógica

Triggers simples têm custo pequeno, mas milhares de expressões complexas, funções históricas e dependências podem aumentar trabalho. Avalie se toda métrica realmente precisa de trigger e se a expressão usa janela coerente.

Tempestade de problemas é problema de capacidade também

Uma falha de backbone pode criar milhares de eventos e notificações. Dependências, correlação e Services reduzem ruído humano e também evitam trabalho desnecessário em Actions, webhooks e banco.

Cardinalidade de metadados também precisa de padrão

Tags facilitam correlação e Services, mas nomenclatura descontrolada cria combinações inconsistentes e consultas difíceis. Defina vocabulário para site, service, operator, environment e owner.

Distribua coleta perto da origem

Proxies reduzem conexões diretas ao Server, agregam coleta regional e bufferizam dados. Eles não eliminam carga final de history no banco, mas distribuem polling, preprocessing suportado e dependência de WAN.

Proxy deve ser dimensionado pelo workload local

Considere NVPS, tipos de checks, quantidade de hosts, discovery, preprocessing, banco local e tempo de buffer. Um Proxy para 500 roteadores SNMP pode ter perfil diferente de um Proxy para 500 servidores com Agent 2.

Redundância exige capacidade ociosa

Quando proxies de um grupo podem assumir hosts uns dos outros, cada membro precisa suportar carga adicional durante falha. Planeje N+1 ou outra política explícita. Operar todos no limite elimina a vantagem do failover.

Coleta também é tráfego

NVPS elevado através de links WAN, VPN ou satélite pode ser relevante, principalmente com payloads HTTP, logs e SNMP walks. Meça bytes e não apenas valores. Compressão e coleta local via Proxy podem reduzir dependência de WAN.

Itens de log têm perfil diferente de métricas periódicas

Log monitoring pode produzir bursts imprevisíveis. Um incidente pode aumentar justamente o volume de logs quando a infraestrutura já está degradada. Defina filtros, limites e retenção para evitar amplificação.

Push desloca polling, não elimina ingestão

Zabbix trapper e sender podem receber grandes volumes sem polling tradicional. Isso reduz processos de coleta ativa, mas history syncers, preprocessing e banco continuam precisando absorver os valores.

Automação também consome capacidade

Consultas frequentes de API, especialmente history.get ou buscas amplas, podem pressionar frontend/Server/banco. Integrações devem usar filtros, paginação e frequência coerentes. Não transforme API em exportador bruto contínuo sem medir impacto.

Painel operacional pode virar carga de leitura

Dashboards com muitos widgets, gráficos extensos e refresh agressivo multiplicados por dezenas de operadores aumentam consultas. Observe desempenho do frontend e banco em horários de NOC ativo.

Capacidade precisa prever crescimento, não apenas fotografar hoje

Projete hosts, itens, NVPS, storage e eventos para 6, 12 e 24 meses. Inclua novos projetos e margem. Comprar recurso somente quando queue aparece transforma planejamento em resposta a incidente.

Operar no limite impede absorver falhas e picos

Mantenha margem para discovery, incidentes, catch-up de proxies, manutenção e perda de nó HA. O percentual adequado depende da arquitetura, mas 100% de utilização nunca é capacidade saudável.

Teste com workload parecido com produção

Benchmarks genéricos de hardware têm valor limitado. Reproduza templates, intervalos, payloads, banco e retenção próximos do real. O melhor sizing é aquele validado com a sua distribuição de carga.

Transforme inventário em taxa

Exemplo:

20.000 itens @ 60s
20.000 / 60 = 333 NVPS

8.000 itens @ 30s
8.000 / 30 = 267 NVPS

2.000 itens @ 10s
2.000 / 10 = 200 NVPS

Total aproximado:
333 + 267 + 200
= 800 NVPS

Depois adicionar:
+ dependent items
+ trapper/sender
+ discovery
+ bursts
+ crescimento
+ margem operacional

History cresce quase linearmente com tempo e taxa

VALORES/DIA

NVPS × 86.400

Exemplo:
800 × 86.400
= 69.120.000 valores/dia

30 dias:
≈ 2,07 bilhões de valores

90 dias:
≈ 6,22 bilhões de valores

IMPORTANTE:
isso é quantidade de registros, não bytes.

Storage real depende de:
- tipo de valor
- engine
- índices
- páginas
- compressão
- WAL/binlog
- replicação
- overhead
- events/trends/audit

Nem toda métrica merece a mesma retenção

Valores são exemplos. Retenção real deve seguir troubleshooting, compliance, SLO e custo.

Sintoma → provável camada

Planeje 6, 12 e 24 meses

Tabela ilustrativa. O valor está no método: projetar carga e validar antes do crescimento chegar.

O gargalo pode estar em qualquer estágio

DISPOSITIVOS / APPS
        │
        ▼
  POLLERS / TRAPPERS
        │
        ▼
   PREPROCESSING
        │
        ▼
     CACHES
        │
        ▼
 TRIGGER EVALUATION
        │
        ▼
 HISTORY SYNCERS
        │
        ▼
     DATABASE
        │
   ┌────┴────┐
   ▼         ▼
HISTORY    TRENDS
   │
   ▼
API / DASHBOARDS / REPORTS

Capacity planning =
medir cada etapa + encontrar o recurso limitante.

Como desperdiçar capacidade

Meça antes de aumentar hardware

Capacity planning baseado em evidência

Base factual

Conteúdo estruturado sobre métricas internas, processos, caches, queue, proxies, preprocessing, dependent items, LLD, history, trends e armazenamento no ecossistema Zabbix 7.4. Os modelos de NVPS, retenção, crescimento, headroom, N+1, diagnóstico de gargalos e metodologia de sizing são síntese de engenharia de capacidade aplicada a ambientes Zabbix.

Linha Zabbix 7.4

Dimensione por NVPS, tipo/frequência de checks, preprocessing, quantidade de valores, retenção e comportamento do banco. Contagem de hosts isoladamente é um indicador fraco de capacidade.