Découverte de l'observabilité et du suivi dans SAP BTP, exécution Cloud Foundry

Au fur et à mesure que l'application phare de votre entreprise gagne en traction et en pics de trafic utilisateur, des problèmes de performance et des erreurs inattendues commencent à faire surface. Pour maintenir une expérience utilisateur fluide et garantir la fiabilité du système, vous devez implémenter des stratégies robustes d'observabilité et de surveillance. Dans cette leçon, vous allez découvrir comment utiliser les outils de SAP BTP, exécution Cloud Foundry pour obtenir des informations approfondies sur les performances de votre application et résoudre rapidement les problèmes.

Observabilité et surveillance sont vos fenêtres dans les rouages intérieurs de vos logiciels et systèmes. L'observabilité vous permet de comprendre ce qui se passe dans vos applications et votre infrastructure en analysant les données qu'elles produisent. Pendant ce temps, le suivi exploite ces données d'observabilité pour contrôler activement et alerter sur le statut du système, garantissant ainsi que les performances restent optimales et que les problèmes sont rapidement résolus.

SAP BTP, exécution Cloud Foundry fournit les indicateurs d'observabilité suivants :

Les journaux dans Cloud Foundry proviennent de deux sources principales : vos applications et les composantes du système Cloud Foundry.

• Les journaux des applications fournissent des informations sur les opérations et les problèmes dans vos applications. Ils peuvent être définis par les développeurs en termes de contenu et de format. Pour en savoir plus, voir Journalisation de l'application dans Cloud Foundry.
• Les journaux système offrent un aperçu de la manière dont la plate-forme gère et interagit avec vos applications. Elles sont générées par les composantes internes de Cloud Foundry, telles que Cloud Controller, ou lorsqu'une demande à une application arrive au routeur de Cloud Foundry, le routeur journalise la demande. Ces journaux ne peuvent pas être désactivés.

Vous pouvez accéder aux journaux en temps réel à l'aide de la commande cf logs dans la CLI Cloud Foundry. Cette commande vous permet de faciliter la correction des erreurs et l'analyse en temps réel dans SAP BTP, Cloud Foundry.

Pour la conservation des données à long terme et l'analyse approfondie, le transfert des journaux vers des systèmes externes, tels que Splunk ou Elasticsearch, devient nécessaire. Vous pouvez configurer Syslog Drains pour acheminer de manière sélective des types de journaux spécifiques vers un serveur syslog pour un stockage centralisé.

Une fois que vos journaux se trouvent dans un système de stockage externe, vous pouvez utiliser différents outils de visualisation pour créer des tableaux de bord dynamiques et pertinents. Par exemple, Kibana est souvent employé avec Elasticsearch pour explorer les journaux de manière interactive.

Nous pouvons séparer les métriques dans les catégories Cloud Foundry : paramètres de conteneur et paramètres personnalisés, chacun répondant à des besoins de suivi distincts :

• Les métriques de conteneur révèlent comment vos applications utilisent les ressources affectées à leurs conteneurs, y compris l'utilisation du processeur, l'utilisation de la mémoire et l'espace disque. La cellule Diego respective, qui exécute votre application, collecte ces métriques toutes les 15 secondes environ et les transfère à Loggregator pour agrégation. Par défaut, les métriques de conteneur sont stockées temporairement dans le cache de journal pour une récupération rapide et sont accessibles à l'aide des commandes CLI Cloud Foundry, telles que cf logs <app-name>. Pour le stockage à long terme et l'analyse historique, les métriques sont généralement transmises à des systèmes externes tels que Prometheus. Vous pouvez transférer des métriques avec syslog-drains. Pour utiliser Prometheus avec un syslog-drain, vous avez besoin d'un middleware, qui se traduit d'un serveur syslog-à un point d'extrémité PromQL, tel que Telegraf. Pour en savoir plus, voir Métriques de conteneur.
• Les paramètres personnalisés sont définis par l'utilisateur, qui peuvent mesurer les taux de transaction, le nombre d'erreurs, les métriques d'engagement des utilisateurs ou toute autre donnée pertinente pour les performances et les objectifs commerciaux de votre application. Cela nécessite souvent une instrumentation dans votre code, soit par le biais de bibliothèques spécifiques à la langue (par exemple, expvar pour Golang), de systèmes de surveillance tiers (par exemple, Prometheus) ou de la bibliothèque Java de SAP. La plupart des bibliothèques de métriques permettent d'exposer les métriques via un point de terminaison HTTP. Vous pouvez également exécuter un agent dans le conteneur de l'application. Ces méthodes gèrent la collecte de métriques indépendamment de la logique d'application, offrant ainsi de la flexibilité dans la collecte et l'exportation de métriques personnalisées avec un minimum de modifications du code.

Les deux types de métriques sont généralement stockés directement dans des outils de surveillance tels que Prometheus, ce qui permet une analyse détaillée, des alertes et une intégration à d'autres systèmes. Pour la visualisation, Grafana est un choix populaire dans la communauté Cloud Foundry.

