La migración a la nube puede tomar muchas formas. Algunas empresas optan por trasladar su aplicación directamente desde su centro de datos a la nube (una migración de “Lift and Shift”), mientras que otras se centran en rediseñar completamente su aplicación para aprovechar los beneficios disponibles sólo en la nube. Independientemente de su enfoque, hay tres preguntas principales que desea responder después de su migración:
- ¿Mi aplicación se ha vuelto más lenta?
- ¿Mi aplicación es menos estable que antes?
- ¿Estoy perdiendo clientes por alguna de las preguntas anteriores?
Para responder a estas preguntas, comience realizando algunas pruebas básicas para establecer una línea de base para el rendimiento y la disponibilidad de sus sistemas. Una línea de base es una medición del rendimiento y la disponibilidad actuales de su aplicación, que luego utiliza como comparación después de la migración para validar su caso de negocio. En algunos casos, puede cambiar una línea de base cuando realiza pruebas de aceptación de migración. También puede utilizar una línea de base como punto de comparación durante su migración para asegurarse de que va por buen camino.
1. Identificar componentes
Antes de comenzar una migración a la nube, identifique todo el nivel de toda su stack de aplicaciones. Enumere todos los componentes (aplicación, servicios, etc.) que desea migrar. Segmente la stack de aplicaciones de la siguiente manera:
- Aplicación (backend/microservicios/trabajos cron)
- Servicios de dependencia, como la cola de mensajes.
- Base de datos
- Sitio web
- Servidor e infraestructura subyacentes
Sugerencia
Asegúrese de tener acceso a la aplicación y la instancia antes de comenzar a crear la aplicación línea de base. Involucre a los propietarios de su aplicación, al ingeniero de DevOps y al gerente de productos para obtener acceso.
2. Determinar la compatibilidad
Una vez que identifiques la aplicación que deseas migrar, es momento de verificar qué nivel de aplicación monitor con la plataforma New Relic. Trabaje con las partes interesadas de su organización para determinar la cantidad de instrumentación que es posible (o permitida) dentro de su organización. Este es un paso importante y que dará sus frutos, ya que cuanto más pueda instrumentar, mejor será su línea de base.
Estos son los productos New Relic que se pueden utilizar para la línea de base, según los componentes que haya identificado:
: monitor tus aplicaciones web con APM. Consulte Compatibilidad y requisitos para el agente y los productos New Relic para conocer detalles precisos de compatibilidad para cada idioma admitido.
: monitor tus hosts con infraestructura. Consulte Compatibilidad y requisitos de infraestructura para sistemas operativos y entornos compatibles. También puedes instrumentar otros productos y servicios con integración en el host.
: monitor interfaces web y API con monitoreo sintético. A veces, es posible que no pueda instrumentar su entorno local con
o infraestructura. Por ejemplo, tal vez la política de su organización prohíba instalar un agente detrás de un firewall. En estos casos, si la aplicación tiene una interfaz web, utilice el monitoreo sintético, ya que ofrece monitoreo sin agente y al mismo tiempo brinda la capacidad de establecer una línea de base.
3. implementar el monitoreo
Según las coincidencias entre componente y producto que haya realizado, despliegue agente o monitoree en su arquitectura:
4. Reunir métrica
Después de desplegar el agente y monitorear, identifique qué métricas son las más importantes para su negocio y utilícelas para definir sus KPI. Algunas recomendaciones incluyen:
Response time:
Tiempo necesario para responder a una solicitud.
Throughput:
Número de solicitudes que llegaron a través de la aplicación.
Requesting queuing (Apache, IIS, NGINX):
Duración del tiempo que tarda una solicitud en llegar a su aplicación.
Database call duration:
Duración del tiempo necesario para completar una llamada a la base de datos.
DB call counts:
Número de llamadas realizadas por código de aplicación a la base de datos.
Error rate:
Porcentaje de errores reportados.
Apdex score:
Un estándar de la industria para medir la satisfacción del usuario con el tiempo de respuesta de las aplicaciones y servicios web.
DNS setup timing:
El tiempo que lleva conectarse y recibir datos de DNS.
SSL setup timing:
El tiempo que lleva establecer una conexión SSL.
Puede encontrar algunas de estas métricas en mapas de servicios, así como en APM y páginas del navegador summary .
Para obtener información más detallada sobre cómo navegar, interpretar y usar APM, consulte estos tutoriales de New Relic University:
5. Configurar el panel
Después de definir sus KPI, es fácil visualizarlos en el panel. El panel de control ofrece una ubicación única para ver todos los datos que recopilan los productos New Relic. Los datos del tablero constan de eventos, y cada evento tiene un tipo de evento, una timestamp y un atributo de valor principal.
Para obtener más información sobre el evento, consulte Recopilación de datos y Evento predeterminado para productos New Relic.
Puede ubicar sus KPI y datos métricos comerciales en New Relic usando métrica y evento y el lenguaje de consulta NRQL. También puede crear un panel para realizar un seguimiento del rendimiento de esos KPI:
Después de su migración, compare estas línea de base con su prueba de aceptación de migración línea de base.
Consejos de expertos
Si descubre que necesita datos que no se capturan mediante la instrumentación predeterminada, le facilitamos la captura de datos personalizados:
- Instrumentación APM personalizada
- Datos personalizados browser
- Atributo de infraestructura personalizado
- Datos del evento personalizado
- Datos personalizados móviles
- Aparato sintético personalizado
También puede obtener más información sobre la instrumentación personalizada de APM con la serie de tutoriales de datos personalizados de New Relic University.