La migration vers le cloud peut prendre de nombreuses formes. Certaines entreprises choisissent de porter leurs applications directement de leur data center vers le cloud (une migration « Lift and Shift ») tandis que d’autres se concentrent sur la réarchitecture complète de leurs applications pour profiter des avantages disponibles uniquement dans le cloud. Quelle que soit votre approche, il y a trois questions principales auxquelles vous devez répondre après votre migration :
- Mon application est-elle devenue plus lente ?
- Mon application est-elle moins stable qu’avant ?
- Est-ce que je perds des clients à cause de l’une des questions précédentes ?
Pour répondre à ces questions, commencez par effectuer quelques tests de base pour établir une base de référence pour les performances et la disponibilité de votre système. Une base de référence est une mesure des performances et de la disponibilité actuelles de votre application, que vous utilisez ensuite comme comparaison après votre migration pour valider votre analyse de rentabilisation. Dans certains cas, vous pouvez modifier une base de référence lorsque vous effectuez des tests d'acceptation de migration. Vous pouvez également utiliser une base de référence comme point de comparaison lors de votre migration pour vous assurer que vous êtes sur la bonne voie.
1. Identifier les composants
Avant de commencer une migration vers le cloud, identifiez tous les niveaux de l'ensemble de votre stack applicative. Répertoriez tous les composants (applications, services, etc.) que vous souhaitez migrer. Segmentez la stack d’applications comme suit :
- Application (backend/microservices/tâches cron)
- les services de dépendance, comme le fichier d'attente des messages
- base de données
- Site web
- Serveur et infrastructure sous-jacents
Conseil
Assurez-vous d'avoir accès aux applications et aux instances avant de commencer à créer une base de référence d'application. Engagez les propriétaires de vos applications, votre ingénieur DevOps et vos produits responsables pour l'accès.
2. Déterminer la compatibilité
Une fois que vous avez identifié les applications que vous souhaitez migrer, il est temps de vérifier quel niveau d'application doit être monitoré avec la plateforme New Relic. Travaillez avec les parties prenantes de votre organisation pour déterminer la quantité d’instrumentation possible – ou autorisée – au sein de votre organisation. Il s’agit d’une étape importante et qui s’avérera payante, car plus vous pourrez instrument, meilleure sera votre base de référence.
Voici les produits New Relic à utiliser pour la référence, en fonction des composants que vous avez identifiés :
- APM: monitorez vos applications Web avec APM. Consultez Compatibilité et exigences pour les agents et produits New Relic pour connaître les détails de compatibilité précis pour chaque langue prise en charge.
- Infrastructure: monitorez vos hôtes avec infrastructure. Voir Compatibilité et exigences relatives à infrastructure pour les systèmes d'exploitation et environnements pris en charge. Vous pouvez également instrumenter d'autres produits et services avec l'intégration sur hôte.
- Synthetic monitoring: Monitorez les interfaces Web et les API avec monitoring Synthétique. Parfois, vous ne pourrez peut-être pas instrumenter votre environnement sur site avec ou infrastructure. Par exemple, il se peut que la politique de votre organisation interdise l’installation d’un agent derrière un pare-feu. Dans ces cas, si l'application dispose d'une interface Web, utilisez monitoring Synthétique, car elle offre monitoring sans agent tout en offrant la possibilité d'établir une base de référence.
3. Monitoring de deploiement
En fonction des correspondances composant-produit que vous avez effectuées, déployez des agents ou des moniteurs sur votre architecture :
4. Rassembler les métriques
Après avoir déployé les agents et le moniteur, identifiez les mesures les plus importantes pour votre entreprise et utilisez ces mesures pour définir vos KPI. Voici quelques recommandations :
- Response time: Temps nécessaire pour répondre à une demande.
- Throughput: Nombre de requests reçues via l'application.
- Requesting queuing (Apache, IIS, NGINX): Durée nécessaire pour qu'une demande parvienne à votre application.
- Database call duration: Durée nécessaire pour terminer un appel de base de données.
- DB call counts: Nombre d'appels effectués par le code d'application vers la base de données.
- Error rate: Pourcentage d'erreurs signalées.
- Apdex score: Une norme industrielle pour mesurer la satisfaction des utilisateurs quant au temps de réponse des applications et services Web.
- DNS setup timing: Le temps nécessaire pour se connecter et recevoir des données du DNS.
- SSL setup timing: Le temps nécessaire pour établir une connexion SSL.
Vous pouvez trouver certaines de ces métriques dans les cartes de services, ainsi que sur les pages APM et summary du navigateur .
Pour des informations plus détaillées sur la navigation, l'interprétation et l'utilisation d'APM, consultez ces tutoriels de New Relic University :
5. Configurer le dashboard
Après avoir défini vos KPI, il est facile de les visualiser dans le dashboard. Dashboards offrent un emplacement unique pour afficher toutes les données collectées par les produits New Relic. Les données Dashboards sont constituées d'événement, et chaque événement a un type d'événement, un horodatage et un attribut valeur clé .
Pour plus d'informations sur l'événement, voir Collecte de données et événement par défaut pour les produits New Relic.
Vous pouvez localiser vos KPI et données de métriques métier dans New Relic à l'aide de métriques et événement et du langage de requête NRQL . Vous pouvez également créer un dashboard pour suivre les performances de ces KPI :
Après votre migration, comparez ces bases de référence à votre base de référence de tests d'acceptation de migration .
Conseils d'experts
Si vous constatez que vous avez besoin de données qui ne sont pas capturées par l'instrumentation par défaut, nous vous facilitons la capture de données personnalisées :
- Instrumentation APM personnalisée
- Données personnalisées Browser
- infrastructure attribut personnalisé
- événement personnalisé data
- Données mobiles personnalisées
- Synthétique attribut personnalisé
Vous pouvez également en apprendre davantage sur l'instrumentation personnalisée APM avec la série de didacticiels sur les données personnalisées de New Relic University.