OpenTelemetry Go Logs chega a RC: compatibilidade está próxima, mas ainda precisa de canário

O sinal e os factos que mudam a decisão

O projeto OpenTelemetry anunciou em 31 de agosto o Go Logs API e SDK v1.47.0-rc.1 como release candidate, a etapa final antes das garantias de compatibilidade v1 estável segundo o próprio projeto. Release candidate significa pedido de teste amplo, não estabilidade já concedida.

O anúncio identifica v1.47.0-rc.1 como release candidate; as garantias v1 ainda são um estado futuro. A estabilidade OpenTelemetry é definida por sinal e componente; Logs em Go não implica estabilidade automática de Collector, exporters ou backend.

O modelo de dados de Logs permite correlação e atributos, mas convenções e cardinalidade precisam de contrato local. Migrar toda a frota para obter correlação mais cedo pode criar lock-in numa API pré-estável ou custos de ingestão inesperados. Testar apenas happy path deixa de fora backpressure, cardinalidade, perda, retry e comportamento quando o backend está indisponível.

Decisão, limites e condição de bloqueio

Teste o RC num serviço canário que represente volume, atributos, correlação, exporters, Collector, sampling e falhas da produção. Mantenha a interface atrás de uma abstração e fixe versões, porque a decisão é avaliar compatibilidade antes do v1, não prometer API estável hoje.

Migrar toda a frota para obter correlação mais cedo pode criar lock-in numa API pré-estável ou custos de ingestão inesperados. Testar apenas happy path deixa de fora backpressure, cardinalidade, perda, retry e comportamento quando o backend está indisponível.

Execução e prova de conclusão

A execução deve começar por selecionar um serviço representativo e fixar sdk, api, collector, exporter, backend, schema e limites. Depois, comparar logs antes/depois, correlação trace-log, throughput, memória, cpu, perda, retry e custo de ingestão. O fecho exige simular backend lento ou indisponível e confirmar que a aplicação preserva slo e que o rollback remove o rc sem perda de observabilidade essencial.

O canário passa quando a semântica permanece consistente, perdas e recursos ficam dentro dos limites, falhas do pipeline não degradam o serviço e o rollback funciona; a adoção geral espera a decisão de estabilidade ou uma exceção formal.

• selecionar um serviço representativo e fixar SDK, API, Collector, exporter, backend, schema e limites.
• comparar logs antes/depois, correlação trace-log, throughput, memória, CPU, perda, retry e custo de ingestão.
• simular backend lento ou indisponível e confirmar que a aplicação preserva SLO e que o rollback remove o RC sem perda de observabilidade essencial.
• O canário passa quando a semântica permanece consistente, perdas e recursos ficam dentro dos limites, falhas do pipeline não degradam o serviço e o rollback funciona; a adoção geral espera a decisão de estabilidade ou uma exceção formal.