Utiliser le service de configuration des applications pour Tanzu

Article
03/27/2024

Remarque

Azure Spring Apps est le nouveau nom du service Azure Spring Cloud. Bien que le service ait un nouveau nom, vous verrez l’ancien nom à divers endroits pendant un certain temps, car nous travaillons à mettre à jour les ressources telles que les captures d’écran, les vidéos et les diagrammes.

Cet article s’applique à :❌ De base/Standard ✔️ Entreprise

Cet article explique comment utiliser le service de configuration des applications pour VMware Tanzu avec le plan Azure Spring Apps Enterprise.

Le service de configuration des applications pour VMware Tanzu est l’un des composants commerciaux de VMware Tanzu. Il permet une gestion native Kubernetes des ressources ConfigMap qui sont renseignées avec les propriétés définies dans un ou plusieurs dépôts Git.

Le service de configuration des applications est l’emplacement central dans lequel vous pouvez gérer les propriétés externes des applications dans tous les environnements. Pour comprendre les différences par rapport à Spring Cloud Config Server dans les plans De base et Standard, consultez la section Utiliser le service de configuration des applications pour la configuration externe dans Migrer une instance du plan Azure Spring Apps De base ou Standard vers le plan Entreprise.

Le service de configuration d’application est proposé en deux versions : Gen1 et Gen2. La version Gen1 sert principalement aux clients existants à des fins de rétrocompatibilité et n'est prise en charge que jusqu'au 30 avril 2024. Les nouvelles instances de service doivent utiliser Gen2. La version Gen2 utilise le flux comme back-end pour communiquer avec les référentiels Git et offre de meilleures performances par rapport à Gen1.

Le tableau suivant présente les relations entre les sous-composants :

Génération du service de configuration des applications	Sous-composants
Première génération	`application-configuration-service`
Deuxième génération	`application-configuration-service` `flux-source-controller`

Le tableau suivant présente quelques données de référence à titre indicatif. Cependant, la taille du dépôt Git est un facteur clé qui a un impact significatif sur les données de performance. Nous vous recommandons de ne stocker que les fichiers de configuration nécessaires dans le dépôt Git afin qu'il reste petit.

Génération du service de configuration des applications	Durée d’actualisation de moins de 100 modèles	Durée d’actualisation de moins de 250 modèles	Durée d’actualisation de moins de 500 modèles
Première génération	330 s	840 s	1 500 s
Deuxième génération	13 s	100 s	378 s

Gen2 fournit également plus de vérifications de sécurité lorsque vous vous connectez à un dépôt Git distant. Gen2 exige une connexion sécurisée si vous utilisez HTTPS, et vérifie la clé et l'algorithme hôte corrects lorsque vous utilisez une connexion SSH.

Vous pouvez choisir la version du service de configuration d’application lorsque vous créez une instance de service Azure Spring Apps Enterprise. La version par défaut est Gen1. Vous pouvez également passer à Gen2 après la création de l'instance, mais la rétrogradation n'est pas prise en charge. La mise à jour ne nécessite aucune interruption de service, mais nous vous recommandons de la tester dans un environnement d'essai avant de la transférer dans un environnement de production.

Prérequis

Une instance du plan Azure Spring Apps Enterprise déjà approvisionnée, dans laquelle est activé le service de configuration des applications. Pour plus d’informations, consultez Démarrage rapide : Générer et déployer des applications sur Azure Spring Apps à l’aide du plan Enterprise.

Gestion des paramètres du service de configuration des applications

Le service de configuration des applications prend en charge Azure DevOps, GitHub, GitLab et Bitbucket pour le stockage de vos fichiers de configuration.

Pour gérer les paramètres du service, ouvrez la section Paramètres. Dans cette section, vous pouvez configurer les aspects clés suivants :

