Solucionar problemas com a página de resumo do APM

Identifique pontos problemáticos com blocos de resumo

Antes de mergulhar nos detalhes, é importante primeiro observar os blocos de resumo na parte superior da página. Esses blocos alertam você imediatamente sobre quaisquer problemas, vulnerabilidades ou falhas de implantação em seu sistema. Se os blocos na parte superior da sua página mostrarem um estado vazio, clique em Set up now para ativar cada bloco.

Problemas

Uma forma importante de rastrear comportamentos incomuns em seu sistema é por meio de alertas. Digamos que você queira saber quando a taxa de erros da transação para Checkout-service excede 10%. Você criaria uma condição do alerta e definiria as regras que desencadeariam um incidente. Um ou mais incidentes criam um problema. Este bloco exibirá quaisquer problemas em seu serviço.

Neste exemplo, você já configurou sua condição do alerta para que, ao verificar seus blocos de resumo, você veja imediatamente que seu sistema tem dois problemas críticos. Clique no bloco para visualizar detalhes sobre cada problema crítico, o incidente que eles contêm e a entidade relacionada.

Última implantação

Marcador de implantação ajuda você monitor os resultados de cada atualização que você faz em seu serviço. Este bloco mostra a alteração na taxa de erros e no tempo de resposta acionados pela sua última implantação.

A partir de 15 minutos após uma implantação, este bloco exibirá uma comparação entre os dados coletados antes e depois da implantação. Se você ativou um novo recurso há 45 minutos, este bloco mostrará uma comparação entre os 45 minutos anteriores e os 45 minutos depois. Durante as primeiras três horas após uma implantação, este bloco exibirá apenas uma comparação do tempo decorrido desde a ativação correspondente ao tempo correspondente antes da ativação. Após três horas, o bloco usa a comparação padrão de 3 horas.

Para um intervalo de tempo personalizado, clique no bloco para ir para a página principal de implantação e use o seletor de hora lá

Neste exemplo, sua última implantação gerou um aumento de 27% na taxa de erros e um aumento de 5% no tempo de resposta. Clique no bloco para visualizar sua última implantação e quaisquer erros, logs, alertas e tendências relacionados.

Nível de serviço

Nível de serviço são usados para medir o desempenho de um serviço do ponto de vista do usuário final. Quando o orçamento de erro de um nível de serviço for excedido, você verá estes tipos de incidente:

• Non-compliant significa que você consumiu todo o orçamento de erros desse período. Portanto, tenha cuidado se precisar implantar e planeje algum trabalho para melhorar seus SLs.

• At risk significa que seu orçamento de erros está quase consumido e você deve ser mais cauteloso durante o resto do período.

  Para este exemplo, você já configurou seu nível de serviço e excedeu seu orçamento de erros em duas instâncias. Clique no bloco para ver quais entidades não estão em conformidade e se aprofunde no seu erro de orçamento.

  

  Vulnerabilidades

  O Gerenciamento de vulnerabilidades fornece uma visão panorâmica de todas as vulnerabilidades do seu software. Cada um de seus agentes ou serviços integrados, como Java, .Net ou Github Dependabot , enviará automaticamente vulnerabilidades conhecidas para o New Relic rastrear.

  Aqui você pode ver que ativou o Gerenciamento de vulnerabilidades e tem 3 Critical e 9 High vulnerabilidades detectadas para seu serviço de monitor. Clique no bloco para visualizar o impacto de suas vulnerabilidades.

  

Revise sua métrica principal

Há algum problema com seu Checkout-service? Quais sistemas são afetados e como?

Apdex

O primeiro lugar a observar ao investigar uma falha no serviço é a pontuação Apdex. Sua pontuação Apdex monitora a satisfação geral dos clientes com sua aplicação. Sua pontuação busca uma combinação de desempenho, como tempo de resposta ou taxas de transferência, e taxas de erros.

