"Feature flags com OpenTelemetry" na verdade cobre duas integrações separadas que são tratadas como se fossem uma coisa só. Uma delas o rollfuse entrega hoje. A outra, como a maioria das plataformas de guardrail, não, nativamente, e vale ser clara sobre qual é qual.
O que é real: propagação de trace em toda chamada de avaliação
Toda chamada de origem SDK pra API de avaliação do rollfuse (sdk-js, sdk-browser, e o proxy server-mediado do sdk-react) carrega propagação de trace-context W3C. Se a aplicação integradora tem @opentelemetry/api instalado como peer dependency opcional, com um span ativo no momento da chamada, o contexto desse span é injetado na requisição de saída via propagation.inject. A avaliação da flag aparece como filha de qualquer trace que já estava em andamento, em vez de chegar como uma chamada órfã sem relação com a requisição que a disparou.
Se não tem API do OTel instalada, ou nada ativo, o SDK gera um traceparent autoemitido, válido pela spec. Então a chamada ainda origina um trace linkável de qualquer jeito, degradando graciosamente em vez de exigir que o OTel esteja presente. Isso é uma coisa genuinamente útil de ter funcionando de ponta a ponta: quando você está debugando por que uma requisição se comportou de um jeito específico, conseguir ver "essa requisição avaliou checkout-v2 e pegou a variação B" como um span no mesmo trace da requisição em si, em vez de num log separado de avaliação de flag que você tem que correlacionar na mão, é o ganho real.
O que ainda não existe: métrica OTel guiando um guardrail
A outra metade de "feature flags com OpenTelemetry", usar uma métrica coletada via OTel pra pausar ou reverter um rollout automaticamente, é um mecanismo diferente, e não é uma integração nativa hoje. Os guardrails do rollfuse avaliam uma definição de métrica numa programação; colocar o valor de uma métrica coletada via OTel nesse pipeline significa empurrar como uma observação numa cadência que bate com a janela de avaliação do guardrail, ou puxar via um Connector configurado contra onde quer que essa métrica acabe consultável (a própria API de query de um backend que recebe OTLP, por exemplo). É o mesmo formato de conectar uma métrica do Prometheus, não um receptor OTLP embutido do lado do rollfuse.
Por que vale manter a distinção clara
Tracing e métrica resolvem problemas diferentes até dentro do próprio OpenTelemetry: um explica o que aconteceu numa requisição específica, o outro agrega o que aconteceu em muitas. A história de OTel de uma plataforma ser real pra uma coisa não implica que ela é construída pra outra, e misturar as duas é como um time acaba assumindo que um rollout vai reverter sozinho numa métrica OTel porque "a gente já tem OpenTelemetry funcionando", quando o que de fato está funcionando é a propagação de trace, uma peça genuinamente separada.