Génération : mettez à niveau la génération de service.
Intervalle d’actualisation : ajustez la fréquence à laquelle le service vérifie les mises à jour à partir des référentiels Git.
Référentiels : ajoutez de nouvelles entrées ou modifiez des entrées existantes. Cette fonction vous permet de contrôler les référentiels que les moniteurs de service utilisent pour extraire des données.

Si votre génération de service actuelle est Gen1, vous pouvez effectuer une mise à niveau vers Gen2 pour bénéficier de meilleures performances. Pour plus d’informations, consultez la section Mise à niveau de Gen1 vers Gen2.

L’intervalle d’actualisation spécifie la fréquence (en secondes) de vérification des mises à jour dans le référentiel. La valeur minimale est de 0, ce qui désactive l’actualisation automatique. Pour bénéficier de performances optimales, définissez cet intervalle sur une valeur minimale de 60 secondes.

Le tableau suivant décrit les propriétés de chaque entrée de référentiel :

Propriété	Requis ?	Description
`Name`	Oui	Nom unique pour étiqueter chaque dépôt Git.
`Patterns`	Oui	Modèles à rechercher dans les dépôts Git. Pour chaque motif, utilisez un format tel que {application} ou {application}/{profile} plutôt que {application}-{profile}.yml. Séparez les modèles par des virgules. Pour plus d’informations, consultez la section Modèle de cet article.
`URI`	Oui	Un URI Git (par exemple, `https://github.com/Azure-Samples/piggymetrics-config` ou `git@github.com:Azure-Samples/piggymetrics-config`)
`Label`	Oui	Nom de branche à rechercher dans le dépôt Git.
`Search path`	Non	Chemins de recherche facultatifs séparés par des virgules pour rechercher les sous-répertoires du dépôt Git.

Modèle

La configuration est tirée des back-ends Git en utilisant ce que vous définissez dans un modèle. Un modèle est une combinaison de {application}/{profil}, comme décrit dans les instructions suivantes.

{application} - Le nom d’une application dont vous récupérez la configuration. La valeur application est considérée comme l’application par défaut et comprend des informations de configuration partagées entre plusieurs applications. Toute autre valeur se rapporte à une application spécifique et inclut les propriétés de l’application spécifique ainsi que les propriétés partagées pour l’application par défaut.
{profile} - Facultatif. Nom d’un profil dont vous pouvez récupérer les propriétés. Une valeur vide, ou la valeur default, comprennent des propriétés qui sont partagées entre tous les profils. Les valeurs non définies par défaut incluent des propriétés pour le profil spécifié et des propriétés pour le profil par défaut.

Authentification

La capture d’écran suivante montre les trois types d’authentification de dépôt qui sont pris en charge par le service de configuration des applications.

La liste suivante décrit les trois types d’authentification :

Dépôt public.

Vous n’avez pas besoin d’une configuration supplémentaire de l’authentification lorsque vous utilisez un dépôt public. Sélectionnez Public dans le formulaire Authentification.

Le tableau suivant affiche la propriété configurable que vous pouvez utiliser pour configurer un dépôt Git public :

Propriété Requis ? Description

CA certificate Non Nécessaire uniquement lorsqu’un certificat auto-signé est utilisé pour l’URL du dépôt Git.

Propriété	Requis ?	Description
`CA certificate`	Non	Nécessaire uniquement lorsqu’un certificat auto-signé est utilisé pour l’URL du dépôt Git.

Dépôt privé avec authentification de base.

Le tableau suivant affiche les propriétés configurables que vous pouvez utiliser pour configurer un dépôt Git privé avec une authentification de base :

Propriété	Requis ?	Description
`username`	Oui	Nom d’utilisateur utilisé pour accéder au dépôt.
`password`	Oui	Mot de passe utilisé pour accéder au dépôt.
`CA certificate`	Non	Nécessaire uniquement lorsqu’un certificat auto-signé est utilisé pour l’URL du dépôt Git.

Dépôt privé avec authentification SSH.

