Résoudre les problèmes liés aux flags de fonctionnalité

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Ce guide fournit des étapes pour diagnostiquer et résoudre les problèmes courants liés aux indicateurs de fonctionnalité App Lifecycle Manager.

Évaluation du SDK et de l'environnement d'exécution

L'API OpenFeature est conçue pour une sécurité maximale et ne générera jamais d'erreur entraînant le plantage de votre application.

Symptôme : le flag renvoie une valeur par défaut sécurisée

Si le service de signalisation est inaccessible, que le fournisseur n'est pas disponible ou que le signal est mal configuré, le SDK renvoie la valeur par défaut requise fournie dans votre code.

Solution :

1. Vérifiez la connexion entre votre fournisseur OpenFeature et le point de terminaison saasconfig.googleapis.com.
2. Vérifiez si des erreurs d'authentification se produisent. Assurez-vous que le compte de service dispose de roles/saasconfig.viewer.
3. Vérifiez que FLAGD_SOURCE_PROVIDER_ID est correct.

Symptôme : résultats d'évaluation inattendus

Si un indicateur ne renvoie pas la variante attendue :

Solution :

1. Vérifiez vos conditions CEL et le contexte d'évaluation.
2. Si un attribut requis est manquant dans le contexte lors d'une vérification de condition, le moteur d'évaluation ignore cette règle spécifique.
3. Si un attribut est manquant lors d'une allocation basée sur un pourcentage, l'évaluation renvoie INVALID_CONTEXT.

Surveiller les déploiements

Pour surveiller le déploiement d'un flag de fonctionnalité, vous devez vérifier l'état de l'orchestration (le déploiement est-il terminé ?) et l'état de l'application (le binaire a-t-il récupéré le flag de fonctionnalité ?).

État de l'orchestration du déploiement

Le système surveille le taux de réussite des opérations en temps réel.

Mise en veille automatique

Pour éviter qu'une configuration "défectueuse" n'atteigne l'ensemble de votre parc, le système met automatiquement en veille un déploiement si le taux d'échec dépasse le budget d'erreur (10 % par défaut et par emplacement).

Consulter les statistiques récapitulatives

Utilisez la commande describe pour afficher le nombre total d'échecs et déterminer si le déploiement est PAUSED ou FAILED.

gcloud beta app-lifecycle-manager rollouts describe ROLLOUT_ID --location=global

Filtrer les mises à jour d'unités ayant échoué

Une fois que vous avez confirmé l'existence de défaillances, vous devez identifier les unités spécifiques qui n'ont pas reçu la mise à jour. Utilisez ce filtre pour n'isoler que les mises à jour d'indicateurs ayant échoué dans une région spécifique :

gcloud beta app-lifecycle-manager unit-operations list \
    --location=LOCATION \
    --filter="state:UNIT_OPERATION_STATE_FAILED AND flag_update:*"

Diagnostiquer la cause racine

Pour chaque opération ayant échoué, vous pouvez récupérer un message d'erreur détaillé fourni par le moteur d'actionnement. Lisez le champ state_message.

gcloud beta app-lifecycle-manager unit-operations describe OPERATION_ID --location=LOCATION

Configurations manquantes pour l'unité

Comprendre l'épinglage d'unités

L'épinglage fige une unité à sa version actuelle, l'empêchant d'être mise à jour par des déploiements automatiques ou manuels. Une unité épinglée est explicitement exclue des opérations de déploiement jusqu'à l'expiration de sa période d'épinglage ou jusqu'à ce qu'elle soit désépinglée manuellement.

Configuration manquante dans les unités épinglées

Un scénario critique se produit lorsqu'une unité est épinglée lors du déploiement d'un flag de fonctionnalité. L'épinglage bloque toutes les mises à jour, ce qui signifie que l'appareil ignore l'opération FlagUpdate requise pour recevoir sa configuration.

Symptôme : Une fois l'unité détachée et mise à niveau vers un binaire nécessitant des indicateurs de fonctionnalité, l'application ne parvient pas à s'initialiser ou entre dans une boucle de nouvelle tentative infinie, ce qui entraîne l'échec des vérifications d'aptitude et le redémarrage continu des conteneurs.

Cause première : les default_flag_revisions de UnitKind n'ont pas été mis à jour lorsque l'unité était épinglée, ce qui a laissé l'unité sans configuration active.

Commandes de diagnostic

1. Lister les opérations de signalement ayant échoué

Pour trouver les unités qui n'ont pas été mises à jour, filtrez les opérations d'unité pour l'état UNIT_OPERATION_STATE_FAILED et le type flag_update.

gcloud beta app-lifecycle-manager unit-operations list \
    --location="LOCATION" \
    --filter="state:UNIT_OPERATION_STATE_FAILED AND flag_update:*"

2. Filtrer spécifiquement les déploiements de flags ayant échoué

Pour identifier précisément les mises à jour de flag ayant échoué dans votre parc ou pour une unité spécifique, ajoutez une condition pour l'état UNIT_OPERATION_STATE_FAILED.

# Find all failed operations for a specific unit
gcloud beta app-lifecycle-manager unit-operations list \
    --location="LOCATION" \
    --filter="unit:UNIT_ID AND state:UNIT_OPERATION_STATE_FAILED"

3. Examiner le motif de l'échec

Utilisez la commande describe pour lire state_message.

gcloud beta app-lifecycle-manager unit-operations describe "OPERATION_ID" --location="LOCATION"

4. Vérifier l'état de l'unité

Vous pouvez également vérifier directement l'état actuel d'une unité. Si le déploiement d'un indicateur échoue actuellement ou si la dernière opération a généré une erreur, l'état le reflétera. Conditions de type operationError.

gcloud beta app-lifecycle-manager units describe "UNIT_ID" --location="LOCATION"

Correction manuelle

Appliquer les révisions de flags par défaut UnitKind

Si une unité ne dispose pas de sa configuration, car elle a été épinglée lors d'un ou de plusieurs déploiements, vous pouvez la récupérer en réinitialisant manuellement l'unité sur la référence actuelle définie dans son UnitKind.

1. Détachez l'unité (si elle est épinglée).
2. Récupérez les révisions par défaut à partir de UnitKind parent.
3. Créez un FlagRelease contenant ces révisions.
4. Lancez manuellement une opération unitaire FlagUpdate pour appliquer la version de récupération.

# 1. Unpin
gcloud beta app-lifecycle-manager units update "UNIT_ID" \
    --location="LOCATION" \
    --maintenance-pinned-until-time=""

# 2. Retrieve default revisions
gcloud beta app-lifecycle-manager unit-kinds describe "UNIT_KIND_ID" \
    --location="global" \
    --format="value(defaultFlagRevisions)"

# 3. Create recovery release
gcloud beta app-lifecycle-manager flags releases create "recovery-release-1" \
    --location="global" \
    --unit-kind="UNIT_KIND_ID" \
    --revisions="REVISIONS"

# 4. Initiate manual update
gcloud beta app-lifecycle-manager unit-operations create "recovery-op" \
    --unit="UNIT_ID" \
    --flag-release="recovery-release-1" \
    --location="global"