> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Página de traces

> Inspecione um trace: seu mapa de serviços, linha do tempo de spans, detalhes de spans, tags, logs relacionados, triggers e os outros traces da mesma action.

Quando você escolhe um trace para examinar na lista ["Performance > Traces"](https://appsignal.com/redirect-to/app?to=performance/traces) e seleciona um dos traces mais recentes em um horário específico, você é levado à página de detalhes do trace de performance, que mostra o mapa de serviços, a linha do tempo, as tags e os logs relacionados do trace.
A página do trace mostra um trace armazenado para uma action: uma requisição, um job em background ou outra operação que sua aplicação executou. Um trace é composto por **spans**, as unidades de trabalho individuais dentro dele, como uma requisição HTTP, uma query de banco de dados ou uma tarefa em background.

Use a página para ver onde a operação gastou seu tempo, revisar seu contexto e seus logs, e decidir o que fazer a seguir.

O cabeçalho mostra o nome da action e seu [namespace](/guides/namespaces), por exemplo `run/shop.send_waitlist_notification` em `celery/background`. As abas abaixo do cabeçalho alternam entre visões da mesma action: Summary, Traces e Charts.

<h2 id="service-map">
  Mapa de serviços
</h2>

O mapa de serviços mostra o trace do ponto de vista dos serviços envolvidos: quais serviços a requisição alcançou, e quanto tempo cada chamada entre eles levou. Ele aparece apenas quando um trace atravessa mais de um serviço, porque um trace que permanece dentro de um único serviço não tem nada para mapear.

* **Uma caixa por serviço**, agrupada por `service_name`. Cada caixa é identificada com o nome do serviço e a aplicação do AppSignal para a qual ele reporta. Dentro dela, uma linha por chamada que o serviço tratou, de forma que um serviço chamado duas vezes no mesmo trace mostra duas linhas. Selecione uma linha para abrir a visão desse serviço sobre o trace.
* **As arestas são as chamadas entre serviços**, identificadas com sua duração e chegando na linha da action que chamaram. Isso cobre chamadas síncronas, como uma requisição HTTP, e assíncronas, como um app web enfileirando um job em background.
* **A cor da aresta avalia cada chamada** em relação à própria linha de base do trace, como rápida, lenta ou crítica, de forma que os saltos mais lentos se destaquem sem que você precise ler cada duração. Uma aresta tracejada indica um trace vinculado, e uma caixa tracejada indica um serviço de outro trace.
* **Erros marcam o serviço em que ocorreram**, não o serviço que o chamou.

A legenda explica cada cor e borda, e você pode recolhê-la para ver mais do mapa.

<Frame caption="O mapa de serviços do trace, mostrando os serviços em um trace e as chamadas entre eles">
  <img src="https://mintcdn.com/appsignal-715f5a51/c83ekv4V7F6m4xy5/assets/images/screenshots/performance/trace-service-map.png?fit=max&auto=format&n=c83ekv4V7F6m4xy5&q=85&s=f98eed52b3b3bfefea7a4bed9d373410" alt="Mapa de serviços de um único trace passando por um bot, um serviço web, um serviço de pagamentos e um serviço Sidekiq, com cada chamada identificada por duração e colorida por velocidade" width="2922" height="1810" data-path="assets/images/screenshots/performance/trace-service-map.png" />
</Frame>

<h2 id="trace-timeline">
  Linha do tempo do trace
</h2>

Ao selecionar um trace em um horário específico, a linha do tempo organiza os spans do trace ao longo do tempo, do início do trace até seu fim. A posição de cada barra mostra quando um span começou, sua largura mostra por quanto tempo o span rodou, e sua cor mostra o grupo de spans ao qual ele pertence. O AppSignal também sinaliza problemas aqui, como um evento N+1: a mesma query repetida muitas vezes em uma operação.

A linha do tempo acompanha a operação através dos serviços. Em uma loja de stroopwafels, uma requisição Django pode enfileirar uma tarefa Celery, a tarefa envia um e-mail, e um serviço de auditoria registra o resultado. Cada serviço é identificado na linha do tempo, para que você veja onde um serviço passa o trabalho para o próximo.

Selecione **All spans** para abrir a linha do tempo em tela cheia, onde você pode:

* Buscar spans por nome, atributo ou evento.
* Filtrar por tipo de evento: errors, queries ou events.
* Filtrar por issue, como queries N+1.
* Filtrar por grupo de spans, como servidor web, banco de dados e ORM, HTTP ou outro.
* Filtrar por serviço, ou restringir a linha do tempo a uma parte da duração do trace.
* Expandir e recolher spans aninhados. Um badge mostra quantos spans filhos um span tem, e um badge de repetição como `x6` mostra com que frequência o mesmo span rodou.
* Selecionar um span para abrir seus detalhes.

<Frame caption="A linha do tempo do trace em tela cheia, com os detalhes do span selecionado">
  <img src="https://mintcdn.com/appsignal-715f5a51/c83ekv4V7F6m4xy5/assets/images/screenshots/performance/trace-timeline.png?fit=max&auto=format&n=c83ekv4V7F6m4xy5&q=85&s=236174ca0fe90493dd971b877160fa09" alt="Linha do tempo do trace mostrando os spans de uma requisição ao longo do tempo, os filtros de evento e de grupo de spans, e os atributos do span selecionado" width="3040" height="1760" data-path="assets/images/screenshots/performance/trace-timeline.png" />
</Frame>

<h3 id="span-details">
  Detalhes do span
</h3>

O painel de detalhes nomeia o span e mostra seu tipo, como `consumer`, seu status, sua hora de início e sua duração. Três abas fornecem o restante:

* **Attributes**: os atributos do span, como `celery.task_name` e `messaging.destination`, e os atributos de recurso, como `host.name` e `service.name`. Selecione **Show internal attributes** para listar também os atributos que o AppSignal adiciona. O ID do trace e o ID do span ficam visíveis **somente** enquanto **Show internal attributes** está selecionado.
* **Exceptions** ou **Events**: os erros e outros eventos registrados no span. Um span que gerou um erro também mostra um resumo no topo do painel, com uma ação para ver a exceção.
* **Related logs**: as linhas de log vinculadas ao span. Selecione **View in logs** para continuar no [explorador de logs](/logging).

A aba **Related logs** abre com seu escopo definido como **This span**, então ela busca apenas as linhas de log do span selecionado. Defina o escopo como **Entire trace** para ampliar a busca para todas as linhas de log vinculadas ao trace, em todos os seus spans e serviços.

<h3 id="trace-breakdown">
  Detalhamento do trace
</h3>

O detalhamento do trace resume o trace inteiro em duas barras empilhadas. Em ambas, cada segmento é uma das bibliotecas que fez o trabalho, como `active_record`, `http_rb` ou `sidekiq`, e a legenda lista cada biblioteca com seu próprio total, a maior primeiro.

* **Durations**: quanto do tempo do trace cada biblioteca representa.
* **Allocations**: quantos objetos cada biblioteca alocou, com o total do trace no título.

<h2 id="tags">
  Tags
</h2>

Tags são os pares de chave e valor registrados com o trace, como `hostname`, `queue`, `message_id` e `revision`.

Cada tag tem duas ações:

* **Filter** restringe a lista de Traces aos traces desta action que carregam o mesmo valor. O valor permanece visível acima da lista, e **Reset** o limpa.
* **Search** abre uma visão geral de tudo que o AppSignal registrou com aquele valor. Você pode restringir a visão geral por app, namespace, período e tipo, de forma que veja apenas os erros ou apenas os traces de performance que o compartilham. Selecione **Go to trace** em qualquer resultado para abri-lo.

Para transformar um valor de tag em um link para sua própria aplicação, use os [modelos de link](/application/link-templates). Para enviar mais tags da sua aplicação, veja [tagging](/application/tagging).

<h2 id="related-logs">
  Logs relacionados
</h2>

As linhas de log vinculadas a este trace, com seu horário, severidade e mensagem. No exemplo dos stroopwafels, elas mostram o início da tarefa de lista de espera, a falha no envio do e-mail e a nova tentativa que se segue. Selecione **Open in the log view** para continuar no [explorador de logs](/logging).

O painel informa quando não encontra linhas de log relacionadas. O AppSignal vincula uma linha de log a um trace por um `request_id` ou `trace_id` compartilhado, então o painel permanece vazio quando a operação não registrou nada, quando sua aplicação ainda não envia logs ao AppSignal, ou quando o identificador está ausente em um dos dois. Veja [configurar logging](/logging/configuration) para enviar logs, e [vincular traces com logs](/guides/linking-traces-with-logs) para os identificadores.

<h2 id="request-details">
  Detalhes da requisição
</h2>

Para requisições web, a página também mostra os dados brutos recebidos pelo AppSignal, em três painéis:

* **Cabeçalhos da requisição**: os cabeçalhos HTTP enviados com a requisição. Use a [filtragem de cabeçalhos](/application/header-filtering) para escolher quais cabeçalhos sua aplicação envia.
* **Payload da requisição**: o corpo da requisição, como uma query GraphQL e suas variáveis. Use a [filtragem de parâmetros](/application/parameter-filtering) para manter valores sensíveis fora.
* **Dados de sessão da requisição**: os valores de sessão da requisição. Use a [filtragem de dados de sessão](/application/session-data-filtering) para manter valores sensíveis fora.

<h2 id="performance-trends">
  Tendências de desempenho
</h2>

Um gráfico da performance da action nas últimas 24 horas ou 30 dias.

<h2 id="triggers">
  Triggers
</h2>

Triggers alertam você quando esta action fica lenta. O painel lista os triggers que já existem para a action, como `Mean > 200 ms`.

Selecione **Add new** para abrir o formulário de trigger com o namespace e o nome da action já preenchidos. No formulário, você:

* Escolhe o valor a ser monitorado, como a média, e o limite acima do qual o AppSignal alerta, como 200 ms.
* Define um warm-up e um cooldown de alerta em minutos.
* Adiciona uma descrição para as pessoas que recebem o alerta.
* Seleciona os notifiers que o recebem, como e-mail, Slack, PagerDuty ou OpsGenie.

Para saber como os alertas abrem, fecham e se repetem, veja [anomaly detection](/anomaly-detection) e [warm-up e cooldown](/anomaly-detection#warm-up-and-cooldown).

<h2 id="actions">
  Actions
</h2>

* **Time Detective**: revise os dados da sua aplicação como estavam no momento do trace.
* **Send to your issue tracker**: crie uma issue a partir do trace. Essa ação aparece quando um tracker está conectado, e seu rótulo corresponde a esse tracker, como GitHub, GitLab, Jira ou Linear. Veja [integrações](/application/integrations).

<h2 id="traces">
  Traces
</h2>

O painel Traces lista os outros traces armazenados para essa action, cada um com seu timestamp e duração. Selecione qualquer um deles para abrir esse trace.

Para encontrar um trace específico:

* Insira um valor no campo de filtro de tag, ou use a ação **Filter** em uma tag, para manter apenas os traces que carregam esse valor.
* Abra o controle de data para escolher uma data e horário, ou escolha **Today**, **Yesterday**, **Last week** ou **Latest**. Selecione **Jump to latest** para voltar aos traces mais recentes.
* Selecione **Load newer traces** ou **Load older traces** para navegar pela lista.
* Selecione **Reset** para limpar os filtros e ver novamente todos os traces armazenados.

Um [deploy marker](/application/markers) entre dois traces mostra onde uma nova versão assumiu, o que ajuda você a comparar traces de antes e depois de um deploy.

<Note>
  O AppSignal não armazena um trace para cada requisição. Em vez disso, ele armazena um conjunto representativo, então a lista mostra uma amostra do tráfego da action.
</Note>
