Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'Apigee Edge.
Apigee expose des vérifications d'état à différents niveaux, que vous pouvez exploiter en fonction du cas d'utilisation.
- Vérification d'état d'instance Apigee / au niveau régional : renvoie l'état de l'instance Apigee globale dans une région.
- Vérifications d'état au niveau de l'environnement : renvoient l'état d'un environnement particulier dans l'instance Apigee.
- 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 healthyOù
$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 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 ReadyOù
$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 d'état n'est disponible que pour les versions 1.4 et ultérieures.