Créer et modifier des SLI et des SLO

Le succès du service est le rapport entre le nombre de réponses réussies et le nombre total de requests. Il s'agit en fait d'un taux d'erreur, mais vous pouvez le filtrer, par exemple en supprimant erreurattendue.

Valid events fields

FROM Transaction
WHERE entityGuid = 'ENTITY_GUID'

Où ENTITY_GUID est le GUID du service.

Bad events fields

FROM TransactionError
WHERE entityGuid = 'ENTITY_GUID' AND error.expected != true

Où ENTITY_GUID est le GUID du service.

Un SLI de latence mesure la proportion de requests valides qui ont été traitées plus rapidement que le seuil établi comme une bonne expérience.

Afin de déterminer ce seuil de durée, vérifiez les performances du service au cours des dernières semaines et utilisez ce résultat comme base de référence réaliste et réalisable. Ensuite, vous pouvez itérer sur le seuil SLI et l’aligner sur une performance plus ambitieuse.

Pour sélectionner une valeur appropriée pour la condition de durée, une pratique courante consiste à sélectionner la durée du 95e percentile des réponses pour les 7 ou 15 derniers jours. Trouvez ce seuil de durée à l'aide du générateur de requêtes, et utilisez-le pour déterminer ce que vous considérez comme un bon événement pour votre SLI:

SELECT percentile(duration, 95) FROM Transaction 
WHERE entityGuid = 'ENTITY_GUID' SINCE 7 days ago LIMIT MAX

Valid events fields

FROM Transaction
WHERE entityGuid = 'ENTITY_GUID' AND transactionType = 'Web'

Où ENTITY_GUID est le GUID du service.

Good events fields

FROM Transaction
WHERE entityGuid = 'ENTITY_GUID' AND transactionType = 'Web' AND duration < DURATION

• Où ENTITY_GUID est le GUID du service.
• Où DURATION est le temps de réponse qui, selon vous, offre une bonne expérience à votre service client ou à votre utilisateur final, en secondes.

Le succès du service est le rapport entre le nombre de réponses réussies et le nombre total de requests. Il s'agit en fait d'un taux d'erreur, mais vous pouvez le filtrer, par exemple en supprimant erreurattendue.

Valid events fields

FROM Span
WHERE entity.guid = 'ENTITY_GUID' AND (span.kind IN ('server', 'consumer') 
OR kind IN ('server', 'consumer'))

Où ENTITY_GUID est le GUID du service.

Bad events fields

FROM Span
WHERE entity.guid = 'ENTITY_GUID' AND (span.kind IN ('server', 'consumer') 
OR kind IN ('server', 'consumer')) AND otel.status_code = 'ERROR'

Où ENTITY_GUID est le GUID du service.

Un SLI de latence mesure la proportion de requests valides qui ont été traitées plus rapidement que le seuil établi comme une bonne expérience.

Afin de déterminer ce seuil de durée, vérifiez les performances du service au cours des dernières semaines et utilisez ce résultat comme base de référence réaliste et réalisable. Ensuite, vous pouvez itérer sur le seuil SLI et l’aligner sur une performance plus ambitieuse.

Pour sélectionner une valeur appropriée pour la condition de durée, une pratique courante consiste à sélectionner la durée du 95e percentile des réponses pour les 7 ou 15 derniers jours. Trouvez ce seuil de durée à l'aide du générateur de requêtes, et utilisez-le pour déterminer ce que vous considérez comme un bon événement pour votre SLI:

SELECT percentile(duration.ms, 95) FROM Span 
WHERE entityGuid = 'ENTITY_GUID' AND (span.kind IN ('server', 'consumer') 
OR kind IN ('server', 'consumer')) SINCE 7 days ago LIMIT MAX

Valid events fields

FROM Span
WHERE entity.guid = 'ENTITY_GUID' AND (span.kind IN ('server', 'consumer') 
OR kind IN ('server', 'consumer'))

Où ENTITY_GUID est le GUID du service.

Good events fields

FROM Span
WHERE entity.guid = 'ENTITY_GUID' AND (span.kind IN ('server', 'consumer') 
OR kind IN ('server', 'consumer')) AND duration.ms < DURATION

• Où ENTITY_GUID est le GUID du service.
• Où DURATION est le temps de réponse qui, selon vous, offre une bonne expérience à votre service client ou à votre utilisateur final, en secondes.

Le succès du service est le rapport entre le nombre de réponses réussies et le nombre total de requests. Il s’agit en fait d’un taux d’erreur.

Valid data

FROM Metric
SELECT sum(getField(apm.service.transaction.duration, count))
WHERE appName = 'APP_NAME'