Le tableau suivant affiche les propriétés configurables que vous pouvez utiliser pour configurer un dépôt Git privé avec SSH :

Propriété	Requis ?	Description
`Private key`	Oui	Clé privée qui identifie l’utilisateur Git. Les clés privées chiffrées à l’aide d’une phrase secrète ne sont pas prises en charge.
`Host key`	Non pour Gen1 Oui pour Gen2	Clé hôte du serveur Git. Si vous vous connectez au serveur via Git sur la ligne de commande, la clé d’hôte se trouve dans votre fichier .ssh/known_hosts. N’incluez pas le préfixe de l’algorithme, car il est spécifié dans `Host key algorithm`.
`Host key algorithm`	Non pour Gen1 Oui pour Gen2	Algorithme pour `hostKey` : `ssh-dss`, `ssh-rsa`, `ecdsa-sha2-nistp256`, `ecdsa-sha2-nistp384` ou `ecdsa-sha2-nistp521`. (Obligatoire si vous fournissez une `Host key`).
`Strict host key checking`	Non	Valeur facultative qui indique si le back-end doit être ignoré s’il rencontre une erreur lors de l’utilisation de la `Host key` fournie. Les valeurs valides sont `true` et `false`. La valeur par défaut est `true`.

Pour valider l’accès à l’URI cible, sélectionnez Valider. Une fois la validation terminée, sélectionnez Appliquer pour mettre à jour les paramètres de configuration.

Mettre à jour de Gen1 à Gen2

Le service de configuration d’application Gen2 offre de meilleures performances que Gen1, en particulier lorsque vous avez un grand nombre de fichiers de configuration. Nous vous recommandons l’utilisation de Gen2, d’autant plus que Gen1 sera bientôt mis hors service. La mise à jour de Gen1 à Gen2 ne nécessite aucune interruption de service, mais nous vous recommandons de la tester dans un environnement d'essai avant de la transférer dans un environnement de production.

Gen2 nécessite plus de propriétés de configuration que Gen1 lors de l’utilisation de l’authentification SSH. Vous devez mettre à jour les propriétés de configuration de votre application pour qu’elle fonctionne avec Gen2. Le tableau suivant présente les propriétés requises pour Gen2 lors de l’utilisation de l’authentification SSH :

Propriété	Description
`Host key`	Clé hôte du serveur Git. Si vous vous connectez au serveur via Git sur la ligne de commande, la clé d’hôte se trouve dans votre fichier .ssh/known_hosts. N’incluez pas le préfixe de l’algorithme, car il est spécifié dans `Host key algorithm`.
`Host key algorithm`	Algorithme pour `hostKey` : `ssh-dss`, `ssh-rsa`, `ecdsa-sha2-nistp256`, `ecdsa-sha2-nistp384` ou `ecdsa-sha2-nistp521`.

Procédez comme suit pour effectuer une mise à niveau de Gen1 à Gen2 :

Dans le Portail Microsoft Azure, accédez à la page Service de configuration d’application pour votre instance de service Azure Spring Apps.
Sélectionnez la section Paramètres, puis sélectionnez Gen2 dans le menu déroulant Génération.
Pour valider l’accès à l’URI cible, sélectionnez Valider. Une fois la validation terminée, sélectionnez Appliquer pour mettre à jour les paramètres de configuration.

Prise en charge polyglotte

Le service de configuration d’application fonctionne de manière transparence avec les applications Spring Boot. Les propriétés générées par le service sont importées en tant que configurations externes par Spring Boot et injectées dans les beans. Vous n’avez pas besoin d’écrire du code supplémentaire. Vous pouvez utiliser les valeurs à l’aide de l’annotation @Value, accessible via l’abstraction Environnement de Spring ou les lier à des objets structurés à l’aide de l’annotation @ConfigurationProperties.

