Exercice - Définir l’état d’intégrité, les métriques et les seuils

  • 6 minutes

Dans cet exercice, nous poursuivons avec la structure du modèle d’intégrité que vous avez créée précédemment. Votre tâche consiste à quantifier les états d’intégrité des composants individuels de l’exemple d’application.

Dans la structure du modèle d’intégrité, commencez par évaluer les couches à partir du haut avec les flux utilisateur, puis passez aux couches inférieures.

État d’intégrité de flux utilisateur

Jusqu’à présent, nous avons identifié deux flux d’utilisateurs : Répertorier les éléments du catalogue et Ajouter un commentaire. Pour déterminer les états d’intégrité de chaque flux, posez des questions de type :

  • Quand le flux utilisateur est-il considéré comme étant sain ?
  • Peut-il fonctionner dans un état détérioré ?

En fonction des exigences fonctionnelles et d’implémentation, identifiez les composants d’application qui participent au flux utilisateur. Les composants sont décrits dans Exemple de composants d’architecture.

Flux utilisateur Composants
Répertorier les éléments du catalogue Application web interne de front-end, API du catalogue
Ajouter un commentaire Application web interne de front-end, API du catalogue, processeur en arrière-plan

Si l’un de ces composants n’est plus sain, le flux utilisateur n’est plus sain non plus.

Notes

Certaines applications peuvent fonctionner dans un mode détérioré spécial. Par exemple, si Contoso Shoes implémente la mise en cache locale du navigateur, les employés qui utilisent l’application web peuvent créer des commentaires, mais les commentaires ne peuvent pas être envoyés et la vue du client n’est pas mise à jour tant que l’API du catalogue n’est pas saine, ce que le navigateur peut vérifier en continu.

État d’intégrité du composant d’application

Déterminez les métriques qui contribuent à l’état d’intégrité du composant. Pour cette étape, vous devez connaître les fonctionnalités du composant. Posez des questions de type :

  • Quel est le temps de traitement acceptable dans l’API pour maintenir une bonne expérience utilisateur ?
  • Y a-t-il des erreurs attendues ? Quel est le taux d’erreur « normal » ?
  • Quel est le temps de traitement « normal » ? Qu’est-ce que cela signifie si le temps de traitement est supérieur à la normale ?
  • Que se passe-t-il pour les opérations d’écriture si Azure Cosmos DB est inaccessible ?

Ces questions doivent vous permettre de définir des seuils spécifiques et mesurables pour les métriques clés. Par exemple, vous pouvez utiliser ces valeurs de seuil pour le composant d’API du catalogue.

Métriques et seuil État d’intégrité
Temps de réponse < 150 ms Nombre de demandes ayant échoué < 10 Healthy
Temps de réponse < 300 ms Nombre de demandes ayant échoué < 50 Détérioré
Temps de réponse > 300 ms Nombre de demandes ayant échoué > 50 Unhealthy

Vous pouvez obtenir les valeurs avec une solution de monitoring d’application, comme Application Insights.

État d’intégrité d’une ressource Azure

Les états d’intégrité du service Azure sont basés sur des ressources spécifiques. Par exemple, Azure Cosmos DB signale l’utilisation des unités de transaction de base de données (DTU) et Azure App Services fournit des informations sur l’utilisation du processeur.

Pour plus d’informations sur les métriques par type de ressource, consultez Métriques prises en charge avec Azure Monitor.

États et seuils d’intégrité

Après avoir évalué toutes les couches de l’application, vous devriez avoir une liste des composants et de leurs définitions d’état d’intégrité qui ressemblent à cet exemple.

Composant Indicateur/métrique Healthy Détérioré Unhealthy
Flux utilisateur Lister les éléments du catalogue État d’intégrité sous-jacent Front-end sain et API du catalogue saine
Flux utilisateur Ajouter un commentaire État d’intégrité sous-jacent Front-end sain, API du catalogue saine et processeur en arrière-plan sain
Applications web de front-end Nombre de réponses HTTP non-20x/min 0 1-10 >= 10
API Catalogue Nombre d’exceptions/s <= 10 10-50 >= 10
Temps de traitement moyen (ms) < 150 150-500 > 500
Processeur en arrière-plan Temps moyen dans la file d’attente (ms) < 200 200-1 000 > 1 000
Temps de traitement moyen (ms) < 100 100-200 > 200
Nombre d’échecs < 3 3-10 >= 10
Azure Cosmos DB Utilisation des DTU < 70 % 70 %-90 % > 90 %
Azure Key Vault Nombre d’échecs < 3 3-10 >= 10
Hubs d'événements Azure Longueur du backlog de traitement (messages sortants/entrants) < 3 3-20 > 20
Stockage Blob Azure Latence moyenne (ms) < 100 100-200 > 200

Dans cet exemple, la tolérance d’erreur pour l’application web de front-end et l’API du catalogue est différente. Cette différence est liée à la compréhension technique de l’application. Toutes les erreurs de front-end doivent être gérées côté client, le seuil est donc de zéro. Toutefois, sur la couche d’API, 10 exceptions sont autorisées pour les erreurs causées par l’utilisateur. Par exemple, les erreurs comme 404 - Introuvable n’indiquent pas nécessairement un problème d’intégrité.