Visão geral do rastreamento distribuído

O rastreamento distribuído para balanceadores de carga de aplicativo oferece visibilidade de ponta a ponta das solicitações que vão dos clientes, passam pelo balanceador de carga e chegam aos serviços de back-end.

O Cloud Load Balancing se integra ao Cloud Trace para gerar períodos de trace para solicitações processadas pelo balanceador de carga. Como o balanceador de carga é o ponto de entrada do tráfego do aplicativo, iniciar e propagar o contexto de traces no balanceador de carga garante a visibilidade de diagnóstico em todo o caminho da solicitação. É possível usar esses traces para identificar gargalos de latência, isolar saltos com falha e resolver erros em arquiteturas de várias camadas.

O balanceador de carga gera traces que estão em conformidade com padrões abertos (Contexto de traces do W3C e OpenTelemetry). Os serviços de back-end instrumentados com o OpenTelemetry podem continuar o trace iniciado pelo balanceador de carga.

Principais vantagens

O rastreamento distribuído com o Cloud Trace oferece os seguintes benefícios:

  • Visibilidade de solicitações de ponta a ponta: rastreie o caminho de uma solicitação em balanceadores de carga de aplicativo externos e internos e nos serviços de back-end para os quais eles encaminham o tráfego.
  • Observabilidade de borda: capture períodos de trace na regra de encaminhamento, antes que o balanceador de carga selecione um back-end, para que você possa ver erros de borda e latência que a instrumentação de back-end não consegue detectar.
  • Configuração de telemetria desacoplada: defina as configurações de rastreamento em recursos TelemetryPolicy independentes sem alterar a configuração de roteamento do balanceador de carga.
  • Correlação de telemetria cruzada: correlacione períodos de trace com registros de solicitação do Cloud Load Balancing e métricas do Cloud Monitoring para identificar onde a latência ou os erros se originam.

Balanceadores de carga compatíveis

A tabela a seguir lista os balanceadores de carga que oferecem suporte ao rastreamento distribuído e os modos de amostragem compatíveis com cada balanceador de carga:

Balanceador de carga Esquema de balanceamento de carga Amostragem probabilística Amostragem baseada em pais
Balanceador de carga de aplicativo externo global EXTERNAL_MANAGED
Balanceador de carga de aplicativo externo regional EXTERNAL_MANAGED
Balanceador de carga de aplicativo interno regional INTERNAL_MANAGED
Balanceador de carga de aplicativo interno entre regiões INTERNAL_MANAGED

Os balanceadores de carga de aplicativo clássicos não são compatíveis com o trace distribuído.

Como funciona o rastreamento distribuído

Para configurar o rastreamento distribuído, crie um recurso TelemetryPolicy na API Network Services. Uma política de telemetria especifica o seguinte:

  • Destinos: as regras de encaminhamento dos balanceadores de carga que você quer rastrear.
  • Configuração de rastreamento: as configurações de amostragem que determinam quais solicitações o balanceador de carga rastreia.

Quando uma solicitação chega a uma regra de encaminhamento que é o destino de uma política de telemetria, o balanceador de carga decide se vai amostrar a solicitação. Se a solicitação for amostrada, o balanceador de carga vai gerar um período de trace, enviá-lo ao Cloud Trace e propagar o contexto de traces para o back-end no cabeçalho da solicitação W3C traceparent.

Anexo da regra de encaminhamento

As políticas de telemetria segmentam a regra de encaminhamento do balanceador de carga, que representa o front-end do balanceador de carga. Ao anexar o rastreamento à regra de encaminhamento, o balanceador de carga pode rastrear todo o tráfego que entra em um endereço IP virtual (VIP) e em uma porta, incluindo solicitações que falham antes que o balanceador de carga selecione um back-end.

As políticas de telemetria têm as seguintes características:

  • Ciclo de vida independente: as políticas de telemetria são separadas dos serviços de back-end, mapas de URL e proxies de destino. É possível criar, modificar ou excluir uma política de telemetria sem alterar a forma como o balanceador de carga roteia o tráfego.
  • Reutilizável em front-ends: uma única política de telemetria pode segmentar várias regras de encaminhamento, permitindo aplicar configurações de rastreamento consistentes em vários front-ends de balanceador de carga.
  • Com escopo de local: crie uma política de telemetria no local global para segmentar regras de encaminhamento globais, como as usadas por balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo internos entre regiões. Crie uma política de telemetria em uma região para segmentar regras de encaminhamento regionais nessa região, como as usadas por balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais.

Modos de amostragem

