Housekeeper e TimescaleDB: desligar não delega, impede

“Agora que temos particionamento, pode desligar o housekeeper.” É a decisão que mais enche disco de Zabbix em escala — e ela inverte o funcionamento real. Com TimescaleDB, é o housekeeper quem descarta as partições vencidas.

O sintoma

O ambiente migrou para TimescaleDB. As consultas ficaram mais rápidas, a remoção de dados antigos parou de travar o banco, e alguém encerrou a mudança desligando o housekeeping de histórico e tendências — parecia redundância óbvia.

Semanas depois o disco volta a crescer. E o diagnóstico é difícil justamente porque o crescimento não tem a cara do problema antigo: a escrita continua particionada e eficiente, o desempenho está bom. Ninguém liga o volume de hoje a uma decisão tomada no mês passado.

Por que a orientação errada soa plausível

Ela parte de uma premissa correta. Particionamento realmente substitui o mecanismo mais caro do housekeeper: a remoção linha a linha de history e trends. Em vez de DELETE em milhões de registros, o banco descarta a partição inteira. É mais rápido, não fragmenta e não compete com a coleta.

O erro está no salto seguinte: concluir que, por isso, o housekeeper deixou de ser necessário. Com TimescaleDB, é exatamente o contrário.

O que a documentação oficial exige

A documentação do Zabbix 7.0 é explícita. Para aproveitar o particionamento automático de history e trends do TimescaleDB, é preciso habilitar Override item history period e Override item trend period — e também manter o Enable internal housekeeping ligado para histórico e tendências.

Sem isso, nas palavras da própria documentação, os dados continuam sendo armazenados em partições, porém o housekeeper não descarta as partições vencidas, e avisos de configuração incorreta passam a ser exibidos.

Isso explica o sintoma demorado. O que parou não foi a escrita nem a performance — foi o descarte. As partições se acumulam, uma por período, até o volume acabar.

E os avisos?

O Zabbix avisa. A configuração inconsistente gera aviso na interface. Só que ele aparece numa tela de administração que ninguém reabre depois que a migração foi dada como concluída.

O escopo real do housekeeper

Vale entender o que mais está sob responsabilidade dele, porque isso independe de particionamento. O housekeeping é configurável por tarefa, separadamente, para eventos e alertas, serviços, sessões de usuário, histórico e tendências. A retenção de auditoria fica em seção própria.

Há uma ordem interna que importa: um evento só é removido se não estiver associado a nenhum problema. O housekeeper apaga primeiro os problemas e depois os eventos, para não deixar registro órfão.

O que configurar em cada cenário

Como verificar no seu ambiente

1. Confirme qual mecanismo está realmente em uso

Muita gente acredita ter particionamento porque alguém configurou um dia. Confirme no banco, não na memória da equipe:

-- Existe hypertable do TimescaleDB?
SELECT hypertable_name
FROM timescaledb_information.hypertables;

-- Quantas partições (chunks) existem por hypertable?
SELECT hypertable_name, COUNT(*) AS chunks
FROM timescaledb_information.chunks
GROUP BY hypertable_name
ORDER BY chunks DESC;

Um número de chunks que só cresce, e cujo mais antigo é bem anterior ao seu período de retenção, é o diagnóstico deste artigo.

2. Veja onde o volume está

SELECT relname AS tabela,
       pg_size_pretty(pg_total_relation_size(c.oid)) AS tamanho
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public' AND c.relkind IN ('r','p')
ORDER BY pg_total_relation_size(c.oid) DESC
LIMIT 15;

3. Confira a tela de housekeeping

Vá em Administração, seção de housekeeping, e verifique três coisas de uma vez: se o housekeeping interno de histórico e tendências está ligado, se os dois overrides estão habilitados, e se há algum aviso de configuração incorreta exibido. Em ambiente com TimescaleDB, os três precisam estar em ordem — não dois de três.

Por que o erro é tão persistente

Porque a recompensa é imediata e o custo é adiado. No dia em que se desliga o housekeeper, o banco fica visivelmente mais leve e a decisão parece acertada. A conta chega semanas depois, num sintoma que não se parece com a causa.

É o mesmo padrão de boa parte dos problemas de operação de monitoramento: o que quebra não é a ferramenta, é uma decisão tomada com informação incompleta e nunca revisada.