O que é cardinalidade de métricas e como controlar o custo da observabilidade?
Muitas empresas descobrem o problema na fatura: a plataforma de observabilidade, que começou barata, passa a custar mais que a infraestrutura monitorada. Uma das causas mais frequentes é a cardinalidade das métricas, somada a logs e traces coletados sem critério.
O que é cardinalidade
Em sistemas de métricas, cada combinação única de nome e rótulos (labels ou tags) forma uma série temporal separada. Cardinalidade é a quantidade dessas séries.
Um exemplo: uma métrica de requisições HTTP com os rótulos método (5 valores), rota (50), código de status (10) e instância (20) pode gerar até 5 × 50 × 10 × 20 = 50 mil séries. Acrescente um rótulo com o identificador do usuário, com 100 mil valores possíveis, e o potencial passa de bilhões. Cada série consome memória, armazenamento e processamento, e muitas plataformas cobram por série ou por métrica personalizada.
Onde a cardinalidade explode
- Identificadores ilimitados como rótulo: ID de usuário, de pedido, de sessão ou de requisição.
- URLs completas: caminhos como /pedidos/48213 em vez da rota normalizada /pedidos/{id}.
- Valores livres: mensagens de erro, nomes de arquivo ou consultas inteiras usadas como rótulo.
- Ambientes efêmeros: containers que mudam de nome a cada implantação multiplicam séries que logo deixam de receber dados.
A regra prática: rótulos devem ter um conjunto pequeno e conhecido de valores. Informação de alta cardinalidade pertence a traces e logs, que foram feitos para guardar o detalhe de cada evento.
Logs e traces também pesam
Em logs, o custo vem do volume ingerido e da retenção: mensagens de depuração esquecidas em produção, logs repetidos a cada poucos segundos e registros com o corpo inteiro das requisições. Em traces, vem da instrumentação automática sem amostragem, que guarda milhões de requisições idênticas e normais.
Nos dois casos, o problema não é coletar, mas coletar tudo, guardar por muito tempo e no armazenamento mais caro.
Práticas que controlam o custo
- Normalizar e limitar rótulos: rotas em vez de URLs, e remoção de rótulos sem uso no pipeline, por exemplo no Collector do OpenTelemetry.
- Agregar antes de guardar: quando só o total importa, descarte as dimensões de detalhe.
- Amostrar traces: guarde todos os erros e lentidões e só uma fração do tráfego normal.
- Filtrar logs na origem: níveis adequados por ambiente e descarte de mensagens repetitivas sem valor.
- Retenção em camadas: dados recentes em armazenamento rápido e o histórico em armazenamento barato ou só em forma agregada.
- Medir o próprio consumo: acompanhe as séries, o volume por serviço e o custo por equipe, para que quem gera o dado veja quanto ele custa.
Equilíbrio entre custo e capacidade de investigar
Cortar sem critério também sai caro: o dado que faltou é justamente o que explicaria o próximo incidente. O caminho é partir das perguntas que a operação precisa responder, como os SLOs dos serviços críticos, os alertas e as investigações mais comuns, e garantir que esses sinais estejam completos. O restante passa por amostragem, agregação ou retenção curta.
Revisões periódicas, por exemplo trimestrais, ajudam a eliminar painéis, métricas e logs que ninguém consulta.
Cardinalidade é o número de séries temporais geradas pelos rótulos de uma métrica, e identificadores ilimitados a fazem explodir. Rótulos com poucos valores, amostragem de traces, filtro de logs e retenção em camadas controlam o custo sem perder o que importa para investigar.
Este conteúdo foi útil?
Revisão técnica VIPER IT — última atualização em 10 de outubro de 2026.