Rechercher un contrôle d'intégrité

L'API de contrôle d'intégrité de la recherche est utilisée pour vérifier régulièrement le statut des conteneurs Commerce afin de s'assurer qu'ils sont dans un état sain.

Le contrôle d'intégrité de la recherche est un appel REST avec le nœud final suivant, avec le type de paramètre requis et un mode de paramètre facultatif :
/search/admin/resources/health/status?type=type&mode=modetype
où type est un environnement ou un conteneur. Le conteneur autorise un paramètre supplémentaire, mode=modetype où modetype est soit startup (valeur par défaut) soit liveness. La valeur par défaut du mode est startup, qui est le comportement actuel.

L'appel de contrôle d'intégrité va renvoyer 200 en cas de réussite et 500 en cas d'échec.

type=environment
Un contrôle d'intégrité est composé pour vérifier si plusieurs parties peuvent communiquer entre elles. Le résultat diffère légèrement selon le type de nœud qui est soumis à une commande ping :
  • Sur les serveurs maîtres, la base de données création et le serveur de transactions de création sont tous deux vérifiés.
  • Sur le répéteur, le processus recherche une base de données opérationnelle et des cœurs dans tous les subordonnés.
  • Dans les subordonnés, il recherche une base de données opérationnelle, un serveur de transactions opérationnel et des cœurs dans tous les subordonnés.
type=container
Il s'agit de tests de microservice exécutés à un intervalle défini pour s'assurer que chaque conteneur reste en bonne santé. Lorsqu'il est appelé sur le maître ou le répéteur, il vérifie que tous les noyaux locaux acceptent les requêtes de recherche et sont réactifs. S'il est exécuté sur le répéteur, il effectue la même vérification. En outre, si le mode est défini sur démarrage, il vérifiera que la réplication fonctionne avec des subordonnés.
mode=startup
Option PAR DEFAUT si le paramètre mode n'est pas défini. Lorsque le paramètre mode n'est pas appelé ou a la valeur startup, si le répéteur de recherche est arrêté (ou est temporairement indisponible), tous ses serveurs de recherche subordonnés sont également arrêtés.
  • Vérifiez que nous pouvons envoyer une demande à chacun de nos noyaux de recherche (en fonction des noyaux de recherche définis dans la table SRCHCONF/SRCHCONFEXT).
  • Si l'étape 1 aboutit, vérifiez les résultats de la réplication d'index.
  • Renvoyez un contrôle d'intégrité réussi si aucun contrôle n'a échoué, sinon renvoyez un contrôle d'intégrité ayant échoué.
mode=liveness
Si le paramètre mode a la valeur liveness, le contrôle d'intégrité renverra OK si les serveurs subordonnés Solr sont opérationnels, même si le répéteur de recherche n'est pas disponible.
  1. Vérifiez qu'il peut envoyer une demande à chacun de ses noyaux de recherche (en fonction des noyaux de recherche définis dans la table SRCHCONF/SRCHCONFEXT).
  2. Renvoyez un contrôle d'intégrité réussi si aucun contrôle n'a échoué, sinon renvoyez un contrôle d'intégrité ayant échoué.

Les deux appels suivants seront renvoyés avec le statut 500.

search/admin/resources/health/status?type=container 

search/admin/resources/health/status?type=container& mode=startup

Cet appel renverra le statut 200 si le répéteur est arrêté, mais que les serveurs subordonnés sont en cours.

search/admin/resources/health/status?type=container& mode=liveness