Plano de observabilidade: logs estruturados, métricas, traces e alertas
Desenha a observabilidade do teu backend: SLO por percurso de utilizador, esquema de logs estruturados, métricas RED e USE, traces com OpenTelemetry, alertas úteis e controlo de custos. Pensado para ChatGPT, Claude, Gemini e Microsoft Copilot. Inclui 4 variáveis personalizáveis e pode copiá-lo gratuitamente com um clique.
Intermédio · Texto · Pendente de revisão editorial
Prompt
Atua como engenheiro SRE que desenha observabilidade para equipas pequenas e médias.
Contexto:
- Sistema e componentes: {{sistema}}
- Stack e linguagens: {{stack}}
- Ferramentas preferidas: {{ferramentas}}
- Incidentes ou dificuldades recentes: {{incidentes}}
Entregáveis:
1. Três a cinco percursos críticos de utilizador e, para cada um, um SLI mensurável e uma proposta de SLO com o respetivo orçamento de erro. Apresenta os objetivos como propostas a validar com o negócio.
2. Esquema de logs estruturados em JSON: campos obrigatórios (marca temporal, nível, serviço, ambiente, id de trace e de pedido, utilizador pseudonimizado, evento), quando usar cada nível e o que nunca registar (palavras-passe, tokens, dados pessoais completos).
3. Métricas: método RED para serviços (pedidos, erros, duração) e USE para recursos (utilização, saturação, erros), com nomes, etiquetas e avisos sobre etiquetas de alta cardinalidade.
4. Traces distribuídos com OpenTelemetry: o que instrumentar automaticamente e o que instrumentar à mão, propagação de contexto entre serviços e filas, e estratégia de amostragem.
5. Alertas: baseados em sintomas e na velocidade de consumo do orçamento de erro, não em cada causa; para cada alerta, gravidade, quem é avisado e ligação para o runbook. Lista de alertas a eliminar ou despromover.
6. Painéis: uma visão geral por serviço e um por percurso crítico, com os gráficos concretos.
7. Retenção e custos: quanto tempo guardar cada sinal, amostragem e como evitar que a fatura dispare.
8. Código de exemplo para a minha stack: middleware que acrescenta um id de pedido, logs estruturados e uma métrica de latência.
9. Um plano de implementação a 30, 60 e 90 dias.
Restrições:
- Não inventes volumes de tráfego nem preços de ferramentas: usa [PREENCHER] e explica como os estimar.
- Se faltar informação essencial, pergunta-me antes de propor os SLO.
- Dá prioridade ao que teria ajudado a detetar ou resolver mais cedo os incidentes que descrevi.Como utilizar
- Descreve os serviços, filas e bases de dados, e os últimos incidentes difíceis de detetar.
- Indica se preferes open source alojado por ti, um SaaS ou as ferramentas do teu fornecedor cloud.
- Implementa primeiro logs estruturados e ids de trace; depois métricas e alertas por SLO.
Exemplo de utilização
Sistema: API Django, worker Celery, PostgreSQL e Redis em Kubernetes · Ferramentas: open source alojado internamente · Incidente: a fila encravou duas horas e ninguém deu por isso até os clientes ligarem.
Exemplo de resultado
1. Percursos críticos e SLO (propostas a validar com o negócio)
| Percurso | SLI | SLO proposto |
|---|---|---|
| Iniciar sessão | % de pedidos 2xx em < 500 ms | 99,5 % em 28 dias |
| Criar encomenda | % de pedidos sem 5xx | 99,9 % |
| Tarefa em segundo plano | % de tarefas que arrancam < 60 s depois de entrarem na fila | 99 % |
Foi precisamente este terceiro que teria detetado o incidente: a fila não «falhou», simplesmente deixou de avançar.
5. Alerta prioritário: fila do Celery parada
- alert: CeleryQueueStalled
# O nome da métrica depende do exporter escolhido: [COMPLETAR]
expr: max(celery_queue_oldest_task_age_seconds) > 300
for: 5m
labels:
severity: page
annotations:
summary: "A tarefa mais antiga está à espera há mais de 5 min"
runbook: "https://wiki.interna/runbooks/fila-celery-parada"
Alerta-se pelo sintoma (idade da tarefa mais antiga) e não por uma causa (CPU do worker, ligações ao Redis), porque cobre qualquer motivo para a fila encravar.
Alertas a despromover para ticket
- CPU do nó > 80 % sem impacto na latência.
- Reinícios isolados de um pod que recupera sozinho…
Dados-chave
- Categoria
- Programação e desenvolvimento · DevOps
- Tipo de resultado
- Texto
- Nível
- Intermédio
- Pensado para
- ChatGPT, Claude, Gemini e Microsoft Copilot
- Verificado em
- Pendente de verificação editorial
- Variáveis
- Sistema e componentes, Stack e linguagens, Ferramentas preferidas e Incidentes recentes
- Idioma
- Português
- Preço
- Gratuito, sem registo
- Atualizado
- 07/11/2026
Perguntas frequentes
Qual é a diferença entre SLI e SLO?
O SLI é a medida (por exemplo, a percentagem de pedidos de pagamento que respondem bem em menos de 500 ms). O SLO é o objetivo para essa medida num período, como 99,5 % em 30 dias.
Porquê alertar por sintomas e não por causas?
Os alertas por causa (CPU alta, um pod reiniciado) geram muito ruído e muitas vezes não afetam o utilizador. Alertar quando o utilizador sofre, ou quando o orçamento de erro se consome depressa, reduz o cansaço de quem está de prevenção.
Para que serve este prompt?
Desenha a observabilidade do teu backend: SLO por percurso de utilizador, esquema de logs estruturados, métricas RED e USE, traces com OpenTelemetry, alertas úteis e controlo de custos.
Com que ferramentas de IA funciona?
Foi pensado para ChatGPT, Claude, Gemini e Microsoft Copilot. Ainda não o verificámos nestas ferramentas, pelo que os resultados podem variar entre elas.
Como personalizo o prompt?
Clique em “Personalizar” e preencha as variáveis (Sistema e componentes, Stack e linguagens, Ferramentas preferidas e Incidentes recentes). O texto atualiza-se instantaneamente e pode depois copiá-lo com um clique. Os valores ficam guardados apenas no seu navegador.
Preciso de experiência para o utilizar?
É de nível intermédio: convém conhecer o tema para fornecer bom contexto e rever o resultado com sentido crítico.
Este prompt é gratuito?
Sim. Todos os prompts do HomeCasa Prompts são gratuitos, sem registo nem subscrição. Pode também utilizá-los em projetos profissionais.
Posso confiar no resultado da IA?
Trate-o como um rascunho de qualidade: verifique sempre os dados, os números e as afirmações importantes antes de publicar ou tomar decisões.