System Design/03 - Qualidade/Monitoring2 min
Usage Monitoring
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Mede quem usa o quê, quanto e como — a ponte entre a operação técnica e as decisões de produto e custo.
O que medir
| Categoria | Exemplos |
|---|---|
| Adoção | Usuários ativos, funcionalidades usadas, retenção |
| Consumo por cliente | Requisições, armazenamento, banda — base de cobrança |
| Padrão temporal | Pico, sazonalidade, distribuição por região |
| Custo por unidade | Custo por requisição, por usuário, por tenant |
| Capacidade | Quanto falta para o limite; quando será atingido |
Para que serve na prática
- Planejamento de capacidade — projetar quando o recurso acaba, em vez de descobrir no pico
- Cobrança e cotas — medição confiável é pré-requisito de Throttling por plano
- Priorização — funcionalidade que ninguém usa não merece otimização
- Detecção de abuso — um cliente consumindo desproporcionalmente
- FinOps — atribuir custo de infraestrutura a times e produtos
Trade-offs
O maior risco aqui é de privacidade e conformidade. Dados de uso são dados pessoais em boa parte das jurisdições: exigem base legal, retenção limitada, anonimização quando possível, e cuidado com o que vai parar em log ou em ferramenta de terceiro.
O segundo é de custo e cardinalidade: uma métrica com dimensão por usuário, em um sistema com milhões de usuários, é impagável em um sistema de métricas. Agregação em pipeline de eventos (e não em métricas) é o caminho para granularidade alta.
Há também a diferença entre medição para cobrança e medição para observação. Cobrança exige precisão auditável e não pode amostrar; observação tolera aproximação. Tratar as duas com o mesmo pipeline costuma resultar em cobrança imprecisa ou observabilidade cara demais.
E o clássico: métrica vira meta e deixa de ser boa métrica. Otimizar "número de cliques" pode piorar o produto.
Exemplo prático
Uma API com planos de uso:
por cliente, por hora: requisições · bytes · tempo de CPU
→ cobrança e enforcement de cota
agregado, por endpoint: chamadas · latência · erro
→ priorização de engenharia
projeção: crescimento de armazenamento
→ em 90 dias atinge o limite atual
A terceira linha é a que evita incidente: com a projeção, a ampliação é planejada e executada numa janela tranquila. Sem ela, o limite é descoberto quando as escritas começam a falhar — normalmente no pior momento possível.
Relacionado
Parte de Monitoring · roadmap.sh/system-design