Le service de configuration des applications prend également en charge les applications polyglottes telles que dotNET, Go, Python, etc. Pour accéder aux fichiers de configuration que vous spécifiez pour charger pendant le déploiement d’applications polyglotte dans les applications, essayez d’accéder à un chemin d’accès de fichier que vous pouvez récupérer via une variable d’environnement avec un nom tel que AZURE_SPRING_APPS_CONFIG_FILE_PATH. Vous pouvez accéder à tous vos fichiers de configuration sous ce chemin d'accès. Pour accéder aux valeurs des propriétés dans les fichiers de configuration, utilisez les bibliothèques de fichiers en lecture/écriture existantes pour votre application.

Actualiser les stratégies

Lorsque vous modifiez et validez vos configurations dans un référentiel Git, plusieurs étapes sont effectuées avant que ces modifications ne soient reflétées dans vos applications. Ce processus, bien qu’automatisé, implique les étapes et composants distincts suivants, chacun avec sa propre échéance et sa propre comportement :

Interrogation par le service de configuration d’application : le service de configuration d’application interroge régulièrement les référentiels Git principaux pour détecter toute modification. Cette interrogation se produit à une fréquence déterminée, définie par l’intervalle d’actualisation. Lorsqu’une modification est détectée, le service de configuration d’application met à jour la ConfigMap Kubernetes.
Mise à jour et interaction de ConfigMap avec le cache kubelet : dans Azure Spring Apps, ce ConfigMap est monté en tant que volume de données dans l’application appropriée. Toutefois, ce processus est naturellement retardé en raison de la fréquence à laquelle le kubelet actualise son cache pour reconnaître les modifications dans ConfigMap.
L’application lit la configuration mise à jour : votre application s’exécutant dans l’environnement Azure Spring Apps peut accéder aux valeurs de configuration mises à jour. Les beans existants dans le contexte Spring ne sont pas automatiquement actualisés pour utiliser les configurations mises à jour.

Ces étapes sont résumées dans le diagramme suivant :

Vous pouvez ajuster l’intervalle d’actualisation de l’interrogation du service de configuration d’application pour qu’il corresponde à vos besoins spécifiques. Pour appliquer les configurations mises à jour dans votre application, il est nécessaire de la redémarrer ou de l’actualiser.

Dans les applications Spring, les propriétés sont conservées ou référencées en tant que beans dans le contexte Spring. Pour charger de nouvelles configurations, envisagez d’utiliser les méthodes suivantes :

Redémarrez-la. Le redémarrage de l’application charge toujours la nouvelle configuration.
Appelez le point de terminaison /actuator/refresh qui est exposé sur le client de configuration via Spring Actuator.

Pour utiliser cette méthode, ajoutez la dépendance suivante au fichier pom.xml de votre client de configuration.
```
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
```
Vous pouvez également activer le point de terminaison Actuator en ajoutant la configuration suivante :
```
management.endpoints.web.exposure.include=refresh, bus-refresh, beans, env
```
Après avoir rechargé les sources de propriété en appelant le point de terminaison /actuator/refresh, les attributs liés à @Value dans les beans comportant l’annotation @RefreshScope sont actualisés.
```
@Service
@Getter @Setter
@RefreshScope
public class MyService {
   @Value
   private Boolean activated;
}
```
Utilisez curl avec le point de terminaison d’application pour actualiser la nouvelle configuration, comme illustré dans l’exemple suivant :
```
curl -X POST http://{app-endpoint}/actuator/refresh
```
Utilisez FileSystemWatcher pour surveiller les modifications apportées au fichier et actualiser le contexte à la demande. FileSystemWatcher est une classe fournie avec spring-boot-devtools qui surveille des répertoires spécifiques pour détecter les modifications de fichiers. Vous pouvez également utiliser un autre utilitaire avec une fonction similaire. La première option exige que les utilisateurs lancent activement l’actualisation, tandis que la dernière option peut surveiller les modifications de fichiers et appeler automatiquement l’actualisation lors de la détection des mises à jour. Vous pouvez récupérer le chemin d’accès du fichier à l’aide de la variable d’environnement AZURE_SPRING_APPS_CONFIG_FILE_PATH, comme indiqué dans la section Prise en charge polyglotte.

