Atributos de Alta Cardinalidade em Spans Podem Disparar Custos de Observabilidade
Aprofundamento CEVIU
Aprofundamento
A observabilidade moderna, essencial para entender sistemas distribuídos, trouxe o desafio de gerenciar grandes volumes de dados. Atributos de alta cardinalidade em spans, especialmente quando promovidos a dimensões de métricas, são um gargalo silencioso. Eles causam um inchaço nas séries temporais, disparando custos. O problema não está no volume de spans, mas na quantidade de combinações únicas de valores que um atributo pode gerar. Uma métrica não é cobrada pelo número de pontos de dados, mas pela existência de uma série ativa, impactada diretamente pela cardinalidade.
O OpenTelemetry Collector, através dos conectores span_metrics e do processador transform, oferece controles cruciais. Ferramentas como aggregation_cardinality_limit e metrics_expiration são vitais. O primeiro estabelece um teto para a quantidade de combinações únicas, prevenindo explosões de custo. O segundo garante que séries não usadas expirem, evitando que incidentes temporários criem custos permanentes. Ignorar estas configurações, que vêm desativadas por padrão, é um convite para surpresas desagradáveis na fatura.
O que mudou
Em nossa cobertura anterior, como no artigo “A Pedra Filosofal do Tracing Distribuído: Amostragem” de 24 de março de 2026, focamos na amostragem como principal estratégia para controlar o volume de dados de tracing. A amostragem é eficiente para reduzir bytes e, consequentemente, custos de armazenamento de traces. No entanto, a discussão atual aprofunda o entendimento: ela não resolve o problema da alta cardinalidade em métricas derivadas de spans. Agora sabemos que a amostragem atua no eixo de volume, mas o custo das métricas, muitas vezes maior, é impulsionado pela cardinalidade, que exige controles específicos, como os do OpenTelemetry Collector.
Por que isso importa
Para equipes de dados, engenharia e analytics, entender a diferença entre custos de volume de traces e custos de cardinalidade de métricas é vital. A confusão entre esses eixos leva a estratégias ineficazes, como tentar "amostrar mais" para reduzir custos de métricas, sem sucesso. O gerenciamento proativo de atributos de spans, agrupando-os e estabelecendo limites de cardinalidade, é fundamental para manter os custos de observabilidade previsíveis. Isso evita que uma simples adição de uma dimensão a um dashboard se transforme em um aumento percentual significativo na fatura mensal, garantindo a sustentabilidade financeira da infraestrutura de monitoramento.
Linha do tempo
CEVIU publica "A Pedra Filosofal do Tracing Distribuído: Amostragem"
CEVIU publica "Monitorando o Desempenho de Agentes Cortex com Dados de Rastreamento"
Notícia atual sobre custos de observabilidade e alta cardinalidade em spans
Perguntas frequentes
O que é alta cardinalidade em atributos de spans?
Alta cardinalidade se refere a um atributo de span que possui um grande número de valores únicos. Por exemplo, um tenant.id em um sistema multi-tenant, onde cada ID de inquilino gera uma nova combinação quando usado como dimensão de métrica.
Por que a amostragem não resolve o problema de alta cardinalidade em métricas?
A amostragem reduz o volume de traces armazenados, afetando os custos por byte. No entanto, ela não limita as combinações únicas de labels que são geradas quando atributos de span são convertidos em métricas. Mesmo com pouquíssimos traces amostrados, se um atributo ainda gerar muitas combinações distintas, a quantidade de séries de métricas permanece alta, e o custo associado também.
Quais ferramentas do OpenTelemetry Collector ajudam a gerenciar a cardinalidade?
O OpenTelemetry Collector oferece configurações chave como aggregation_cardinality_limit, que define um máximo de combinações únicas para agregação de métricas, e metrics_expiration, que remove séries métricas inativas após um período, ambos parte do conector span_metrics.
Qual é a diferença entre um problema de volume e um problema de cardinalidade nos custos de observabilidade?
Um problema de volume está ligado à quantidade de dados, como bytes armazenados de traces, e é gerenciado por amostragem. Um problema de cardinalidade, por outro lado, refere-se à quantidade de séries únicas de métricas geradas por atributos, e é gerenciado por limites de agregação e expiração.
Fontes
- thinhdanggroup.github.iofonte original
- Categoria
- CEVIU Dados
- Publicado
- 21 de setembro de 2026
- Editoria
- CEVIU Dados

