Rollout progressivo, avançar um release por percentuais crescentes de tráfego, cada estágio condicionado ao anterior estar saudável, só é tão bom quanto o que está decidindo "saudável". Pra maioria dos times, o dado que responderia essa pergunta já vive no Prometheus: taxa de requisição, taxa de erro, histograma de latência, tudo consultável via PromQL. O buraco geralmente não é o dado. É conectar esse dado à coisa que de fato avança ou trava o rollout.
O que o Prometheus te dá, e o que não dá
O Prometheus e o Alertmanager conseguem te dizer que um resultado de query cruzou um limite, e acionar alguém sobre isso. Nenhum dos dois avança um estágio de rollout, segura ele, ou reverte. Essa decisão precisa viver em outro lugar, avaliada contra o próprio estado do rollout (qual estágio está ativo, há quanto tempo) além da métrica.
Pra ser específica sobre o rollfuse aqui: não existe um scraper de Prometheus embutido. O que existe é um rollout com alvos de percentual em estágios, programados, e um guardrail anexado a ele que avalia uma definição de métrica numa programação. O valor da métrica precisa chegar ao rollfuse de algum jeito, e o Prometheus não é a coisa que coloca ele lá sozinho.
Duas formas de fechar o buraco
Empurrar. Calcule o resultado do PromQL na cadência que bate com a janela de avaliação do seu guardrail, e empurre como uma observação:
POST /v1/environments/{environment_id}/metric-definitions/{metric_definition_id}/observations
{
"value": 0.987,
"observed_at": "2026-08-27T09:15:00Z"
}
Puxar. Um Connector, configurado com um template de contrato que mapeia a resposta da API HTTP de query do Prometheus pro formato {value, observed_at}, faz polling numa programação sem você hospedar um script sozinha.
De qualquer jeito, uma vez que o valor chega como uma observação contra a definição de métrica certa, ele se comporta de forma idêntica a qualquer outra métrica de guardrail: avaliado continuamente contra o limite do rollout, com uma violação revertendo o percentual de tráfego do rollout automaticamente.
Por que "progressivo" e "automático" precisam andar juntos
Um rollout progressivo sem um portão automatizado é, na prática, só um rollout completo lento. O estagiamento não te compra nada se todo estágio avança num timer independente do que as métricas dizem. O valor inteiro de estagiar tráfego depende de algo de fato checar, em cada estágio, se é seguro continuar. Se o Prometheus já tem o sinal, a peça que falta geralmente não é mais instrumentação. É a única chamada de API que deixa esse sinal de fato parar o rollout em vez de só registrar que deveria ter parado.