Quando você recorreria a um trace distribuído em vez de uma métrica ou de um log?

Métricas te dizem que algo está errado e mais ou menos onde. Logs te dizem o que aconteceu dentro de um processo. Traces te dizem para onde foi o tempo entre serviços numa única requisição. Recorra a um trace quando a latência está alta mas nenhum serviço individual parece doente, ou quando uma requisição atravessa muitos saltos. Métricas são baratas e agregadas, logs são detalhados e caros, traces são amostrados e relacionais.

Eu penso nisso como três perguntas. Métricas respondem se está quebrado e o quão grave, logs respondem o que aconteceu neste processo, e traces respondem para onde foi o tempo na requisição inteira. O momento em que eu recorro a um trace é quando a latência geral subiu mas todo dashboard de serviço individual parece bem, o que quase sempre significa que o tempo está num salto sem dono. Isso aconteceu com a gente com um sidecar de service mesh adicionando retries que a gente não sabia que existiam; o trace deixou óbvio em mais ou menos um minuto, porque dava para ver três spans idênticos aninhados sob uma chamada. A cola prática é colocar trace id e span id em toda linha de log, para você conseguir pular de uma métrica agregada para um trace exemplar lento e daí para as linhas de log exatas daquela requisição. E eu amostraria traces no head com uma taxa baixa, com amostragem no tail para erros e requisições lentas, porque guardar tudo não compensa a conta.