Pular para conteúdo

MVP 1 - Monitoramento e Observabilidade

Atualizado: 2026-05-18

Objetivo

Definir uma estrategia de monitoramento e observabilidade para o MVP 1 que seja:

  • open source por padrao;
  • de custo inicial 0;
  • facil de implantar;
  • amigavel para operacao;
  • robusta e segura;
  • completa o bastante para logs, metricas, latencia, trafego e erros.

Decisao executiva

Fase 0 - custo inicial zero

Enquanto o produto ainda nao tiver monetizacao recorrente validada, a estrategia recomendada e:

  • manter a baseline atual de CloudWatch, Route53, healthz, logs estruturados e budgets de latencia;
  • nao criar nova VM dedicada de observabilidade;
  • endurecer instrumentacao e padronizacao antes de subir stack adicional.

Fase 1 - stack OSS recomendada

Quando houver receita recorrente inicial ou dor operacional real que justifique stack propria:

  • Grafana OSS para dashboards e visualizacao;
  • Prometheus para metricas;
  • Loki para logs;
  • Grafana Alloy como collector;
  • Alertmanager para alertas;
  • Tempo apenas na fase seguinte, nao no dia 1.

Por que essa stack

Grafana OSS + Prometheus + Loki + Alloy

Esta combinacao foi escolhida porque oferece:

  • licenca 0;
  • ecossistema maduro;
  • UX melhor do que stacks muito cruas;
  • boa aderencia a logs, metricas e dashboarding;
  • menor risco de lock-in;
  • caminho natural de evolucao para OpenTelemetry e tracing.

Tempo depois, nao agora

Tracing distribuido agrega valor, mas nao precisa nascer junto do billing. No MVP 1, o custo operacional de tracing completo e maior do que o valor imediato. O recomendado e:

  • primeiro logs e metricas consistentes;
  • depois traces por sampling.

O que ja existe hoje

Na API, ja existe uma baseline util:

  • logs HTTP estruturados com request_id, trace_id, rota, status e duracao;
  • metricas internas de request, GraphQL, auth e budgets de latencia;
  • baseline operacional com CloudWatch, Route53 e Logs Insights.

Isso significa que a stack de observabilidade nao comeca do zero.

O que nao recomendamos agora

  • Elastic/Kibana como stack principal do MVP 1:
  • maior complexidade operacional;
  • licenciamento menos simples do que uma stack OSS pura;
  • maior chance de custo e manutencao acima do necessario.
  • tracing full desde o dia 1;
  • dashboards pesados e abertos 24x7 sem necessidade real.

Matriz de escolha

Opcao Vantagem Trade-off Parecer
Grafana OSS + Prometheus + Loki + Alloy melhor equilibrio geral exige composicao de stack recomendado
SigNoz self-hosted UX integrada muito boa menos granularidade por componente boa alternativa
OpenSearch Dashboards bom para logs-first stack mais pesada nao recomendada como primeira escolha
Elastic/Kibana produto conhecido licenciamento/custo/operacao menos aderentes nao recomendado para o MVP 1

Custo alvo por fase

Fase Infra adicional Custo alvo
Fase 0 nenhuma 0
Fase 1 1 instancia pequena dedicada baixo
Fase 2 stack completa com traces + retencao maior medio

Escopo funcional minimo

Dashboards

  • 5xx por rota;
  • p95/p99 por rota;
  • trafego por endpoint;
  • erros de auth;
  • webhook de billing invalido;
  • healthz e disponibilidade externa.

Alertas

  • burst de 5xx;
  • latencia acima do budget;
  • webhook invalido;
  • degrade de health check;
  • recurrence job falhando.

Correlacao

  • investigar por request_id;
  • usar trace_id quando existir;
  • no GraphQL, cruzar request_id, graphql_operation e graphql_root_fields.

AI Insights - metricas, logs e alertas

Detalhamento canonico: MVP 2 - AI Insights - Auditoria de Precisao.

AI Insights precisa medir custo, qualidade e governanca, nao apenas chamadas ao LLM. A instrumentacao deve acompanhar AIInsightRun, snapshot_hash, status do run, evidencias, rejeicoes, truncamento, expurgo e data_quality.

Metricas minimas

  • ai_insight_runs_total{status,period_type};
  • ai_insight_cost_usd_total{model,period_type};
  • ai_insight_tokens_total{model,period_type,direction};
  • ai_insight_rejections_total{reason};
  • ai_insight_truncations_total{field};
  • ai_insight_data_quality_total{flag};
  • ai_insight_purges_total{status};
  • ai_insight_budget_block_total{window};
  • ai_insight_preview_total{period_type};
  • ai_insight_cache_hits_total{period_type}.

Logs estruturados

Logs devem incluir run_id, snapshot_hash, period_type, period_label, status, tokens, custo, cache hit, motivo de rejeicao e resultado de expurgo quando aplicavel.

Logs nao devem incluir PII, prompt bruto, snapshot nao sanitizado, observacoes livres do usuario ou dados bancarios reidentificaveis.

Alertas especificos

  • custo diario ou mensal acima do orcamento configurado;
  • tokens por insight acima do esperado;
  • taxa alta de rejeicao de respostas;
  • truncamento frequente de snapshot ou resposta;
  • falha de expurgo de AIInsightRun;
  • queda de qualidade dos dados, como aumento de missing_comparison_periods;
  • circuit breaker acionado por budget.

Backlog executavel

Repo Task Objetivo
auraxis-platform J18 #486 programa de observabilidade centralizada do MVP 1
auraxis-platform J18-1 #487 decisao de stack OSS e rollout zero-cost
auraxis-api API23 #804 exporters, metricas canônicas e instrumentacao compativel com collector OSS
auraxis-api #1314 runs, custo, tokens, rejeicoes, truncamento, expurgo e qualidade dos AI Insights
auraxis-platform PLT7 #488 baseline de dashboards, alertas e operacao de observabilidade

Ordem recomendada

  1. congelar a estrategia zero-cost first;
  2. padronizar metricas/logs/exporters na API;
  3. publicar dashboards e alertas minimos;
  4. subir stack OSS dedicada apenas apos sinal de monetizacao ou dor operacional;
  5. adicionar tracing completo depois.

Criterios de aceite

  • custo incremental inicial 0;
  • stack OSS recomendada documentada e aprovada;
  • contratos minimos de metricas/logs definidos;
  • plano de rollout por fase registrado;
  • gatilho objetivo para sair da fase 0 definido.