Dans Cloud Foundry, les événements d'audit fournissent des informations sur les interactions des ressources en documentant des actions telles que les déploiements d'applications, les liaisons de service, la gestion des utilisateurs, etc. Contrairement aux événements de sécurité, qui se concentrent sur l'accès et l'autorisation, ou les événements d'utilisation, qui sont axés sur la facturation, les événements d'audit offrent une vue plus granulaire des activités qui ont un impact sur les ressources, en enregistrant des détails tels que l'acteur (l'entité initiant l'action), la cible (la ressource affectée) et un horodatage.

Les événements d'audit sont générés par des applications et des composantes Cloud Foundry, puis capturés par Loggregator et transmis à différents points de terminaison pour l'accès et l'analyse.

Regardez la vidéo suivante pour découvrir comment suivre les événements pour des applications individuelles ou dans des espaces entiers.

N'oubliez pas : comme SAP BTP conserve les événements Cloud Foundry pendant 14 jours, vous devez transférer ces données à une solution de stockage externe pour une persistance à long terme et des analyses avancées.

Pour mieux comprendre les événements d'audit, consultez la documentation suivante : Présentation des événements d'audit

Les contrôles de fonctionnement sont des tests automatisés que Cloud Foundry effectue sur vos instances d'application en cours d'exécution pour déterminer leur statut, garantissant ainsi la fiabilité et la disponibilité. Cloud Foundry utilise le contrôle de disponibilité et de disponibilité, au service de fonctions distinctes :

• Les contrôles de disponibilité garantissent qu'une instance d'application est préparée pour traiter les demandes. Si un contrôle de l'état de préparation échoue, l'instance est temporairement supprimée de l'équilibreur de charge, ce qui l'empêche de recevoir du trafic jusqu'à ce qu'elle se stabilise. Cela est essentiel lors des mises à jour, des opérations de mise à l'échelle ou des durées de démarrage longues pour garantir des déploiements gracieux.
• Les contrôles de disponibilité vérifient qu'une instance d'application est active et en cours d'exécution. Si un contrôle d'activité échoue, l'instance est automatiquement relancée. Ce mécanisme d'auto-récupération permet d'atténuer efficacement les défaillances du système.

Il existe trois types de contrôles de fonctionnement :

• Contrôles de port (par défaut) : vérifiez si une connexion TCP peut être établie sur le port de l'application.
• Contrôles de processus : vérifiez si le processus principal de l'application est en cours d'exécution. Elle est utile pour les processus de travail ou les applications qui n'utilisent pas de ports standard.
• Contrôles HTTP (recommandé) : exécution d'une requête HTTP GET à un point d'extrémité indiqué et contrôle d'un code de statut 200. Il fournit un feedback plus précis pour les applications Web.

Le cycle de vie des contrôles de fonctionnement peut être résumé comme suit :

• Déploiement : les configurations Health Check sont définies dans le fichier manifeste de l'application (manifest.yml) ou via la CLI Cloud Foundry lors du déploiement. Pour plus de détails, consultez Configuration des contrôles de fonctionnement.
• Initialisation : Diego lance et planifie l'instance d'application avec les contrôles de fonctionnement indiqués.
• Démarrage : au démarrage, les contrôles de fonctionnement commencent immédiatement toutes les deux secondes. Cela se poursuit jusqu'à ce que l'application réussisse les contrôles ou qu'un délai d'expiration indiqué soit atteint (par défaut, 60 secondes, configurable jusqu'à 10 minutes sur SAP BTP, comme indiqué dans la directive Déploiement des applications volumineuses).
• Surveillance continue : une fois l'application lancée avec succès, des contrôles réguliers de disponibilité et de disponibilité sont effectués pour surveiller en continu son fonctionnement.
• Gestion des échecs : l'échec d'un contrôle de disponibilité entraîne un redémarrage de l'instance de l'application. L'échec d'un contrôle de l'état de préparation entraîne la suppression de l'instance du routage, bien qu'elle continue à s'exécuter pour une éventuelle restauration. Lorsque les contrôles de fonctionnement échouent, analysez vos journaux des applications à la recherche d'erreurs ou d'avertissements. Si vous utilisez un point de terminaison HTTP personnalisé, assurez-vous qu'il renvoie la bonne réponse. En outre, considérez les contraintes de ressources (mémoire, unité centrale) et la connectivité réseau comme des coupables potentiels. Finalement, si une instance échoue à plusieurs reprises aux contrôles de fonctionnement, Cloud Foundry abandonne sa relance et la marque comme en panne.

Pour en savoir plus sur les contrôles de fonctionnement, voir la documentation suivante : Contrôles de fonctionnement dans Cloud Foundry

SAP vous permet d'établir facilement des stratégies complètes d'observabilité et de monitorage pour les applications exécutées sur SAP BTP, exécution Cloud Foundry. Cela est possible grâce à une suite de services robustes, y compris SAP Cloud Logging, SAP Alert Notification et SAP Cloud Application Lifecycle Management (SAP Cloud ALM).

Cette leçon vous a fourni les connaissances nécessaires pour configurer et gérer l'observabilité et le monitorage dans SAP BTP, exécution Cloud Foundry. En comprenant et en appliquant ces outils, vous pouvez vous assurer que vos applications sont fiables, performantes et sécurisées.

Mission : Implémenter l'observabilité dans une application CAP full stack