Doolta

mAPI-ng

Diagnostic d'incident explicable et falsifiable pour vos APIs Go : observabilité Go, ClickHouse, cause probable plutôt que mur de graphiques.

Détails du projet

Problème réelUn endpoint Go ralentit ou se met à échouer en production : quelle en est la cause la plus probable, et que vérifier en premier ? Les stacks classiques (OTel + Prometheus + Grafana) répondent par un mur de graphiques à interpréter soi-même, avec un coût d’installation et d’interprétation élevé.
ContraintesRester falsifiable : chaque cause proposée doit pouvoir être écartée par une preuve contraire, pour ne jamais inventer un diagnostic. Rester simple à instrumenter (pas de YAML, pas d’exploitation Prometheus/Grafana à maintenir). Rester efficace à forte volumétrie de requêtes sans exploser le volume de données transmises et stockées.
Choix structurantsAgrégation côté client en DDSketch avant envoi. Stockage de résumés compacts dans ClickHouse, avec roll-up en paliers 1 minute / 1 heure / 1 jour. Diagnostic classé sur 8 familles de causes (mémoire/GC, CPU, congestion des connexions, surcharge et timeouts, fuite de goroutines, aval et IO, localisé à une instance, régression de release), chacune accompagnée de sa preuve et d’une ligne « ce qui écarterait cette cause ». Confiance exprimée par palier (Haute/Moyenne/Basse), jamais en pourcentage.
Preuve aujourd'huiStack MIT complète (client, serveur, protocole) auto-hébergeable en une commande, et service hébergé public avec une instrumentation strictement identique. Une couche commerciale complète (facturation, invitations d’équipe, surface marketing) a été construite par composition au-dessus du cœur open source, sans le forker.
Offre associéeAudit Flash : le même principe de diagnostic fondé sur la preuve, appliqué à votre API en 3 à 5 jours.

Diagnostiquer plutôt qu’afficher

La plupart des stacks d’observabilité répondent à une panne par des graphiques : à vous d’interpréter. mAPI-ng répond à une question précise, en langage clair : pourquoi cet endpoint a-t-il ralenti, et qu’est-ce qui l’explique le plus probablement ?

Chaque cause diagnostiquée est accompagnée de la preuve qui la soutient et d’une ligne qui dit explicitement ce qui l’écarterait. Quand rien n’explique l’anomalie, le système l’affiche : « cause non attribuée », plutôt que d’inventer une explication rassurante mais fausse.

Une instrumentation minimale, une architecture pensée pour le volume

Côté client, un seul recorder, un seul middleware, une seule variable d’environnement suffisent : en son absence, l’instrumentation reste inerte et ne transmet rien, ce qui permet de fusionner le code d’instrumentation indépendamment de son activation.

Côté serveur, les métriques sont agrégées en process avant transmission (DDSketch), puis stockées sous forme de résumés compacts dans ClickHouse avec un roll-up en paliers. Ce choix réduit fortement ce qui est transmis, stocké et interrogé, comparé à une collecte d’événements bruts.

Du moteur open source au produit commercial complet

Le cœur (client, serveur, protocole) est un projet MIT, auto-hébergeable. Autour de ce cœur, une couche commerciale entière (facturation Stripe, invitations d’équipe, surface marketing, documentation intégrée) a été construite par composition, jamais par fork : chaque fonctionnalité reste optionnelle et le binaire dégrade proprement vers le comportement communautaire quand rien n’est configuré.

Ce projet démontre une capacité directement mobilisable en mission : concevoir une instrumentation légère, agréger efficacement les données, et transformer des métriques en diagnostic explicable et vérifiable plutôt qu’en mur de graphiques.