Apdex é um padrão da indústria que mede a satisfação do seu usuário com o tempo de resposta da sua aplicação/serviço web. É representado como uma pontuação de 0-1. Quanto mais próxima sua pontuação estiver de 1, melhor será o desempenho do seu aplicativo. O valor padrão para uma experiência satisfatória é 0,5 segundos, mas você pode definir um destino diferente em Configurações.

Sua pontuação Apdex normalmente é dividida nas seguintes cores:

• ** < 0.5 - Gray:** O desempenho do seu aplicativo está além do crítico e precisa de ação imediata.

• 0.5-0.7 - Red: Existem problemas críticos de desempenho em seu aplicativo e ele precisa de ação imediata.

• 0.7-0.85 -Orange: Seu aplicativo está tendendo a uma direção negativa e precisa de mais investigação.

• 0.85-0.95 - Blue: Esta é a gama Apdex ideal. Essa pontuação significa que você ajustou seu Apdex T perfeitamente para seu aplicativo e seu desempenho está saudável.

• > 0.95 - Blue: Se sua pontuação Apdex estiver nessa faixa, significa que seu Apdex T pode estar definido um pouco alto e você não está obtendo uma leitura precisa do desempenho de seu aplicativo. Você deve considerar reduzir seu Apdex T.

  Dica

  Se você tiver uma pontuação Apdex 0, pode ser porque uma solicitação retornou com um erro. Cada solicitação com erro marca automaticamente 0 no Apdex.

  Neste exemplo, após abrir sua entidade Checkout-service no APM, você verá que sua pontuação Apdex caiu e está pairando em 0,6. O gráfico é vermelho.

  Agora você sabe com certeza que as reclamações de seus clientes estão corretas: há um problema em algum lugar da sua stack.

  Para saber mais sobre como entender sua pontuação, consulte Apdex: medir a satisfação do usuário.

  Transação da web

  

  Com base nos relatórios dos clientes, você sabe que o botão Pay now está falhando no seu aplicativo, mas não tem certeza do que está causando o erro real. Você verificou o Apdex e ele mostra pouca satisfação do usuário.

  A próxima etapa é descobrir qual parte do processo de checkout está falhando investigando Web-transactions do seu aplicativo.

  Na New Relic, uma transação é definida como uma unidade lógica de trabalho em um aplicativo de software. Especificamente, refere-se às chamadas de função e métodos que compõem essa unidade de trabalho. Para APM, geralmente se refere a uma transação da web, que representa a atividade que acontece desde o momento em que o aplicativo recebe uma solicitação da web até o momento em que a resposta é enviada.

  O tempo de transação na Web é dividido em três partes:

• Segmento azul: todas as transações

• Segmento amarelo: operações de banco de dados

