Como vocês monitoram erro/performance de aplicação nos seus SaaS/side-projects?

Eu utilizo 2 coisas, new relic para projetos pequenos(EXTREMAMENTE facil de configurar e sem dor de cabeça)

e para saas maiores que ofereço eu tenho já um sistema inteiro de monitoramento igual o new relic para facilitar minha vida, perdi MUITO tempo configurando mas meu saas ja tem 14 meses e não teve um bug que eu "aceitei" que existia sem problemas, todos consegui trackear os logs e dados de query ou request ou fila pra poder fz a observabilidade

link pro github caso esteja interessado na ideia e precise de exemplos:

https://github.com/JulioVianaDev/telemetry-examples

para mim ter argumentos e dados para um pós mortem é excencial para contrapor um cliente irritado

Acho que a estrutura geral que vai achar mais simples/poderosa (Não rápida) e pode ser construida do zero em projetos pequenos que vão se tornando grandes, é principalmente logs, voce precisa ser fanatico com logs, se o erro não for documentado não tem como ver simples assim. Padronize eles ao extremo, cubra tudo, coloque rotações para não explodir disco, depois que isso estiver estruturado, ai sim vem ferramentas, eu prefiro criar minhas proprias todas do zero, elas ja fazem parte da minha stack então eu apenas as reutilizo e incremento, mas a base toda é log bem feito. Eu fiz uma central de erros que alerta o tempo todo até via telegram, o nivel de visibilidade depende do que voce tem prioridade em acompanhar, logs de erros, segurança etc, voce decide. O trabalho ai é preparar o log em si, ele será o responsavel depois por gerar as informações da forma correta, integrando a uma base de dados para registrar não há problema de perda de log por rotatividade e seu disco agradece, no meu caso especifico cada erro ou problema é tratado como uma nova pendencia a ser resolvida e encaminhada ao lugar certo imediatamente, sem necessidade de ticket do cliente, mas ele tem essa opção claro. E um detalhe se você usa IA para codificar atenção redobrada, elas aprenderam com código humano e humano adora esconder erro pra mostrar que esta funcionando, elas amam colocar falbacks silenciosos, e erros sem resposta, por isso ainda mais atenção na padronização de logs, isso te tira dessa roubada.

Respsta gerada pelo claude com o contexto do meu projeto:

Cara, você descreveu exatamente o ponto cego que quase todo mundo tem. Infra é o problema fácil (binário: subiu/caiu, tem ferramenta boa pra caramba). O difícil é o que você listou: health check verde, container de pé — e mesmo assim o fluxo que importa não terminou.

Toco um SaaS de e-commerce de joia 3D (upload de STL, render, pagamento, nota, frete) — mesma família de dor: fila, worker, mídia, job assíncrono. O que virou a chave aqui foi parar de instrumentar infra e instrumentar desfecho de domínio. Dois sinais, e o segundo é o que pega o silêncio:

1. Contador de fluxo com outcome. Cada etapa emite evento_total{outcome="success|failed"}. Render, thumbnail, notificação, PDF — todos com taxa de falha visível. Pega "worker falhou num item específico".

2. Gauge de estado preso — o pulo do gato. Em vez de "o job rodou", eu meço "quantas coisas estão num estado não-terminal além do SLA" (ex.: presos_em_pending há +5 min). Alerta quando fica > 0. É exatamente o "job rodou com sucesso mas deixou o usuário sem resultado" — sucesso do job ≠ desfecho entregue. E o mesmo job de reconciliação que mede o preso também reprocessa, fechando o loop antes do usuário abrir ticket.

Os outros silêncios que você citou:

• Dead-letter durável: mensagem envenenada não some — vai pro Postgres (outbox/inbox do Wolverine), com contador + alerta e reprocessável.
• Fila sem consumer: alerta em queue_messages > 0 AND consumers == 0.
• Trace correlacionado (trace_id no log): do alerta pulo direto pro trace daquele item. Sem grep.

O mapa do que roda:

graph LR
    API[API dotnet]
    WORKER[Worker dotnet]
    UI[UI browser Faro]

    ALLOY[Alloy coletor unico]

    PROM[Prometheus metricas]
    LOKI[Loki logs]
    TEMPO[Tempo traces]

    PGX[postgres-exporter]
    BB[blackbox-exporter]
    RMQ[RabbitMQ metricas]

    GRAF[Grafana dashboards e alertas]

    API -->|OTLP metricas e traces| ALLOY
    API -->|logs Serilog| LOKI
    WORKER -->|OTLP metricas e traces| ALLOY
    WORKER -->|logs Serilog| LOKI
    UI -->|Faro web vitals e erros| ALLOY

    ALLOY -->|metricas| PROM
    ALLOY -->|traces| TEMPO
    ALLOY -->|logs Faro| LOKI

    PGX --> PROM
    BB --> PROM
    RMQ --> PROM

    PROM --> GRAF
    LOKI --> GRAF
    TEMPO --> GRAF

Direto ao que você perguntou:

• Sentry vs OTel? Não é ou-ou. Sozinho, começa com Sentry pra exceção (10 min, já mata "falha silenciosa"). A parte de pipeline (fila, estado preso, backlog) ele não pega bem — aí entra métrica+alerta.
• Valeu o OTel/Tempo/Grafana? Valeu — mas só porque instrumentei desfecho de negócio. Se subir a stack e só olhar latência HTTP e CPU, vira a aba esquecida que você citou. O ROI tá nos 4-5 alertas de fluxo, não no LGTM completo.
• A fricção real: não é subir o Grafana, é manter a instrumentação viva dentro do código de domínio. Isso morre num sidecar longe do código. Regra: mexeu numa transição de estado, mexe na métrica junto, faz parte do PR.
• Ponto de equilíbrio pra time pequeno (80% dos silêncios com 20% do trabalho): (1) outcome em cada etapa; (2) gauge de "presos > X min" + job que reprocessa; (3) dead-letter que persiste; (4) alerta em fila sem consumer. Roda num Prometheus + Alertmanager modestos. Tracing e RUM são o passo 2.

Numa frase: pare de alertar em "o job rodou" e comece a alertar em "o resultado que o usuário esperava existe". O primeiro fica verde enquanto a experiência de alguém está quebrada.

A stack de observabilidade é o LGTM da Grafana + exporters, num perfil Docker separado. O que cada peça faz:

Instrumentação (dentro dos apps)

Coleta

Armazenamento

Exporters / probes

Visualização

node-exporter / cAdvisor são infra de host compartilhada — as métricas node_*/container_* vêm de um Prometheus HOST, adicionado ao Grafana como datasource Prometheus HOST. Os dashboards de infra apontam pra ele.

OBS: toda essa stack roda num único docker-compose no mesmo servidor da aplicação

Daqui vou falar minha experiência passando por empresas e startups: Penso que uma das vantagens que você tem é conseguir entregar uma exmperiencia muito melhor que grandes empresas, onde cada pequena melhoria na experiencia ou correção tem que passar por 4 squads e alinhar os 4 roadmaps e só chegam pro user no próximo cycle (em 2 meses). Uma startup, solo founder ou pet projects você consegue e deve se atentar muito a estes pequenos problemas que degradam a experiência.

Então sem muito mais delongas, penso que Elastic + Graphana, Prometheus, ou mesmo um free tier de data dog ou New Relic seriam minhas opções. Penso que a observabilidade e monitoria sempre devem ser levadas a serio.

Eu sempre coloco bastante logs, principalmemnte de erros, faults/warnings.
A maior parte dos tollings de observabilidade trabalham com eventos custom, por exemplo o job rodou ok e processou video x, um job falhou no video y, eventos de mensagens processadas e mensagens que falharam, com info de qual usuario, e assim por diante, cobrindo principalmente os fluxos chaves do seu business.

Com estes logs, metricas, custom events e os traces padrao, crio varios dashboards, um focado em um overview geral tecnico, um overview de business, um focado em falhas e erros.

Ao menos esta é minha stack de observabilidade básica que penso que qualquer projeto que esteja em produção nas mão de usuários tira bastante vantagem. E muitas vezes a depender da escala vai demorar precisar sair do free tier.