Niveau de service de consommation

Après avoir créé votre ensemble de SLI et de SLO, New Relic commencera à générer des données SLI. Les premiers résultats prendront quelques minutes pour apparaître dans notre interface utilisateur.

Trouver et consulter le niveau de service

Vous avez plusieurs façons de trouver le niveau de service :

• Dans la barre de navigation supérieure, sous Service Levels dans le menu More (que vous pouvez personnaliser). Ici, vous pouvez filtrer les SLI par leur tag.
• Dans les aperçus de ces entités qui ont un SLI défini. Vous pouvez les trouver partout dans l’interface utilisateur. Par instance, cliquez sur une entité depuis la vue Navigateur de l'Explorateur.
• Dans les services APM , dans la section rapports.
• Dans tout workload qui contient le SLI ou l'entité associée au SLI, comme un service APMou une application de navigateur. Si vous souhaitez regrouper des SLI sous une certaine workload, assurez-vous d'ajouter le service APM ou l'application de navigateur à une workload existante ou d'en créer une nouvelle.

La liste des niveaux de service affiche un niveau de service par ligne, avec le nom du niveau de service, son entité associée, ainsi que la cible et la période du SLO.

Niveau de service du filtre

Si vous ajoutez une balise à votre niveau de service, utilisez la barre de filtre pour réduire le niveau de service que vous obtenez et les regrouper.

• Utilisez le filtrage pour masquer tout test ou niveau de service ambitieux auquel l'équipe ne s'est pas encore engagée.
• Utilisez le regroupement pour vous concentrer sur les niveaux de service liés à un propriétaire, une unité organisationnelle ou un flux d'utilisateurs spécifique.

Modes d'affichage de conformité SLO

En fonction de ce que vous souhaitez réaliser, utilisez l’un des modes d’affichage suivants pour vérifier la conformité SLO :

• Operational:Lorsque vous êtes responsable de l'exploitation d'un service, utilisez cette vue pour voir l'évolution de la conformité SLO et du budget d'erreur au cours des 2 dernières heures et des fenêtres glissantes de 1, 7 et 28 jours.
• Period over period:Pour les revues d'entreprise, les rétrospectives et les réunions de priorisation, utilisez cette vue pour comparer la conformité par semaine civile ou par mois.

Notez que les SLO basés sur les demandes sont déterminés à partir des SLI définis comme le rapport entre le nombre de bonnes réponses et le nombre total de requests. Cela signifie qu'un SLO basé sur les demandes est atteint lorsque ce ratio atteint ou dépasse l'objectif de la période de conformité du SLO.

De plus, les résultats de conformité SLO pour les fenêtres temporelles glissantes sont plus cohérents lorsqu’ils incluent des semaines complètes. Par conséquent, les périodes SLO n'incluent que des semaines complètes. De cette façon, le calcul inclut toujours le même nombre de week-ends, et toute saisonnalité hebdomadaire n'a pas d'impact sur les résultats en fonction du jour de la semaine où vous regardez les SLO.

Afficher les SLO pour les opérations

La vue opérationnelle montre comment votre niveau de service s'améliore ou se dégrade dans différentes fenêtres temporelles.

• Si la cellule de conformité SLO a un fond vert, vous vous en sortez bien pour la période. Vous n'avez peut-être pas traité avec succès 100 % des requests, mais il vous reste encore une marge d'erreur à exploiter.
• Si la cellule de conformité SLO a un fond jaune, votre budget d'erreur est plus proche d'être totalement consommé et vous devez être plus prudent pour le reste de la période.
• Si la cellule de conformité SLO a un arrière-plan rouge, vous n'avez pas atteint le SLO cible au cours de cette période et vous avez consommé l'intégralité de votre budget d'erreur. Soyez prudent si vous devez déployer et prévoyez du travail pour améliorer vos SLI. Vous pouvez cliquer sur le SLO pour voir plus de données sur l'entité, telles que les métriques dorées, les derniers déploiements, les anomalies et les problèmes en cours. Ces données peuvent vous aider à comprendre quand et pourquoi vous avez manqué l’objectif SLO.