Configurer les paramètres du service de configuration des applications

Azure portal
Azure CLI

Pour configurer le service de configuration des applications, procédez comme suit :

Sélectionnez Service de configuration de l’application.
Sélectionnez Vue d’ensemble pour afficher l’état de l’exécution et les ressources qui sont allouées au service de configuration des applications.
Sélectionnez Paramètres et ajoutez une nouvelle entrée dans la section Dépôts avec les informations du back-end Git.
Pour valider l’accès à l’URI cible, sélectionnez Valider. Une fois la validation terminée, sélectionnez Appliquer pour mettre à jour les paramètres de configuration.

Pour configurer le service de configuration des applications, utilisez les commandes suivantes :

az spring application-configuration-service git repo add \
    --name <entry-name> \
    --patterns <patterns> \
    --uri <git-backend-uri> \
    --label <git-branch-name>

Configurer le certificat TLS pour accéder au backend Git avec un certificat auto-signé pour Gen2

Cette étape est facultative. Si vous utilisez un certificat auto-signé pour le backend Git, vous devez configurer le certificat TLS pour accéder au backend Git.

Vous devez d’abord charger le certificat dans Azure Spring Apps. Pour plus d'informations, consultez la certification Importer un certificats de Utiliser des certificats TLS/SSL dans votre application dans Azure Spring Apps.

Azure portal
Azure CLI

Procédez comme suit pour configurer le certificat TLS :

Accédez à votre ressource de service puis sélectionnez Service de configuration des applications.
Sélectionnez Paramètres et ajoutez ou mettez à jour une nouvelle entrée dans la section Dépôts avec les informations du back-end Git.

Utilisez la commande suivante pour configurer le certificat TLS :

az spring application-configuration-service git repo add \
    --name <entry-name> \
    --patterns <patterns> \
    --uri <git-backend-uri> \
    --label <git-branch-name> \
    --ca-cert-name <ca-certificate-name>

Utiliser le service de configuration des applications avec les applications

Lorsque vous utilisez le service de configuration d’application avec un back-end Git, vous devez lier l’application au service de configuration d’application.

Azure portal
Azure CLI

Suivez les étapes suivantes pour utiliser le service de configuration des applications avec des applications :

Ouvrez l’onglet Liaison d’application.
Sélectionnez Lier l’application et choisissez une application à partir du menu déroulant. Sélectionnez Appliquer pour établir la liaison.

Remarque

Lorsque vous modifiez l’état de liaison, vous devez redémarrer ou redéployer l’application pour que le changement prenne effet.
Dans le menu de navigation, sélectionnez Applications pour afficher la liste de toutes les applications.
Pour la colonne name, sélectionnez l’application cible pour laquelle configurer des modèles.
Dans le volet de navigation, sélectionnez Configuration puis Paramètres généraux.
Dans la liste déroulante Modèles de fichier config, choisissez un ou plusieurs modèles dans la liste. Pour plus d’informations, consultez la section Modèle.
Sélectionnez Enregistrer.

Utilisez la commande suivante pour utiliser le service de configuration des applications avec des applications :

az spring application-configuration-service bind --app <app-name>
az spring app deploy \
    --name <app-name> \
    --artifact-path <path-to-your-JAR-file> \
    --config-file-pattern <config-file-pattern>

Lier une application au service de configuration d’application

Vous pouvez maintenant choisir de lier votre application au service de configuration d’application lors de la création d'une nouvelle application.

Azure portal
Azure CLI

Pour créer une nouvelle application et la lier au service de configuration des applications, procédez comme suit :