Où APP_NAME est le nom de l'application APM.

Bad events fields

FROM Metric
SELECT sum(getField(apm.service.error.count, count))
WHERE appName = 'APP_NAME' AND getField(`apm.service.error.count`, count) > 0

Où APP_NAME est le nom de l'application APM.

Imaginez qu'un bon événement soit rapporté par des métriques personnalisées. Le nombre d'événements valides pourrait être le même.

Valid data

FROM Metric
SELECT sum(getField(apm.service.transaction.duration, count))
WHERE appName = 'APP_NAME'

Où APP_NAME est le nom de l'application APM.

Et maintenant, nous utilisons les métriques personnalisées pour découvrir le bon événement.

Good data

FROM Metric
SELECT sum(getField(newrelic.timeslice.value, count))
WHERE appName = 'APP_NAME' AND metricTimesliceName = 'Custom/CrossClusterQuery/DataAvailability/status/success'

Où APP_NAME est le nom de l'application APM.

Il s'agit de la proportion de pages vues qui sont diffusées sans erreurs.

Valid events fields

FROM PageView
WHERE entityGuid = 'ENTITY_GUID'

Où ENTITY_GUID est le GUID de l'application du navigateur.

Bad events fields

FROM JavaScriptError
WHERE entityGuid = 'ENTITY_GUID' AND firstErrorInSession IS true

Où ENTITY_GUID est le GUID de l'application du navigateur.

Il s'agit de la proportion de pages vues valides où le plus grand élément de contenu visible dans la fenêtre d'affichage a été rendu plus rapidement que le seuil considéré comme correspondant à une bonne expérience.

Valid events fields

FROM PageViewTiming
WHERE entityGuid = 'ENTITY_GUID' AND largestContentfulPaint IS NOT NULL

Où ENTITY_GUID est le GUID de l'application du navigateur.

Good events fields

FROM PageViewTiming
WHERE entityGuid = 'ENTITY_GUID' AND largestContentfulPaint < 'LARGEST_CONTENTFUL_PAINT'

• Où ENTITY_GUID est le GUID de l'application du navigateur.

• Où LARGEST_CONTENTFUL_PAINT est la durée (en millisecondes) nécessaire pour rendre visible dans la fenêtre d'affichage l'élément de contenu le plus volumineux qui, selon vous, offre une bonne expérience à votre utilisateur final. Une norme fréquente est de 4000 ms.

  Pour déterminer un nombre réaliste à utiliser pour LARGEST_CONTENTFUL_PAINT dans votre environnement, une pratique courante consiste à sélectionner la durée du 95e percentile des réponses pour les 7 ou 15 derniers jours. Trouvez-le en utilisant le générateur de requêtes :

  SELECT percentile(largestContentfulPaint, 95) FROM PageViewTiming 
  WHERE entityGuid = 'ENTITY_GUID' SINCE 7 days ago LIMIT MAX

  Copier

Il s'agit de la proportion de pages vues où le temps entre la première interaction d'un utilisateur avec la page et le moment où le navigateur répond à cette interaction est inférieur à un certain seuil.

Valid events fields

FROM PageViewTiming
WHERE entityGuid = 'ENTITY_GUID' AND interactionToNextPaint IS NOT NULL

Où ENTITY_GUID est le GUID de l'application du navigateur.

Good events fields

FROM PageViewTiming
WHERE entityGuid = 'ENTITY_GUID' AND interactionToNextPaint < INTERACTION_TO_NEXT_PAINT

• Où ENTITY_GUID est le GUID de l'application du navigateur.

• Où INTERACTION_TO_NEXT_PAINT est le délai (en millisecondes) dans lequel le navigateur doit répondre pour offrir une bonne expérience à votre utilisateur final. Une norme fréquente est de 300 ms.

  Pour déterminer un nombre réaliste à utiliser pour INTERACTION_TO_NEXT_PAINT dans votre environnement, une pratique courante consiste à sélectionner la durée du 95e percentile des réponses pour les 7 ou 15 derniers jours. Trouvez-le en utilisant le générateur de requêtes :

  SELECT percentile(interactionToNextPaint, 95) FROM PageViewTiming 
  WHERE entityGuid = 'ENTITY_GUID' SINCE 7 days ago LIMIT MAX FACET deviceType

  Copier

Il s'agit de la proportion de pages vues avec un bon décalage de mise en page cumulé (CLS). Le CLS est décrit comme la somme totale de tous les scores de décalage de mise en page individuels pour chaque décalage de mise en page inattendu qui se produit pendant toute la durée de vie de la page. Un changement de disposition se produit chaque fois qu'un élément visible change de position d'une image rendue à la suivante.

