Desafios

Observabilidade para Startups: Logs, Metricas e Traces sem Quebrar o Banco

Por Marc Molas·4 de junho de 2024·10 min de leitura

Se voce descobre os problemas em producao pelos seus usuarios, voce nao tem observabilidade -- tem um canal de suporte.

E uma situacao mais comum do que parece. A aplicacao cai, um cliente manda um email furioso, o time comeca a revisar logs no console da AWS, alguem diz "comigo funciona" e assim se passam duas horas ate alguem encontrar o problema. Parece familiar?

A observabilidade nao e um luxo de empresas grandes com times de SRE dedicados. E a capacidade de entender o que esta acontecendo no seu sistema sem precisar adivinhar. E em uma startup, onde cada incidente pode custar usuarios (e a proxima rodada de investimento), e um investimento que retorna seu custo desde o primeiro dia.

Os tres pilares da observabilidade

Existe um framework classico que divide a observabilidade em tres pilares: logs, metricas e traces. Nao sao intercambiaveis -- cada um responde a uma pergunta diferente.

Logs: O que aconteceu? Sao registros de eventos discretos. Um usuario tentou fazer login, uma transacao falhou, um servico reiniciou.
Metricas: Quanto e a que velocidade? Sao dados numericos agregados no tempo. Latencia media, taxa de erros, uso de CPU.
Traces: Onde no sistema? Sao o percurso de uma requisicao atraves de multiplos servicos. A request entrou pelo API gateway, passou pelo servico de autenticacao, consultou o banco de dados, chamou o servico de pagamentos.

Voce nao precisa dos tres desde o dia um. Mas precisa entender quando incorporar cada um.

Logs: a base de tudo

Todo sistema gera logs. A diferenca esta em se voce os gera de forma util ou se simplesmente faz console.log("erro aqui") e reza.

Logging estruturado e a primeira coisa que voce deveria implementar. Em vez de strings soltas, gere logs em formato JSON com campos consistentes: timestamp, nivel, servico, mensagem, request ID, usuario. Isso permite buscar, filtrar e agregar automaticamente.

{
  "timestamp": "2024-06-04T10:23:45Z",
  "level": "error",
  "service": "payment-api",
  "message": "Payment processing failed",
  "requestId": "abc-123",
  "userId": "user-456",
  "errorCode": "GATEWAY_TIMEOUT"
}

Os niveis de log devem significar algo. Se tudo e INFO ou tudo e ERROR, voce nao tem niveis -- tem ruido. Defina uma convencao clara: DEBUG para desenvolvimento, INFO para fluxos normais, WARN para situacoes recuperaveis, ERROR para falhas que precisam de atencao.

Centralize seus logs. Se voce precisa fazer SSH em tres servidores diferentes para investigar um problema, ja perdeu. Opcoes conforme orcamento:

Orcamento minimo: Loki + Grafana (open source, leve, perfeito para comecar)
Cloud nativo: CloudWatch Logs (AWS), Cloud Logging (GCP)
Tudo em um: Datadog, New Relic (mais caro, mas mais completo)
Classico: ELK Stack (Elasticsearch, Logstash, Kibana) -- poderoso mas requer manutencao

Metricas: os 4 sinais dourados

O Google definiu os 4 sinais dourados de monitoracao, e continuam sendo o melhor ponto de partida:

Latencia: Quanto tempo seu servico leva para responder? Nao apenas a media -- os percentis p95 e p99 sao os que importam. Se sua latencia media e 200ms mas o p99 e 5 segundos, voce tem um problema que a media esconde.
Trafego: Quantas requisicoes voce esta recebendo? Ajuda a entender padroes de uso e detectar anomalias (picos inesperados ou quedas repentinas).
Erros: Qual porcentagem das requisicoes falha? Tanto erros explicitos (HTTP 5xx) quanto implicitos (respostas corretas mas com dados erroneos).
Saturacao: Quao cheio esta seu sistema? CPU, memoria, disco, conexoes com banco de dados. Quando algo satura, todo o resto comeca a degradar.

Ha uma distincao importante entre metricas de aplicacao e metricas de infraestrutura. As de infraestrutura (CPU, memoria, disco) te dizem que algo esta errado. As de aplicacao (requisicoes por segundo, taxa de erros, latencia por endpoint) te dizem o que esta errado. Voce precisa de ambas.

Ferramentas:

