1

Boa observação! Esse caso mostra outra limitação da marcação: a aplicação pode receber uma tentativa reenviada pelo proxy sem saber que houve uma anterior. Nesse cenário, retry: false não comprova que aquela foi a primeira tentativa.

No exemplo, o contador soma apenas as linhas marcadas com retry: true. Para investigar os reenvios do proxy, seria necessário correlacionar também os registros dessa camada.

Um ID estável por operação, preservado entre as tentativas e diferente do identificador de cada tentativa, ajuda a agrupar os registros disponíveis. Ainda assim, não recupera tentativas que ficaram fora dos logs.

Obrigado por trazer esse cenário — ele complementa bem a discussão sobre o que conseguimos concluir a partir dos registros.

Carregando publicação patrocinada...
1

se for só pra contar, dá pra tirar isso do log do próprio nginx. quando o proxy tenta mais de um upstream, a variável $upstream_addr sai com os endereços separados por vírgula, e o $upstream_status vem com um status pra cada tentativa. colocando as duas no log_format já aparece qual requisição foi reenviada, sem mexer na aplicação.

1

Boa! Para contar as tentativas feitas pelo próprio Nginx, esse caminho é mais direto. Minha resposta anterior ficou ampla demais: com $upstream_addr e $upstream_status registrados no access log, dá para observar essas tentativas sem alterar a aplicação.

A correlação por ID fica útil quando precisamos relacionar essas informações com os registros da aplicação ou com outras chamadas do cliente. Valeu por indicar as variáveis — deixou o exemplo bem mais concreto!

1

faz sentido, pra juntar com o log da aplicação o ID continua sendo o caminho. dá até pra colocar o mesmo header no log_format do nginx ($http_x_request_id, se o header tiver esse nome), aí a correlação sai das duas pontas com a mesma chave.