Pequenas empresas raramente precisam de uma plataforma enterprise no primeiro dia. Precisam saber se o cliente consegue comprar, se integrações e jobs rodaram, se dados estão frescos, se erros aumentaram e quem responde. Observabilidade eficiente começa por essas decisões.
Varejo, clínica, logística, escritório contábil ou SaaS regional pode operar com poucas VMs, bancos gerenciados, functions, APIs, ERP, planilhas e cron. As falhas caras costumam ser silenciosas: nota que não sincroniza, webhook rejeitado, estoque stale, backup quebrado ou relatório com dados antigos.
Liste jornadas, tempo máximo para detectar e recuperar, owner e canal de resposta. Depois instrumente o menor conjunto capaz de provar sucesso ou localizar a fronteira que falhou.
OpenTelemetry oferece APIs, SDKs, convenções e Collector neutros. Prometheus atende métricas e alertas. Loki ou outro store indexa labels de baixa cardinalidade, mantendo contexto dinâmico em campos. Tempo ou equivalente guarda traces amostrados. Dashboard e roteador de alertas ficam acima.
O primeiro deploy pode ser gerenciado, single-node ou híbrido. Mantenha OTLP, Prometheus/OpenMetrics, W3C Trace Context, logs JSON e schemas documentados nas fronteiras para trocar storage sem reescrever aplicações.
Comece com tráfego, erro, latência e saturação. Adicione pedidos concluídos, pagamentos, falhas de integração, idade de fila, registros sincronizados, idade do backup e freshness de relatório. Métricas servem para agregados, não IDs de clientes ou payloads.
Cada combinação de labels vira série. Não use usuário, email, pedido, trace, query string ou exception message. Prefira serviço, ambiente, operação, rota normalizada, classe de resultado, dependência, fila e região limitada.
Use JSON com timestamp, severidade, serviço, ambiente, versão, operação, outcome, duração, trace/span, request, job, integração e código de erro seguro. Identificadores dinâmicos ficam em campos pesquisáveis, não labels indexados.
Não registre tokens, senhas, cartão, documento integral, saúde ou payload completo por padrão. Redija na origem e no Collector. Dê retenção curta a logs verbosos e longa apenas a eventos com finalidade operacional, jurídica ou de auditoria.
Scheduler disparado não prova trabalho concluído. Emita started, heartbeat, completed, failed, skipped, timed out e partial. Registre agenda esperada, início real, duração, processados, rejeitados, watermark, output e próxima execução.
Use dead-man check: o monitor espera heartbeat ou conclusão até o prazo. É essencial para sync de ERP, folha, backup, certificado, nota e relatório diário.
Métricas internas podem ficar verdes enquanto DNS, TLS, CDN, rota, autenticação ou terceiro quebram. Rode probes de fora da rede produtiva. Verifique status, latência, certificado, schema e fluxo read-only.
Em caminhos críticos, use transação controlada com dados de teste e compensação. Não polua finanças, estoque, mensagens ou analytics.
Guardar todo request custa caro. Retenha erros, traces lentos e pequena amostra normal. Tail sampling decide após o trace completo, mas consome memória no Collector. Head sampling é simples e barato, mas perde falhas raras.
Propague contexto mesmo sem retenção. Logs e eventos ainda podem correlacionar. Proteja atributos sensíveis e limite span events.
Interrompa uma pessoa apenas quando ação rápida é necessária. Outros sinais viram ticket, digest ou dashboard. Prefira sintomas: checkout falhando, confirmação de pagamento atrasada, job stale, error budget queimando ou fila envelhecendo.
Todo alerta inclui serviço, owner, severidade, jornada, início, valor, razão do limite, deploy, dashboard, runbook e condição de recuperação. Teste o próprio canal de notificação.
Sinais recentes e detalhados valem mais durante debug. Depois, deployments e dependências mudam. Mantenha janela quente curta, agregue métricas, arquive logs selecionados em object storage e exclua o que não tem finalidade.
Retenção deve ser configuração versionada com owner e data de revisão. Guardar tudo para sempre aumenta custo e risco.
| Sinal | Mínimo útil | Driver de custo | Controle | Reter mais quando |
|---|---|---|---|---|
| Métricas de serviço | Tráfego, erro, histograma de latência, saturação e versão. | Séries, intervalo, buckets e retenção. | Labels baixos, recording rules e intervalo maior em baixo risco. | Capacidade, SLO e sazonalidade exigem histórico. |
| Métricas de negócio | Pedidos, pagamentos, sync, fila e freshness. | Dimensões e labels por entidade. | Agregar por operação/resultado; detalhar via logs. | Há necessidade operacional ou de auditoria. |
| Logs | Warnings/errors estruturados e infos amostrados. | Bytes, índice, queries e retenção. | Nível, rate limit, dedupe, redaction, labels baixos e archive. | Incidente, segurança ou compliance justificam. |
| Traces | Erros, lentos e pequena amostra normal. | Spans, atributos, eventos e índice. | Sampling, limites e normalização. | Latência distribuída ou dependência precisa ser analisada. |
| Eventos de job | Início, conclusão, outcome, duração, watermark e deadline. | Baixo; volume de histórico e alerta. | Um resumo por tentativa e erros limitados. | Financeiro, backup ou regulação exigem evidência. |
| Checks sintéticos | DNS/TLS/HTTP e uma jornada segura. | Frequência, locais e browser minutes. | Frequência por risco e browser apenas onde necessário. | Comportamento regional ou de terceiros precisa comparação. |
Overview de serviço: golden signals, alertas, deploys, dependências e erros. Operações de negócio: pedidos, pagamentos, integrações, freshness, backlog e exceções. Custo de telemetria: ingest por sinal, séries, logs, sampling, retenção, queries e cardinalidade.
Dashboard sem owner ou uso recorrente deve sair.
Use idioma local nos alertas e runbooks, mas mantenha campos estáveis. Considere equipe pequena, on-call limitado, conectividade de filial, distância de regiões cloud, câmbio na fatura e dependência de ERP, fiscal, pagamentos e mensageria locais.
Sistemas de filial devem bufferizar telemetria limitada e priorizar health, segurança e evidência transacional. Monitore também Collector, exporters, filas e storage.
Eu começaria com logs estruturados, métricas Prometheus, checks externos de uptime/TLS, heartbeats de jobs, roteador simples e três dashboards. Depois adicionaria Collector para centralizar enrichment, redaction, batching, sampling e routing.
Tracing começaria nas jornadas críticas e integrações. Todo mês eu revisaria falsos alertas, dados sem uso, cardinalidade, retenção, cobertura e custo por serviço.
Observabilidade barata não é enxergar menos. É enxergar com disciplina: capturar o que muda uma decisão, preservar contexto suficiente, alertar o owner correto e parar de pagar para guardar ruído.
Artigo sobre observabilidade de baixo custo para PMEs latino-americanas, incluindo logs estruturados, Prometheus, cron monitoring, dead-man checks, probes sintéticos, traces OpenTelemetry amostrados, alertas, dashboards, retenção, cardinalidade, privacidade e custos.