Fragmentação
Logs via SSH, CPU em outra tela e erros percebidos pelo usuário. Não existe uma linha causal única.
Do deploy ao sinal.
Uma camada de observabilidade nativa do Cleat para entender saúde, falhas e performance de todas as aplicações — sem tentar reconstruir o Datadog no primeiro dia.
01 / 09
A oportunidade
O Cleat já sabe onde a aplicação vive. Falta saber como ela vive.
Hoje o deploy termina quando o processo sobe. Para o operador, o trabalho real começa depois: descobrir se a aplicação está saudável, por que ficou lenta e o que mudou antes de uma falha.
Setup caro
Cada app exige agentes, dashboards, retenção e credenciais. A observabilidade vira outro produto para operar.
Contexto perdido
Ferramentas externas não conhecem deploy, runtime, servidor, release ou tenant como o Cleat conhece.
Tese: o diferencial não é armazenar mais telemetria. É correlacionar automaticamente aplicação, release, infraestrutura e incidente.
02 / 09
Definição do produto
Observabilidade opinionada para quem faz deploy.
“Cleat Signals” é o nome de trabalho para uma experiência integrada: cada app ganha uma visão de saúde, logs pesquisáveis, métricas essenciais, erros agrupados e uma trilha de deploys.
Funciona no primeiro deploy
Coleta padrão instalada pelo Cleat; instrumentação avançada é incremental.
Release como eixo
Toda mudança de saúde deve poder ser comparada com o deploy que a antecedeu.
OpenTelemetry no centro
Sem SDK proprietário obrigatório e com exportação para outros backends.
03 / 09
Catálogo do produto
Funcionalidades por corte de valor.
Cada item é uma funcionalidade concreta do Cleat Signals, agrupada pelo corte em que entra, pelo status de entrega e pelas superfícies que a expõem. O corte 01 responde “o que aconteceu?”, o 02 “piorou depois do deploy?” e o 03 “por que aconteceu?”.
Ver o que a aplicação está fazendo
- Tail de logs em tempo real por aplicação
- Busca por texto, severidade, processo e janela de tempo
- Filtro por app, release e environment
- Agrupamento de erros e stack traces
- Coletor gerenciado pelo Cleat no primeiro deploy
- Redaction de dados sensíveis e quotas por tenant
Ligar saúde, release e infraestrutura
- Health overview de todas as aplicações
- Métricas RED + host em uma visão só
- Deploy markers sobrepostos aos gráficos e logs
- Alertas padrão de indisponibilidade, erro e saturação
- Timeline de incidente com linha causal única
- Comparação de saúde entre releases
Entender a causa raiz
- Endpoint OTLP para traces, métricas e logs
- Waterfall de traces distribuídos
- Service map de dependências
- Correlação trace ↔ log ↔ métrica
- Sampling configurável por aplicação
- Sumário assistido de incidente (depois)
Painel em LiveView
Experiência completa: log explorer, gráficos, timeline de incidente, configuração de alertas e retenção.
cleat no terminal
As mesmas capacidades para scripts e CI, com saída --json. Ex.: cleat signals health.
cleat mcp para agentes
Claude Code, Codex e Grok consultam saúde, métricas e logs como ferramentas nativas, sem shell.
Paridade por design: toda funcionalidade nasce na API do painel (
/api/v1); o painel consome essa API e CLI/MCP são clientes dela. Um sinal só é considerado “pronto” quando está disponível nas três superfícies.| Funcionalidade | O que entrega | Web | CLI | MCP | Status |
|---|---|---|---|---|---|
| Log explorer | Busca, filtros e tail por app, release, severidade e tempo. | ● | apps logs | apps_logs | ● MVP |
| Coletor gerenciado | Ingestão de stdout, systemd e OTLP com enrichment e batching. | ● | config | — | ● MVP |
| Redaction & quotas | Mascara dados sensíveis e limita volume por tenant. | ● | ○ | — | ● MVP |
| Health overview | Uma tela para detectar aplicações degradadas. | ● | signals health | signals_health | ● MVP |
| Métricas RED + host | Latência, taxa de erro, CPU, memória, disco e restarts. | ● | signals metrics | signals_metrics | ● MVP |
| Deploy markers | Sobrepor cada release aos gráficos, logs e alertas. | ● | status | deploy_status | ● MVP |
| Alertas padrão | Notificar indisponibilidade, erro e saturação. | ● | signals alerts | signals_alerts | ● MVP |
| Timeline de incidente | Linha causal única reunindo os sinais de uma falha. | ● | ○ | signals_incident | ● Fase 2 |
| Endpoint OTLP | Receber traces, métricas e logs via OpenTelemetry. | ● | — | — | ● Fase 2 |
| Trace waterfall + service map | Visualizar chamadas e dependências entre serviços. | ● | signals traces | signals_traces | ● Fase 2 |
| Correlação trace ↔ log | Saltar de um log para o trace correspondente e vice-versa. | ● | ○ | ○ | ● Fase 2 |
| Sampling configurável | Controlar o custo de traces por aplicação. | ● | signals sampling | signals_set_sampling | ● Fase 2 |
| Exportação para backends externos | Enviar telemetria para Datadog ou Grafana Cloud. | ● | — | — | ● Conector |
| RUM / Session replay | Observabilidade de front-end no navegador. | — | — | — | — Fora agora |
| AI / RCA automático | Sumário assistido e diagnóstico automático de incidentes. | ● | — | signals_summary | — Depois |
● nativo · ○ leitura/básico · — não exposto. Os nomes de comandos CLI e ferramentas MCP são propostas deste estudo — hoje já existem apps logs, servers logs e deploy_status nas três superfícies.
04 / 09
Arquitetura proposta
Coletar perto. Processar uma vez. Consultar por contexto.
Um collector por servidor recebe os sinais das aplicações e do host. Ele adiciona metadados do Cleat, aplica limites e envia para um backend central por tenant.
OrigemApps + hoststdout · OTLP · systemd · CPU · memória · HTTP
→
EdgeOTel Collectorenrichment · batching · sampling · redaction · quotas
→
Control planeStore + Cleat UIconsulta · correlação · alertas · retenção · exportação
Contexto injetado
O dado precisa chegar com identidade
tenant_id, app_id, deployment_id, server_id, runtime, environment e service.version. Essa taxonomia é o verdadeiro moat do produto.
05 / 09
Recorte de MVP
Começar pelo diagnóstico de produção.
O primeiro resultado valioso é responder rapidamente: “está quebrado?”, “começou depois de qual deploy?” e “onde olho agora?”.
| Capacidade | MVP | Depois | Fora agora | Resultado esperado |
|---|---|---|---|---|
| Logs centralizados | ● Sim | Busca avançada | — | Filtrar por app, release, processo, severidade e tempo. |
| Métricas essenciais | ● Sim | Custom metrics | — | CPU, memória, disco, restarts, latência e taxa de erro. |
| Deploy markers | ● Sim | Comparação automática | — | Sobrepor cada release aos gráficos e logs. |
| Health overview | ● Sim | SLOs | — | Uma tela para detectar apps degradadas. |
| Tracing distribuído | Receber OTLP | ● Fase 2 | Auto-instrumentar tudo | Waterfall e correlação trace ↔ log. |
| Alertas | 3 regras padrão | ● Fase 2 | Motor complexo | Notificar indisponibilidade, erro e saturação. |
| RUM / Session replay | — | — | ● Sim | Não competir com suites completas no início. |
| AI / RCA automático | — | Sumário assistido | Agente autônomo | Só depois de dados confiáveis e bem correlacionados. |
06 / 09
Build vs. compose
Não construir bancos de telemetria.
O produto deve ser a experiência Cleat e a camada de contexto. Armazenamento e ingestão são melhor compostos com projetos maduros.
A · recomendada
OpenTelemetry + stack Grafana
Alloy/Collector na borda, Loki para logs, Prometheus/Mimir para métricas e Tempo para traces. Ecossistema amplo e separação clara por sinal, com maior custo operacional interno.
Melhor começo incrementalB · atalho
OpenTelemetry + SigNoz
Experiência integrada sobre ClickHouse, com logs, métricas, traces e exceções. Acelera time-to-market, mas aproxima a UI do Cleat de uma segunda UI de observabilidade.
Ótimo para validar rápidoC · managed
Exportar para Datadog / Grafana Cloud
Menor carga operacional, maior custo variável e dependência externa. Pode existir como integração premium sem ser a fundação obrigatória.
Conector, não núcleoRecomendação v0.1: provar UX e modelo de dados com OTel Collector + um backend composto. Fazer um spike curto entre Loki/Prometheus e SigNoz antes de cristalizar a escolha.
07 / 09
Plano de validação
Três cortes que entregam valor.
As durações são hipóteses para planejamento, não compromissos. Cada fase deve terminar com uso real em pelo menos duas aplicações de runtimes diferentes.
Logs com contexto
Responder “o que aconteceu?”- Collector por servidor
- stdout/systemd centralizado
- filtros por app e deploy
- limites e redaction
- Web · CLI · MCP
Saúde e correlação
Responder “piorou depois do deploy?”- métricas RED + host
- overview das aplicações
- deploy markers
- alertas padrão
- timeline de incidente
Tracing opt-in
Responder “por que aconteceu?”- endpoint OTLP
- service map básico
- trace ↔ logs
- sampling configurável
- sumário assistido
Escala e autonomia
O que vem depois dos três cortes.- SLOs e orçamento de erro
- RCA assistido por AI
- exportação para Datadog / Grafana Cloud
- RUM / session replay
- escala multi-região
Corte 01 · 2–3 sem
Logs com contexto — por que primeiro
Logs são o sinal mais barato de coletar e o mais consultado no dia a dia. Hoje eles obrigam o operador a abrir SSH: não existe uma linha do tempo única por aplicação. Sem essa base, correlação é teoria — falta o registro do que aconteceu.
O Cleat passa a instalar e gerenciar um collector por servidor, que coleta stdout/systemd das aplicações e o journal do host, enriquecendo cada linha com tenant_id, app_id, deployment_id, server_id, runtime e environment. O operador busca e filtra por release sem tocar no servidor.
Corte 02 · 2–4 sem
Saúde e correlação — por que agora
Com a linha do tempo dos logs no lugar, o próximo salto é medir. Métricas transformam “tem log de erro” em “a taxa de erro subiu 4× depois do deploy 87” — e é aí que o Cleat tem vantagem: ele conhece o deploy.
Entram métricas RED + host (CPU, memória, disco, restarts), um health overview de todas as aplicações, deploy markers sobrepostos aos gráficos e três alertas padrão: indisponibilidade, taxa de erro e saturação. O release vira o eixo causal de qualquer investigação.
Validamos quando: detectar uma app degradada no overview e apontar o release que antecedeu a mudança, sem SSH.Corte 03 · 3–4 sem
Tracing opt-in — por que depois
Tracing custa mais caro: volume de dados e instrumentação. Ele só compensa quando logs e métricas já são confiáveis, porque responde “por que aconteceu?”, não “o que aconteceu?”. Colocar na frente seria construir o telhado antes da fundação.
Entram o endpoint OTLP para receber traces, o waterfall, o service map básico, a correlação trace ↔ log e o sampling configurável por aplicação. Nada de auto-instrumentar tudo: é opt-in, aplicação por aplicação, quando o time quiser o detalhe.
Validamos quando: uma app instrumentada com traces navegáveis e o salto log → trace funcionando.Próximo · horizonte
Escala e autonomia — o que vem depois dos cortes
Só entra depois dos três cortes em uso real: SLOs e orçamento de erro, RCA assistido por AI, exportação para Datadog/Grafana Cloud (conector, não núcleo), RUM/session replay (fora do escopo) e escala multi-região.
Depende de: dados confiáveis e bem correlacionados nas fases anteriores.
08 / 09
Registro vivo
Decisões para construirmos juntos.
Itens “propostos” formam a tese atual. Itens “abertos” precisam de spike técnico ou decisão de produto.
PropostoOpenTelemetry será o protocolo e modelo de ingestão principal.
D-001PropostoO primeiro caso de uso será diagnóstico pós-deploy, não BI de produto.
D-002PropostoLogs, métricas e traces terão quotas e retenção por tenant desde o início.
D-003AbertoBackend inicial: stack Grafana modular ou SigNoz integrado?
D-004AbertoO collector roda diretamente no host ou em container gerenciado?
D-005AbertoQual retenção padrão e qual orçamento de armazenamento por app?
D-006AbertoAlertas começam por e-mail, webhook, Slack ou WhatsApp?
D-007PropostoToda funcionalidade existirá em web, CLI e MCP, consumindo a mesma API do painel.
D-008
09 / 09
Referências consultadas
Base técnica do estudo.
Documentação primária usada para validar protocolo, sinais e opções de coleta. A recomendação de produto é uma inferência aplicada ao contexto atual do Cleat.