La fenêtre de 2 heures peut faire apparaître des incidents qui ont un impact rapide et significatif sur vos clients. Si ce SLO n'est pas respecté, lancez une enquête et assurez-vous que votre service ne continue pas à se dégrader. En revanche, des fenêtres temporelles plus longues peuvent faire apparaître des problèmes qui ne sont pas suffisamment graves pour violer la condition d’alerte et qui pourraient autrement passer inaperçus.

Vous obtiendrez également le budget d'erreur restant pour les 1, 7 et 28 derniers jours consécutifs pour vérifier la vitesse à laquelle vous récupérez ou consommez le budget d'erreur.

Afficher les SLO sur plusieurs périodes pour les revues d'activité

Utilisez la vue période par période pour générer des rapports lors des réunions d'évaluation qui ont lieu selon une certaine fréquence calendaire. La valeur ajoutée de cette vue est d'afficher un historique plus long de votre conformité SLO sur des fenêtres temporelles dans une période calendaire donnée.

• Vous pouvez changer la période entre les semaines et les mois.
• La couleur de la cellule fonctionne exactement comme décrit dans la vue des opérations.

Comprendre les détails du niveau de service

Cliquez sur n'importe quel SLI pour ouvrir les détails du SLI :

Utilisez les détails SLI pour deux objectifs principaux :

• Pour l'analyse SLO : voir dans quelles plages de temps les cibles SLO ont été manquées.
• Pour la configuration et le réglage précis de SLI/SLO : découvrez comment New Relic a calculé les valeurs SLO.

La carte SLI contient les graphiques suivants :

Bonnes et mauvaises réponses

Voici les concepts clés pour analyser le niveau de service:

• Une demande valide est toute demande que vous souhaitez considérer comme significative pour vos SLI.
• Une bonne réponse est toute réponse que vous considérez comme offrant une bonne expérience (par exemple, le service a répondu en moins de 2 secondes, offrant une bonne expérience de navigation à l'utilisateur final).
• Une mauvaise réponse est toute réponse que vous considérez comme offrant une mauvaise expérience (comme le service qui a répondu avec une erreur de serveur, interrompant le flux de l'utilisateur).

Ce graphique montre le nombre total de requests valides reçues par votre service, réparties en bonnes ou mauvaises.

Ce graphique montre le débit réel de votre service, que vous pouvez utiliser pour voir s'il existe une corrélation entre l'augmentation du débit et les mauvaises réponses.

Atteinte du SLI au fil du temps (%)

C'est la proportion de ce que vous considérez comme de bonnes réponses au fil du temps. La ligne devrait rester proche de 100 %, ce qui signifie que la plupart requests ont été traitées avec succès.

Conformité sur la période

Il s'agit du rapport entre les bons événements (réponses) et le total des événements (requests), mesuré sur la période de conformité du SLO. Plus le chiffre est proche de 100 %, plus votre service est proche d'atteindre l'objectif SLO sur la période. Lorsque ce pourcentage descend en dessous de l'objectif SLO, le graphique devient rouge : vous devez faire plus d'efforts en matière de fiabilité.

Budget d'erreur restant (requêtes)

Le budget d'erreur restant indique quel pourcentage de requests pourraient encore avoir une mauvaise réponse au cours de la période SLO sans compromettre l'objectif. Par conséquent, le nombre total de mauvaises réponses tolérées variera en fonction du débit des requests.

Le budget d’erreur est une manière alternative de lire le SLO. Il indique quel pourcentage de requests pourraient encore avoir une mauvaise réponse au cours de la période SLO, sans compromettre l'objectif.

Comme le nombre total de mauvaises réponses tolérées varie en fonction du débit des requêtes, New Relic affiche le pourcentage de marge d'erreur restante :

• Tant que le budget d'erreur restant est supérieur à 25 %, vous verrez du vert et votre SLO est bon.
• Lorsque le budget d'erreur descend en dessous de 25 %, il devient jaune. Cela signifie que vous êtes sur le point de brûler l’intégralité du budget de la période. Vous souhaiterez peut-être être plus prudent avec les nouveaux déploiements et modifications, et prévoir des travaux de fiabilité.
• Une fois le budget d’erreur entièrement épuisé, il s’affichera en rouge.

Atteinte SLI au fil du temps et objectif SLO (%)

Le dernier graphique montre deux séries chronologiques : l’ atteinteSLI au fil du temps et l’objectif SLO. Lorsque la valeur SLI est inférieure à la cible SLO, votre service n'atteint pas le SLO. Utilisez ce graphique pour savoir dans quelles plages horaires votre service a manqué l'objectif SLO.

Représentation graphique de l'atteinte SLI sur un dashboard

Vous pouvez représenter graphiquement les séries chronologiques d'atteinte SLI sur votre dashboard personnalisé à l'aide de la requête suivante :

FROM Metric SELECT clamp_max(
  (count(newrelic.sli.valid) - count(newrelic.sli.bad)) / 
  count(newrelic.sli.valid) * 100, 100) AS 'SLI attainment' 
WHERE sli.id = 'SLI_ID' 
UNTIL 2 MINUTES AGO TIMESERIES AUTO

Où sli.id est l'identifiant SLI. Le moyen le plus simple d'ajouter un graphique comme celui-ci à votre dashboard est d'utiliser l'option Add to dashboard, disponible sur la vue Details.

Alternativement, vous pouvez trouver l'identifiant SLI et la requête d'atteinte SLI via l'API Nerdgraph avec la requête suivante :

{
  actor {
    entity(guid: "{entityGuid}") {
      serviceLevel {
        indicators {
          name
          id
          resultQueries {
            indicator {
              nrql
            }
          }
        }
      }
    }
  }
}

Utilisez le entityGuid de l’entité associée au SLI. Dans les résultats de la requête, vous obtiendrez l'ID SLI dans le champ serviceLevel.indicators.id .

Diagnostiquer les violations de SLO

Pour vous aider à diagnostiquer les violations de SLO, vous pouvez :

Regroupez vos mauvais événements

Vous pouvez sélectionner un certain attribut (tel que le compte, l'identifiant client, la source de la demande, etc.) et détecter s'il endommage particulièrement le SLO. Nous appellerons ces valeurs dommageables des « détracteurs ».

Par exemple, pour les données de transaction , essayez d'utiliser la facette name pour voir si l'une des transactions du service renvoie plus de résultats infructueux que les autres. Pour savoir quel client obtient le plus grand nombre de résultats infructueux, essayez de faire un facettage par request.uri.

Un autre exemple, vous pouvez essayer de facetter l'événement PageViewTiming du navigateur, par deviceType, userAgentName, userAgentOS, countryCode, etc.

Lorsque vous détectez qu’un ou quelques détracteurs dégradent réellement la conformité SLO, vous pouvez prendre plusieurs mesures :

• Tout d’abord, résolvez le problème et planifiez les travaux pour que le détracteur respecte le SLO.
• Vous pouvez également ajuster temporairement la cible SLO à une valeur plus réaliste et planifier des travaux pour améliorer la fiabilité.

Mais si le détracteur est vraiment une exception qui ne répondra pas facilement aux attentes générales en matière de performances et de fiabilité de votre service, envisagez d'avoir un SLO dédié à ce cas. Nous vous recommandons les étapes suivantes :

• Tout d’abord, utilisez une clause WHERE sur la requête SLI d’origine pour filtrer le détracteur (par exemple, WHERE countryCode != 'US').
• Ensuite, créez un nouveau SLI avec une clause WHERE sur la requête qui ne prend en compte que le cas du détracteur (par exemple, WHERE countryCode = 'US') et définissez un objectif SLO plus réaliste pour celui-ci.

Limites

Il existe quelques exceptions où vous ne pouvez pas calculer la mauvaise requête d'événement :

• Pour les SLI configurés sur un bon événement où les types d'événements sont différents.
• Pour les SLI configurés sur un bon événement où le bon événement n'a pas de filtre.
• Pour les SLI configurés sur un bon événement qui utilisent à la fois SUM et COUNT.
• Pour les SLI configurés sur un bon événement qui utilise SUM avec un attribut différent.

Carte des relations

Grâce à la carte des relations, vous pouvez identifier quand et où un problème a commencé en visualisant les relations autour du niveau de service affecté.