Dans le volet de navigation, sélectionnez Applications pour afficher toutes vos applications.
Sélectionnez Créer une application pour créer une application.
Entrer un nom pour votre nouvelle application.
Sélectionnez l’onglet Lier puis sélectionnez Service de configuration des applications dans le menu déroulant.
Sélectionnez Créer pour terminer la création de votre application et la lier au service de configuration d’application.

Pour créer une nouvelle application et la lier au service de configuration des applications, utilisez la commande suivante :

az spring app create \ 
    --resource-group <resource-group> \ 
    --service <service-name> \ 
    --name <app-name> \ 
    --bind-application-configuration-service

Activer ou désactiver le service de configuration d’application après la création du service

Vous pouvez activer et désactiver le service de configuration d’application après la création du service à l'aide du Portail Microsoft Azure ou de l'interface de ligne de commande Azure. Avant de désactiver le service de configuration des applications, vous devez en dissocier toutes vos applications.

Azure portal
Azure CLI

Pour activer ou désactiver le service de configuration des applications, procédez comme suit :

Accédez à votre ressource de service puis sélectionnez Service de configuration des applications.
Sélectionnez Gérer.
Sélectionnez ou désélectionnez Activer le service de configuration d’application, puis sélectionnez Enregistrer.
Vous pouvez maintenant afficher l’état du service de configuration d’application dans la page Service de configuration d’application.

Pour activer ou désactiver le service de configuration des applications, utilisez les commandes suivantes :

az spring application-configuration-service create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-service-instance-name>

az spring application-configuration-service delete \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-service-instance-name>

Examiner le fichier config dans ConfigMap

La section suivante vous montre comment examiner le contenu du fichier config extrait par le service de configuration de l’application des dépôts Git en amont dans le ConfigMap Kubernetes associé. Pour plus d’informations, consultez la section Stratégies d’actualisation de cet article.

Affecter un rôle Azure

Tout d’abord, le rôle Azure Azure Spring Apps Application Configuration Service Config File Pattern Reader Role doit vous être attribué.

Azure portal
Azure CLI

Effectuez les étapes suivantes pour attribuer un rôle Azure :

Ouvrez le Portail Azure et accédez à votre instance de service Azure Spring Apps.
Dans le volet de navigation, sélectionnez Contrôle d’accès (IAM).
Dans la page Contrôle d’accès (IAM), sélectionnez Ajouter, puis Ajouter une attribution de rôle.
Dans la page Ajout de l’attribution de rôle, dans la liste Nom, recherchez et sélectionnez le rôle cible, puis sélectionnez Suivant.
Sélectionnez Membres, puis recherchez et sélectionnez votre nom d’utilisateur.
Sélectionnez Vérifier + attribuer.

Utilisez la commande suivante pour attribuer un rôle Azure :

az role assignment create \
    --role "Azure Spring Apps Application Configuration Service Config File Pattern Reader Role" \
    --scope "<service-instance-resource-id>" \
    --assignee "<your-identity>"

Examiner le fichier config avec Azure CLI

Utilisez la commande suivante pour afficher le contenu du fichier config par Modèle:

az spring application-configuration-service config show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --config-file-pattern <pattern>

Cette commande produit une sortie JSON semblable à celle de l’exemple suivant :

{
  "configurationFiles": {
    "application.properties": [
      "example.property.application.name: example-service",
      "example.property.cloud: Azure"
    ]
  }
}

Vous pouvez également utiliser cette commande avec le paramètre --export-path {/path/to/target/folder} pour exporter le fichier config vers le dossier spécifié. Elle prend en charge les chemins d’accès relatifs et les chemins d’accès absolus. Si vous ne spécifiez pas de chemin d’accès, la commande utilise celui du répertoire actif par défaut.

Examiner le fichier config dans l’application

