Development #23823
Fournir une API de vérification de bon fonctionnement
0%
Description
Histoire de ne pas devoir multiplier les vérifications dans Nagios, Hobo pourrait fournir un endpoint qui assurerait que tout va bien (ou listerait ce qui ne va pas).
- résolution de nom pour tous les services
- réponse positive de tous les services
- certificat valide et de confiance sur tous les services
- idées supplémentaires (?)
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Christophe Siraut il y a presque 6 ans
- Lié à Development #16599: cook : vérification des noms de domaine avant de lancer le déploiement ajouté
Mis à jour par Christophe Siraut il y a presque 6 ans
- Lié à Development #24519: Vérifier que l'adresse email mise en From existe bien ajouté
Mis à jour par Christophe Siraut il y a presque 6 ans
- Fichier 0001-provide-a-health-api.patch 0001-provide-a-health-api.patch ajouté
Une première version de travail ouverte aux commentaires.
ça sort un json structuré comme suit (le statut false est hérité par les parents):
{
"status": true,
"data": {
"services": {
"status": true,
"data": {
"Wcs": {
"status": true,
"data": {
"count": 0
}
},
"Passerelle": {
"status": true,
"data": {
"count": 0
}
},
"Combo": {
"status": true,
"data": {
"count": 2,
"foo": {
"status": true,
"data": {
"resolvable": {
"status": true,
"data": {}
},
"sucessfull": {
"status": true,
"data": {}
}
}
},
"bar": {
"status": true,
"data": {
"resolvable": {
"status": true,
"data": {}
},
"sucessfull": {
"status": true,
"data": {}
}
}
}
}
},
[…]
Mis à jour par Frédéric Péters il y a presque 6 ans
Ok sur l'approche du calcul à la volée; pour exposer l'API éventuellement considérer django rest framework pour l'API ? Même utilisé de façon minimale ça peut déjà amener un peu de cohérence et à un moment nous offrir des fonctionnalités gratuites.
(attention à l'orthographe de successful).
Peut-être prendre en compte is_operational() pour ne même rien tenter sur des services qui ne fonctionnent pas ?
Pour le is_successful par contre sûr se baser sur check_operational qui sait déjà ce qui est bon comme réponse http.
Mis à jour par Christophe Siraut il y a presque 6 ans
- Fichier 0001-add-dependency-on-djangorestframework.patch 0001-add-dependency-on-djangorestframework.patch ajouté
- Fichier 0002-provide-a-health-api-23823.patch 0002-provide-a-health-api-23823.patch ajouté
Nouvelle version de travail, basée sur rest framework.
Si c'était utile d'implémenter des pages ServiceView individuelles, on a pas vraiment d'identifiant unique parce que les objets viennent de tables différentes. En fait par rapport aux cas d'usages énnoncés, plusieurs peuvent utiliser directement les méthodes des modèles (tableau de bord utilisateurs, vérification pré-cook), d'autres (monitoring externe) peuvent parser le json fourni ici.
Mis à jour par Frédéric Péters il y a presque 6 ans
(les deux commits peuvent être réunis)
netloc = self.base_url.split('/')[2]
Utilise plutôt urlparse(self.base_url).netloc.
is_responsive
Toujours pas bien fan de ce nom (j'aurais suggéré is_operational mais c'est déjà pris; has_valid_http_response est long et s'éloigne de la forme is_, is_online peut-être).
Aussi, comme je le notais, il est important d'utiliser, ou au moins de faire comme, check_operational pour l'URL. (cas pratique, un combo déployé correctement a malgré tout une réponse 404 à l'accueil, c'est pour ça qu'on y teste plutôt /manage/).
20015-2018
Zéro en trop.
...# mock_socket.gethostbyname
L'intention est à mon sens bonne, c'est utile d'avoir les tests ok hors connexion.
Mis à jour par Christophe Siraut il y a presque 6 ans
- Fichier 0001-provide-a-health-api-23823.patch 0001-provide-a-health-api-23823.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Voici une version testable hors ligne, renommé l'url /api/service en /api/services, pour le code de retour HTTP j'ai mis pour l'instant "is_running()".
Je ne sais pas encore si le test sur le certificat est suffisant. Peut-être ajouter le nombre de jours restant, mais est-ce que c'est pertinent ici?
Dans un autre ticket on pourra ajouter des tests sur l'expéditeur des emails.
Si on veut présenter ces infos dans le backoffice, faudra faire un design, autre ticket.
Mis à jour par Christophe Siraut il y a plus de 5 ans
version revue.
pour le moment:
- la page api/services/ est accessible aux utilisateurs non-authentifiés
- pas de stockage du statut dans la db
Mis à jour par Christophe Siraut il y a plus de 5 ans
J'aimerais valider/intégrer ce patch avant d'aller éventuellement plus loin.
- les tests sont très rapides
- pas de stockage en db
- pas d'ACL
- utilisable facilement pour #16599
Pour des tests (un peu plus complexe) sur la durée de validité du certificat et le statut SPF des expéditeurs (tickets liés), j'anticipe la création d'un ServiceStatus qui serait ajourné par une tâche plannifiée, et étendrait l'api actuel.
Mis à jour par Christophe Siraut il y a plus de 5 ans
sur les tests pour l'environnement coverage-django18-authentic, j'ai l'erreur suivante:
authentic2.plugins.PluginError: ('unable to load entrypoint authentic2-auth-ssl = authentic2.auth2_auth.auth2_ssl:Plugin', VersionConflict(djangorestframework 3.8.2 (/tmp/tox-chris/hobo/coverage-django18-authentic/li
b/python2.7/site-packages), Requirement.parse('djangorestframework<3.4,>=3.3')))
c'est résolu si j'aligne la version de djangorestframework dans tox.ini avec celle définie dans le tox.ini de authentic (djangorestframework<3.4,>=3.3)
est-ce que c'est ce qu'on fait dans ce cas de figure?
Mis à jour par Frédéric Péters il y a plus de 5 ans
est-ce que c'est ce qu'on fait dans ce cas de figure?
J'aimerais dire qu'on fait plutôt un ticket dans authentic pour fonctionner avec les dernières versions de django-rest-framework et qu'un patch se trouve écrit, etc.
Mais bien sûr, oui, modifie le tox.ini pour limiter à une version acceptée par authentic.
Mis à jour par Frédéric Péters il y a plus de 5 ans
Quand ils étaient ok, garder les import dans un ordre qui fait plaisir à pylint (datetime/json/logging/socket/sys).
if sys.version_info[0] 2: éviter et préférer django.utils.six (from django.utils.six.moves.urllib import parse as urlparse)
logging.getLogger("urllib3").setLevel(logging.WARNING) sonne inapproprié à cet endroit, les modifcations au logging se font aujourd'hui dans debian/debian_config_common.py.
valid_statuses = [200, ] ça semble prévu pour être étendu mais il n'y a rien pour étendre, compare donc directement le statut, return bool(r.status_code 200).
# dans un init.py. Plutôt le laisser vide.
Mis à jour par Christophe Siraut il y a plus de 5 ans
Frédéric Péters a écrit :
#dans un init.py. Plutôt le laisser vide.
(je me trompais et pensais que les fichiers vides sont ignorés par git comme le sont les dossiers vides)
Mis à jour par Christophe Siraut il y a plus de 5 ans
J'ai renommé les ServiceBla en HealthBla et le résultat est servi sur /api/health/.
Mis à jour par Frédéric Péters il y a plus de 5 ans
logging.getLogger("urllib3").setLevel(logging.WARNING) sonne inapproprié à cet endroit, les modifcations au logging se font aujourd'hui dans debian/debian_config_common.py.
Ce que je voulais dire c'est que ça devait être fait comme les autres paramètres de logging, pas juste déplacer la ligne.
Mis à jour par Christophe Siraut il y a plus de 5 ans
le même patch sans le paramétrage de logging superflu (la valeur par défault INFO convient)
Mis à jour par Frédéric Péters il y a plus de 5 ans
pytest.mark.django_db plutôt que répéter ce décorateur je pense qu'il suffit de taper pytestmark = pytest.mark.django_db. Tu peux changer ça et hop.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Solution proposée à Résolu (à déployer)
J'ai fait cette modification, j'ai aussi remplacé l'utilisation du test client de django par django-webtest, ce qu'on devrait faire partout. Et relâcher un peu la pression sur la version de djangorestframework.
commit a6df6bdcd627b965c6c9123fad2296ef5d05a998
Author: Christophe Siraut <csiraut@entrouvert.com>
Date: Fri Sep 14 14:36:47 2018 +0200
general: provide a health api (#23823)
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
general: provide a health api (#23823)