Effectuer des vérifications d'état

Cette page s'applique à Apigee et à Apigee hybrid.

Consulter Apigee Edge documentation.

Apigee est compatible avec deux approches de vérification de l'état. Celle qui vous convient dépend de la manière dont le trafic client atteint Apigee.

  • Vérification d'vérification de l'état : pour les architectures qui acheminent le trafic client vers Apigee via un Google Cloud équilibreur de charge soutenu par un groupe d'instances géré (MIG). L'équilibreur de charge (ou votre client) interroge activement l'un des points de terminaison /healthz/* pour déterminer l'état de l'instance / de l'environnement, et l'équilibreur de charge bascule entre les régions. Si votre architecture utilise des MIG, continuez à utiliser la vérification de l'état active.
  • Vérification d'vérification de l'état PSC : pour les architectures qui acheminent le trafic client vers Apigee via Private Service Connect (PSC). Apigee surveille les instances régionales pour vous et met automatiquement à jour l'état de fonctionnement par région. Aucune sonde initiée par le client ou l'équilibreur de charge n'est requise. Si votre architecture utilise PSC, activez la vérification de l'état PSC.

Sélectionnez un onglet pour en savoir plus.

Vérification de l'état active

Apigee expose des vérifications d'état actives à différents niveaux, que vous pouvez exploiter en fonction du cas d'utilisation.

  1. Vérification d'vérification de l'état d'instance Apigee / au niveau régional : renvoie l'état de l'instance Apigee globale dans une région.
  2. Vérifications d'état au niveau de l'environnement : renvoient l'état d'un environnement particulier dans l'instance Apigee.
  3. Vérification d'état personnalisée via un proxy d'API : pour les cas d'utilisation complexes, vous pouvez configurer un proxy d'API dédié en tant que point de terminaison de vérification d'état personnalisée.

Effectuer une vérification d'état au niveau régional

Apigee propose une vérification d'état d'instance Apigee / au niveau régional, qui permet d'évaluer l'état de fonctionnement global de l'instance Apigee dans une région spécifique. Ce modèle de vérification d'état, largement utilisé par les équilibreurs de charge, détermine l'état de fonctionnement des instances Apigee et effectue des basculements régionaux. Vous pouvez effectuer une vérification d'état au niveau régional en structurant la requête comme suit :

  • Chemin de la vérification d'état : /healthz/ingress
  • Ajoutez un en-tête de requête : User-Agent: GoogleHC.
$ curl -H 'User-Agent: GoogleHC' https://$HOST/healthz/ingress
Apigee Ingress is healthy
 où $HOST représente le nom d'hôte défini dans le groupe d'environnements Apigee, diffusé par l'équilibreur de charge.

Effectuer une vérification de l'état au niveau de l'environnement

Apigee propose une vérification d'état au niveau de l'environnement, qui permet d'évaluer l'état d'un environnement spécifique diffusé par l'instance Apigee. Ce modèle de vérification d'état est préférable lorsque vous souhaitez effectuer des basculements régionaux en fonction de l'état de certains environnements critiques/sélectifs. Vous pouvez effectuer une vérification d'état au niveau de l'environnement en appelant n'importe quel proxy d'API valide dans un environnement, en structurant la requête comme suit :

  • Ajoutez /healthz/ au chemin d'accès de base du proxy.
  • Ajoutez un en-tête de requête : User-Agent: GoogleHC.

Supposons par exemple que /catalog est un chemin de base de proxy valide, déployé dans un environnement. Pour effectuer une vérification d'état, appelez le proxy comme suit : 

$ curl -H 'User-Agent: GoogleHC' https://$HOST/healthz/catalog
Server Ready
 où $HOST représente le nom d'hôte défini dans le groupe d'environnements Apigee, diffusé par l'équilibreur de charge.

Effectuer une vérification d'état personnalisée via un proxy d'API

Si vous souhaitez effectuer des validations supplémentaires, vous pouvez définir une logique de vérification d'état personnalisée dans un proxy d'API déployé dans un environnement. La vérification d'état classique peut par exemple échouer lorsque plusieurs environnements sont arrêtés. La vérification d'état peut également échouer en fonction de l'état cible ou de la latence.

Dans ce cas, vous pouvez effectuer la vérification d'état en passant un appel d'API standard vers ce proxy.

Supposons par exemple que vous souhaitiez vérifier l'état d'un environnement appelé prod. Déployez un proxy d'API dans cet environnement avec le chemin de base /healthcheck-prod. Pour vérifier l'état de l'environnement prod diffusé par l'instance Apigee, appelez le proxy comme suit : 

