Value Cache no Zabbix: como validar o sizing usando diaginfo=valuecache

Quando aparece alerta ou dúvida sobre Value Cache no Zabbix, uma reação comum é aumentar ValueCacheSize.

Só que o tamanho configurado, sozinho, não diz se o cache está apertado.

Em uma coleta real, o servidor tinha:

1
ValueCacheSize=1024M

E o diagnóstico em runtime mostrava aproximadamente:

1
2
3
4
5
6
Items: 23340
values: 100737

Memory:
  free: 1066455488
  used:    6059408

Ou seja: naquela fotografia, a maior parte da área alocada estava livre.

A conclusão não era “1 GB é o tamanho ideal”.

Era outra:

antes de aumentar cache, medir o cache que existe.

O comando que interessa #

No Zabbix Server, o runtime control aceita diagnósticos específicos.

Para Value Cache:

1
zabbix_server -R diaginfo=valuecache

A saída pode trazer informações como:

1
2
3
4
5
6
7
8
9
== value cache diagnostic information ==
Items: ...
values: ...
mode: ...
Memory:
  size: free:... used:...
  chunks: ...
Top.values:
  itemid:... values:... request.values:...

É muito mais útil do que olhar apenas a linha do arquivo de configuração.

Primeiro: confirme o valor configurado #

1
grep -E '^ValueCacheSize=' /etc/zabbix/zabbix_server.conf

Na coleta usada neste artigo, o valor era:

1
ValueCacheSize=1024M

O mesmo inventário também registrava outros caches e quantidades de workers, mas eles têm papéis diferentes.

Não trate CacheSize, HistoryCacheSize, TrendCacheSize e ValueCacheSize como se fossem a mesma reserva.

Depois compare `used` e `free` #

Naquela amostra, o diagnóstico mostrava cerca de 6 MB usados e mais de 1 GB livre dentro da área reportada pelo Value Cache.

Isso é uma fotografia muito folgada.

Não justificaria aumentar o parâmetro naquele momento com base apenas em “cache pode estar alto”.

Por outro lado, uma única fotografia também não garante que o cache nunca se aproxima do limite.

Eu repetiria a coleta em horários diferentes:

1
2
date -Is
zabbix_server -R diaginfo=valuecache

Especialmente:

durante pico de coleta;
durante problemas conhecidos;
depois de crescimento relevante de itens;
depois de alteração de templates;
em horários de housekeeper ou processamento intenso.

`Top.values` ajuda a entender quem usa o cache #

A saída recuperada também listava diversos itemid com quantidade de valores armazenados/requisitados.

Isso ajuda a sair da pergunta genérica:

o cache está grande?

para perguntas melhores:

1
2
3
4
quais itens estão puxando mais valores?
há padrões concentrados em determinados templates?
funções de trigger estão exigindo histórico maior?
o crescimento veio de quantidade de itens ou da forma como são consultados?

O diagnóstico não entrega sozinho toda a causa, mas aponta para onde investigar.

Um cuidado com `diaginfo`: nem toda seção existe em toda versão #

Na mesma coleta foram tentados comandos como:

1
2
zabbix_server -R diaginfo=processes
zabbix_server -R diaginfo=cache

E a versão em questão respondeu:

1
Unknown diaginfo section

Enquanto:

1
2
zabbix_server -R diaginfo=historycache
zabbix_server -R diaginfo=valuecache

retornaram informação útil.

Isso é um bom lembrete: não copie uma lista de comandos de outra versão presumindo suporte idêntico.

Teste a seção na versão real.

Cache cheio e cache grande são problemas diferentes #

Imagine dois cenários.

Cenário A #

1
2
3
ValueCacheSize=256M
used≈245M
free≈11M

Aqui existe evidência de pressão e vale investigar tendência, workload e sizing.

Cenário B #

1
2
3
ValueCacheSize=1024M
used≈6M
free≈1017M

Aqui aumentar para 2 GB seria difícil de justificar com essa amostra.

O segundo cenário também pode motivar a pergunta oposta:

esse cache está superdimensionado?

Mas reduzir memória em produção também exige observação ao longo do tempo, não uma leitura isolada.

Correlacione com sintomas reais #

Antes de mexer em ValueCacheSize, eu procuraria:

1
2
3
4
5
6
7
8
alertas de cache
logs do zabbix_server
tendência de uso ao longo do dia
crescimento do número de itens
trigger functions pesadas
processos busy
CPU/load
memória disponível no host

Se o host está pressionado de memória, reservas superdimensionadas também importam.

Se há sobra de RAM e o cache está saudável, talvez não exista ação necessária.

Não confunda memória reservada com memória efetivamente útil #

Parâmetros grandes podem parecer “seguros”, mas toda reserva compete com o restante do processo e do sistema.

Por isso eu tento responder duas perguntas antes de ajustar:

1
2
1. O cache chega perto do limite?
2. O host tem memória suficiente para a reserva proposta?

A resposta precisa considerar o conjunto do Zabbix, banco de dados e sistema operacional.

Um roteiro simples #

1. Registrar configuração #

1
2
grep -E '^(ValueCacheSize|CacheSize|HistoryCacheSize|TrendCacheSize)=' \
  /etc/zabbix/zabbix_server.conf

2. Coletar runtime #

1
zabbix_server -R diaginfo=valuecache

3. Repetir em horários relevantes #

1
2
3
4
normal
pico
incidente
pós-mudança

4. Correlacionar com host #

1
2
3
free -m
vmstat 1 10
uptime

5. Só então decidir sizing #

Documentar:

1
2
3
4
5
6
antes
motivo
tamanho proposto
margem esperada
como validar depois
rollback

Por que tirei `256M` do título original #

A pauta editorial nasceu com a pergunta:

ValueCacheSize=256M é suficiente?

Mas a coleta técnica que consegui religar tinha 1024M, não 256M.

Eu poderia usar 256M como exemplo teórico, mas isso faria o título parecer um caso que a fonte não comprova.

Então a pergunta foi generalizada para o que a evidência realmente sustenta:

como validar o sizing do Value Cache usando o diagnóstico do próprio Zabbix.

O que a fonte prova #

A coleta recuperada comprova:

configuração ValueCacheSize=1024M;
diaginfo=valuecache funcionando;
23 mil+ itens representados no diagnóstico;
100 mil+ valores no cache;
aproximadamente 6 MB usados na fotografia coletada;
ampla memória livre naquela amostra;
Top.values listando itens consumidores;
algumas outras seções de diaginfo não suportadas naquela versão/comando.

Nenhum hostname, IP ou identificador operacional é necessário para a explicação e foi removido.

O principal aprendizado #

ValueCacheSize é configuração.

diaginfo=valuecache é evidência de runtime.

Quando os dois discordam da sensação de “cache apertado”, eu confio primeiro na medição e observo tendência antes de aumentar memória por hábito.