Après avoir lié l’application au service de configuration de l’application et défini le Modèle pour le déploiement de l’application, comme décrit dans la section Utiliser le service de configuration de l’application avec des applications de cet article, le ConfigMap contenant le fichier config du modèle doit être monté sur le conteneur de l’application. Pour vérifier les fichiers config dans chaque instance du déploiement de l’application, effectuez les étapes suivantes :

Connectez-vous à l’une des instances d’application. Pour plus d’informations, consultez Se connecter à une instance d’application pour la résolution des problèmes.
Utilisez la commande echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH pour rechercher les dossiers contenant les fichiers config. Une liste d’emplacements séparés par des virgules s’affiche, comme illustré dans l’exemple suivant :
```
  $ echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH
  /etc/azure-spring-cloud/configmap/acs-default-payment-default-e9d46,/etc/azure-spring-cloud/configmap/acs-default-catalog-default-616f4
```
Vérifiez le contenu du fichier config à l’aide de commandes telles que cat.

Inspecter les journaux d’activité

Les sections suivantes vous expliquent comment consulter les journaux d'application à l'aide de l'interface de ligne de commande Azure ou du Portail Microsoft Azure.

Utiliser le streaming de journaux en temps réel

Vous pouvez diffuser en continu les journaux en temps réel avec Azure CLI. Pour plus d’informations, consultez Diffuser en continu les journaux des composants Azure Spring Apps en temps réel. Les exemples suivants montrent comment utiliser des commandes Azure CLI pour diffuser en continu de nouveaux journaux pour les sous-composants application-configuration-service et flux-source-controller.

Utilisez la commande suivante pour diffuser en continu des journaux pour application-configuration-service :

az spring component logs \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name application-configuration-service \
    --all-instances \
    --follow

Utilisez la commande suivante pour diffuser en continu des journaux pour flux-source-controller :

az spring component logs \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name flux-source-controller \
    --all-instances \
    --follow

Utiliser Log Analytics

Les sections suivantes vous expliquer comment activer et afficher les journaux système à l’aide de Log Analytics.

Paramètres de diagnostic pour Log Analytics

Vous devez activer les journaux système et envoyer les journaux à votre instance Log Analytics avant d'interroger les journaux du service de configuration des applications. Pour activer les journaux système dans le Portail Microsoft Azure, procédez comme suit :

Ouvrez votre instance Azure Spring Apps.
Dans le volet de navigation, sélectionnez Paramètres de diagnostic.
Sélectionnez Ajouter un paramètre de diagnostic ou Paramètre de modification pour un paramètre existant.
Dans la section Journaux, sélectionnez la catégorie Journaux système.
Dans la section Détails de la destination, sélectionnez Envoyer à l’espace de travail Log Analytics, puis votre espace de travail.
Sélectionnez Enregistrer pour mettre à jour le paramètre.

Vérifiez les journaux d’activité dans Log Analytics

Pour vérifier les journaux d’activité application-configuration-service et flux-source-controller à l’aide du Portail Microsoft Azure, procédez comme suit :

Veillez à activer les journaux système. Pour plus d’informations, consultez la section Paramètres de diagnostic de Log Analytics.
Ouvrez votre instance Azure Spring Apps.
Dans le menu de navigation, sélectionnez Journaux puis sélectionnez Vue d’ensemble.
Utilisez les exemples de requêtes suivants dans le volet d’édition des requêtes. Ajustez l’intervalle de temps, puis sélectionnez Exécuter pour rechercher les journaux.
- Pour visualiser les journaux pour application-configuration-service, utilisez la requête suivante :
```
AppPlatformSystemLogs
| where LogType in ("ApplicationConfigurationService")
| project TimeGenerated , ServiceName , LogType, Log , _ResourceId
| limit 100
```
- Pour visualiser les journaux pour flux-source-controller, utilisez la requête suivante :
```
AppPlatformSystemLogs
| where LogType in ("Flux")
| project TimeGenerated , ServiceName , LogType, Log , _ResourceId
| limit 100
```