Rastros distribuídos geram grandes volumes de dados de span. Sem amostragem, os custos de armazenamento e computação aumentam conforme o tráfego, embora a maioria dos rastros represente requisições normais e saudáveis. O Application Real-Time Monitoring Service (ARMS) oferece cinco políticas de amostragem que permitem manter apenas os rastros relevantes — como erros, requisições lentas e interfaces de baixo tráfego — e descartar o rest. Essa abordagem reduz custos e preserva a cobertura de observabilidade necessária para solução de problemas e análise de desempenho.
Todas as alterações na configuração de amostragem entram em vigor imediatamente. Não é necessário reiniciar a aplicação.
Termos
|
Termo |
Definição |
|
Span |
Uma única operação dentro de uma requisição, como uma chamada RPC ou uma invocação de método interno. |
|
Root span |
O primeiro span de um rastro. Um root span não possui pai. |
|
Local root span |
O primeiro span de um rastro dentro de um único serviço. Cada serviço em um rastro distribuído tem seu próprio local root span. |
|
Span context |
Metadados associados a um span, propagados entre limites de processos. |
|
Head-based sampling |
Decisão de amostragem tomada no root span antes que o rastro comece a se propagar. O head-based sampling garante rastros completos: todos os spans são amostrados ou nenhum é. |
|
Non-head based sampling |
Amostragem que entra em vigor quando o head-based sampling não é acionado. O non-head based sampling pode ser ativado em qualquer local root span; portanto, a integridade do rastro não é garantida. |
Escolha uma política de amostragem
O ARMS fornece duas políticas baseadas em head-based sampling e três baseadas em non-head based sampling. As políticas head-based decidem no root span e garantem rastros completos de ponta a ponta. Já as políticas non-head based decidem em serviços individuais e capturam rastros que o head-based sampling poderia ignorar.
|
Objetivo |
Política recomendada |
Categoria |
|
Amostrar uma porcentagem fixa de todos os rastros |
Head-based |
|
|
Equilibrar a cobertura entre todas as interfaces, independentemente do volume de tráfego |
Head-based |
|
|
Garantir pelo menos um rastro por interface por minuto |
Non-head based |
|
|
Capturar automaticamente rastros de erros e requisições lentas |
Non-head based |
|
|
Sempre amostrar interfaces específicas por nome |
Non-head based |
Várias políticas podem estar ativas simultaneamente. O ARMS as avalia em uma ordem definida. Consulte Fluxograma de decisão de amostragem.
Políticas de head-based sampling
O head-based sampling toma uma única decisão no root span de um rastro. Se o rastro for amostrado, todos os spans downstream herdam essa decisão por meio do span context. Isso garante rastros completos de ponta a ponta.
Amostragem de taxa fixa
A amostragem de taxa fixa seleciona rastros com base em uma porcentagem configurada no serviço de entrada. Por exemplo, uma taxa de amostragem de 10% significa que aproximadamente 1 em cada 10 rastros será amostrado.
Os spans amostrados carregam o atributo sample.reason: s4.
Configure a amostragem de taxa fixa
Faça login no console do ARMS. No painel de navegação à esquerda, escolha .
-
Selecione uma região na barra de navegação superior e clique em na aplicação.
NotaOs ícones na coluna
Language
indicam a linguagem de programação: -
: Java -
: Go -
: Python -
-
(Hífen): uma aplicação monitorada no Managed Service for OpenTelemetry
Na barra de navegação superior, escolha .
-
Na seção Sampling Settings, defina Sampling strategy como Fixed sampling rate. No campo Sample Rate Percentage, insira um valor. Por exemplo, insira
10para uma taxa de amostragem de 10%.NotaO valor padrão é 10. Uma taxa de amostragem mais alta consome mais recursos do sistema. Mantenha o padrão, a menos que sua carga de trabalho exija uma cobertura de rastros mais ampla.
Clique em Save.
Amostragem adaptativa
Interfaces de alto tráfego frequentemente dominam os resultados da amostragem de taxa fixa, enquanto interfaces críticas, mas com pouco tráfego, ficam sub-representadas. A amostragem adaptativa resolve esse problema ao alocar um número fixo de rastros por interface, independentemente do volume de requisições.
Como funciona: O ARMS identifica as 1.000 interfaces com maior volume de requisições e amostra 10 rastros por interface por minuto usando um algoritmo LFU (Least Frequently Used). Todas as interfaces restantes compartilham um orçamento combinado de 10 rastros por minuto.
Exemplo: Suponha que seu serviço tenha uma interface /api/orders/list processando 50.000 requisições por minuto e outra interface /api/orders/refund processando apenas 100 requisições por minuto. Com a amostragem adaptativa, ambas obtêm 10 rastros amostrados por minuto. Você mantém a visibilidade do fluxo de reembolso de baixo tráfego sem ser sobrecarregado pelo fluxo de listagem de alto tráfego.
Os spans amostrados carregam o atributo sample.reason: s6.
Configure a amostragem adaptativa
Faça login no console do ARMS. No painel de navegação à esquerda, escolha .
-
Selecione uma região na barra de navegação superior e clique em na aplicação.
NotaOs ícones na coluna
Language
indicam a linguagem de programação: -
: Java -
: Go -
: Python -
-
(Hífen): uma aplicação monitorada no Managed Service for OpenTelemetry
Na barra de navegação superior, escolha .
Na seção Sampling Settings, defina Sampling strategy como Adaptive Sampling.
Clique em Save.
Políticas de non-head based sampling
O non-head based sampling é acionado independentemente em cada serviço quando o head-based sampling ainda não selecionou o rastro. Como a decisão ocorre no meio do rastro e não na raiz, rastros completos de ponta a ponta não são garantidos. No entanto, essas políticas capturam rastros que o head-based sampling poderia perder, como erros, requisições lentas e interfaces raramente invocadas.
Amostragem mínima para todas as interfaces
O ARMS amostra automaticamente pelo menos um rastro por interface por minuto. Isso garante visibilidade básica em todas as interfaces, incluindo aquelas com tráfego muito baixo que a amostragem de taxa fixa ou adaptativa poderia ignorar completamente.
Os spans amostrados carregam o atributo sample.reason: s2.
Amostragem para requisições com falha ou lentas
Esta política captura automaticamente rastros de requisições com falha ou lentas, garantindo que você sempre tenha dados de rastro para as chamadas que precisam de investigação.
Antes de usar esta política, verifique se a chave Call chain compression está ativada. Acesse a página de detalhes da aplicação, escolha na barra de navegação superior e verifique a seção Advanced Settings. A chave vem ativada por padrão.
Um rastro é amostrado quando qualquer uma das seguintes condições é atendida:
Requisição com falha: Uma interface HTTP retorna um código de status diferente de 200 ou uma interface não HTTP lança uma exceção a partir do método instrumentado.
Exceção interna não capturada: Ocorre uma exceção durante a execução interna, mas ela não é propagada para o serviço de entrada do framework.
Requisição lenta: A duração da chamada excede o limiar de chamada lenta configurado na página Custom Configurations.
Se os quantis estiverem habilitados, chamadas com duração acima do percentil 99 daquela interface também correspondem à regra de amostragem de chamada lenta.
O valor do atributo sample.reason depende da condição de acionamento:
|
Condição |
**Valor de |
|
Requisição com falha |
|
|
Chamada anormal (exceção não capturada) |
|
|
Requisição lenta |
|
Amostragem personalizada
A amostragem personalizada permite especificar interfaces por nome exato, prefixo ou sufixo e amostrar todos os seus rastros. Utilize este recurso para interfaces que exigem cobertura completa de rastros — por exemplo, interfaces de processamento de pagamentos ou serviços recém-implantados.
Os spans amostrados carregam o atributo sample.reason: s3.
Configure a amostragem personalizada
Faça login no console do ARMS. No painel de navegação à esquerda, escolha .
-
Selecione uma região na barra de navegação superior e clique em na aplicação.
NotaOs ícones na coluna
Language
indicam a linguagem de programação: -
: Java -
: Go -
: Python -
-
(Hífen): uma aplicação monitorada no Managed Service for OpenTelemetry
Na barra de navegação superior, escolha .
Na seção Sampling Settings, especifique os nomes, prefixos ou sufixos das interfaces.
Clique em Save.
Marcas de amostragem
Quando os contextos de rastro passam entre serviços usando o protocolo EagleEye, o ARMS usa marcas de amostragem para comunicar a decisão de amostragem. O cabeçalho de requisição EagleEye-Sampled carrega um destes dois valores:
|
Valor |
Significado |
|
|
Não amostrado |
|
|
Amostrado |
O ARMS também registra o motivo pelo qual um rastro foi amostrado no atributo de span sample.reason. Use esse atributo para filtrar e analisar rastros no Trace Explorer. Por exemplo, filtre por s10 para encontrar todos os rastros amostrados devido a requisições lentas.
|
**Valor de |
Política de amostragem |
|
|
Amostragem mínima para todas as interfaces |
|
|
Amostragem personalizada |
|
|
Amostragem de taxa fixa |
|
|
Reservado |
|
|
Amostragem adaptativa |
|
|
Reservado |
|
|
Amostragem da Basic Edition |
|
|
Amostragem de requisição com falha |
|
|
Amostragem de requisição lenta |
|
|
Amostragem de chamada anormal |
Fluxograma de decisão de amostragem
O diagrama a seguir ilustra como o ARMS avalia as políticas de amostragem para um rastro que abrange os serviços A, B e C.
O fluxograma utiliza três caminhos codificados por cores:
Roxo (head-based sampling): Avaliado apenas no root span do rastro. Uma única decisão de amostragem é tomada no serviço A e propagada para todos os serviços downstream.
Azul (amostragem personalizada e amostragem mínima): Avaliado em cada serviço se o head-based sampling não tiver sido acionado. Quando o serviço B amostra um rastro por meio de amostragem personalizada ou mínima, os atributos de amostragem são passados para o serviço C. Cada serviço (A, B, C) toma sua própria decisão.
Verde (amostragem de requisição com falha ou lenta): Avaliado em cada serviço se nenhuma das políticas anteriores tiver acionado a amostragem. Quando o serviço B amostra um rastro devido a uma falha ou resposta lenta, os atributos de amostragem não são passados para o serviço C. Cada serviço toma uma decisão independente.
Veja também
Analise dados de rastro no Trace Explorer: Filtre por
sample.reasone outros atributos para investigar rastros específicos.Protocolos de rastreamento suportados: Detalhes sobre o protocolo EagleEye e outros formatos de propagação suportados.