Préparer le grand événement de votre entreprise est un défi. Cela vous pousse, vous et votre équipe, à repenser l'architecture de votre système d'un point de vue commercial, puis vous demande de prendre une série de décisions lorsque plusieurs incidents critiques surviennent. Comment faire d'un jour de match un succès lorsque vous ne pouvez pas tout prioriser en même temps ? Comment trouvez-vous ce qui compte ?
Notre plus grande recommandation pour toute équipe participant à un événement est de mettre en place un niveau de service. Avec le niveau de service, vous pouvez prendre des composants système discrets et extraire des données commerciales précieuses sur votre journée de jeu. Alors qu'une équipe réfléchit en termes d'hôtes, de services et d'applications, le niveau de service vous demande de décomposer ces entités en parties requises.
Objectifs
Dans ce tutoriel, vous allez :
- requête New Relic pour déterminer votre base de référence
- Créer une base de niveau de service fondé sur une référence
Identifiez vos priorités
Si vous pensez généralement en termes d’hôtes, d’applications et de services, il peut être difficile de trouver vos priorités, et l’objectif de la planification de la capacité est de prioriser les bonnes choses. Nous vous recommandons d'évaluer la manière dont les clients interagissent avec votre application, puis d'identifier les fonctionnalités qui alimentent les points de contact de ces clients.
Voici un exemple de parcours utilisateur issu de notre site de démonstration New Relic Acme Telco Home :
Combien de capacités cet utilisateur touche-t-il ? Ils accèdent à une page de liste de produits, puis sélectionnent un produit. Une fois sur la page du produit, ils font défiler la page vers le bas, saisissent une quantité et ajoutent l'article à leur panier. Chacune de ces actions correspond à un niveau de service potentiel, qui peut être monitoré un jour de pointe.
Pour vous aider à identifier les capacités de votre propre application, nous avons quelques questions préliminaires que vous pourriez vous poser sur votre architecture :
- Quels parcours vos clients empruntent-ils le plus fréquemment ?
- Parmi ces voyages, lesquels impliquent des transactions d’achat ?
Une fois que vous avez identifié les capacités critiques pour l’entreprise, vous devez déterminer la couverture d’observabilité dont elles ont besoin. Où se situent les lacunes d’alerte dans ces parcours ? Ont-ils encore besoin d’être monitorés ?
En répondant à ces questions, vous pouvez créer un récit sur l’architecture de votre système qui s’appuie sur les besoins de l’entreprise. Les données collectées sur un appel d'API, une action de clic ou une transaction peuvent être transformées en un indicateur de santé de l'entreprise.
requête pour votre base de référence
Une fois que vous avez déterminé les priorités, l'étape suivante consiste à déterminer comment votre application se comporte au cours d'une journée ordinaire. Le comportement ordinaire de votre application est une base de référence, qui est une sorte d’attente. Vous pouvez le considérer comme une tasse de café le matin : vous avez une idée du goût de ce café, donc toute différence de goût peut indiquer un problème avec votre machine.
Extraire toutes les transactions populaires
Accédez à one.newrelic.com > Query Your Data, puis saisissez la requête suivante :
FROM Transaction SELECT count(*) FACET request.uri SINCE 1 week AGO
Cette requête extrait toutes les données sur les transactions de votre application, puis filtre pour inclure uniquement les transactions pour lesquelles une demande est adressée à votre application. À partir du tableau des request.uris, nous voyons que /js/controllers/ est un request.uri populaire. Nous allons travailler avec celui-ci.
Trouver la base de référence de latence et la base de référence de succès
En se concentrant sur /js/controllers/, mettez à jour la requête ci-dessus :
Supprimez le
FACETet concentrez la requête sur cet URI particulierRemplacez le total
count(*)parpercentile(duration, 95)FROM Transaction SELECT percentile(duration, 95) AS 'Latency Baselines', percentage(count(*), WHERE error is false) AS 'Success Baseline' SINCE 1 WEEK AGO WHERE request.URI LIKE '/js/services/%'
Cette requête nous indique que la transaction répond généralement en 42 ms et a un taux de réussite de 99,27 %. C’est notre base de référence de latence.
Créer une base de niveau de service fondé sur une référence
Maintenant que vous disposez d’une base de référence, vous pouvez créer un niveau de service significatif. Depuis la page Query Your Data , revenez à one.newrelic.com > APM & Services, puis cliquez sur Service levels situé sous Reports.
Lorsque vous ajoutez un nouveau niveau de service, New Relic remplit automatiquement une base de référence moyenne à partir de chaque source de données de votre application. Mais nous voulons donner la priorité à une base de référence spécifique pour une capacité spécifique.
Avec la base de référence que nous avons tirée de la section précédente, nous pouvons éditer la case WHERE . Ajoutez la chaîne suivante à la fin de la requête renseignée afin que la ligne soit la suivante :
entityGUID = 'YOUR_GUID' AND (transactionType = 'Web') AND request.uri LIKE `/js/services/%`
Après avoir mis à jour le champ WHERE , confirmez que votre durée dans le champ AND correspond au temps en millisecondes demandé à l'étape 2. Dans ce cas, la requête obtient une réponse en environ 42 (ms) et le champ AND correspond à 0,4 durée.
Affichez votre niveau de service dans l'interface utilisateur
Maintenant que vous avez créé un niveau de service basé sur une base de référence, vous pouvez désormais l'afficher dans l'interface utilisateur. Nous vous recommandons de créer une alerte pour ce niveau de service, dont vous pourrez évaluer la qualité dans la prochaine partie de la série de didacticiels.
