SekYo a écrit :
Vous êtes en forme depuis quelques jours :D Question monitoring. On a un produit compose de 20-30 "micro" services dans un cluster k8s et qui utilisent en backend différents outils/DB, certains in cluster, d'autres des services AWS (RDS etc...). Nos services ont tous actuellement une "liveness" probe, qui globalement ne fait rien (mais vraiment rien), a part renvoyer 200. En gros ca teste que le serveur Spring/Flask/Node a pu démarrer correctement en gros, mais c'est a peu près tout. C'est notamment utilise par k8s pour déterminer si les pods sont en vie ou pas. On a une demande pour aller potentiellement plus loin (parce que le fait que Spring démarre est pas une garantie suffisante que le service fonctionne :o), mais sans créer des fakes data, je vois pas comment faire. Et sur des systèmes de clients en prod, je trouve ça un peu dégueu. Mais je vois pas de vraie alternative. Genre un endpoint qui va chercher en DB un post/user/whatever ton entité "XXX-Monitoring" qui serait crée au moment du déploiement. Ca valide les éventuelles connexions a la DB, que la DB en question est up, les éventuelles interactions avec d'autres systèmes (bien entendu on pourrait même imaginer des trucs plus complexes, genre créer puis supprimer une entité etc...) Mais on est plus très loin de tests end to end. Et encore une fois, sur des systèmes en prod, j'ai l'impression que c'est quand même pas super de polluer les DB avec des objets de tests. Mais je vois pas trop d'autres moyens d'offrir plus de vraies garanties que nos liveness probes actuelles. Des idées alternatives ? Ou ma réticence a polluer les DB de prod est injustifiée ?
|