A métrica você já tem. http_requests_total com o label status, um histograma de latência p99, um gauge de profundidade de fila, qualquer coisa que seus serviços já expõem para o Prometheus. O que falta na maioria dos times não é visibilidade. É o último passo: transformar a violação de uma métrica em um rollback de verdade, sem depender de alguém olhando um dashboard e reagindo na mão.
Um guardrail do rollfuse faz esse passo. Ele não consulta o Prometheus sozinho: o valor precisa chegar ao rollfuse como observações, puxado por um conector ou enviado por um job seu. Com as observações lá, um rollout cuja métrica ultrapassa o limite é abortado automaticamente.
1. Defina a métrica no rollfuse
Uma definição de métrica dá nome à métrica e à unidade. Ela não guarda PromQL; a consulta continua no seu Prometheus.
POST /v1/projects/{project_id}/metric-definitions
{
"name": "Proporção de 5xx no checkout",
"key": "checkout_5xx_ratio",
"aggregation_type": "average",
"unit": "ratio"
}
2. Leve o valor do Prometheus para o rollfuse
Puxe com um conector. Um conector chama uma URL HTTPS periodicamente (e sempre que você pede uma sincronização), envia o segredo dele como Authorization: Bearer <segredo> e transforma a resposta JSON em observações usando um modelo de contrato aprovado. O endpoint de consulta instantânea do Prometheus pode ser essa URL, por exemplo https://prometheus.exemplo.com.br/api/v1/query?query=<sua PromQL, codificada para URL>. A resposta dele guarda cada série em data.result, com o ponto num par [timestamp, "valor"], então o mapeamento fica assim:
{
"root_path": "data.result",
"value_field": "value.1",
"observed_at_field": "value.0",
"observed_at_format": "unix_seconds"
}
Dá para testar o mapeamento contra a URL real antes de salvar qualquer coisa, e o tutorial de conectores mostra a pré-visualização, a criação e a sincronização. A URL precisa ser HTTPS e acessível pelo rollfuse, e quem responde nela (o Prometheus ou um proxy na frente dele) precisa aceitar ou ignorar o cabeçalho Bearer.
Envie do seu lado. Um job que você roda executa a consulta PromQL e envia o resultado com uma service credential que tenha o escopo metrics:write:
POST /v1/environments/{environment_id}/metric-definitions/{metric_definition_id}/observations
{
"observations": [
{ "value": 0.004, "occurred_at": "2026-10-11T14:00:00Z" }
]
}
3. Anexe um guardrail ao rollout
Um guardrail referencia a definição de métrica, um operador de comparação, um limite e uma janela de avaliação. Você pode criá-lo no console ou pela API:
POST /v1/rollouts/{rollout_id}/guardrails
{
"metric_definition_id": "<metric_definition_id>",
"comparison_operator": "gt",
"threshold": 0.01,
"evaluation_window_seconds": 900
}
O tutorial de rollback automático mostra essa chamada e como ler o histórico de avaliações do guardrail.
Como a janela de avaliação funciona
A cada avaliação, o rollfuse tira a média das observações do ambiente do rollout que caem dentro da janela que termina naquele momento, e compara essa média com o limite. Um pico isolado é diluído pelo resto da janela em vez de disparar um rollback sozinho. Uma janela sem observações é registrada como dados insuficientes, não como violação.
O que o rollback faz de fato
Reverter não significa fazer um novo deploy da versão anterior. Quando um guardrail é violado, o rollfuse aborta o rollout: a flag volta a servir a variação padrão para 100% daquele ambiente, e o rollout para de avançar. Os SDKs recebem a nova configuração na próxima atualização. A regressão continua deployada; ela só deixa de ser servida enquanto alguém investiga.
O que fica registrado
Cada avaliação é guardada com o valor médio, o limite, se houve violação e, quando houve, a ação tomada. Esse histórico pode ser consultado por guardrail no console, então "por que isso reverteu" tem resposta no registro.
Limites que vale conhecer
- O rollfuse não tem coletor próprio de Prometheus e não executa PromQL. Seu Prometheus responde a consulta; o rollfuse só vê os números que chegam até ele.
- O guardrail reage ao número que você envia. Se a consulta mede o serviço inteiro, o guardrail reage ao serviço inteiro, não só ao tráfego do rollout.
- Um conector só se autentica com token Bearer sobre HTTPS, e um projeto pode ter até 20 conectores.