La capacité de gérer et d'interroger efficacement de grandes quantités de données est l'une des capacités de base de New Relic. Nous mesurons la santé de la sortie des requêtes de la même manière que vous pourriez mesurer vos capacités orientées client : par la rapidité et l'absence d'erreur avec lesquelles les requests HTTP reçoivent des réponses. Nous appelons cela les performances de sortie, et vous pouvez mesurer les SLI pour suivre cela. Une fois que vous avez configuré un SLI de performances de sortie à l'aide de la procédure ci-dessous, vous pouvez suivre à la fois les temps de réponse et le taux d'erreur de vos applications.
Trouvez votre application
Tout d’abord, vous devez vous assurer que vous avez configuré l’application pour laquelle vous souhaitez créer le SLI. Si vous ne le trouvez pas ou si vous ne l'avez pas encore configuré, assurez-vous de procéder comme suit avant de continuer :
instrumentez vos applications principales avec les agents New Relic APM .
Nommez vos applications avec une convention de dénomination familière pour les rendre faciles à trouver.
Localisez votre application sur one.newrelic.com > All entities.
Sous All entities, recherchez votre application (type d’entité
Services - APM) et sélectionnez-la. Vous devriez voir l’écran d’aperçu ci-dessous, mais ne cliquez pas encore surService levels.
Identifiez les limites de votre service
Ensuite, vous voudrez vous assurer que vous mesurez le rendement de votre service. Bien que la dépendance d'une application joue un rôle dans le temps de réponse et les taux de réussite, vous pouvez mesurer le temps de réponse et les taux de réussite finaux et totaux au moment où la demande est reçue et à laquelle il est répondu.
Vous pouvez utiliser des cartes de service et des cartes automatiques pour vous aider à déterminer si l'application que vous regardez est une dépendance ou exécute l'API de point de terminaison.
Dans l'exemple de capture d'écran ci-dessous, vous pouvez voir toutes les applications qui prennent en charge le traitement des commandes. Nous commençons par sélectionner #2 (Order-Composer). Ensuite, nous cliquons sur Service maps et découvrons qu'Order-Composer est en réalité une dépendance. Vous devrez sélectionner #1 (Traitement des commandes) afin d'établir un véritable niveau de service de santé.
Conseil
Votre équipe peut uniquement être responsable de la dépendance Order-Composer . Si tel est le cas, votre propre niveau de service sur Order-Composer peut auto-monitorer les performances. Assurez-vous tag vos propres clients non confrontés au niveau de service comme customer-facing:false pour permettre un meilleur filtrage dans les rapports de santé. Envisagez également de travailler avec le point de terminaison orienté client (#1 Traitement des commandes) pendant l'observabilité pour créer de véritables performances de sortie, un niveau de service de connectivité d'entrée et un niveau de service client.
Créez votre base de référence
Lorsque vous créez un niveau de service, vous devez d'abord examiner les performances de sortie de votre application comme base de référence, que vous devez établir pour implémenter le niveau de service. La création d'une base de référence vous permet de mesurer les performances d'un service comme point de référence, puis d'utiliser les rapports de niveau de service pour savoir si vous atteignez ou non cette base de référence. Vous pouvez créer une base de référence pour presque n’importe quel ensemble de données ; cependant, vous utilisez différentes formules et recommandations dans différents cas d’utilisation.
Vous pouvez utiliser le temps de réponse (latence) et le pourcentage de non-erreurs (succès) comme base de référence de départ. Lorsque vous faites cela, vous créez une mesure de fiabilité et de santé.
Nous recommandons un historique d’une à deux semaines de données de performance pour établir une bonne base de référence. La saisonnalité et l'utilisation maximale ne devraient pas handicaper vos performances, et plus vous incluez d'historique dans votre mesure, plus vous êtes susceptible d'inclure une base de code différente de celle de sortie. Un déploiement antérieur, aussi petit soit-il, pourrait fausser vos résultats.
Voici un exemple de requête NRQL pour la cible recommandée d'un objectif de niveau de service de sept jours pour la latence :
FROM Transaction SELECT percentile(duration, 95) AS 'Latency Baseline SLI' WHERE appName='Order-Processing' SINCE 1 WEEK AGO
Pour une base de référence réussie (sans erreur), essayez la requête suivante. N'oubliez pas de remplacer Order-Processing par le nom de votre propre application.
FROM Transaction SELECT percentage(count(*), WHERE error is false) AS 'Success Baseline SLI' SINCE 1 WEEK AGO WHERE appName='Order-Processing'Créez votre niveau de service
Remarque : si vous ne voyez pas le bouton Add a service level , vérifiez auprès de votre administrateur New Relic vos autorisations.
Notre plateforme calcule automatiquement pour vous la base de référence et le navigateur recommandés. Recherchez les données APM de votre application que vous avez choisies à l'étape 2 et cliquez sur Service levels, et vous devriez voir la vue ci-dessous :
Cliquez sur Add baseline service level objectives pour créer à la fois votre SLI de latence et SLI de réussite, ainsi que leurs objectifs respectifs. Vous pouvez afficher et modifier tous les paramètres en cliquant sur l’icône représentant des points de suspension dans le coin supérieur droit de chaque dashboard SLO.
Conseil
Il faut environ 10 minutes pour que les données remplissent les scores SLO car nous utilisons le service événement-to-métriques pour la longévité des données et les performances des requêtes. Il faut un moment pour que la conversion ait lieu et commence à renseigner les données.