TTL no ClickStack
${TABLES_TTL} é substituído pela retenção configurada (3 dias, a menos que seja alterada) quando o collector cria a tabela:
PARTITION BY. Essa cláusula pode conter uma expressão SQL em qualquer coluna, cujo resultado definirá para qual partição uma linha será enviada. Isso faz com que os dados sejam associados logicamente (por meio de um prefixo comum no nome da pasta) a cada partição no disco, que então pode ser consultada isoladamente. No exemplo acima, o schema padrão otel_logs particiona por dia usando a expressão toDate(Timestamp). À medida que as linhas são inseridas no ClickHouse, essa expressão será avaliada em relação a cada linha e encaminhada para a partição resultante, se ela existir (se a linha for a primeira de um dia, a partição será criada). Para mais detalhes sobre particionamento e suas outras aplicações, consulte “Partições de tabela”.
O schema da tabela também inclui TTL toDateTime(Timestamp) + ${TABLES_TTL} e a configuração ttl_only_drop_parts = 1. A primeira cláusula garante que os dados serão removidos quando tiverem mais do que o TTL configurado (3 dias por padrão). A configuração ttl_only_drop_parts = 1 faz com que apenas partes de dados em que todos os dados expiraram sejam removidas (em vez de tentar excluir linhas parcialmente). Como o particionamento garante que dados de dias diferentes nunca sejam “mesclados”, os dados podem, assim, ser removidos com eficiência.
Por padrão, dados com TTL expirado são removidos quando o ClickHouse mescla partes de dados. Quando o ClickHouse detecta que os dados expiraram, ele executa uma mesclagem fora do cronograma.
Agendamento de TTLTTLs não são aplicados imediatamente, mas sim de acordo com um agendamento, como observado acima. A configuração de tabela MergeTree
merge_with_ttl_timeout define o atraso mínimo, em segundos, antes de repetir uma mesclagem com TTL de exclusão. O valor padrão é 14400 segundos (4 horas). Mas esse é apenas o atraso mínimo; a mesclagem de TTL pode demorar mais para ser acionada. Se o valor for muito baixo, muitas mesclagens fora do cronograma serão executadas, o que pode consumir muitos recursos. A expiração de TTL pode ser forçada com o comando ALTER TABLE my_table MATERIALIZE TTL.Como modificar o TTL
- Modificar os schemas da tabela (recomendado). Para isso, é necessário se conectar à instância do ClickHouse, por exemplo, usando o clickhouse-client ou o Cloud SQL Console. Por exemplo, podemos modificar o TTL da tabela
otel_logsusando o seguinte DDL:
- Modifique o OTel collector. O ClickStack OpenTelemetry collector cria tabelas no ClickHouse caso elas ainda não existam. Isso é feito por meio do ClickHouse exporter, que expõe um parâmetro
ttlusado para controlar a expressão TTL padrão, por exemplo.
TTL em nível de coluna
Body caso novos metadados dinâmicos sejam adicionados e ainda não tenham sido extraídos no momento da inserção, por exemplo, um novo label do Kubernetes. Após um período, por exemplo, de 1 mês, pode ficar evidente que esses metadados adicionais não são úteis, reduzindo assim o valor de manter a coluna Body.
Abaixo, mostramos como a coluna Body pode ser removida após 30 dias.
Para especificar um TTL no nível da coluna, os usuários precisam definir seu próprio schema. Isso não pode ser especificado no OTel collector.