# Cloudflare Analytics Engine: métricas, logs e decisões de produto
> Entenda Analytics Engine, Workers Logs e Traces: o que medir, como lidar com alta cardinalidade, custo, privacidade e decisões orientadas por evidência.
**Autores:** Mauro Mequelussi
**Publicado:** 2026-07-29T12:00:00.000Z
**Atualizado:** 2026-07-29T12:00:29.088307873Z
**Tags:** analytics-engine, workers, observabilidade, metricas, cloudflare
---
Você não melhora um Worker olhando apenas se ele respondeu 200. Um produto precisa saber quais links foram clicados, qual rota ficou lenta, onde ocorre erro, quanto a fila atrasa e se uma regra de cache realmente reduz trabalho. Cloudflare Analytics Engine e Workers Observability cobrem partes diferentes dessa pergunta.

Analytics Engine registra eventos de alta cardinalidade e permite consulta SQL. Workers Logs e Traces ajudam a depurar execução. Em conjunto, eles evitam dois extremos: logar dados demais até ficar caro e não ter evidência quando uma automação falha.

## Analytics Engine, Logs e Traces: diferenças

| Ferramenta | Melhor uso | Não use como |
| --- | --- | --- |
| Analytics Engine | métricas de produto com muitos IDs distintos | banco relacional ou log completo de payload |
| Workers Logs | investigar request e erro recente | histórico analítico de longo prazo |
| Workers Traces | CPU, duração, gargalos e caminhos de execução | substituto de métricas de negócio |
| Axiom/Logpush | retenção/consulta externa e alertas | desculpa para registrar segredos |

No serviço de links, por exemplo, cada clique pode registrar slug, campanha, país, referenciador normalizado e resultado sem criar uma tabela transacional para cada pageview. O evento deve ser enxuto; o banco guarda regras de negócio, não telemetria de cada visita.

## O que significa alta cardinalidade?

Um campo como `slug`, `visitor_id` ou `campaign_id` pode ter milhões de valores. Sistemas de métricas tradicionais sofrem quando cada valor cria uma série nova. Analytics Engine foi desenhado para receber dimensões de alta cardinalidade e consultar depois por SQL.

O binding permite até 20 blobs, 20 doubles e um index por ponto; blobs somados têm limite de 16 KB, e uma invocação pode gravar até 250 pontos. Dados ficam retidos por três meses segundo a documentação atual. Isso pede disciplina: escreva dimensões úteis, não o JSON inteiro de uma request.

```ts
env.AE_LINK_CLICKS.writeDataPoint({
  blobs: [slug, country, result],
  doubles: [1],
  indexes: [campaignId],
})
```

## Preço e retenção

O preço deve ser verificado no painel e na documentação antes de escalar. A referência de observabilidade usada no projeto lista 10 milhões de writes mensais incluídos no Workers Paid e US$ 0,25 por milhão adicional, com retenção de 90 dias para Analytics Engine. Workers Logs tem franquias/retenção próprias e Traces tem preço por span após franquia. A regra é simples: eventos de produto são agregáveis; payloads de depuração são amostrados e protegidos.

Para custo, calcule `eventos por request × requests por mês`. Se cada clique gera um ponto e você tem 2 milhões de cliques, a conta é pequena. Se cada middleware gera cinco pontos sem valor de decisão, o volume cresce sem melhorar produto.

::callout{type="warning" title="Telemetria também é dado pessoal"}
Não escreva token, e-mail, CPF, telefone, conteúdo de conversa ou URL assinada em blobs, logs ou traces. Normalize, reduza e aplique retenção compatível com a finalidade.
::

## Um painel que ajuda a decidir

Comece por perguntas que geram ação:

1. Quais short links têm mais clique e de qual campanha?
2. Qual rota aumentou p95 de latência depois do deploy?
3. Qual consumer de Queue acumulou retry ou DLQ?
4. Que porcentagem das respostas de IA virou sugestão aceita?
5. Cache de blog reduziu leitura do banco ou apenas mascarou erro?

Cada pergunta deve ter dono, janela de tempo e ação associada. “Vamos registrar tudo” não é observabilidade; é custo e risco sem decisão.

## Prós e contras

Analytics Engine oferece escrita simples no Worker e dimensão de alta cardinalidade. Em troca, sua modelagem é mais próxima de eventos temporais do que de SQL relacional. Logs são rápidos para investigação, mas retenção curta não substitui auditoria. Traces mostram execução, mas não sabem qual métrica de negócio é importante sem você instrumentar esse contexto.

::read-more{slug="cloudflare-workers-vibe-coding" label="Voltar: Workers como base para APIs e produtos na edge" placement="mid_content"}
## Checklist de instrumentação

- [ ] cada evento tem finalidade de produto ou operação;
- [ ] dimensões possuem nomes e valores normalizados;
- [ ] dados sensíveis foram removidos antes de escrever;
- [ ] índice é reservado para filtro realmente frequente;
- [ ] painéis mostram volume, erro, latência e custo;
- [ ] alertas têm limiar, dono e runbook;
- [ ] retenção foi considerada antes de usar logs como banco.

## Perguntas frequentes

### Analytics Engine substitui o banco de dados?

Não. Ele é ótimo para eventos e agregação temporal. Para estado transacional, relações e regras de produto, use o banco apropriado.

### Devo usar `await` ao escrever métrica?

Não bloqueie uma resposta crítica esperando telemetria se o binding já oferece escrita própria para o runtime. Ainda assim, trate instrumentação como parte testável do fluxo e confirme o comportamento do SDK atual.

### Logs são suficientes para acompanhar erro de produção?

Logs ajudam, mas métricas e traces mostram tendência, impacto e CPU. Use as três camadas com amostragem e dados mínimos.

### Fontes e leitura recomendada

- [Cloudflare Analytics Engine](https://developers.cloudflare.com/analytics/analytics-engine/)
- [Limites do Analytics Engine](https://developers.cloudflare.com/analytics/analytics-engine/limits/)
- [Workers Observability](https://developers.cloudflare.com/workers/observability/)
- [Preços de Workers](https://developers.cloudflare.com/workers/platform/pricing/)