Un système observable fournit les outils pour accomplir les types de tâches suivants :
Journalisation des informations sur les événements survenant dans le système
Obtention des métriques sur la performance du système, à la fois à un moment donné et sur une période donnée
Suivi des requêtes circulant dans le système
Sensibilisation des opérateurs système à l’état du système
Prévision des performances futures du système
Découverte de la cause première des problèmes observés dans le système
Les solutions de télémétrie vous permettent de capturer des journaux, des métriques et des traces. Les solutions de surveillance améliorent les connaissances liées aux données de télémétrie en fournissant des tableaux de bord et en alertant les administrateurs lorsque le système fonctionne en dehors des seuils prédéfinis. Un système entièrement observable étend les solutions de télémétrie et de surveillance pour permettre la prévision et l’analyse des causes premières.
La prévision consiste à utiliser les informations dont vous disposez sur les performances passées et actuelles d’un système pour déterminer ses performances futures probables. La prévision peut vous aider à prendre des décisions concernant les changements apportés à votre système. Par exemple, si vous prévoyez une augmentation considérable du nombre de requêtes auprès des services de carte, vous pouvez décider d’ajouter une machine supplémentaire à votre site ArcGIS Server avant que les utilisateurs ne constatent une dégradation des performances dues à des contraintes de ressources.
L’observation des modèles ou des tendances dans les données de télémétrie peut vous aider à établir des prévisions. Ainsi, les modèles cycliques des métriques permettent de prévoir à quel moment ces métriques connaîtront des pics et des creux. De fortes tendances à la hausse ou à la baisse vous permettent de prévoir les valeurs futures en partant du principe que la tendance se poursuive.
L’analyse prédictive peut être réalisée par les administrateurs, mais des fonctionnalités d’intelligence artificielle (IA) de plus en plus sophistiquées laissent augurer un système capable de s’auto-analyser et de répondre de manière appropriée. Les agents IA disposant d’un accès à la télémétrie, de l’autorisation de modifier le système et d’un modèle d’entraînement robuste pour déterminer les actions appropriées peuvent être en mesure de maintenir un système stable avec une intervention humaine directe minimale. Comme pour tout type d’IA, faites preuve de prudence lorsque vous envisagez la mise en place d’un système de réponse automatisée afin de vous assurer qu’il est en phase avec vos priorités et valeurs.
Si votre système n’est pas intègre, vous devez connaître la cause première du problème afin de mettre en œuvre la solution appropriée. Par exemple, l’augmentation de la latence pour un service peut nécessiter une mise à niveau coûteuse de l’infrastructure, mais peut aussi être corrigée par une simple reconfiguration du service.
L’analyse des causes premières comporte six étapes :
Détectez le problème. Par exemple, votre solution de surveillance peut vous alerter sur le fait que le temps de réponse d’un service a dépassé le seuil prédéterminé. Pour des problèmes non anticipés par la solution de surveillance, vous pouvez plutôt recevoir des rapports d’utilisateurs indiquant que le système ne fonctionne pas comme prévu.
Évaluez le problème. Déterminez si le problème affecte un seul service ou s’il s’agit d’un problème systémique concernant plusieurs services. Des outils de surveillance tels que les tableaux de bord, les cartes de service et les contrôles d’intégrité sont utiles à ce stade pour déterminer l’ampleur du problème.
Étudiez le problème grâce aux données de télémétrie.
Les métriques permettent d’identifier des anomalies ou des violations de seuils, comme une hausse soudaine d’erreurs 500 ou une baisse du débit.
Recherchez des messages d’erreur ( error ), des traces de pile et des avertissements dans les journaux. La journalisation structurée permet de faire coïncider les entrées du journal avec des identifiants de requête spécifiques ou des horodatages, ce qui vous aide à affiner la recherche des messages de journal pertinents.
Les traces peuvent localiser les zones où les requêtes ont connu une latence ou une défaillance. Par exemple, une trace peut indiquer une requête lente dans la base de données ou un appel API ayant échoué.
Corrélez et contextualisez les données. Combinez des métriques, des journaux et des traces pour établir la chronologie des événements observés. Ainsi, il est possible qu’une requête lente dans une base de données apparaissant dans une trace se soit produite en même temps qu’un pic de la métrique d’utilisation du processeur sur la machine de base de données. Des outils tiers comme OpenTelemetry, Jaeger ou Datadog APM peuvent être utiles pour mettre en corrélation différentes sources de données.
Identifiez la cause première. Recherchez des changements dans votre système qui pourraient expliquer les corrélations que vous avez observées. Voici quelques exemples de cause première courants :
Déploiement récent ou modifications de la configuration
Épuisement des ressources, comme une fuite de mémoire
Échecs dans des dépendances externes, comme l’échec d’une réponse d’une API tierce
Problèmes de réseau, comme une modification des règles du pare-feu
Résolvez le problème. Apportez la mesure corrective appropriée en fonction de l’identification de la cause première. Par exemple, vous pourriez avoir besoin d’annuler une modification de configuration récente, de corriger le logiciel ou de faire évoluer vos services. La simple résolution du problème actuel ne suffit pas. Documentez le problème, votre analyse et la solution afin que d’autres utilisateurs puissent plus facilement traiter des problèmes similaires à l’avenir. Ajoutez des alertes, des tableaux de bord ou des tests automatisés pour empêcher la réapparition du problème.