On m’a avec raison fait remarquer que les articles mi-sérieux mi-troll devenaient redondants, donc repartons sur un article un peu plus technique.

Appclacks est une solution SaaS de monitoring de type "blackbox", permettant d’exécuter des health checks sur vos services web (requêtes HTTP(s), TLS, DNS, TCP, vérification d’expiration de certificats…​).
Les health checks sont réalisés depuis plusieurs endroits dans le monde (2 actuellement, 3 prochainement).

J’essaye toujours de créer des produits dont moi même je serai utilisateur, souvent car je suis frustré par les solutions existantes. Construire un SaaS complet d’une qualité professionel en solo est aussi un bon challenge et me permet également d’expérimenter.

Appclacks a plusieurs avantages par rapport à la concurrence:

Tout n’est pas encore finalisé, le produit n’est pas totalement "prod ready" mais on en est pas loin. N’hésitez pas à tester en vous inscrivant à l’alpha (lien dispo en fin de page ici).

Mais comment faire tout ça de manière fiable quand on travaille sur le produit en mode "side project" ?

On voit qu’on a besoin ici de plusieurs choses:

J’utilise aujourd’hui exclusivement Scaleway (la partie Cloud) pour l’hébergement. Voici un schema d’architecture global:

Je vais maintenant expliquer l’architecture en détail.

Un défi était ensuite de configurer les différentes instances de Cabourotte exécutant les health checks des utilisateurs. J’avais un cahier des charges assez strict:

Voici la solution retenue.

Prober ID

Chaque instance de Cabourotte dans une région donnée (France par exemple) se voit attribuer un ID (un peu comme un statefulset Kubernetes): 0, 1, 2…​

L’API connait ensuite le nombre total d’instances de Cabourotte par région: 3 par exemple. Détail important: bien qu’utilisant des UUID comme clés primaires, chaque health check créé sur Appclacks se voit attribuer un autre ID aléatoire au format integer. C’est important pour la suite.

Si nous avons 1000 health checks à exécuter dans une région, nous voulons une répartition à peu près stable entre instances, proche de 333..

Cabourotte supporte déjà du service discovery, c’est ce qui permet de le faire tourner chez vous mais branché sur Appclacks. J’ai donc réutilisé ce système pour assigner les health checks aux instances de Cabourotte gérées par le SaaS.

Chaque instance est configurée pour récupérer via un endpoint API interne (path/credentials spécifiques) les probes à exécuter. Le endpoint est de type /probers/discovery?prober-id=1, on voit que le prober ID décrit précédemment est passé en paramètre.

Que fait donc l’API à partir de ça ? Une simple requête SQL similaire à "SELECT * FROM healthcheck WHERE random_id%<nombre_total_prober>=<prober_id> AND enabled=true":

Prenons un exemple avec 3 health checks ayant comme ID aléatoire 46, 190, 27. Si nous n’avons qu’une seule instance Cabourotte par région, voici ce que ça donne:

Si l’instance Cabourotte 0 demande à l’API donne moi mes health checks à exécuter, tous les health checks seront retournés. Normal, on a qu’une instance de Cabourotte qui tourne.

Voyons maintenant le comportement si nous avons deux instances de Cabourotte. On s’attend à ce que les health checks soient répartis entre ces instances. Rappelez vous du calcul effectué (WHERE random_id%<nombre_total_prober>=<prober_id>). Ici le nombre de total de prober est 2.

Ici, le prober 0 gèrera les health checks 46 et 190, le prober 1 le health check 27.

On voit que grâce au modulo chaque instance récupère seulement un sous ensemble de health checks à exécuter. Si un nouveau health check est créé, celui ci sera automatiquement démarré au prochain "refresh" du service discovery de l’instance Cabourotte correspondante.

Scale les probers est donc facile: il me suffit de rajouter des instances et de modifeir le nombre total d’instance dans l’API pour que les health checks se reconfigurent de manière équitable entre ces instances, et surtout la solution a le mérite d’être très simple.
Elle est sûrement améliorable notamment pour éviter un déplacement important de health checks en cas d’ajout d’une instance Cabourotte (consistent hashing) mais c’est vraiment de l’optimisation prématurée surtout vu ma volumétrie actuelle. Je n’ai également aucune idée de la scalabilité de faire du modulo directement dans postgreSQL mais j’ai le temps de voir venir.

Cabourotte pousse ensuite le résultat des health checks dans l’API, qui sont ensuites récupérables par les utilisateurs.

Comme dit en début d’article, une instance Prometheus peut directement scrape l’API d’Appclacks pour récupérer les métriques des health checks exécutés par le SaaS.

Il faut donc stocker ces métriques et les rendre récupérable.

Prometheus récupère directement les métriques de Cabourotte sur le endpoint /metrics des prober.

Lorsque les instances Prometheus des utilisateurs (ou quand appclacks healthcheck metrics get est exécuté) ciblent l’API d’Appclacks, cette dernière se contente de récupérer dans Prometheus les métriques de l’organisation les demandant.

Oui, une simple query Prom du type (sum by (name, name, le, zone, id) (healthcheck_duration_seconds_bucket{owner="%s"})) or (sum by (name, name, status, zone, id) (healthcheck_total{owner="%s"})), où owner est un label indiquant l’organisation envoyant la requête (déduite depuis le token d’authentification). Les données sont ensuites renvoyées au format texte de Prometheus en réponse.

Je n’ai aujourd’hui qu’une instance de Prometheus mais je prévois d’en mettre rapidement une deuxième, en actif/actif et avec un load balancing pas trop bête côté client, dans le but d’avoir une forte tolérance aux pannes sur ce composant.

Comme dit précédemment, tout part également en remote write dans Scaleway Cockpit (métriques systèmes et applicatives incluses).

Une des propriétés intéressantes lorsqu’on branche Cabourotte installé on premise au service discovery d’Appclacks est la possibilité de passer des labels pour sélectionner les health checks à récupérer (et donc à exécuter) par Cabourotte.

En effet, comme la majorité des ressources d’Appclacks, il est possible d’attacher à leurs créations des labels (de simples clés/valeurs). Elles sont stockées dans PostgreSQL au format jsonb (labels jsonb dans la table SQL).

Ici pas de magie malheureusement, pour l’instant je me contente d’itérer de manière un peu degueulasse dans le code pour ne retourner que les "match" pour des labels donnés.

J’utilise Dorik pour le site vitrine appclacks.com[appclacks.com]. Pour les pas doués du CSS comme moi c’est très bien et j’en suis content.

Monter tout ça était (et est toujours) bien fun, on verra où ça va dans les années à venir :)