Gerenciamento de Logs: como funciona

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado ago/2021Atualizado set/2026

Um gigabyte de log ingerido no CloudWatch Logs em São Paulo custa US$ 0,90. Em contrapartida, guardar esse mesmo gigabyte por um mês inteiro custa US$ 0,0408. Isto é, a entrada sai 22 vezes mais cara que o arquivo.

Essa razão inverte a intuição de quem corta custo apagando histórico. Ou seja, encurtar a janela de 90 para 30 dias mexe em centavos por gigabyte. Já filtrar o que entra mexe em dólares. Por isso a primeira decisão de um pipeline de log é o que não coletar.

Este texto traz três medições feitas em laboratório próprio, em 3 de setembro de 2026. A primeira é o preço real da ingestão nas duas maiores nuvens. As outras duas comparam Loki e Elasticsearch sobre os mesmos 50 mil eventos, além de testar uma política de amostragem.

O que o gerenciamento de logs decide

Gerenciar logs é decidir quatro coisas: o que entra, em que formato, por quanto tempo fica e quem consegue perguntar. A parte barata é a coleta, que agente e biblioteca já resolvem. As outras três, no entanto, definem a fatura no fim do mês e o tempo de resposta durante um incidente.

Para a definição de log, os níveis de severidade e os campos obrigatórios, vale o artigo sobre logs na observabilidade. Aqui o recorte é outro: o que fazer com eles depois que já estão sendo gerados.

Essas decisões acontecem em quatro etapas. A coleta pega o evento na origem, seja por agente, por Syslog ou por instrumentação com OpenTelemetry. Em seguida, a ingestão normaliza e cobra. O armazenamento define por quanto tempo a evidência existe. A consulta determina se você acha o evento em segundos ou em uma tarde.

Nessas três últimas etapas está o preço. É nelas, portanto, que a decisão de ferramenta aparece.

Quanto custa um gigabyte de log

Duas das maiores nuvens publicam preço em API aberta, sem login e sem chave. Por isso, o bloco abaixo lê a conta do CloudWatch Logs em São Paulo e imprime as quatro linhas que importam.

const https = require('https');
const URL = 'https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/' +
  'AmazonCloudWatch/current/sa-east-1/index.json';
const QUERO = {
  'SAE1-DataProcessing-Bytes': 'ingestao Standard (por GB)',
  'SAE1-DataProcessingIA-Bytes': 'ingestao Infrequent Access (por GB)',
  'SAE1-TimedStorage-ByteHrs': 'armazenamento (por GB por mes)',
  'SAE1-DataScanned-Bytes': 'consulta Logs Insights (por GB varrido)',
};

https.get(URL, (r) => {
  let b = '';
  r.setEncoding('utf8');
  r.on('data', (d) => (b += d));
  r.on('end', () => {
    const d = JSON.parse(b);
    console.log('tabela publicada em ' + d.publicationDate);
    for (const [sku, p] of Object.entries(d.products)) {
      const rotulo = QUERO[(p.attributes || {}).usagetype];
      if (!rotulo || !d.terms.OnDemand[sku]) continue;
      for (const o of Object.values(d.terms.OnDemand[sku]))
        for (const pd of Object.values(o.priceDimensions))
          if (pd.beginRange === '0')
            console.log('USD ' + Number(pd.pricePerUnit.USD).toFixed(4) + '  ' + rotulo);
    }
  });
});

Executado no dia do teste, o script devolveu isto:

node preco-log.cjs

tabela publicada em 2026-08-31T09:21:48Z
USD 0.0408  armazenamento (por GB por mes)
USD 0.4500  ingestao Infrequent Access (por GB)
USD 0.0090  consulta Logs Insights (por GB varrido)
USD 0.9000  ingestao Standard (por GB)

Rodar a mesma leitura contra a tabela de varejo da Azure e contra a região da Virgínia completa o quadro.

Três leituras saem dessa tabela. Primeiro, a região move a conta: São Paulo custa 80% mais que a Virgínia na AWS. Na Azure, Brazil South custa exatamente o dobro de East US. Ou seja, preço de log sem região declarada é número errado.

Segundo, a classe do log vale metade da fatura. Nesse caso, trocar a classe padrão pela de acesso raro corta a ingestão em 50% na AWS. O custo é perder consulta interativa sobre aquele grupo.

Terceiro, o armazenamento quase não pesa. Um ano inteiro guardando um gigabyte em São Paulo custa US$ 0,4896. Isso é menos, inclusive, que a única ingestão de US$ 0,90 que colocou o dado lá.

Uma ressalva de comparação: o preço de ingestão da Azure já embute 31 dias de retenção, enquanto o da AWS cobra armazenamento à parte. Comparar só a primeira linha exagera a diferença entre as duas.

Loki ou Elasticsearch: onde cada um cobra

A escolha entre um motor de índice invertido e um motor de rótulos costuma ser descrita por lista de recursos. Medida, no entanto, ela vira uma troca simples entre disco e tempo de resposta.

Para medir, o laboratório carregou os mesmos 50.000 eventos em JSON, gerados por semente fixa, em três destinos. Em seguida, fez a mesma pergunta nos três: quantos eventos do payment-api responderam 500 na janela. As três respostas bateram em 328, o que valida a comparação.

Com mapping declarado, o Elasticsearch ocupou 3,9 vezes o disco do Loki e respondeu 10 vezes mais rápido. Cada um cobra numa moeda diferente. Portanto, a decisão depende de qual delas dói mais na sua operação.