O rastreamento distribuído é compatível com os seguintes modos de amostragem. Para mais informações sobre quais modos de amostragem cada balanceador de carga aceita, consulte Balanceadores de carga compatíveis neste documento.

  • Amostragem probabilística: o balanceador de carga faz a amostragem de uma proporção fixa de solicitações, que você define no campo samplingRate. Por exemplo, um valor de 0.01 faz a amostragem de 1% das solicitações. A amostragem probabilística é compatível com todos os balanceadores de carga compatíveis.

  • Amostragem baseada em pai: o balanceador de carga respeita a decisão de amostragem no cabeçalho traceparent recebido de um cliente ou serviço upstream. Configure a amostragem baseada em pai no campo parentBasedSampling. A amostragem baseada em pai só é compatível com balanceadores de carga de aplicativo internos.

    Quando você ativa a amostragem baseada em pai, o balanceador de carga processa as solicitações da seguinte maneira:

    • Se o cabeçalho traceparent recebido tiver a flag de amostragem definida, o balanceador de carga vai amostrar a solicitação na taxa especificada no campo parentBasedSampling.samplingRate. Por exemplo, defina esse campo como 1.0 para rastrear todas as solicitações que um serviço upstream já tenha amostrado.
    • Se o cabeçalho traceparent recebido não tiver a flag de amostragem definida, o balanceador de carga não fará a amostragem da solicitação. Esse comportamento respeita a decisão upstream e segue a especificação do OpenTelemetry, que impede que traces desconectados apareçam no Cloud Trace.
    • Se a solicitação não incluir um cabeçalho traceparent, o balanceador de carga vai aplicar o samplingRate de referência.

Tratamento de cabeçalho de contexto de trace

O balanceador de carga processa o cabeçalho traceparent do W3C da seguinte maneira:

  • O rastreamento não está ativado ou a solicitação não foi amostrada: o balanceador de carga encaminha o cabeçalho traceparent recebido para o back-end sem alterações.
  • A solicitação é amostrada e não inclui um cabeçalho traceparent: o balanceador de carga gera um novo ID de trace e de período e define as flags de trace como 03 (aleatório e amostrado).
  • A solicitação é amostrada e inclui um cabeçalho traceparent: o balanceador de carga preserva o ID de trace recebido e a flag aleatória, gera um novo ID de período e define a flag de amostragem.

Os serviços de back-end que usam um SDK do OpenTelemetry com o propagador de contexto de traces do W3C leem automaticamente o cabeçalho traceparent e continuam o trace. Para mais informações, consulte Contexto de traces.

Casos de uso comuns

Nesta seção, descrevemos cenários comuns de rastreamento distribuído.

Monitorar a borda da vitrine

Uma vitrine de e-commerce usa um balanceador de carga de aplicativo externo global para receber o tráfego de clientes. Para monitorar a latência de borda e erros como respostas 404 e falhas de TLS, anexe uma política de telemetria com amostragem probabilística à regra de encaminhamento da vitrine. Uma taxa de amostragem baixa, como 0.01 (1%), mantém os custos de ingestão do Cloud Trace previsíveis durante eventos de pico de tráfego.

Manter a continuidade do trace nos serviços de finalização de compra

As solicitações de finalização de compra vão da vitrine, por um balanceador de carga de aplicativo interno, para os serviços internos de carrinho, inventário e pagamento. Para garantir que as solicitações de finalização de compra amostradas na vitrine sejam rastreadas em todos os saltos internos, ative a amostragem baseada em pai no balanceador de carga interno com um parentBasedSampling.samplingRate de 1.0. O tráfego interno de rotina que não carrega uma decisão de amostragem upstream é amostrado no valor de referência samplingRate.

Isolar gargalos de latência

Quando a latência de finalização de compra aumenta ou os erros 5xx aumentam, você compara os períodos do balanceador de carga no Cloud Trace com os registros de solicitação do balanceador de carga e as métricas de latência. Essa comparação ajuda a determinar se o problema se origina na borda do balanceador de carga, em um salto interno do balanceador de carga ou em um serviço de back-end.

Preços

O balanceador de carga não cobra pela geração de períodos de trace. No entanto, o Cloud Trace cobra pela ingestão de períodos de trace de acordo com os preços do Cloud Trace.

Para gerenciar os custos de ingestão de cargas de trabalho de produção de alto tráfego, recomendamos um samplingRate de 0.01 (1%) ou 0.001 (0,1%).

Limitações

Durante o pré-lançamento, o rastreamento distribuído para balanceadores de carga de aplicativo tem as seguintes limitações:

  • A amostragem baseada em pai não é compatível com balanceadores de carga de aplicativo externos.
  • Não há suporte para atributos de período personalizados.
  • Não é possível configurar o rastreamento distribuído usando a API Gateway do Google Kubernetes Engine ou o Terraform.
  • Uma única política de telemetria pode segmentar até 50 recursos.

Rastreamento distribuído para o Gateway de Agente

Se você usa o Gateway de Agente para gerenciar o tráfego de agentes de IA, consulte Monitorar o tráfego pelo Gateway de Agente para saber como monitorar o tráfego de agentes.

A seguir