• Segmento verde: serviços externos

  Dica

  Se você estiver tentando monitor um aplicativo assíncrono, seu tempo de resposta - a linha azul escura - poderá ser menor que os tempos de resposta de cada segmento individual (transação, banco de dados e externos). Isso pode acontecer porque um aplicativo assíncrono pode processar diversas solicitações ao mesmo tempo. Assim, é possível que uma transação “termine” enquanto algumas solicitações ainda estão “abertas”.

  Uma transação lenta pode ser um forte indicador de que algo está se comportando de forma anormal, então dê uma olhada no gráfico e veja se alguma área do seu serviço está demorando mais do que o normal para responder. A transação lenta parecerá picos no gráfico.

  Você também pode usar nossa ferramenta de marcador de implantação para verificar se sua equipe lançou uma alteração no momento em que os clientes começaram a reclamar que o botão Pay Now estava demorando muito para carregar.

  Um marcador de implantação aparece como um alfinete cinza em cada gráfico. Você pode passar o mouse sobre o alfinete para obter informações gerais ou clicar no marcador para obter uma visão mais detalhada da implantação.

  Taxas de transferência

  

  Ao consultar o tempo de resposta para Checkout-service , você também pode investigar taxas de transferência. Throughput é uma forma de medir a quantidade de trabalho que seu aplicativo está realizando. taxas de transferência ajuda você a entender se o trabalho está distribuído uniformemente entre seus hosts e contêiner. Problemas de desempenho muitas vezes podem ser um sintoma de falta de recursos.

  Para efeitos deste exemplo, verifica-se que as taxas de transferência são um pouco mais elevadas do que o normal. Se as suas taxas de transferência forem muito altas durante um período de degradação do serviço, isso pode indicar que o seu aplicativo está processando mais trabalho do que pode suportar.

  Por outro lado, taxas de transferência baixas podem indicar que seu aplicativo não está lidando com muitas solicitações. Isso pode simplesmente significar que ele não é muito usado ou que um serviço que chama seu aplicativo está quebrado e as solicitações não estão sendo processadas.

  Erros

  

  Agora que você identificou a lentidão na transação e analisou suas taxas de transferência, é hora de dar uma olhada nos erros. O gráfico Errors mostra a porcentagem de transação que resultou em erro.

  No contexto do APM, os erros representam o evento TransactionError e ErrorTrace .

  Nesse caso, você verá um aumento em Web errors na mesma época em que o tempo de resposta de sua transação da web aumentou. Você também verá um marcador de implantação alertando sobre uma alteração que sua equipe fez em seu sistema.

  Agora você vê um padrão em torno desta implantação recente: diminuição na satisfação do usuário, aumento no tempo de resposta, taxas de transferência e erros.

  Use o dropdown para alternar para uma visualização do usuário afetado. Para saber como rastrear o usuário afetado, consulte Errors Inbox.

  Para obter mais informações sobre como gerenciar erros, consulte Gerenciar erros

Localize o problema em um contexto mais amplo

Quais partes da sua stack estão com problemas? O problema foi causado por alterações na entidade que liga para o seu serviço ou é chamada pelo seu serviço?

Registro

O gráfico de log fornece uma visão resumida do log do seu aplicativo relatado por meio do nosso recurso de logs contextualizados . Clicar em Logs leva você para a interface de registro completa .

Neste exemplo, depois de investigar sua métrica principal, você sabe que tem um problema com uma implantação recente que afetou o tempo Web-transaction , o que resultou em um aumento nos erros e na baixa satisfação do usuário. Agora você quer saber como isso afetou o restante do seu serviço.

Com o logs contextualizados, seu log individual é marcado com a entidade ou serviço ao qual está relacionado. No gráfico de log você pode selecionar Log patterns (top 10) para exibir grupos de log que são idênticos até o identificador de string exclusivo.

Para mais informações sobre como funcionam os padrões de log, consulte Padrões de log.

Distributed tracing

O gráfico Distributed tracing insights mostra entidades upstream e downstream que podem causar aumentos no tempo de resposta, na taxa de erros ou nas taxas de transferência do seu serviço.

Por exemplo, digamos que você queira investigar um aumento no tempo de resposta de um serviço, mas o pico está relacionado a uma chamada externa. Se distributed tracing registrou uma entidade downstream que causou latência ao seu serviço, você poderá visualizar essa alteração no desempenho nesta lista. Clique no botão View trace para ver um distributed trace que mostra alterações de desempenho.

Você pode saber mais em nossos documentos de insightsdistributed tracing .

A infraestrutura

Agora, role para baixo até a seção Infrastructure da página de resumo do APM. Aqui você verá uma tabela que lista cada host conectado ao aplicativo Checkout Service e um registro de seu tempo de resposta, taxas de transferência, taxas de erros, porcentagem de CPU. e porcentagem de memória.

Para este exemplo, sugerimos verificar se houve alguma alteração na porcentagem de CPU em torno da mesma implantação recente que causou aumento no tempo de resposta e altas taxas de erros.

Saiba mais sobre como investigar dados de infraestrutura na página de resumo do APM aqui.

Leve sua investigação para o próximo nível