Downsampling e camadas de retenção para dados de séries temporais

Objetivo

Responder a perguntas de longo prazo (um ano de latência, três anos de leituras de medidores) com uma fração do custo de armazenamento e de varredura das amostras brutas, mantendo a resolução bruta durante o período em que ela é de fato consultada.

Pré-requisitos

Uma tabela ou um armazenamento particionado por tempo, e uma decisão sobre o que cada camada deve ser capaz de responder. A documentação de armazenamento do Prometheus (citada) mostra a política mais simples: um tempo de retenção das amostras (--storage.tsdb.retention.time, padrão de 15 dias quando nem ele nem um limite de tamanho estão definidos) ou um limite de tamanho que remove primeiro os blocos mais antigos. O Thanos (citado) descreve o downsampling como a reescrita das séries para reduzir a resolução sem perder precisão em intervalos de tempo mais longos, armazenando em cada chunk reduzido o count, o sum, o min, o max e uma série de contador, de modo que os dados mais grosseiros ainda possam ser agregados. O date_bin do PostgreSQL (citado) agrupa um timestamp em um intervalo (stride) alinhado a uma origem especificada, que é a primitiva de que um rollup em SQL precisa.

Passos

1. Registre as camadas como (resolução, retenção, finalidade): por exemplo, dados brutos por 14 dias para análise de incidentes, intervalos de 5 minutos por 13 meses para tendências de capacidade, intervalos de 1 hora por 5 anos para relatórios. Os períodos de retenção são uma decisão a documentar, não um número a copiar de outro lugar.
2. Para cada intervalo, armazene apenas estatísticas reagregáveis: count, sum, min, max e, para contadores, o incremento. Calcule as médias como sum dividido por count no momento da consulta; não armazene médias nem percentis, pois eles não podem ser combinados em um intervalo mais grosseiro. Se percentis forem necessários, armazene um histograma com limites de buckets fixos.
3. Alinhe os intervalos com date_bin(stride, ts, origin) usando uma única origem fixa (a época Unix ou a meia-noite UTC), para que os intervalos de execuções e tabelas diferentes coincidam.
4. Agende o rollup de um intervalo apenas depois de passada a janela de dados atrasados desse intervalo, e faça com que ele substitua o intervalo em vez de somar a ele, para que uma nova execução seja segura.
5. Expire uma camada removendo partições ou blocos inteiros, nunca por exclusões linha a linha; verifique o rollup de uma partição (contagem de linhas, soma de uma medida) antes de remover a partição bruta correspondente.
6. Exponha as camadas por meio de uma única view ou camada de consulta, que escolha a camada mais fina que cubra o intervalo solicitado.

Resultado esperado

As consultas de longo prazo varrem a camada grosseira e retornam em tempo limitado; o armazenamento cresce apenas com as camadas grosseiras; os dados brutos permanecem durante o período em que são usados.

Limites e base de verificação

Dados reduzidos não conseguem responder a perguntas sobre picos menores que um intervalo. Quando uma consulta atravessa o limite entre camadas, o resultado contém duas resoluções e deve ser rotulado como tal. O protocolo deriva da documentação citada; nenhuma medição é afirmada.