Audit SLO Dynatrace : des définitions que la redétection casse

Un contrôle sur les objectifs de niveau de service — si le sélecteur d’entités de chaque SLO correspond encore aux entités visées à l’origine.

Réserver un audit gratuit Les 71 contrôles

Ce que ces contrôles lisent

Validité des définitions de SLO

Chaque SLO, son sélecteur d’entités, et si ce sélecteur résout aujourd’hui vers les entités prévues.

Pourquoi c’est important

Un SLO s’écrit contre un sélecteur, et les sélecteurs s’écrivent contre des entités que la redétection peut remplacer. Quand un service est redétecté — après un changement de déploiement, une modification de règle de nommage ou une migration de plateforme —, le SLO ne renvoie pas d’erreur. Il mesure silencieusement un ensemble plus petit, ou vide, et affiche un budget d’erreur parfait.

Le contrôle résout chaque sélecteur de SLO et signale ceux qui ne correspondent à rien ou dont l’ensemble a fortement changé de taille. Un SLO qui affiche 100 % parce qu’il ne mesure rien est pire que pas de SLO du tout : quelqu’un s’en sert pour décider des mises en production.

Les questions qu’on nous pose sur ce domaine

Pourquoi un SLO cesse-t-il de correspondre à son service ?

Parce que l’identité de l’entité a changé. La redétection crée un nouvel id d’entité pour ce qu’un humain appellerait le même service, et le sélecteur — surtout s’il repose sur un id — continue de pointer vers l’ancien.

Faut-il plutôt des sélecteurs fondés sur les tags ?

En général, oui, et c’est dans le domaine Tagging que l’audit vérifie si la convention de tagging est assez cohérente pour le permettre. L’ordre compte : des sélecteurs fondés sur des tags incohérents échouent d’une manière plus difficile à repérer.

Les autres domaines d’audit

Dix-neuf domaines, 71 contrôles, une exécution en read-only. Chaque domaine a sa page.

FinOps Où part l’argent, et ce qui est récupérable Kubernetes Couverture des clusters, versions, échecs récurrents Alerting Si un incident atteindrait réellement un humain Audit log Qui a changé quoi, quand, et hors heures ouvrées Coverage Ce qui est surveillé, et ce qui en a seulement l’air RUM Portée du monitoring des utilisateurs réels et réglages de confidentialité Grail Buckets, retention, coût de stockage annualisé Pipelines Traitement à l’ingestion, masquage, règles de rejet Synthetic Moniteurs Synthetic qui passent, échouent ou ne tournent jamais Topology Qualité de la détection d’entités et explosion du nombre d’entités OpenTelemetry Sources OTel et double instrumentation Security Portées des tokens, expiration, identifiants dormants Workflows Automatisations qui échouent ou ne se déclenchent jamais Bizevents Hygiène des fournisseurs d’événements métier Dashboards Inventaire des dashboards Davis Taux d’attribution de cause racine OpenPipeline Résolution des routes et des pipelines SLO Définitions de SLO qui cassent à la redétection Tagging Convention de tagging des environnements

Voyez ce que ce domaine trouve sur votre propre tenant.

Une exécution en read-only couvre les dix-neuf domaines. Vous gardez le rapport dans tous les cas.

Réserver un audit gratuit Voir comment fonctionne AudiTrace

Découvrez ce que votre Obervability fait réellement.

Un audit prend une exécution. Les constats prennent une réunion. Ce que vous en faites vous appartient.

Experts Dynatrace certifiés

Envoyer

Obervability

Implémentation, services managés et support Dynatrace. Chaque constat arrive avec la source qui le sous-tend.

Services

Services AudiTrace Étude de cas

Guides

Audit Dynatrace Optimisation des coûts Dynatrace Étude de cas Articles

Nous joindre

Contact hello@obzervability.com

Confidentialité Conditions d’utilisation Accessibilité