$ curl https://$HOST/healthcheck-prod
 où $HOST représente le nom d'hôte défini dans le groupe d'environnements Apigee, diffusé par l'équilibreur de charge.

Remarques sur l'utilisation

Pour les vérifications d'état au niveau régional et au niveau de l'environnement : si elles sont effectuées par les équilibreurs de charge Google Cloud, alors l'équilibreur de charge définit l'en-tête User-Agent approprié. Si votre propre client consomme ces appels d'API de vérification d'état, vous devez vous assurer que l'en-tête User-Agent approprié est défini.

Pour Apigee hybrid : la fonctionnalité de vérification de l'état n'est disponible que pour les versions 1.4 et ultérieures.

Vérification de l'état PSC

Apigee est compatible avec la vérification d'état avec Private Service Connect (PSC), ce qui permet un basculement interrégional automatique pour les déploiements multirégionaux. Si vous disposez de plusieurs instances Apigee dans plusieurs régions, vous pouvez activer les vérifications d'état PSC afin que le trafic bascule automatiquement vers une région opérationnelle lorsque l'instance Apigee de la région active n'est plus opérationnelle. Aucune requête de votre client ou de votre équilibreur de charge n'est requise pour déclencher la vérification. Google Cloud surveille l'instance en continu en votre nom et met automatiquement à jour l'état de fonctionnement.

La fonctionnalité de vérification de l'état PSC est configurée sur le backend Apigee. Vous n'avez pas besoin de déployer de ressources supplémentaires, d'écrire de code ni de modifier vos proxys d'API.

Prérequis

  • Vous disposez d'une organisation Apigee avec abonnement ou en paiement à l'usage.
  • Votre organisation comporte au moins deux instances Apigee, chacune dans une région différente Google Cloud .
  • Le trafic de vos clients atteint Apigee via Private Service Connect (PSC).
  • Chaque environnement, groupe d'environnements, proxy d'API, flux partagé et ressource sont déployés de manière identique sur toutes les instances Apigee qui participent au basculement. Les déploiements incohérents peuvent entraîner un comportement inattendu lorsque le trafic passe d'une région à une autre.

Comment l'activer

Vérification de l'état PSC est une fonctionnalité facultative gérée par Google. Pour demander l'activation de votre organisation, contactez votre équipe chargée du compte Apigee ou Apigee Support. Si cette fonctionnalité est activée, le basculement régional automatique est actif pour toutes les instances de votre organisation. Aucune configuration supplémentaire n'est requise.

Recommandations de test

Étant donné que la vérification de l'état PSC introduit un basculement régional immédiat et automatique qui affecte directement le routage du trafic, nous vous recommandons de tester la fonctionnalité dans un environnement Apigee hors production avant de l'activer pour votre organisation de production. Vérifiez que le basculement et la récupération se comportent comme prévu pour vos modèles de trafic d'API et que vos applications clientes gèrent la transition de manière transparente.

Pour simuler un scénario de basculement et valider votre configuration, contactez votre équipe chargée du compte Apigee ou l'assistance Apigee. L'équipe peut vous aider à induire des conditions de défaillance dans un environnement contrôlé afin que vous puissiez observer le comportement de basculement avant d'activer la fonctionnalité en production.

Fonctionnement du basculement

Lorsque la vérification de l'état PSC détermine que l'instance Apigee de votre région active n'est pas opérationnelle, le trafic client est immédiatement et automatiquement acheminé vers une instance Apigee opérationnelle dans une autre région. Lorsque l'instance non opérationnelle est rétablie, le trafic revient à la région d'origine. Le basculement et la récupération se produisent de manière transparente pour vos applications clientes.

Limites actuelles

  • Vérification de l'état PSC ne détecte actuellement que les pannes complètes de l'infrastructure régionale. Elle ne se déclenche pas en cas d'incidents où le trafic peut toujours circuler, même si le trafic est dégradé en termes de taux d'erreur ou de latence. Une vérification d'état plus large au niveau des composants est prévue pour une version ultérieure.

Vérifier l'état de fonctionnement dans Cloud Logging

Vous pouvez observer les événements d'état de fonctionnement par région pour vos instances Apigee dans Cloud Logging. Dans l'explorateur de journaux du Google Cloud projet qui héberge votre organisation Apigee, exécutez le filtre suivant : 

resource.type="compute.googleapis.com/NetworkEndpointGroupV2"

Pour en savoir plus, consultez Surveiller les journaux de vérification de l'état composite.

Pour chaque région, examinez le champ healthState dans les entrées de journal correspondantes. Une valeur de HEALTHY indique que l'instance Apigee de cette région est accessible et diffuse du trafic. Les autres valeurs indiquent que la vérification de l'état PSC n'achemine pas actuellement de trafic vers cette région.