Detalhes técnicos distributed tracing

Aqui estão alguns detalhes técnicos sobre como funciona distributed tracing da New Relic:

• Como funciona a amostragem de rastreamento
• Como estruturamos dados trace
• Como armazenamos dados trace
• Como o contexto do trace é passado entre aplicativos

Amostragem de rastreamento

A forma como o seu rastreamento será amostrado dependerá da sua configuração e da ferramenta de rastreamento New Relic que você está usando. Por exemplo, você pode estar usando um serviço de telemetria de terceiros (como OpenTelemetry) para implementar amostragem de rastreamento antes que seus dados cheguem até nós. Ou, se você estiver usando o Infinite Tracing, provavelmente nos enviará todos os seus dados trace e confiará em nossa amostragem.

Temos algumas estratégias de amostragem disponíveis:

• Amostragem head-based ( distributed tracing padrão)
• Amostras tail-based (rastreamento infinito)
• Sem amostragem

Amostragem head-based ( distributed tracing padrão)

Com exceção do nosso recurso Infinite Tracing , a maioria de nossas ferramentas de rastreamento usa uma abordagem Amostragem baseada em cabeça. Isso aplica filtros a intervalos individuais antes que todos os intervalos em um trace cheguem, o que significa que as decisões sobre aceitar ou não intervalos são tomadas no início (o "cabeçalho") do processo de filtragem. Usamos essa estratégia de amostragem para capturar uma amostra representativa da atividade, evitando problemas de armazenamento e desempenho.

Assim que chega o primeiro intervalo em um trace , uma sessão é aberta e mantida por 90 segundos. A cada chegada subsequente de um novo intervalo para esse trace, o tempo de expiração é redefinido para 90 segundos. O rastreamento que não recebeu um intervalo nos últimos 90 segundos será fechado automaticamente. O resumo trace e os dados de extensão são gravados somente quando um trace é fechado.

Aqui estão alguns detalhes sobre como o Amostragem head-based é implementado em nossas ferramentas padrão distributed tracing :

Amostras tail-based (rastreamento infinito)

Nosso recurso Infinite Tracing usa uma abordagem tail-based de amostragem. "Amostras tail-based" significa que as decisões de retenção de tracesão feitas no final do processamento, após a chegada de todos os intervalos em um trace .

Com o Infinite Tracing, você pode nos enviar 100% dos seus dados trace do seu aplicativo ou serviço de telemetria de terceiros, e o Infinite Tracing descobrirá quais dados de trace são mais importantes. E você pode configurar a amostragem para garantir que o traço importante para você seja retido.

Arquitetura

Para Rastreamento Infinito, o agente ou integração envia 100% de todos os intervalos do instrumento para um observador trace . O observador trace é um serviço distributed tracing que reside em um cluster de serviços na AWS chamado New Relic Edge.

Dica

Apenas seus spans vão para o observador trace – todos os outros dados, como métrica, evento personalizado e rastreamento da transação, são enviados pela rota normal para o New Relic e estão sujeitos à amostragem local.

Você configura um endpoint de observador trace exclusivo para a região da AWS para a qual deseja enviar dados. Como o rastreamento é um recurso entre contas, nossa implementação padrão é permitir apenas um observador trace por região, por família de contas (para solicitar mais, fale com seu representante de conta). O endpoint representa um observador trace para uma workload específica. Por exemplo, todos os intervalos de um único trace (solicitação) devem ir para esse endpoint.

Aqui estão dois diagramas de arquitetura: um mostrando como os dados fluem se você usar o agente APMe outro se você usar a integração New Relic como exportadores OpenTelemetry:

O observador trace mantém o rastreamento aberto enquanto os intervalos desse trace chegam. Assim que chega o primeiro intervalo em um trace , uma sessão é mantida aberta por 10 segundos. Cada vez que chega um novo intervalo para esse trace , o tempo de expiração é redefinido para 10 segundos. o rastreamento que não viu um intervalo chegar nos últimos 10 segundos expirará automaticamente.

Amostragem de algoritmos tail-based

