La solution Universal Service Monitoring permet de découvrir les services qui utilisent des tags de conteneur populaires (tels que app, short_image ou kube_deployment) et de générer des entrées dans le Service Catalog pour ces services.
Dans Datadog, vous pouvez accéder à des métriques de requêtes, d’erreurs et de durée pour le trafic entrant et sortant de tous les services découverts avec Universal Service Monitoring. Ces métriques de santé des services peuvent ensuite être utilisées pour créer des alertes, suivre les déploiements et définir des Service Level Objectives (SLO) afin d’obtenir une visibilité étendue sur tous les services exécutés au sein de votre infrastructure.
Dans ce guide, vous verrez comment rechercher des métriques USM telles que universal.http.* afin de les utiliser dans vos monitors, SLO et dashboards.
Métriques USM et métriques APM
Nom de la métrique
Unités
Type
Description
universal.http.client
Secondes
Distribution
Latence, nombre, erreurs et taux des requêtes sortantes.
universal.http.client.hits
Hits
Count
Nombre total de requêtes sortantes et d’erreurs.
universal.http.client.apdex
Score
Gauge
Score Apdex des requêtes sortantes pour ce service.
universal.http.server
Secondes
Distribution
Latence, nombre, erreurs et taux des requêtes entrantes.
universal.http.server.hits
Hits
Count
Nombre total de requêtes entrantes et d’erreurs.
universal.http.server.apdex
Score
Gauge
Score Apdex de ce service Web.
Contrairement aux métriques APM, les erreurs sont disponibles via le tag error:true au lieu de prendre la forme d’une métrique séparée.
Remarque : les métriques .hits contiennent tous les tags de votre infrastructure et constituent donc la méthode recommandée pour obtenir le nombre de requêtes et d’erreurs. Vous pouvez également ajouter un deuxième tag primaire à toutes les métriques USM.
Syntaxe des métriques
La syntaxe de requête des métriques USM diffère de celle des métriques APM, qui utilise trace.*. Les métriques USM sont regroupées sous un même nom de métrique de distribution.
Par exemple :
APM
USM
trace.universal.http.client.hits{*}
count:universal.http.client{*}
trace.universal.http.client.errors
count:universal.http.client{error:true}
trace.universal.http.client.hits.by_http_status
count:universal.http.client{*} by http_status_family
pXX:trace.universal.http.client{*}
pXX:universal.http.client{*}
trace.universal.http.client.apdex{*}
universal.http.client.apdex{*}
Les mêmes traductions s’appliquent à l’opération universal.http.server, qui capture le trafic entrant. Pour en savoir plus sur les métriques de distribution, consultez la section Métriques basées sur DDSketch dans APM.
Utilisation
Accédez à APM > Service Catalog, filtrez les résultats en fonction du type de données de télémétrie Universal Service Monitoring, puis cliquez sur un service. L’onglet Performance affiche des graphiques représentant les hits, la latence, les requêtes, les erreurs, etc. pour le service sélectionné. Vous pouvez également accéder à ces métriques lors de la création d’un monitor ou d’un SLO, ou lorsque vous consultez un dashboard dans le Service Catalog.
Créer un monitor
Vous pouvez créer un monitor APM pour déclencher une alerte lorsqu’une métrique USM telle que universal.http.client dépasse un certain seuil ou affiche un comportement inattendu.
Accédez à Monitors > New Monitor et cliquez sur APM.
Sélectionnez APM Metrics et définissez le tag env d’un service ou d’une ressource, ainsi que tout autre tag primaire de votre choix. Sélectionnez le service ou la ressource à surveiller et définissez l’intervalle d’évaluation de la requête du monitor.
Sélectionnez Threshold Alert et choisissez une métrique USM, telle que Requests per Second, sur laquelle le monitor se déclenchera. Ensuite, indiquez si la valeur doit être above (supérieure) ou below (inférieure) aux seuils d’alerte et d’avertissement. Saisissez une valeur pour le seuil d’alerte, ainsi que pour le seuil d’avertissement si vous le souhaitez.
La section dédiée aux notifications contient un message prédéfini pour le monitor. Vous pouvez personnaliser le nom de l’alerte et le message, mais aussi définir les autorisations de ce monitor.
Vous pouvez créer un SLO pour chaque service afin de vous assurer que vous respectez les objectifs définis par les métriques USM et que la disponibilité du service s’améliore au fil du temps. Datadog vous conseille de créer vos SLO par programmation afin de couvrir un vaste nombre de services.
Sous la colonne SLOs, passez votre curseur sur un service et cliquez sur + Create Availability SLO ou + Create Latency SLO.
Vous pouvez également créer un SLO manuellement à partir de métriques USM :
Accédez à Service Management > SLOs et cliquez sur New SLO.
Sélectionnez Metric Based et créez deux requêtes dans la section Good events (numerator) :
Requête A : Saisissez une métrique USM telle que universal.http.server, filtrez en fonction d’un service spécifique en ajoutant les tags primaires service et env dans le champ from, et sélectionnez count dans le champ as.
Requête B : Saisissez une métrique USM telle que universal.http.server, filtrez en fonction d’un service spécifique en ajoutant les tags primaires service et env en plus du tag error:true dans le champ from, et sélectionnez count dans le champ as.
Cliquez sur + Add Formula et saisissez a-b.
Dans la section Total events (denominator), saisissez une métrique USM telle que universal.http.server, filtrez en fonction d’un service spécifique en ajoutant les tags primaires service et env dans le champ from, et sélectionnez count dans le champ as.
Cliquez sur + New Target pour créer un seuil cible avec les paramètres suivants :
Intervalle de temps de 7 Days, seuil cible de 95% et seuil d’avertissement de 99.5%. Datadog vous conseille de définir le même seuil cible pour tous les intervalles de temps.
Saisissez un nom et une description pour ce SLO. Définissez les tags primaires env et service en plus du tag team.
Le Service Catalog identifie les dashboards définis dans votre fichier de définition de service et les répertorie sur l’onglet Dashboards. Cliquez sur Manage Dashboards pour accéder à la définition de service et la modifier directement dans GitHub.
