• /
  • EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

Esta tradução de máquina é fornecida para sua comodidade.

Caso haja alguma divergência entre a versão em inglês e a traduzida, a versão em inglês prevalece. Acesse esta página para mais informações.

Criar um problema

Migração para nuvem: Criar linha de base do aplicativo

A migração para a nuvem pode assumir muitas formas. Algumas empresas optam por migrar seus aplicativos diretamente do data center para a nuvem (uma migração “Lift and Shift”), enquanto outras se concentram em reestruturar completamente seus aplicativos para aproveitar os benefícios disponíveis apenas na nuvem. Não importa a sua abordagem, há três perguntas principais que você deseja responder após a migração:

  • Meu aplicativo ficou mais lento?
  • Meu aplicativo está menos estável do que antes?
  • Estou perdendo clientes devido a alguma das perguntas anteriores?

Para responder a essas perguntas, comece realizando alguns testes básicos para estabelecer uma baseline para o desempenho e a disponibilidade dos seus sistemas. Uma baseline é uma medida do desempenho e da disponibilidade atuais do seu aplicativo, que você usa como comparação após a migração para validar seu caso de negócios. Em alguns casos, você pode alterar uma baseline ao realizar testes de aceitação de migração. Você também pode usar uma baseline como ponto de comparação durante a migração para ter certeza de que está no caminho certo.

1. Identifique os componentes

Antes de iniciar uma migração para a nuvem, identifique todo o nível de toda a sua stack de aplicativos. Liste todos os componentes (aplicativo, serviços, etc.) que deseja migrar. Segmente a stack de aplicativos da seguinte maneira:

  • Aplicativo (back-end/microsserviços/cron jobs)
  • Serviços de dependência, como fila de mensagens
  • Banco de dados
  • Local na rede Internet
  • Servidor e infraestrutura subjacentes

Dica

Certifique-se de ter acesso ao aplicativo e à instância antes de começar a criar a linha de base do aplicativo. Envolva os proprietários do aplicativo, o engenheiro DevOps e o gerente de produto para obter acesso.

2. Determine a compatibilidade

Depois de identificar o aplicativo que deseja migrar, é hora de verificar qual aplicativo monitor com a plataforma New Relic. Trabalhe com as partes interessadas da sua organização para determinar a quantidade de instrumentação que é possível – ou permitida – dentro da sua organização. Este é um passo importante e que valerá a pena, pois quanto mais você puder instrumentalizar, melhor será sua linha de base.

Aqui estão os produtos New Relic para usar como linha de base, dependendo dos componentes que você identificou:

  • APM: monitor seus aplicativos da web com APM. Consulte Compatibilidade e requisitos para agente e produtos New Relic para obter detalhes precisos de compatibilidade para cada idioma compatível.
  • Infrastructure: monitor seus hosts com infraestrutura. Consulte Compatibilidade e requisitos de infraestrutura para sistemas operacionais e ambientes suportados. Você também pode instrumentar outros produtos e serviços com integração no host.
  • Synthetic monitoring: monitor interfaces da Web e API com monitoramento sintético. Às vezes, talvez você não consiga instrumentar seu ambiente local com ou infraestrutura. Por exemplo, talvez a política da sua organização proíba a instalação de um agente atrás de um firewall. Nestes casos, se o aplicativo possuir frontend web, utilize monitoramento sintético, pois oferece monitoramento não-agente e ainda fornece a capacidade de estabelecer uma baseline.

3. monitoramento implantar

Com base nas correspondências componente-produto que você fez, implante um agente ou monitor em sua arquitetura:

4. Reúna métricas

Após implantar o agente e monitor, identifique quais métricas são mais importantes para o seu negócio e utilize essas métricas para definir seus KPIs. Algumas recomendações incluem:

  • Response time: Tempo necessário para responder a uma solicitação.
  • Throughput: Número de solicitações recebidas pelo aplicativo.
  • Requesting queuing (Apache, IIS, NGINX): Duração do tempo que uma solicitação leva para chegar ao seu aplicativo.
  • Database call duration: Duração do tempo necessário para concluir uma chamada de banco de dados.
  • DB call counts: Quantidade de chamadas realizadas pelo código do aplicativo ao banco de dados.
  • Error rate: Porcentagem de erros relatados.
  • Apdex score: Um padrão do setor para medir a satisfação do usuário com o tempo de resposta de aplicativos e serviços web.
  • DNS setup timing: O tempo que leva para conectar e receber dados do DNS.
  • SSL setup timing: O tempo necessário para estabelecer uma conexão SSL.

Você pode encontrar algumas dessas métricas em mapas de serviço, bem como no APM e nas páginas do Browser summary .

Para obter informações mais detalhadas sobre navegação, interpretação e uso do APM, confira estes tutoriais da New Relic University:

5. Configure o painel

Depois de definir seus KPIs, é fácil visualizá-los no dashboard. O painel oferece um único local para visualizar todos os dados coletados pelos produtos New Relic. os dados do painel consistem em events, e cada evento possui um tipo de evento, um timestamp e valor principal atributo.

Para obter mais informações sobre evento, consulte Coleta de dados e Evento padrão para produtos New Relic.

Você pode localizar seus KPIs e dados métricos de negócios no New Relic usando métrica e evento e a linguagem de consulta NRQL. Você também pode criar um painel para monitorar o desempenho desses KPIs:

Após a migração, compare essas linhas de base com a linha de base dos testes de aceitação da migração .

Dicas de especialistas

Se você achar que precisa de dados que não são capturados pela instrumentação padrão, facilitamos a captura de dados personalizados:

Você também pode aprender mais sobre a instrumentação personalizada do APM com a série de tutoriais de dados personalizados da New Relic University.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.