Prometheus + Grafana: O padrao open source. Prometheus coleta e armazena metricas, Grafana as visualiza. Gratuito, poderoso, e com um ecossistema enorme.
Datadog: Metricas, logs e traces em uma unica plataforma. Excelente mas caro -- cuidado com a fatura.
New Relic: Similar ao Datadog. Tem um tier gratuito decente para comecar.

Traces: quando um servico nao e suficiente

Se voce tem um monolito simples, provavelmente nao precisa de traces distribuidos ainda. Mas assim que tiver dois ou mais servicos se comunicando, os traces se tornam essenciais.

Um trace distribuido mostra o percurso completo de uma requisicao pelo seu sistema. Voce ve exatamente onde o tempo e gasto, onde falha e qual servico esta causando o gargalo.

OpenTelemetry se consolidou como o padrao para instrumentacao. E open source, vendor-neutral, e suporta logs, metricas e traces. Se vai investir tempo em instrumentar seu codigo, faca com OpenTelemetry -- assim voce nao se prende a nenhum vendor especifico.

Ferramentas:

Jaeger: Open source, criado pelo Uber. Perfeito para comecar com traces distribuidos.
Zipkin: Outra opcao open source, mais simples que o Jaeger.
Datadog APM / New Relic: Se ja usa a plataforma deles para metricas, adicionar traces e natural.

O stack amigavel para startups

Nao tente implementar tudo de uma vez. Esta e uma progressao sensata:

Fase 1 -- O minimo viavel (desde o dia 1):

Logging estruturado em JSON
Logs centralizados (Loki + Grafana ou CloudWatch)
Metricas basicas de infraestrutura (o que seu cloud provider oferece de graca)
Alertas sobre erros HTTP 5xx e latencia

Fase 2 -- Maturacao (quando tiver usuarios reais):

Metricas de aplicacao com Prometheus + Grafana
Dashboards por servico com os 4 sinais dourados
Alertas mais sofisticados com severidades

Fase 3 -- Distribuicao (quando tiver multiplos servicos):

OpenTelemetry para instrumentacao
Traces distribuidos com Jaeger ou seu APM preferido
Correlacao entre logs, metricas e traces (o request ID e a chave)

Otimizacao de custos: nao va a falencia monitorando

A observabilidade pode ficar cara rapidamente. Datadog e excelente ate voce ver a fatura. Aqui vao algumas estrategias:

Sampling em traces: Voce nao precisa rastrear 100% das requisicoes. 10-20% geralmente e suficiente para detectar problemas. Rastreie sempre as requisicoes com erros.
Politicas de retencao: Voce precisa de logs de 6 meses atras? Provavelmente nao para o debugging do dia a dia. Defina retencoes curtas para dados detalhados e longas para metricas agregadas.
Niveis de log em producao: Nao envie logs de nivel DEBUG para producao. E ruido caro. INFO e superiores geralmente sao suficientes.
Alertas inteligentes: Cada alerta que nao e acionavel e um custo -- nao apenas economico, mas de atencao do time.

Alertas: a arte de nao gerar fadiga

Uma ma estrategia de alertas e pior do que nao ter alertas. Se seu time recebe 50 notificacoes por dia, vao aprender a ignorar todas -- incluindo a que importa.

Alerte sobre sintomas, nao sobre causas. Alerte quando a taxa de erros subir acima de 1%, nao quando a CPU chegar a 80%. A CPU a 80% pode ser normal sob carga; uma taxa de erros de 5% nunca e.

Cada alerta precisa de um runbook. Se alguem recebe um alerta as 3 da manha, deveria saber exatamente o que olhar primeiro. Sem runbook, e panico + SSH + "que e isso".

Classifique por severidade. Nem tudo e urgente. Um erro intermitente em um endpoint pouco usado pode esperar ate amanha. Uma queda do servico de pagamentos, nao.

A observabilidade como cultura

A observabilidade nao e so ferramentas -- e uma mentalidade de engenharia. Os times que a adotam desde o inicio debugam mais rapido, fazem deploy com mais confianca e dormem melhor.

Na Conectia, os engenheiros senior que integramos no seu time constroem sistemas observaveis por padrao. Nao como um add-on depois da terceira queda em producao, mas como parte fundamental da arquitetura. Porque quando seu sistema cresce e a complexidade aumenta, a diferenca entre um time que sabe o que acontece em producao e um que adivinha e a diferenca entre escalar e sobreviver.

Seu time descobre os problemas em producao pelos usuarios? Fale com um CTO -- integramos engenheiros senior que constroem observabilidade desde o primeiro deploy.