Tutoriel NerdGraph : Configurer le niveau de service

Avec New Relic vous pouvez implémenter le niveau de service pour votre application, consommer facilement les résultats depuis l'UI lors de vos sessions de planification et de réponse aux incident , et itérer progressivement sur la configuration pour ajuster vos objectifs à l'expérience utilisateur souhaitée.

Outre l'UI, vous pouvez également utiliser notre explorateur API NerdGraph pour créer et modifier des SLI et leurs SLO. Alternativement, vous pouvez automatiser cette configuration à l'aide de la ressource de niveau de service Terraform.

Important

Afin de créer un niveau de service, un utilisateur nécessite une autorisation pour modifier et supprimer les règles événement-à-métriques.

Créer un SLI avec un SLO

Veuillez vous référer à Créer et modifier des SLI et des SLO pour découvrir les concepts de base de la configuration SLI et SLO, tels que l'entité à laquelle un SLI est associé. Vous pouvez également vous référer à cette documentation pour trouver des exemples des indicateurs les plus courants pour les services et l'application .

Voici un exemple d'appel NerdGraph qui crée un SLI à l'aide de la requête de mutation serviceLevelCreate :

mutation {
  serviceLevelCreate(
    entityGuid: "entityGuid"
    indicator: {
      name: "Latency below 0.25 seconds"
      description: "The proportion of valid requests that were served faster than 0.25s, which is considered to correspond to a good experience."
      events: {
        validEvents: { from: "Transaction", where: "entityGuid = 'entityGuid'" }
        goodEvents: {
          from: "Transaction"
          where: "entityGuid = 'entityGuid' and duration < 0.25"
        }
        accountId: accountId
      }
      objectives: {
        target: 99.5
        timeWindow: { rolling: { count: 7, unit: DAY } }
      }
    }
  ) {
    id
    description
  }
}

Il contient ces champs :

entityGuid: Le GUID de l'entité (par exemple, le service , l'application de navigateur, etc.) à laquelle vous souhaitez associer ce SLI. Sur l'UI, vous pouvez trouver ce GUID sur la page de l'entité, sous See metadata and manage tags.
description:Utilisez des descriptions détaillées, y compris le seuil sélectionné qui détermine le bon événement.
- Par exemple, pour un SLI de disponibilité, incluez quelque chose comme « La proportion de requests valides qui ont été traitées sans erreur ».
- Ou, pour un SLI de latence, incluez une description telle que « La proportion de requests valides qui ont été traitées plus rapidement que 0,25 s, ce qui est considéré comme correspondant à une bonne expérience ».
accountId: L'ID du compte auquel appartient le service ou l'application de navigateur, qui contient les données NRDB pour les calculs SLI/SLO.
badEvents.from, badEvents.where
- La requête NRQL qui définit un mauvais événement, SELECT count(*) FROM badEvents.from WHERE badEvents.where, nécessite ces clauses FROM et WHERE.
- Si vous avez défini un SLI à partir d'événements valides et incorrects, laissez l'objet goodEvents vide.
goodEvents.from, goodEvents.where
- La requête NRQL qui définit le bon événement, SELECT count(*) FROM goodEvents.from WHERE goodEvents.where, nécessite ces clauses FROM et WHERE.
- Si vous avez défini un SLI à partir d'un événement valide et correct, laissez l'objet badEvents vide.
validEvents.from, validEvents.where
- Ce sont les clauses FROM et WHERE pour la requête NRQL qui définit un événement valide, qui donnera SELECT count(*) FROM validEvents.from WHERE validEvents.where.
name:Un nom de catégorie court pour votre SLI pour vous aider à comprendre en quoi consiste le niveau de service. Nous suggérons d'inclure tous les paramètres et filtres spécifiques impliqués dans la définition SLI . Exemples :
- Disponibilité
- latence inférieure à 4 secondes
- CLS pour les ordinateurs de bureau inférieurs à 0,1
objectives:Un éventail d'objectifs (SLO) pour le SLI.
- target:L'objectif de votre SLO, jusqu'à 100,00. Le champ prend en charge jusqu'à 5 décimales.
  - Si vos utilisateurs sont satisfaits de l'expérience actuelle, définissez le pourcentage SLO pour qu'il corresponde à la base de référence actuelle. Par instance, le percentile utilisé pour déterminer le bon événement du SLI.
- timeWindow.rolling.count:La durée de la période prise en compte pour calculer le SLO. Les valeurs prises en charge sont 1, 7, 14, 28 et 30.
- timeWindow.rolling.unit: DAYest la valeur prise en charge.

En utilisant `SELECT`

Nous avons un attribut SELECT facultatif, défini sur count(*) par défaut. Si vous avez un scénario plus complexe, vous pouvez utiliser select pour être explicite sur la métrique ou la propriété d'événement que vous souhaitez interroger. Pour le SELECT la fonction SUM est également prise en charge, ainsi que le caractère générique (%). Voyons un exemple d’une configuration SELECT plus complexe.

mutation {
  serviceLevelCreate(
    entityGuid: "entityGuid"
    indicator: {
      name: "Success request"
      description: "The proportion of success requests count is 99% that the total count"
      events: {
        validEvents: {
          select: { function: SUM, attribute: "http.request.status.%.count" }
          from: "Metric"
        }
        goodEvents: {
          select: { function: SUM, attribute: "http.request.status.2%.count" }
          from: "Metric"
        }
        accountId: accountId
      }
      objectives: {
        target: 99.5
        timeWindow: { rolling: { count: 7, unit: DAY } }
      }
    }
  ) {
    id
    description
  }
}

Notez que les propriétés validEvents et goodEvents de events incluent désormais un select. Dans la sélection, vous pouvez configurer la fonction :

COUNT: fonction par défaut, comptera le nombre de résultats ;
SUM: additionne toutes les valeurs pour l'événement/métrique sélectionné.

Une autre différence importante dans cet exemple est l'utilisation du caractère générique (%) pour interroger les valeurs de toutes les métriques avec le même format. Imaginez que votre application signale le nombre de requêtes par statut (par exemple, http.request.status.200.count, http.request.status.201.count, http.request.status.400.count, etc.), la requête additionnera tous les noms de métriques correspondants à l'aide du caractère générique.

Récupérer la configuration d'un SLI pour un service APM

Utilisez cette requête pour récupérer la configuration d'un SLI, y compris son id.

{
  actor {
    entity(guid: "entityGuid") {
      guid
      name
      serviceLevel {
        indicators {
          createdAt
          createdBy {
            email
          }
          description
          entityGuid
          id
          name
          objectives {
            target
            timeWindow {
              rolling {
                count
                unit
              }
            }
          }
        }
      }
    }
  }
}

Mettre à jour les SLO d'un SLI

Utilisez la mutation serviceLevelUpdate pour définir un ou plusieurs SLO pour chacun des SLI. Pour obtenir les SLI id, utilisez la requête ci-dessus.

mutation {
  serviceLevelUpdate(
    id: "indicators.id"
    indicator: {
      objectives: {
        target: 99.00
        timeWindow: { rolling: { count: 7, unit: DAY } }
      }
    }
  ) {
    id
  }
}