Valid events fields

FROM PageViewTiming
WHERE entityGuid = 'ENTITY_GUID' AND cumulativeLayoutShift IS NOT NULL

Où ENTITY_GUID est le GUID de l'application du navigateur.

Si vous souhaitez créer des SLI distincts pour suivre séparément les CLS sur les ordinateurs de bureau et les appareils mobiles, ajoutez l'une de ces clauses à la fin du champ :

• AND deviceType = 'Mobile'
• AND deviceType = 'Desktop'

Good events fields

FROM PageViewTiming
WHERE entityGuid = 'ENTITY_GUID' AND cumulativeLayoutShift < CUMULATIVE_LAYOUT_SHIFT

• Où ENTITY_GUID est le GUID de l'application du navigateur.

• Où CUMULATIVE_LAYOUT_SHIFT est une valeur prédéfinie. Pour offrir une bonne expérience utilisateur, votre site doit s'efforcer d'avoir un score CLS de 0,1 ou moins. Un score CLS de 0,25 ou plus est considéré comme une mauvaise expérience utilisateur.

  Si vous avez décidé de créer des SLI distincts pour suivre les CLS sur les ordinateurs de bureau et les appareils mobiles séparément lorsque vous avez défini la requête d'événement valide, ajoutez cette clause à la fin du champ :

  • AND deviceType = 'Mobile'
  • AND deviceType = 'Desktop'

  Pour déterminer un nombre réaliste à sélectionner pour CUMULATIVE_LAYOUT_SHIFT dans votre environnement, une pratique courante consiste à sélectionner le 75e percentile des chargements de pages au cours des 7 ou 15 derniers jours, segmentés sur les appareils mobiles et de bureau. Trouvez-le en utilisant le générateur de requêtes :

  SELECT percentile(cumulativeLayoutShift, 95) FROM PageViewTiming 
  WHERE entityGuid = 'ENTITY_GUID' SINCE 7 days ago LIMIT MAX FACET deviceType

  Copier

Le succès est le rapport entre le nombre de contrôles synthétiques réussis et le nombre total de contrôles.

Valid events fields

FROM SyntheticCheck
WHERE entity.guid = 'ENTITY_GUID'

Où ENTITY_GUID est le GUID du contrôle Synthétique.

Good events fields

FROM SyntheticCheck
WHERE entity.guid = 'ENTITY_GUID' AND result='SUCCESS'

Où ENTITY_GUID est le GUID du contrôle Synthétique.

Afin de définir votre nouveau SLI, choisissez l'une de ces trois options :

• Entity data:Basez le SLI sur des données standards provenant de nos agents ou de votre propre événement personnalisé. C'est l'option la plus courante. Si tel est votre choix, sélectionnez l’entité (par exemple, le service APM) que vous souhaitez utiliser.
• Custom data:Vous pouvez également baser le SLI sur votre événement NRDB personnalisé ou sur des métriques dimensionnelles. Utilisez cette option lorsque vous ne pouvez pas relier les données de niveau de service à une entité spécifique ou lorsque vous souhaitez relier le niveau de service directement à une workload.
• Metric data:Basé sur les données provenant de Prometheus, OTel ou vos propres métriques dimensionnelles personnalisées.

Dans cette étape, vous allez configurer la requête SLI qui détermine quel événement est valide, bon ou mauvais.

Si vous associez le SLI à un service APM ou à une application de navigateur, New Relic suggérera un SLI typique et leur requête. Nous utiliserons les données les plus récentes comme base de référence pour vos objectifs de niveau de service, et vous pourrez modifier le SLI et le SLO par la suite.

Si vous utilisez un type d'entité différent, si vous souhaitez interroger des métriques dimensionnelles ou si vous souhaitez personnaliser les valeurs de base de référence fournies par New Relic, vous pouvez personnaliser le SLI selon vos besoins. Par instance, vous pouvez utiliser la clause WHERE pour filtrer les contrôles de santé. Vous pouvez également utiliser des types d'événements différents sur chaque requête ; dans ce cas, assurez-vous que chaque événement valide correspond uniquement à un ou plusieurs événements sur la bonne ou la mauvaise requête.

Le compte à partir duquel les données sont collectées correspond au compte de l’entité à laquelle le SLI fait référence. Veuillez consulter la section ci-dessus pour savoir ce qui se passe dans chaque champ.

Sur la droite, vous verrez la requête finale, et en bas, vous aurez un aperçu du nombre d'événements valides et bons/mauvais au cours des derniers jours.

