Serverless App Engine:Consulter les historiques de modification

Aperçu de la page

• Type d'enregistrement de publication : À partir de la liste déroulante située à côté de Number of Release Tasks, filtrez par type d'enregistrement de publication pour visualiser le nombre de publications réussies et échouées pour ce type.

• Temps consommé par les enregistrements de publication : Consultez le temps moyen et maximal consommé par les enregistrements de publication d'un même type.

• Cinq principales sous-étapes par temps consommé : Un enregistrement de publication se compose de plusieurs sous-étapes. Le système identifie les cinq sous-étapes qui prennent le plus de temps en moyenne pour chaque type d'enregistrement de publication. Pour plus d'informations sur chaque sous-étape, consultez la section Visualisation du temps consommé par les enregistrements de publication.

• Détails de l'enregistrement de publication : Dans la colonne Actions d'un enregistrement de publication, cliquez sur Change Details pour en afficher les détails. Pour connaître les sous-étapes de l'enregistrement de publication, reportez-vous à la section Visualisation du temps consommé par les enregistrements de publication.

Visualisation du temps consommé par les enregistrements de publication

Veuillez noter les points suivants :

• Les sous-étapes des enregistrements de publication sont divisées en deux catégories :

  • Platform : Les sous-étapes liées à la plateforme apparaissent en texte noir.

  • User : Les sous-étapes liées à l'utilisateur apparaissent en texte bleu.

• Analyse du temps consommé : Visualisez le temps consommé par chaque sous-étape à droite de son nom. Certaines sous-étapes s'exécutent simultanément.

• Lors de la création ou de la modification d'une application, si une erreur de configuration survient, un message d'erreur correspondant s'affiche pour la sous-étape concernée. Modifiez alors la configuration de l'application en conséquence et redéployez l'application.

• Pour une description détaillée des sous-étapes des enregistrements de publication, consultez le tableau suivant.

  Sous-étape	Catégorie	Description
  Build Image	Côté plateforme	Lorsque vous déployez une application à l'aide d'un package de code, le système construit une image à partir de votre package de code téléchargé et la pousse vers un référentiel d'images privé Alibaba Cloud. Remarque Le système crée et gère ce référentiel d'images automatiquement.
  Initialize Environment	Côté plateforme	Cette étape confirme l'espace de noms requis pour créer l'application SAE et garantit que les ressources de l'environnement sont prêtes.
  Create Or Update Deployment Configuration	Côté plateforme	Cette étape crée ou met à jour les configurations de base de l'application, telles que l'adresse de l'image, les spécifications des ressources et les politiques.
  Execute Deployment Steps	Côté plateforme	Cette étape lance la tâche de déploiement de l'application, qui comprend la configuration réseau et la pré-allocation des ressources.
  Release Instances	Côté plateforme	Cette étape crée des instances (pods). Elle inclut des étapes telles que l'ordonnancement des ressources, le montage des volumes, le démarrage des conteneurs d'initialisation, le tirage de l'image et le démarrage des conteneurs. S'il y a plusieurs instances, le système les crée indépendamment.
  Resource scheduling	Côté plateforme	L'ordonnanceur attribue les instances d'application (pods) à des nœuds de ressources spécifiques. Cela inclut les étapes suivantes : Le système attribue l'instance d'application à un nœud qui répond aux exigences de ressources de l'application en matière de CPU, de mémoire et de configuration réseau. Le système lie ensuite l'instance d'application au nœud de ressource. Une fois l'instance d'application liée avec succès au nœud de ressource, cette liaison achève le processus d'allocation et de configuration des ressources.
  Instance is being prepared	Côté plateforme	Le nœud de ressource réserve des ressources pour l'instance d'application et prépare son environnement d'exécution. Cela inclut des opérations côté plateforme telles que l'initialisation du réseau, l'initialisation du stockage et l'initialisation des conteneurs d'initialisation.
  An image starts to be pulled from a repository.	Côté plateforme	Le système tire l'image de l'application depuis le référentiel d'images privé. Déploiement avec une image : L'image de l'application est tirée en fonction de l'adresse de l'image. Déploiement avec un package de code : L'adresse de l'image est au format Image Source/Image Repository Name/Image Tag.
  An image is successfully pulled from a repository.	Côté plateforme	L'image de l'application a été tirée avec succès. Si le tirage échoue, un message d'erreur s'affiche.
  Container Created Successfully	Côté utilisateur	Le conteneur de l'application a été créé avec succès. Si la création échoue, un message d'erreur s'affiche.
  Container is Started	Côté utilisateur	Le processus du conteneur de l'application démarre avec succès. Si le démarrage échoue, un message d'erreur s'affiche.
  Instance Ready	Côté utilisateur	L'instance d'application passe le test de santé et est prête à traiter le trafic client.

Exemple d'échec du test de santé

Consultez le message d'erreur de deux manières.

• Méthode 1 :

  Consultez le message d'erreur dans la sous-étape de l'enregistrement de publication.

  Dans la chronologie des événements, l'événement Health check failed affiche le message d'erreur suivant : Liveness probe failed: Trying 127.0.0.1... check port 30000 failed, reason: failed: dial tcp 127.0.0.1:30000: connect: connection refused. Cela indique que la sonde de vivacité du conteneur a échoué car la connexion au port 30000 a été refusée. Cet événement apparaît entre les événements Container Running (Succeeded) et Instance Ready (Succeeded).

• Méthode 2 :

  Consultez le message d'erreur dans Application Events.

  Dans Application Events, un événement Unhealthy de niveau Warning apparaît avec le message d'erreur suivant : Liveness probe failed: Trying 127.0.0.1... check port 30000 failed

Exemple de gestion des erreurs

L'instance ne parvient pas à démarrer en raison d'un échec de la sonde de vivacité.

• Possible causes

  • Le port est incorrectement configuré pour le test de santé.

  • La configuration réseau est incorrecte.

• Solution

  • Identifiez le port de l'instance d'application et confirmez que le port est correctement configuré pour le test de santé.

  • Confirmez que la configuration réseau est correcte.