Por padrão, cada observador trace oferece rastreamento para três amostradores: um que procura valores discrepantes de duração, um que procura rastreamento com erros e um que tenta fazer uma amostragem aleatória em todos os tipos trace . Cada amostrador mantém uma porcentagem de rastreamento de destino que corresponde aos seus critérios.

Aqui estão os detalhes sobre cada amostrador:

Amostrador	Critérios de correspondência	Percentual de destino
Duração	Rastreamento com duração outlier , usando dois algoritmos: Gaussiana (assume uma distribuição normal e um limite no percentil 99) Excentricidade (supõe nenhuma distribuição e um limite baseado no cluster)	100%
Erro	Trace tendo pelo menos um intervalo com um erro	100%
Aleatório	Todos os rastreamentos	1% (Isso é configurável. Consulte Rastreamento infinito: filtro de rastreamento aleatório)

Se os critérios correspondentes corresponderem ao trace, cada amostrador examinará a forma do trace . A forma de um traceé a combinação exclusiva do nome da entidade do intervalo raiz e do nome do intervalo. Esta é uma maneira simples de separar o rastreamento usando o ponto de entrada da solicitação.

Uma vez determinada a forma, o amostrador toma a decisão de manter ou rejeitar o trace com base na porcentagem de amostragem de destino. Se for 100%, o trace é mantido automaticamente. Se for menor, a probabilidade de o amostrador manter um determinado trace é determinada pela porcentagem de destino. Por exemplo, a porcentagem de destino padrão é 1 para rastreamento aleatório, portanto, 1% desses rastreamentos são mantidos. Se preferir, você pode alterar a porcentagem aleatória do filtro.

Como o observador trace utiliza porcentagens de taxas de transferência, o número de rastreamento selecionado irá variar de acordo com essas taxas de transferência.

Sem amostragem

Algumas de nossas ferramentas não usam amostragem. Detalhes de amostragem para estas ferramentas:

Limites trace

Nossos sistemas de processamento de dados estão equipados com limites internos para proteger nossa infraestrutura contra picos inesperados de dados. Esta camada protetora não apenas mantém a integridade da nossa plataforma, mas também garante uma experiência confiável e consistente para todos os nossos clientes. Embora esses limites sejam ajustados conforme necessário com base em diversas condições, eles são definidos com uma abordagem voltada para o futuro. À medida que nossa base de usuários e o consumo de dados crescem, expandimos nossa capacidade de infraestrutura. Este compromisso garante que capturamos todos os dados dos clientes enviados para nós e oferecemos a você uma visão clara e ininterrupta dos seus dados trace .

Como os dados trace são estruturados

Compreender a estrutura de um distributed trace pode ajudá-lo a:

• Entenda como os traces são exibidos em nossa interface
• Ajudá-lo a consultar dados de rastreamento

Um distributed trace possui uma estrutura semelhante a uma árvore, com "span filho que se referem a um "span pai. Este diagrama mostra alguns relacionamentos de extensão importantes em um trace:

Este diagrama mostra vários conceitos importantes:

• Trace root.

  O primeiro serviço ou processo em um trace é chamado de serviço ou processo

  root

  .

• Process boundaries

  . Um processo representa a execução de um trecho lógico de código. Exemplos de processo incluem um serviço backend ou função do Lambda. Os períodos dentro de um processo são categorizados como um dos seguintes:

  • Entry span

    : o primeiro intervalo em um processo.

  • Exit span

    : um span é considerado um span de saída se a) for pai de um span de entrada, ou b) tiver atributo http. ou db. e, portanto, representar uma chamada externa.

  • In-process span

    : um intervalo que representa uma chamada de método ou função interna e que não é um intervalo de saída ou entrada.

• Client spans

  . Um span de cliente representa uma chamada para outra entidade ou dependência externa. Atualmente, existem dois tipos de span de cliente:

  • Datastore

    . Se um span de cliente tiver um atributo prefixado com db. (como db.statement), ele será categorizado como um span de armazenamento de dados.

  • External

    . Se um span de cliente tiver um atributo prefixado com http. (como http.url) ou tiver um span filho em outro processo, ele será categorizado como um span externo. Esta é uma categoria geral para qualquer chamada externa que não seja consulta de armazenamento de dados. Se um período externo contiver http.url ou net.peer.name, ele será indexado na página Serviços externos .

