Se sua aplicação enfrentar problemas como tráfego desigual, falhas de instância, endpoints lentos, necessidade de análise de tráfego de negócios ou monitoramento de canary release, use o Trace Explorer no monitoramento de aplicações para identificar rapidamente o código problemático. Este tópico apresenta cinco problemas clássicos de produção para demonstrar como usar o Trace Explorer e o valor que ele oferece.
Informações básicas
Além de usar um trace para investigar anomalias em uma única requisição ou utilizar métricas pré-agregadas para monitoramento e alertas de serviços, o rastreamento distribuído também suporta análise pós-agregação em dados detalhados de traces. Esse recurso é conhecido como Trace Explorer. Em comparação com a análise de traces individuais, o Trace Explorer identifica problemas com mais rapidez. Já em relação aos gráficos de monitoramento pré-agregados, ele oferece maior flexibilidade para diagnósticos personalizados.
O Trace Explorer executa análises em tempo real sobre todos os dados detalhados de traces armazenados. Combine livremente condições de filtro e dimensões de agregação para diagnósticos personalizados em diversos cenários. Por exemplo, visualize a distribuição em série temporal de chamadas que ultrapassam 3 segundos, verifique como as requisições com erro se distribuem entre diferentes máquinas ou monitore alterações de tráfego de clientes VIP.
Problema 1: Distribuição desigual de tráfego
O que fazer quando uma configuração incorreta de balanceamento de carga direciona um alto volume de requisições para poucas máquinas, criando "hotspots" que afetam a disponibilidade do serviço?
Os "hotspots" causados pela distribuição desigual de tráfego podem levar facilmente à indisponibilidade do serviço. Muitos desses casos ocorrem em ambientes de produção devido a fatores como configurações incorretas de balanceamento de carga, anomalias no registro de serviços que impedem nós reiniciados de ficarem online ou fatores de hash DHT anormais.
O maior risco do tráfego desigual é não detectar um "hotspot" a tempo. Os sintomas geralmente se manifestam como respostas lentas ou erros, e o monitoramento tradicional pode não mostrar diretamente o desequilíbrio de tráfego. Como resultado, a equipe de operações pode não considerar essa a causa principal, desperdiçando tempo valioso de resposta a incidentes e permitindo que o problema se agrave.
Com o Trace Explorer, agrupe os dados de traces por endereço IP para visualizar como as requisições estão distribuídas entre suas máquinas, especialmente a mudança na distribuição de tráfego antes e depois de um incidente. Se um grande número de requisições se concentrar repentinamente em uma ou poucas máquinas, provavelmente trata-se de um hotspot causado por tráfego desigual. Correlacione esse dado com eventos de mudança no momento do incidente para identificar rapidamente a alteração defeituosa e executar um rollback.
Na página Trace Explorer, ao agregar por endereço IP, você pode descobrir que a maior parte do tráfego está concentrada na máquina opentelemetry-demo-frontend-XX. Na página Trace Explorer, defina a dimensão de agregação como IP address e ordene por request count para visualizar a contagem de requisições, a contagem de erros e a duração média de cada host. Por exemplo, o host opentelemetry-demo-frontend apresenta uma contagem de requisições de até 17.000, excedendo em muito os outros hosts, o que indica uma clara concentração de tráfego.
Problema 2: Falha de instância
Como investigar quando uma falha de instância, como placa de rede danificada, overcommitment de CPU ou disco cheio, faz com que algumas requisições falhem ou atinjam o tempo limite?
Falhas de instância ocorrem frequentemente, especialmente em clusters de grande porte onde, estatisticamente, são quase inevitáveis. Uma falha de instância pode não causar uma interrupção em larga escala, mas pode levar à falha ou timeout de um pequeno número de requisições de usuários. Isso degrada continuamente a experiência do usuário e aumenta os custos de suporte; portanto, resolva o problema prontamente.
As falhas de instância dividem-se em falhas de host e falhas de contêiner (ou falhas de Nó e Pod em um ambiente Kubernetes). Por exemplo, overcommitment de CPU e falhas de hardware são problemas no nível do host que afetam todos os contêineres nele. Por outro lado, problemas como disco cheio ou erro de falta de memória geralmente afetam apenas um único contêiner. Portanto, ao solucionar falhas de instância, analise os dados tanto da dimensão de IP do host quanto do IP do contêiner.
Para resolver esse problema, use o Trace Explorer para filtrar primeiro requisições anômalas ou com tempo limite esgotado. Em seguida, agregue os resultados por IP do host ou endereço IP do contêiner para determinar rapidamente se uma falha de instância é a causa. Se as requisições anômalas estiverem concentradas em uma única máquina, tente substituir a máquina para uma recuperação rápida ou inspecione suas métricas de sistema, como verificar se o disco está cheio ou se o tempo de roubo de CPU (steal time) está muito alto. Se os erros estiverem espalhados por várias máquinas, provavelmente você pode descartar uma falha de instância e deve focar na análise de dependências downstream ou na lógica da aplicação em busca de problemas.
Na página Trace Explorer, filtre chamadas com erro ou lentas e agrupe os resultados por endereço IP. Se as chamadas anômalas estiverem concentradas em uma máquina específica, uma falha de instância é altamente provável. Na página Trace Explorer, defina a condição de filtro como statusCode IN (2, 3), selecione IP address como dimensão de agregação e marque o status Error na seção de filtro rápido à esquerda. Os resultados da consulta mostram um total de 2.857 chamadas com erro, com dois hosts (.42 e .47) gerando 1.430 e 1.425 chamadas respectivamente, ambos com taxa de erro de 100%. Os erros concentram-se entre 19:21 e 19:26, característica típica de falha de instância.
Problema 3: Gerencie endpoints lentos
Como identificar rapidamente endpoints lentos e resolver gargalos de desempenho antes do lançamento de uma nova aplicação ou de uma grande promoção de vendas?
O ajuste sistemático de desempenho é frequentemente necessário ao lançar uma nova aplicação ou preparar-se para uma grande promoção. O primeiro passo é analisar o sistema atual em busca de gargalos de desempenho, identificando uma lista de endpoints lentos e a frequência com que ocorrem.
Use o Trace Explorer para filtrar chamadas com duração superior a um determinado limiar e, em seguida, agrupe-as pelo nome do endpoint. Isso permite identificar rapidamente a lista de endpoints lentos e seus padrões. Depois, resolva os endpoints lentos mais frequentes um por um.
Após encontrar os endpoints lentos, utilize os traces correspondentes, pilhas de métodos e dados de pool de threads para localizar a causa raiz das chamadas lentas. As causas comuns incluem:
Pool de conexões do banco de dados ou microsserviço muito pequeno, fazendo com que muitas requisições aguardem uma conexão. Resolva isso aumentando a contagem máxima de threads do pool de conexões.
Problema de consulta N+1. Por exemplo, uma única requisição externa dispara centenas de chamadas internas ao banco de dados. Mescle essas requisições fragmentadas para reduzir o tempo de transferência de rede.
Tamanho dos dados de uma única requisição excessivamente grande, resultando em longos tempos de transferência de rede e desserialização, podendo causar facilmente um Full GC. Alterne de uma consulta completa para uma consulta paginada para evitar solicitar muitos dados de uma só vez.
Um "hot lock" no framework de logging. Alterne a saída de log de síncrona para assíncrona.
Na página Trace Explorer, filtre chamadas lentas que demoram mais de 5 segundos e agrupe-as pelo nome do endpoint para identificar padrões entre os endpoints lentos.
Problema 4: Análise de tráfego de negócios
Como analisar mudanças de tráfego e qualidade de serviço para clientes ou canais principais?
Em um ambiente de produção, os serviços costumam ser padronizados, mas os segmentos de negócios são estratificados e classificados. Para o mesmo serviço de pedidos, categorize e agregue estatísticas por dimensões como categoria, canal e usuário para operações refinadas. Por exemplo, no canal de varejo offline, a estabilidade de cada pedido e de cada terminal POS pode se tornar uma questão de relações públicas. Os requisitos de SLA para canais offline são muito superiores aos dos canais online. Então, como monitorar com precisão o status de tráfego e a qualidade de serviço do trace de varejo offline dentro de um sistema genérico de serviços de e-commerce?
Use a filtragem e as estatísticas do Trace Explorer sobre atributos personalizados para realizar análises de traces orientadas a negócios e de baixo custo. Por exemplo, adicione uma tag como {"attributes.channel": "offline"} aos traces de pedidos offline no serviço de ponto de entrada e, em seguida, adicione tags separadas para diferentes lojas, grupos de clientes e categorias de produtos. Por fim, filtre por attributes.channel = offline e use group by em diferentes tags de negócios para agregar métricas como contagem de requisições, duração ou taxa de erro. Assim, você analisa rapidamente as tendências de tráfego e a qualidade de serviço para cada cenário de negócios.
Problema 5: Monitoramento de canary release
Você está implantando em 500 máquinas em 10 lotes. Como determinar rapidamente se há algum problema após o primeiro lote de canary release entrar em produção?
Os três pilares do gerenciamento de mudanças — "canary, monitorar, rollback" — são essenciais para a estabilidade online. Canary releases graduais são um método fundamental para reduzir riscos online e controlar o raio de impacto. Se uma anomalia for detectada em um lote canary, faça o rollback imediatamente, em vez de continuar a implantação. No entanto, muitas falhas de produção ocorrem devido à falta de monitoramento eficaz do canary.
Por exemplo, se o registro de serviços de um microsserviço estiver indisponível, as máquinas reiniciadas não conseguem se registrar ou ficar online. Sem o monitoramento do canary, os primeiros lotes de máquinas reiniciadas podem falhar no registro. Todo o tráfego é então roteado para as máquinas ativas restantes. O tráfego geral da aplicação e a duração podem não mudar significativamente até que o último lote de máquinas também falhe no registro, momento em que toda a aplicação fica indisponível, levando a um grande incidente de produção.
No cenário acima, se você marcar o tráfego de diferentes versões de máquinas com {"attributes.version": "v1.0.x"}, poderá usar o Trace Explorer para agrupar estatísticas por attributes.version. Isso permite distinguir claramente as mudanças de tráfego e a qualidade de serviço entre diferentes versões ou antes e depois de um release, evitando que uma anomalia no lote canary seja mascarada pelas métricas globais de monitoramento.
Limitações do Trace Explorer
Embora o Trace Explorer seja flexível e possa atender a várias necessidades de diagnóstico personalizado, ele possui algumas limitações:
-
A análise de dados detalhados de traces tem custo elevado.
O Trace Explorer exige que você reporte e armazene dados detalhados de traces da forma mais completa possível. Se a taxa de amostragem for baixa e os dados detalhados estiverem incompletos, a eficácia do Trace Explorer será bastante reduzida. Para diminuir o custo do armazenamento completo, implante nós de dados de borda dentro de seus clusters para cache temporário e processamento de dados, reduzindo a sobrecarga de relatórios entre redes. Alternativamente, implemente a separação de dados quentes e frios no lado do servidor: execute análises completas de traces no armazenamento quente e diagnostique apenas traces lentos ou com erro no armazenamento frio.
-
A pós-agregação não é adequada para alertas devido à alta sobrecarga de consulta e baixa concorrência.
O Trace Explorer executa varreduras e estatísticas em tempo real em conjuntos de dados completos. A sobrecarga de desempenho da consulta é muito maior do que com métricas pré-agregadas, tornando-o inadequado para consultas de alerta de alta concorrência. Em vez disso, use o recurso de métricas personalizadas para enviar instruções de pós-agregação ao cliente para coleta de métricas personalizadas, que podem então ser usadas para alertas e painéis personalizados.
-
A marcação de atributos personalizados é necessária para maximizar o valor do Trace Explorer.
Diferentemente das métricas padrão pré-agregadas no monitoramento de aplicações, muitos cenários no Trace Explorer exigem que você instrumente manualmente seu código com tags personalizadas. Esta é a maneira mais eficaz de diferenciar vários cenários de negócios e permitir análises precisas.
Documentos relacionados
Para diagnosticar problemas proativamente, use o recurso de alertas do Application Real-Time Monitoring Service (ARMS) para criar um alerta para um endpoint específico ou para todos os endpoints. Quando ocorre um problema, o serviço envia uma notificação para sua equipe de operações. Para saber como criar um alerta, consulte Regras de alerta do Monitoramento de Aplicações.