Voici un exemple de taux de réussite basé sur un pourcentage pour une métrique dimensionnelle, convertissons-le en événement valide/bon pour SLI:

FROM Metric
SELECT percentage(sum(scrooge_do_expire_count), 
  WHERE status = 'success') AS 'Success Rate'
WHERE env = 'production' 
AND status != 'attempt'

Pour une requête valide, nous copierions simplement la clause extérieure WHERE :

FROM Metric
SELECT sum(scrooge_do_expire_count)
WHERE env = 'production'
AND status != 'attempt'

Alors que le bon événement serait la clause extérieure WHERE et la clause WHERE de la fonction de pourcentage :

FROM Metric
SELECT sum(scrooge_do_expire_count)
WHERE env = 'production'
AND status != 'attempt'
AND status = 'success'

Les quatre fonctions d’agrégation que nous prenons actuellement en charge sont count(), sum(), getField() et getCdfCount(). Count et sum sont disponibles pour tous les types d'événements, tandis que getField et getCdfCount ne sont disponibles que lors de la sélection à partir de Metric.

Utilisez la fonction count() avec les données d'événement pour compter le nombre d'événements valides/bons/mauvais.

La fonction sum() est utile si vous avez des compteurs pré-agrégés dans des données d'événement ou des métriques dimensionnelles. Il nécessite un paramètre : l'attribut à utiliser dans la somme.

Utilisez les fonctions getField() et getCdfCount() pour voir à quelle fréquence un attribut métrique de distribution est en dessous ou à un seuil. Les deux fonctions nécessitent un attribut et getCdfCount() nécessite également un seuil pour mesurer la valeur.

Exemple utilisant count():

FROM JavaScriptError
SELECT count(*)
WHERE entityGuid = 'ENTITY_GUID' AND firstErrorInSession IS true

Exemple utilisant sum():

FROM ServerlessSample
SELECT sum(provider.errors.Sum)
WHERE awsAccountId = 'XXX' AND provider LIKE 'LambdaFunction%'

Exemple utilisant getField() combiné avec getCdfCount():

FROM Metric
SELECT getField(`newrelic.goldenmetrics.synth.monitor.medianDurationS`, count) AS 'Valid'

FROM Metric
SELECT getCdfCount(`newrelic.goldenmetrics.synth.monitor.medianDurationS`, 0.5) AS 'Good'

Vous pouvez également utiliser des caractères génériques dans votre requête SLI , voici un exemple :

FROM ApiGatewaySample
SELECT sum(provider.cache%Count.Sum)
WHERE awsAccountId = 'XXX'

Dans cette étape, vous obtiendrez un aperçu de la valeur SLI et vous ajouterez un SLO pour ce SLI : sélectionnez simplement la durée de la fenêtre temporelle et le pourcentage cible. Le graphique de droite vous aidera à anticiper si l'objectif que vous vous fixez est réalisable ou s'il est souvent manqué.

Les SLO à fenêtre temporelle mobile sont pris en charge. Avec une fenêtre temporelle glissante, la conformité SLO prend en compte les N derniers jours. Chaque minute, les données les plus anciennes disparaissent du calcul actuel et de nouvelles données les remplacent.

Sélectionnez un nom court pour votre SLI qui vous aide à reconnaître ce qu'il mesure.

Nous vous recommandons d'ajouter une balise à votre SLI, afin de pouvoir l'utiliser ultérieurement pour rechercher, filtrer et regrouper des SLI sur l'interface utilisateur.

Vous pouvez définir n'importe quelle tag significative pour votre organisation. Une liste déroulante vous proposera des clés tag utiles telles que les suivantes :

• owner:L'équipe ou l'unité commerciale qui possède ce niveau de service et qui réagira lorsque l'objectif SLO n'est pas atteint.

• category:Un mot clé qui décrit ce que le SLI mesure, tel que latency. Si vous suivez le flux de niveau de service suggéré, New Relic remplira cette tag pour vous et vous pourrez la modifier ultérieurement.

• environment:L'environnement que le niveau de service mesure et qui a du sens pour votre cas d'utilisation.

• maturity:Utile pour communiquer à vos parties prenantes la stabilité du SLO. Nous vous recommandons d'utiliser des valeurs tag telles que test, commitment ou aspirational.

• user_journey et application: ces types de balises vous aident à regrouper les SLI qui s'appliquent à la même expérience utilisateur, qu'il s'agisse d'un parcours utilisateur complet ou simplement d'une application spécifique.

  De plus, la liste déroulante affiche également la balise d'entité associée, ce qui vous permet de les ajouter rapidement au SLI .

  

  Pour terminer, vous pouvez éventuellement ajouter une description pour ce niveau de service.