Por dentro, a diferença é de arquitetura. O Loki guarda o corpo comprimido e indexa apenas os rótulos, logo varre no momento da pergunta. Já o Elasticsearch monta o índice invertido na entrada, paga em disco e depois responde sem varrer.

Em resumo: com poucas consultas por dia, o Loki sai barato. Em contrapartida, com investigação constante, o índice se paga.

A armadilha do mapping padrão

Deixar o Elasticsearch inferir o mapping parece conveniente, porém cobra caro em dois lugares. O índice automático ocupou 1,27 vez o disco do declarado, porque guarda cada campo de texto duas vezes: analisado e como chave exata.

Pior que o disco, contudo, é o segundo custo: ele não aparece como erro. Uma consulta por termo exato no campo analisado devolve zero em vez do número certo.

# mesma pergunta, mesmo indice, so muda o campo consultado
curl -s localhost:9211/logs-padrao/_count -H 'content-type: application/json' -d \
  '{"query":{"term":{"service.name":"payment-api"}}}'
{"count":0}                          # campo analisado: nao casa, e nao avisa

curl -s localhost:9211/logs-padrao/_count -H 'content-type: application/json' -d \
  '{"query":{"term":{"service.name.keyword":"payment-api"}}}'
{"count":9971}                       # subcampo exato: o numero certo

Zero não é erro de sintaxe, é uma resposta. Um alerta construído sobre essa consulta fica em silêncio para sempre. Ao mesmo tempo, o painel mostra que o serviço não tem falha. Por isso, declarar o mapping antes do primeiro documento evita as duas coisas.

A política que cortou 64% sem perder um erro

Amostrar log assusta, sobretudo porque parece jogar fora evidência de incidente. O erro, porém, está em aplicar uma taxa única sobre tudo: aí o sorteio derruba erro junto com ruído.

Na política medida, a separação é por severidade. Todo WARN e todo ERROR passam inteiros. O INFO, que é rotina, entra amostrado a 10%. Já o DEBUG não entra.

# duas pipelines: o amostrador nao sabe olhar severidade sozinho
processors:
  filter/so_graves:
    logs:
      log_record:
        # a condicao diz o que DESCARTAR
        - 'attributes["SeverityText"] != "ERROR" and attributes["SeverityText"] != "WARN"'
  filter/so_info:
    logs:
      log_record:
        - 'attributes["SeverityText"] != "INFO"'
  probabilistic_sampler/dez_por_cento:
    sampling_percentage: 10
    attribute_source: record
    from_attribute: TraceId

service:
  pipelines:
    logs/graves:
      receivers: [filelog/graves]
      processors: [filter/so_graves]
      exporters: [file/graves]
    logs/rotina:
      receivers: [filelog/rotina]
      processors: [filter/so_info, probabilistic_sampler/dez_por_cento]
      exporters: [file/rotina]

Sobre os 50.000 eventos do laboratório, a conta fechou desta forma. Os graves somaram 14.870 eventos e 29,75% dos bytes. A rotina amostrada trouxe 3.008 dos 30.128 eventos de INFO, ou 9,98%, o que confere com a taxa pedida. No total ficaram 17.878 eventos e 35,76% do volume original.

No fim, a redução foi de 64,24%, com os 5.012 ERROR e os 9.858 WARN preservados na íntegra. Os 5.002 eventos de DEBUG ficaram de fora.

Traduzindo para a fatura de São Paulo: uma operação que ingere 100 GB por dia na classe padrão paga US$ 2.700 por mês. Com essa política, o mesmo dia entrega 35,76 GB e a conta cai para US$ 965,52. A diferença é de US$ 1.734,48 por mês, sem perder um evento de erro.

Como escolher a ferramenta

Escolher ferramenta não é decidir qual plataforma é melhor. O que decide é a pergunta que você faz com mais frequência, porque o motor cobra exatamente por ela.

Se a rotina é investigar incidente com filtro por campo, o índice invertido se paga: 3,9 vezes o disco em troca de resposta 10 vezes mais rápida. Por outro lado, se a rotina é guardar muito e consultar pouco, o motor de rótulos entrega o mesmo dado por um quinto do espaço. Vale sobretudo para auditoria e conformidade.

Nos serviços gerenciados a conta muda de lugar. Ali você não paga disco, paga ingestão, logo a decisão vira classe de log e região. Vale conferir os números do Amazon CloudWatch e do Azure Monitor antes de fechar contrato. Nesse sentido, a mesma arquitetura muda de preço conforme onde ela roda.

Em qualquer dos caminhos, a política de entrada vem primeiro. Vale destacar que ela é a única decisão a reduzir custo em todas as camadas, do disco à consulta.

Onde a conta fecha

O gerenciamento de logs vira problema de custo no momento em que o volume cresce sem política. As medições deste artigo apontam para o mesmo lugar: a decisão que mais economiza acontece antes do dado entrar na plataforma.

Ingerir custa 22 vezes o que custa armazenar, portanto encurtar retenção resolve pouco. A classe do log corta metade da ingestão. Além disso, a região muda a conta em 80% na AWS e em 100% na Azure. Por fim, uma política por severidade tirou 64% do volume preservando todos os erros.

Do lado do motor, a escolha é honesta nos dois sentidos: disco barato com consulta lenta, ou consulta rápida com disco caro. O que não se sustenta é adotar mapping automático e descobrir meses depois que um alerta nunca disparou porque a consulta devolvia zero.

Se a sua operação precisa desenhar essa política e ligar o resultado ao monitoramento de infraestrutura, fale com nossos especialistas.