• Trace duration

  . A duração total de um trace é determinada pelo período de tempo desde o início do intervalo mais antigo até a conclusão do último intervalo.

Você pode consultar dados de relacionamento de extensão com o NerdGraph GraphiQL Explorer em api.newrelic.com/graphiql.

Como os dados trace são armazenados

Compreender como armazenamos dados trace pode ajudá-lo a consultar seus dados trace .

Salvamos dados trace como:

• Span: Um intervalo representa operações que fazem parte de um distributed trace. As operações que um span pode representar incluem interação do lado do browser, consulta de armazenamento de dados, chamadas para outros serviços, temporização em nível de método e Função do Lambda. Um exemplo: em um serviço HTTP, um intervalo é criado no início de uma solicitação HTTP e concluído quando o servidor HTTP retorna uma resposta. Span atributo contém informações importantes sobre essa operação (como duração, dados do host, etc.), incluindo detalhes do relacionamento de trace (como traceId, guid). Para dados relacionados ao span, consulte span atributo.
• Transaction: se uma entidade em um trace for monitorada por um agente, uma solicitação para essa entidade gerará um único evento Transaction. A transação permite que os dados trace sejam vinculados a outros recursos da New Relic. Para dados relacionados à transação, veja atributo da transação.
• Metadados contextuais. Armazenamos metadados que mostram cálculos sobre um trace e as relações entre seus intervalos. Para consultar esses dados, utilize o explorador NerdGraph GraphiQL.

Como o contexto do trace é passado entre aplicativos

Apoiamos o padrão W3C Trace Context, que facilita o trace de transações entre redes e serviços. Quando você habilita distributed tracing, o agente New Relic adiciona cabeçalhos HTTP às solicitações de saída de um serviço. Os cabeçalhos HTTP funcionam como passaportes em uma viagem internacional: eles identificam o rastreamento do seu software e carregam informações importantes à medida que viajam por várias redes, processos e sistemas de segurança.

Os cabeçalhos também contêm informações que nos ajudam a vincular os spans posteriormente: metadados como ID trace , ID de span, ID da conta New Relic e informações de amostragem. Veja a tabela abaixo para mais detalhes sobre o cabeçalho:

Essas informações de cabeçalho são transmitidas ao longo de cada intervalo de um trace, a menos que o progresso seja interrompido por algo como middleware ou agente que não reconhece o formato do cabeçalho (veja a Figura 1).

Para resolver o problema de propagação de cabeçalho, oferecemos suporte à especificação W3C Trace Context, que requer dois cabeçalhos padronizados. Nossos agentes W3C New Relic mais recentes enviam e recebem esses dois cabeçalhos obrigatórios e, por padrão, também enviam e recebem o cabeçalho do agente New Relic anterior:

• W3C (traceparent): o cabeçalho principal que identifica todo o trace (ID trace ) e o serviço de chamada (ID do span).
• W3C (tracestate): um cabeçalho obrigatório que contém informações específicas do fornecedor e rastreia onde um trace esteve.
• New Relic (newrelic): O cabeçalho proprietário original que ainda é enviado para manter a compatibilidade com versões anteriores do agente New Relic anterior.

Esta combinação de três cabeçalhos permite que o rastreamento seja propagado através do instrumento de serviços com estes tipos de agente:

• Agente W3C New Relic
• Agente New Relic não W3C
• Agente compatível com W3C Trace Context

Os cenários abaixo mostram vários tipos de propagação de cabeçalho bem-sucedida.

Cenário 1: trace tocando três tipos de agente

Isso mostra o fluxo de cabeçalhos quando uma solicitação atinge três tipos de agentes diferentes:

Cenário 2: trace com W3C New Relic e middleware

Isso mostra a combinação de cabeçalhos enviados por um agente W3C New Relic para algum middleware.

Cenário 3: trace com qualquer agente compatível com W3C e um agente New Relic.

Isso mostra os dois cabeçalhos W3C necessários de outro fornecedor aceitos por um agente W3C New Relic.

Se ainda não o fez, crie sua conta New Relic gratuita abaixo para começar a monitorar seus dados hoje mesmo.