Todo SRE com quem trabalhei tem o mesmo loop. Um incidente começa. Eles abrem o Grafana. E então gastam os três primeiros minutos não investigando o problema — gastam lembrando da query PromQL certa.
O problema real
Os dashboards geralmente estão lá. Alguém os construiu anos atrás para o mesmo tipo de incidente. Mas achar o painel certo sob pressão, ler a expressão da query, adaptar a janela de tempo, copiar o label selector correto — tudo isso é fricção que se acumula quando o sistema está em chamas.
A proposta usual é "adicionar um copilot de IA". A maior parte desses copilots falha em produção pelo mesmo motivo: eles alucinam nomes de métricas que não existem no seu ambiente. Um copilot que escreve confiante rate(http_requests_total[5m]) quando seu time usa nginx_http_requests_total é pior do que copilot nenhum — adiciona uma resposta errada sobre um problema existente.
A forma de uma resposta útil
Uma camada de Retrieval-Augmented Generation (RAG) inverte o modo de falha. Em vez de pedir ao LLM para inventar a query, você pede para ele encontrar e adaptar uma que já existe.
A base de conhecimento é tudo que você já tem:
Toda definição de painel em todo dashboard Grafana seu
Toda alert rule no Prometheus
Toda query gravada no query_log_archive ou nos seus runbooks
Você indexa isso — expressões de query, títulos de painel, descrições, tags de dashboard — em um vector store. O LLM nunca inventa um nome de métrica. Ele recebe a intenção do SRE ("error rate da API durante o incidente de ontem"), retorna os top-N painéis correspondentes, e responde com o PromQL real desses painéis, ajustado para a janela de tempo mencionada no pedido.
Pipeline
Intenção do usuário (NL)
│
▼
Modelo de embedding (OpenAI text-embedding-3-small ou local)
│
▼
Busca vetorial em { panel.title, panel.description, query.expr, dashboard.tags }
│
▼
Top-5 painéis relevantes com seus PromQLs originais
│
▼
LLM (Claude Haiku basta — é reescrita estruturada, não criatividade)
│
▼
PromQL final adaptado à janela e labels do usuárioO passo do LLM é intencionalmente mínimo. Ele recebe contexto retornado estruturado mais a pergunta do usuário e devolve uma string PromQL ou uma recusa. Sem output "criativo". Sem nomes de métricas alucinados — por construção, porque o retrieval entregou nomes reais.
O que muda na prática
O SRE pergunta: "me mostra a taxa de 5xx na API de checkout durante o deploy de 14:02 BRT ontem."
A camada de RAG retorna o painel "checkout-api / 5xx por endpoint" do dashboard de checkout existente, adapta a janela para [2026-05-01T17:02Z, +1h] (BRT para UTC) e devolve:
sum by (endpoint) (
rate(
http_requests_total{service="checkout", status=~"5.."}[5m]
)
)Com link direto para o painel no Grafana. Sem invenção, sem chute — e o SRE mantém os três minutos que a resposta a incidente realmente precisa.
Onde quebra (e como tratar)
O padrão falha graciosamente quando a base de conhecimento é esparsa. Se o usuário pergunta sobre um serviço que não tem dashboards ou alert rules indexados, o LLM não tem nada a recuperar e deve recusar em vez de inventar. Faça disso um guardrail explícito no prompt: "Se nenhum painel relevante foi retornado, responda 'Nenhum dashboard correspondente encontrado' e pare."
O segundo modo de falha é staleness. Dashboards mudam. A indexação tem que rodar periodicamente (um cron diário basta para a maioria dos times) e reindexar em atualizações de dashboard se você tem hooks disponíveis.
O terceiro é governança. A camada de retrieval lê tudo na org Grafana. Se seus dashboards expõem labels com identificação de cliente, o contexto do LLM agora inclui isso. Filtre em tempo de indexação, não em tempo de query.
Por que é melhor que um copilot
Um copilot genérico tenta ser inteligente. Um RAG sobre seus próprios dashboards tenta ser preciso. Para trabalho de SRE, preciso ganha de inteligente — toda vez. O sistema que você entrega responde com PromQL que já roda no seu ambiente, porque copiou de um painel em que você já confia.
É a mesma lógica que o resto do AI-augmented DevOps segue: o LLM é o orquestrador, não a fonte da verdade. Seu conhecimento operacional existente é. O LLM só conecta os pontos mais rápido que seus dedos.
Se o seu time de operações está no ponto de considerar uma camada desse tipo, é exatamente o tipo de trabalho que a Tyber.io engaja. Entre em contato — primeira conversa é exploratória e gratuita.